In short and in plain language
Money can reach your account very fast today. But the open item stays open until someone matches the payment.
This post shows how a program matches payments by rules. The base is the bank statement as a file from the bank.
If invoice number and amount match, it books at once. If only the amount or name match, you get a hint. The rest goes on a list to clear up.
The post also explains part payments and early payment discounts. Reminders only go out after the match.
We link your bank statement to your open items.
Since 9 October 2025, banks have been required to offer instant transfers for euro payments within the EU (BaFin). A customer's money can therefore reach the business account within seconds. In accounting, little changes at first: the open item stays open until someone goes through the bank statement, reads the remittance information and matches the payment to the right invoice. Until then, sales sees a customer in arrears, the dunning run sees an overdue invoice and cash planning sees an amount that arrived long ago. This article describes how incoming payments are matched to open items by rules: which data the electronic bank statement provides, in which order invoice number, amount and name are checked, how part payments and early payment discounts are handled, and what happens to payments that no rule catches. How we record today's path from bank statement to cleared item is described under process analysis.
Key takeaways
- Since 23 November 2025, MT940 and MT942 are no longer a standard of the German Banking Industry Committee (Die Deutsche Kreditwirtschaft). The basis for matching is the camt.053 end-of-day statement with amount, payer, IBAN and remittance information.
- The remittance information of a SEPA credit transfer holds up to 140 characters (European Payments Council). A short, unambiguous invoice number and a note next to the bank details often raise the hit rate more than another matching rule.
- Three switches carry the matching: invoice number with a matching amount posts automatically, amount with a known IBAN or the name alone produce a suggestion for review, everything else becomes an exception case.
- If the customer does not specify which invoice a part payment settles, the statutory order applies, with the debt that is due first (Section 366 BGB). A discount taken requires a correction of the VAT (Section 17 UStG).
- Every receipt without a clear match becomes an exception case with a reason, an owner and a deadline. The dunning run starts only after the matching run, and an open exception case holds the customer's next dunning level.
- Every match is logged with rule, time and confirming person. Keep the bank statement unchanged as an accounting voucher for eight years (Section 147 AO), not only the postings created from it.
Why items stay open although the money has arrived
For the bank, an incoming payment is done once it is credited. For the business, the work only starts then: the payment has to be matched to a customer and to one or more invoices, and the amount has to fit the open amount. Only then is the item considered cleared. As long as the match is missing, the bank account and accounts receivable show two different states, and every department that looks at the open items works with the wrong one.
The consequences show in three places. The dunning run reminds customers of invoices they paid long ago; that costs trust and creates queries that take up time again. Sales sees an exhausted credit limit and follows up although the customer has paid. And cash planning underestimates the balance because matched and unmatched receipts are not kept apart. The volume is considerable: in the second half of 2025, 17.8 billion credit transfers were made in the euro area (ECB). Every single one of them that reaches a business has to be matched to a reason somewhere.
Two related processes do not belong here. Verification of payee in the payment run concerns outgoing payments to suppliers, the other direction. And reconciling payment providers in an online shop with the merchandise management system matches a provider's payouts to the orders paid through it. This article is about all credit transfers that customers make to the business account and about all invoices that could be the reason: from the shop as well as from order processing, service or project business.
The electronic bank statement as data source
Every automatic match is based on the electronic bank statement that the bank provides through its corporate banking access. Since 23 November 2025, the older formats MT940 and MT942 are no longer a standard of the German Banking Industry Committee (Die Deutsche Kreditwirtschaft); what banks have to offer since then are the XML messages camt.052 and camt.053 under ISO 20022. Three messages of this family matter for matching: camt.053 is the end-of-day statement, camt.052 reports intraday transactions, and camt.054 breaks batch bookings down into single items, for example for returned direct debits; whether a bank provides this third message depends on what it offers. The banking industry itself points out that the MT formats can carry considerably less information than the camt messages. Anyone still fetching statements in the old format, or downloading a file from online banking by hand, should switch the retrieval first.
For each booking, the end-of-day statement provides the fields from which matching later draws its conclusions. The overview below shows a credit as it looks after import.
Field Content in the statement Example
------------------------------------------------------------------------------
Amount credit in euro 1,190.00
Booking date day of booking 14.10.2026
Value date date used for interest 14.10.2026
Payer name from the transfer order Customer A
Payer IBAN account the payment came from known in customer master
Remittance info free text, up to 140 characters RE-2026-0412 cust 10234
End-to-end reference reference from the order NOTPROVIDEDThe most important field is the remittance information. The payer can add up to 140 characters, unstructured as free text or structured (European Payments Council). In practice, free text means invoice numbers with and without prefix, with spaces, swapped digits, several numbers in a row or none at all. The statement also carries the payer's name and IBAN. The name is the least reliable clue, because customers pay through group companies, owners' accounts or service providers. The IBAN, by contrast, is stable: once a customer has paid from an account, that account can be stored in the customer's master record and recognised at the next receipt. The retrieval itself runs through the company's bank access and an integration with accounting or merchandise management.
That leaves the question of timing. The payee's bank makes instant transfers available within ten seconds (BaFin); an ordinary credit transfer has to reach the payee's bank at the latest by the end of the following business day (Section 675s BGB). In the second half of 2025, instant transfers accounted for 25 percent of the credit transfers processed by retail payment systems in the euro area (ECB). Even so, matching based on the end-of-day statement in the morning is enough for many businesses. Anyone who wants to see receipts during the day, for example to confirm a payment to a customer on the phone, needs intraday transactions as camt.052 or a credit notification per instant transfer as camt.054. Whether your own bank provides both has to be clarified with it in advance, and the retrieval has to run several times a day. Matching in real time therefore depends on the bank data, not on the matching logic.
Three switches for every payment
Matching itself is a sequence of rules that every payment passes through one after another, like a train through a series of switches. The first switch that applies unambiguously decides the exit. The order matters: from the safest rule to the least safe, and only the safest may post without confirmation by a person. The table below shows what each switch checks and what happens on a hit.
| Switch | What is checked | Result on a hit |
|---|---|---|
| 1 Invoice number | An open invoice number appears in the remittance information, and the amount matches to the cent | Posted automatically |
| 1a Number with a difference | Number found, amount differs, for example by a discount, a deduction or a remainder | Suggested for review |
| 2 Amount and IBAN | No number, but exactly one open item of the customer with this amount, IBAN known in the master data | Suggested for review |
| 3 Name | Only the payer's name resembles a customer | Suggestion with a list of candidates |
| No hit | No rule applies, or several items fit equally well | Exception case |
The first switch searches the remittance information for strings that look like one of your own invoice numbers and compares them with the open items. It helps to normalise the number before comparing: remove spaces, hyphens and slashes, align upper and lower case, add leading zeros. That way, “RE 2026 0412”, “RE20260412” and “re-2026-412” become the same number. If number and amount match, the match is unambiguous and the item is cleared without a query. If the number matches but the amount does not, the result is a suggestion: a person decides whether it is a discount, a part payment or a mistake.
The second switch works without a number. Among the open items of the customer whose IBAN is stored in the master record, it looks for exactly one item with exactly this amount. If there is one, a suggestion is created. If there are two items with the same amount, for example monthly maintenance invoices of equal size, the rule must not guess. The receipt then becomes an exception case, and whoever handles it sees, as a hint, the order that the law provides for the case where the customer has not specified anything.
The third switch, the name, is the weakest. It is useful for finding candidates for an unknown receipt, but it should not post on its own: customers with the same name, owners who pay privately for the company and payments through third parties make the name ambiguous. What has proven useful is showing the hits as a list of candidates, sorted by closeness of amount and due date. One property of the scheme helps when assessing any difference: with SEPA credit transfers, the full amount is transferred, and the banks involved make no deductions (European Payments Council). If money is missing, the payer has as a rule transferred less, and the only question is why.
Every confirmation improves the customer master
What the invoice has to provide for matching
Many matching problems do not arise at the bank but on your own invoice. If the invoice number is long, resembles the customer number or sits in small print in a header, it is copied wrongly or not at all when the transfer is made. A short, unambiguous number with a fixed prefix and the explicit sentence “Please state only the invoice number as the payment reference” often help more than another rule in the matching. The following points belong on the invoice and in the master data before the first run starts.
- An invoice number with a fixed prefix that cannot be confused with customer, order or item numbers.
- A separate note on the payment reference directly next to the bank details, not in the small print at the foot of the page.
- A QR code for credit transfers that many banking apps can read: it transfers payee, IBAN, amount and reference without retyping.
- For customers who pay several invoices at once, a remittance advice by email or portal with the split per invoice.
- In the e-invoice, the payment details in the fields intended for them, not only in free text.
- In the customer master, the known IBANs per customer, added with every confirmed match.
With e-invoicing, payment terms and bank details reach the customer as structured fields. Whether the customer's accounting copies the reference into the transfer order automatically is not in your hands, but the chances improve when the fields are filled in properly. What to consider when switching outgoing invoices is described in e-invoicing mandate 2027: changing the invoice flow.
If you issue many invoices to companies whose accounting initiates payments from a system, you can additionally use a structured creditor reference under ISO 11649. It starts with the letters RF, contains check digits and is transmitted in the structured part of the remittance information, so it can be read without interpretation. For payments by small customers from online banking, the short invoice number in free text remains the more important route, because usually only one free field is offered there.
Part payments, collective payments and discounts
Part payments are a frequent reason why a payment fits an invoice but not its amount. Legally, the obligor is not entitled to render part performance (Section 266 BGB); in practice, part payments are nevertheless accepted and posted, because money in your own account is better than money with the customer. For matching, this means: the payment is matched to the invoice, the item stays open for the remainder, and the dunning run only follows up on that remainder.
It gets harder when a customer has several open invoices and transfers an amount that fits none of them. If the customer has specified in the remittance information which debt is being settled, that determination applies. If not, the law sets an order: first the debt that is due, among several due debts the one offering the creditor the least security, then the more onerous one for the debtor, then the oldest, and where all are equally old, each proportionally (Section 366 BGB). If costs and interest are also outstanding, a payment that does not cover everything is credited first to the costs, then to the interest and finally to the principal performance (Section 367 BGB). A rule can map this order as a suggestion. Weighing security and onerousness in the individual case belongs with a person in accounting.
If the obligor owes performance of the same kind to the obligee under more than one obligation, and if what the obligor pays does not suffice to redeem all debts, that debt is redeemed that the obligor determines when they perform.
Collective payments are the counterpart: a customer settles several invoices with one transfer. If the split is stated in the remittance information or in a remittance advice, it can be taken over directly. If not, the rule can search for a combination of open items whose total exactly equals the amount. That works well with few open items and becomes ambiguous with many, because several combinations can produce the same total. Such a combination is therefore shown as a suggestion as a matter of principle. Remittance advices in PDF format can be read like other incoming documents; the route is described under document digitisation.
With an early payment discount, the difference is intended. The rule needs three details from the invoice: the discount rate, the discount period and the invoice date. If the receipt falls within the period and the difference equals the agreed discount, the item can be cleared with a discount posting. If it falls outside the period, the difference is an open remainder, and whether it is claimed or written off as a goodwill gesture is decided by a person. For tax purposes, a discount is a change in the taxable amount: the business has to correct the tax amount owed for it (Section 17 UStG). The discount posting therefore carries the tax portion instead of putting the difference into an expense account as a lump sum. The example shows such a suggestion.
Invoice RE-2026-0398 Invoice date 05.10.2026
Gross amount 595.00 EUR (500.00 net + 95.00 VAT)
Payment terms 2 % discount until 15.10.2026, net until 04.11.2026
Receipt 14.10.2026 583.10 EUR Remittance info: invoice 398
Difference 11.90 EUR equals 2 % of 595.00 EUR
Discount period met yes
Suggestion clear with discount 10.00 net + 1.90 VAT correctionThe exception list for everything no rule catches
No rule catches every payment. More important than the rate is what happens to the rest. Without a fixed place, unclear receipts end up in a clearing account and are forgotten there until the annual financial statements bring them back up. An exception list works better: every receipt that no rule matches unambiguously becomes an exception case with a reason, an owner and a deadline. The reasons can be grouped in advance, and each group has its own path.
No reference, unknown payer
The receipt carries neither an invoice number nor a known IBAN. The first step is the list of candidates by amount and name, the second a query to the likely customer.
Several items fit
Amount or number fit several open items equally well. The decision follows the customer's determination or the statutory order, and the reason is recorded.
Amount differs
A discount after the period has expired, a deduction because of a complaint or transposed digits. The difference goes to sales or service as a separate case, not into a collective write-off.
Duplicate or excess payment
The same invoice was paid twice, or more arrived than was open. The surplus is kept as a credit balance, agreed with the customer and offset or refunded.
Return and returned direct debit
A direct debit comes back or a payment is recalled. The item is reopened, and dunning only resumes once the reason has been clarified.
Payment without an invoice
Down payments and advance payments arrive before an invoice exists. They are kept as down payments received and later offset against the final invoice.
Three rules apply to the exception list. Every case has exactly one owner and a date by which it should be resolved. Every decision is recorded with a reason, so that the same question does not have to be asked again at the next receipt. And the list is reviewed regularly, at least before every dunning run and before every month-end close. An exception case that has been lying around for weeks is usually no longer a matching problem, but a query to the customer that is still outstanding.
By the end of the year at the latest, it becomes clear whether the list has been maintained. Unresolved receipts and open items that have in fact been paid are among the first queries when it comes to preparing the annual financial statements. Keeping the exception list small over the year saves this search in December.
What matching means for the dunning run
An automated dunning run is only as reliable as the matching before it. The order is therefore fixed: first the bank statements are fetched and matched, then the suggestions are confirmed, and only after that does the dunning run determine which item moves to the next level. How the levels themselves are set up is described under automating dunning.
Two links help prevent wrong reminders. An open exception case with a candidate at the customer holds that customer's next dunning level until the case is decided. And a part payment switches the reminder to the remaining amount instead of repeating the old reminder with the full amount. The legal framework stays the same: with claims for payment, the obligor is in default at the latest if they do not pay within 30 days after the due date and receipt of the invoice (Section 286 BGB); towards consumers this only applies if the invoice specifically points out this consequence. A reminder to a customer whose payment simply was not matched is therefore rarely a legal problem, but regularly a relationship problem.
| Aspect | Matching by hand | Rule-based matching |
|---|---|---|
| Timing | When someone goes through the statement | After every retrieval of the bank statement |
| Unambiguous payments | Searched and posted one by one | Cleared automatically |
| Differences | Decided in someone's head, rarely recorded | Suggestion with a reason, confirmation logged |
| Unclear receipts | Clearing account without a deadline | Exception list with owner and date |
| Dunning run | Does not check payments, or only by sampling | Starts only after matching |
| Knowledge | With individual people | In rules and customer master |
Matching produces metrics that steer the process: the share of payments posted without confirmation, the number of open exception cases and their age, the total of unmatched receipts at month end and the number of reminders that had to be withdrawn because of a payment. These values belong in ongoing metrics reporting, not in a spreadsheet pulled once a quarter.
Logging and retention
Every match is a posting, and every posting needs a voucher. The electronic bank statement is generally treated as an accounting voucher, and accounting vouchers have a retention period of eight years (Section 147 AO). The file from the retrieval therefore belongs in the archive unchanged, not only the postings created from it. In addition, there is a log for each match: which payment, which item, which rule, whether automatic or confirmed, who confirmed and when. For discounts and write-offs, the reason is part of it.
The log is useful beyond the audit. If a customer asks why a payment was matched to a different invoice, the answer is there with rule and time. And when a rule is changed, it can be traced which matches were created under the old version. How documents are stored so that they cannot be altered and can be found again is described in GoBD-compliant document storage.
A write-off is not a match
How a business gets started
Getting started begins with a measurement, not with a rule set. The bank statements of the last three months run once against the open items of that time, and the result shows which share would already pass the first switch today, which the second, and which would be an exception case. This distribution shows where work pays off: on the invoice, in the customer master or in the rules.
- Set up retrieval of the end-of-day statement in camt.053 format and clarify whether the bank provides intraday transactions and batch files.
- Run a test over the statements of the last three months against the open items of that time, with the result split by switch.
- Adjust the invoice template: short invoice number, note on the payment reference next to the bank details.
- Agree the tolerance threshold, the discount rule and the statutory order for part payments with accounting.
- Set up the exception list with groups, owners and deadlines and link the dunning run to the matching run.
- Switch the first switch to live posting, run the second and third as suggestions and fine-tune the rules after a few weeks based on the confirmations.
Technically, the process needs a regular retrieval of bank statements, data integration between bank data, open items and customer master, and an interface in which suggestions and exception cases are handled. If accounting or merchandise management already offer a matching function, the work lies mainly in rules, invoice template and exception list. If not, matching is built as a separate process automation that returns its results to the leading systems and logs every run.
One point is easily overlooked at the start: if the retrieval of the bank statement fails once, matching sees no new payments, and the next dunning run works with an outdated state. A missing statement therefore has to be noticed before reminders go out. How such monitoring can be set up is described in monitoring interfaces properly.
Sources and legal basis
Related Articles
Annual financial statements: the groundwork due in December
Preparing annual financial statements: which deadline applies to which legal form and which five tasks in December cut the follow-up questions in January.
Unused leave at year end: an employer notice you can prove
Unused leave generally only lapses after a personal notice: which fields that notice needs and how delivery and acknowledgement are recorded as evidence for each employee.
Safety briefings: scheduled and evidenced per person
How triggers from HR and asset data, intervals per legal basis and evidence per person add up to a briefing matrix that reports gaps before anyone is deployed.