Cash Application: Matching SEPA Payments to Invoices
Receivables software promises to match incoming payments to invoices. In the EU that means SEPA remittance, split payments, and (in Poland) a 35-character KSeF number. Here is what actually matches, and what never will.
Cash Application: Matching SEPA Payments to Invoices
Cash application is the job of turning a bank credit into a closed invoice. US tools describe it as "we recognise your customer payments and suggest a match." The European version of that sentence has a specification.
What Lands on the Statement
A SEPA Credit Transfer carries an amount, a debtor name, a debtor IBAN, a creditor IBAN, and remittance information. The remittance field is often unstructured, truncated, and written by a human who typed the buyer's internal PO, a truncated invoice number, or nothing.
Batch payments make it worse: one credit, five invoices, a net of a credit note, and a remainder the buyer calls "our round-off." Split payment in Poland (MPP) splits VAT onto the VAT account. The books must still close the commercial invoice in full.
Card takings and cash in the till should never enter this matcher. They were never receivables.
Match Keys That Work
| Key | When it is reliable | Failure mode |
|---|---|---|
| Exact amount + known customer IBAN | One invoice, one payment, stable payer account | Two open invoices with the same total; payment from a factor's account |
| Invoice number in remittance | Buyer pastes the full number | Truncation, prefixes, "INV" vs "FV" |
| End-to-end or structured reference | You printed a RF creditor reference or a national structured message | Buyer pays from a portal that strips it |
| Polish KSeF number in the title (art. 108g, from 1 January 2027) | Transfers between active VAT payers, including MPP, with the 35-character id or the collective batch id | BLIK, cards, cash: out of scope. Wrong dates circulating online (April 2026, August 2026) are false. |
| Spanish reported payment date | After Crea y Crece status is live for that party | Status says paid; the bank credit is a different amount (partial, FX, grouping) |
Build a ranked matcher: structured reference, then KSeF number once live, then (customer + exact amount), then (customer + amount within a tolerance you log), then queue. Never auto-close on debtor name alone. Names on SEPA are not legal identity.
Partials, Credit Notes, FX
A €10,000 invoice and a €9,400 credit is not a failed match. It is a residual of €600. The matcher should propose a combination, not leave both items open until a clerk invents a journal.
FX: a EUR invoice paid from PLN is two rates (NBP for the invoice, bank for the payment) and a różnica kursowa. Matching the payment to the invoice is still possible on the foreign-currency amount. Booking the difference is a separate line. Do not change the invoice total to make the bank row "fit."
What Is Not Cash Application
- An email open or a "mark as paid" click in a mail client
- A payment-link callback with no bank credit in your account
- A reminder that the buyer replied to with "we paid last week" and no amount
- Importing a CSV of "paid" from a marketplace while the payout is still a pooled transfer
If you cannot point at a bank transaction (or a card capture, for the till), the invoice is open. Spain will eventually require you to report the effective payment date. Reporting "paid" from a click, then discovering the credit never arrived, is a false status in a system the AEAT also sees.
Preparation for 1 January 2027 in Poland
Art. 108g puts the KSeF number in the transfer title between active VAT payers. That is the first time mass Polish B2B payments carry a unique invoice id by law. Accounting offices that still paste invoice numbers by hand should be building the extract-and-match path in H2 2026: bank feed in, regex or structured parse for the 35-character id, lookup, post, exception queue for batches that use the collective identifier.
Buyers need templates that insert the number. Sellers need the number on every visualisation and in every payment request, not only inside the XML.
Controls
Auto-post only when the key is unique and the amount matches. Everything else is a suggestion with a human confirm. IBAN changes still follow the vendor-master rule from the fraud note: the invoice does not get to retarget the payment.
Plandesk matches on structured references and, for Polish VAT transfers, on the KSeF number once the 2027 rule applies. Unmatched credits sit on the customer, not in a generic suspense account you forget. Aging reads open invoices after matches, not before.
This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.