When a customer pays an invoice, two things need to happen for your AR team to close it out: the money needs to arrive in your account, and you need to know which invoice it pays. In a well-structured process, these happen together — the payment arrives with a reference that points directly to the invoice. In a poorly structured process, they happen separately, and someone on your team has to spend time figuring out which payment covers which invoice.
The difference between those two outcomes comes down to how remittance information is attached to the payment at the moment it is initiated, and whether it survives intact through the banking chain to your booking notification.
Step 1: the invoice carries a structured reference
It starts on your side, when you issue the invoice. If you include a structured payment reference — either a QR reference on a QR-bill or an ISO creditor reference (ISO 11649) — you are encoding information about the invoice directly into the payment instruction the payer will use.
The QR-IBAN vs IBAN post covers which reference type to use in which scenario. The key point here is that the reference must be structured — a specific, defined data field — not a free-text note. Free-text payment descriptions get truncated, reformatted, or lost at various points in the banking chain. Structured references travel intact.
Step 2: the payer initiates the payment
When the payer pays your invoice, they enter the payment into their banking system. If they scanned the QR code from your QR-bill, the payment form is pre-filled automatically — including the exact 27-digit QR reference. If they are paying programmatically through their ERP, their system reads the reference from the incoming invoice XML and populates the payment file accordingly.
On the Swiss SEPA-equivalent side, the payment is initiated as a credit transfer. For Swiss franc payments between Swiss banks, this goes through SIC (Swiss Interbank Clearing). The payment instruction is formatted as an ISO 20022 message — specifically a pain.001 credit transfer — which includes a field for the structured creditor reference.
Step 3: the payment travels through the interbank network
SIC processes the credit transfer and routes it to your bank. The structured reference is carried in the ISO 20022 message throughout this process. The ISO 20022 migration post covers what changed in 2022 when Swiss banks completed their migration to ISO 20022 messages for domestic payments.
Before the 2022 migration, structured remittance data sometimes degraded as it passed through older legacy message formats that did not have dedicated fields for it. Post-migration, the structured reference field is preserved through the entire chain — from the payer's pain.001 payment initiation, through SIC clearing, to your bank's booking system.
Step 4: your bank delivers the camt.054 notification
When the payment lands in your account, your bank generates a credit notification. In the ISO 20022 world, this is a camt.054 (Bank to Customer Debit Credit Notification) message. It is delivered to you either as a file download from your e-banking portal, pushed to your ERP via a host-to-host connection, or accessible through an API depending on what your bank offers and what you have configured.
The camt.054 contains the full credit details: the amount, the value date, the payer's name, and — critically — the structured reference from the original payment instruction. For a QR reference, this arrives in the <Ref> element within <RmtInf> (remittance information) under the transaction details.
The camt.054 parsing post covers the XML structure in detail with XPath examples.
Step 5: your AR system matches the reference to the open invoice
With the reference extracted from the camt.054, your accounting software can look up the corresponding open invoice automatically. If you encoded your invoice number in the QR reference — which is the standard approach — the match is direct. Payment received for reference 000000000012345 maps to invoice INV-12345. The invoice is marked as paid, the AR entry is cleared.
This is automated cash application: the payment and the remittance information arrive together, and no one has to manually look up which invoice a payment covers. For a company processing hundreds of payments a month, this eliminates a significant reconciliation workload.
Where it breaks down
The clean end-to-end flow above depends on every step working correctly. A few common failure points:
The payer does not use the reference. Some payers enter a free-text description instead of the structured reference — "payment for November services" rather than scanning the QR code or copying the reference number. The payment arrives without a matchable reference, and your AR team has to reconcile it manually. This is particularly common with older or less sophisticated payers.
The payer uses a different reference. The payer's ERP assigns its own payment reference and does not carry through the creditor reference from your invoice. This happens when the two systems are not well integrated and the payer's AP team processes invoices by entering amounts manually rather than reading the structured data.
The reference is partially encoded. If you only encode a customer number in the QR reference — without an invoice number — the camt.054 tells you which customer paid but not which invoice. You still need a second lookup step. Encoding both customer and invoice number in the reference (using the 26 available digits efficiently) is worth the design effort.
Batch payments. A large customer may batch multiple invoices into a single payment. In this case, a single credit arrives covering several open items. The remittance information may carry multiple structured references if the payer's system supports it, or it may carry only a free-text list. Handling batch payments requires a reconciliation rule that can split a single incoming credit across multiple open invoices.
The full picture
The remittance flow — reference on the invoice, reference in the payment, reference in the bank notification, reference matched in your AR system — is what makes straight-through processing possible on the receivables side. It is the AR equivalent of three-way matching on the payables side: a structured, automatable control that removes manual work from a high-volume process.
Getting it right requires consistency at both ends. Your invoices need to carry correctly formatted structured references. Your customers need to use those references when they pay. Your bank connection needs to deliver camt.054 files your system can parse. All three pieces need to be in place before the reconciliation rate meaningfully improves.