Reconciliation & Payment Flows

On the invoices of a valve manufacturer, below the bank details, there is a line that hardly any customer reads: RF18 5390 0754 7034. It is a structured creditor reference under ISO 11649. If the customer quotes it in a bank transfer, the ERP system finds the invoice on its own. The reference travels with the payment and arrives unchanged on the bank statement. If the same customer pays in euro stablecoins, only the amount arrives. Accounting then has to work out the invoice from other features: amount, sender and timing.

How a bank transfer finds its invoice

In the SEPA scheme every credit transfer has a field for remittance information. The rulebook of the European Payments Council (EPC) allows 140 characters there, either unstructured or structured. It justifies the field explicitly with automated reconciliation between receivables and payments at the beneficiary. Every bank along the way must pass the data on in full and without alteration. As the preferred convention the rulebook recommends the structured creditor reference, specifically for payments that refer to a single invoice.

The Swiss implementation guidelines for the QR-bill describe its format in more detail. The reference has 5 to 25 characters and starts with RF and two check digits calculated with modulo 97-10. A transposed digit is therefore caught at the point of entry, not in accounting. When a customer pays two invoices at once, however, the single reference is no help. The free text then carries a list of invoice numbers, or the customer sends a remittance advice.

From this data a matching program works in stages. It looks for the reference first. If there is none, or it does not fit, it checks amount and payer against that customer's open items. If several candidates remain, proximity to the due date decides. Whatever no stage can assign unambiguously goes onto the list for clarification.

What a token payment lacks

With a euro stablecoin on Ethereum, the first stage drops out. The event of a transfer carries sender, recipient and amount, but no remittance information; the fields in detail are described in Data Standard & Account Statement. The second stage only half works. The amount is known, but accounting knows the payer only as an address. Whether that address belongs to a customer is recorded in the master data, provided someone has entered it there. How that is done is described in Master Data, Privacy & Security.

One property of tokens helps instead. With a cross-border transfer, less often arrives than the customer instructed, because correspondent banks deduct charges along the way. With a stablecoin the sender pays the network fee separately, for example in ether. A token that withholds nothing on transfer therefore arrives in exactly the instructed amount. If the amount differs from the invoice, the reason lies with the customer: an early-payment discount, a deduction, a typing error. Every difference thus has a commercial cause, not a technical one.

Two invoices, one payment

In Data Standard & Account Statement a customer of the valve manufacturer pays 18,400 euro stablecoins for two invoices. Suppose four of its invoices are open, for 11,900, 6,500, 4,200 and 2,300 euros. None of them is for 18,400. The program therefore looks for combinations whose total hits the amount and finds two: 11,900 and 6,500, or 11,900, 4,200 and 2,300. Arithmetically both are equally good. The older due date may speak for one, and for the other an email from the customer sitting in the sales team's inbox.

In this case guessing is worse than leaving it. If the program picks the wrong combination, two invoices are cleared that are still open, and a paid invoice goes into the dunning run. That only surfaces when the customer complains about the reminder. A workable rule therefore does not let ambiguous totals through automatically. It puts the receipt forward for clarification with both proposals.

Conversely, one invoice can arrive in several payments. Another customer pays 5,000 on an invoice for 8,000 euros and the rest three weeks later. The first payment does not match any open item in full. The program needs a rule on whether to post it as a partial payment against the only matching invoice or to hold it for clarification. Differences are similar. If a customer pays 6,370 instead of 6,500 euros, that may be a 2 per cent early-payment discount, and the item is cleared. At 6,300 euros it is a deduction someone has to resolve.

Such rules are not a technical setting. How much difference an item tolerates, when a partial payment is posted and what happens to ambiguous totals reaches into dunning and customer accounts. Finance management sets them, and they then apply to every payment alike.

When a provider bundles the payments

Many companies do not accept stablecoins themselves but through a payment service provider (PSP). It gives the customer an address, receives the tokens and pays the money out in bulk, for instance in euros to the business account. The valve manufacturer, say, sells spare parts through an online shop. Suppose 37 payments totalling 9,250 euros come in there on one day, and the provider keeps 1 per cent as its fee. The bank account then receives 9,157.50 euros as a single amount.

The bank statement alone cannot reconcile this receipt. It clears not one invoice but 37, and none of them is for the amount paid out. The assignment is in the provider's payout report: which payment belongs to which order and what it has withheld. Accounting clears the 37 open items in full and posts the 92.50 euros as an expense. Only then do the customer accounts and the bank account agree at the same time.

ISO 20022 has its own form for such batch bookings. In the camt.054 schema a single entry can carry a batch block with the number of transactions and the total amount. Below it follow any number of individual transactions, each with its own amount, its own charges and its own remittance information. If the provider delivers its report in this form, the ERP system reads it like a batch booking from the bank. The format it actually delivers is set by the contract with it. That determines how much manual work each day in the online shop costs.

Batch payments going out

The same pattern exists in the other direction. If the valve manufacturer pays twelve suppliers at once, it can send a single transaction that triggers twelve transfers via a smart contract. Under the token standard EIP-20, every transfer produces its own event. All twelve, however, carry the same transaction hash. The hash then no longer denotes one payment but a bundle. An individual entry only becomes unique together with its position in the block, which every event carries. Anyone storing only the hash in reconciliation cannot tell the twelve payables apart.

What ends up in the suspense account

Whatever no rule assigns, accounting first posts to a suspense account. With token payments it also fills up for reasons that do not arise in banking in the same way. One of them is a sender that appears in no master data. If a customer pays from an account at a trading platform, the platform sends the tokens from an address it manages itself. The statement then shows the platform as sender, and a refund to that address would go to the platform rather than the customer. There is no return as with a direct debit. Every refund is a new outgoing payment to an address that must be checked beforehand.

For the finance director the suspense account shows how well reconciliation works. Two figures are enough: the share of receipts the program assigns without intervention, and the age of the items left over. As long as an amount sits there, the books show money that belongs to no customer and receivables that have long been paid. A high balance at month end therefore costs twice, in clarification and in dunning.

A reference for the ledger

For the missing reference there is a proposal. ERC-7699 extends the token standard with a transfer that carries a reference. The token then writes a second event next to the transfer event, which can hold up to 32 bytes in plain text. A creditor reference of at most 25 characters fits. The RF reference printed on the invoice today could thus travel with the payment on the ledger. The first stage of reconciliation would then work again, without a new rule.

The proposal names its own limits. In September 2026 it is a draft, and it only works for a token whose issuer builds it in. The reference is public and links, visibly to anyone, the payments that belong to one invoice. Moreover, the standard does not validate it. Anyone using another customer's reference creates a receipt that appears to match. The reference then says which invoice is meant, and who paid is still told only by the address.