Short answer
SEPA invoice matching software links each incoming SEPA credit transfer to the invoice it pays, using the payment's remittance information, any RF creditor reference, the payer's IBAN and name. DIGITAL EUR does this today in a free in-browser demo with fixed, explained rules and human approval. Reading the end-to-end ID and structured reference fields from camt.053 is planned.
What does SEPA invoice matching mean on this page?
This page covers one capability: how the matching engine reads the data that travels with a SEPA payment. The broader product, including allocation, exceptions and exports, is described on the bank transfer reconciliation software page. The manual month-end process, with every SEPA scheme and statement format explained, is in our SEPA reconciliation guide.
| Term | Meaning in one line |
|---|---|
| SEPA credit transfer (SCT) | A euro transfer under the European Payments Council (EPC) rulebook; SEPA Instant (SCT Inst) is the real-time variant |
| Remittance information | Up to 140 characters the payer sends to you, either as free text or as one structured reference |
| RF creditor reference | An ISO 11649 reference: "RF", two check digits, then up to 21 letters or digits of your own reference |
| End-to-end ID | The payer's own identifier for the transaction, up to 35 characters, passed through the chain unchanged |
| Counterparty IBAN and name | The account and account holder that sent the money |
| Matching evidence | A fact that ties a payment to a specific invoice; an equal amount alone does not count |
The reason a SEPA-specific view matters is simple. The SCT rulebook requires banks to pass the 140-character remittance field to you in full and without alteration, and the EPC recommends the ISO 11649 structured creditor reference for payments that settle a single invoice. In practice, as the Euro Banking Association's B2B remittance discussion paper notes, the structured reference is underused and many payers still type free text. A SEPA matcher therefore has to handle both well.
Which SEPA payment fields does the matcher use today?
The demo reads two CSV files: your open invoices and your bank transactions. Each SEPA data point is either used today, planned, or deliberately not used.
| SEPA data point | Status | How it is used |
|---|---|---|
| Remittance information (free text) | DEMO | Searched for each invoice's reference as a whole token |
| RF creditor reference | DEMO (as a token) | Matched like any other reference; check digits are not yet validated |
| Structured vs unstructured remittance | PLANNED | A CSV gives one text column, so the engine cannot tell them apart today |
| End-to-end ID | PLANNED as its own field | Today it counts only if you put it in the remittance column (see below) |
| Payer IBAN | DEMO | Compared with the IBAN stored on the invoice, after removing spaces |
| Payer name | DEMO | Compared exactly with the customer name after normalisation |
| Amount and currency | DEMO | Exact amount adds weight; partial and excess amounts lower it; currencies must agree |
| Credit or debit | DEMO | Only credits (CRDT) are matched to invoices |
| Booking and value date | Not used | Matching does not depend on dates; the demo file has no date column |
| Extended Remittance Information (ERI) | Not planned | An optional scheme feature available only between participating banks and customers who have arranged it |
Every match is scored with the same six reason codes used across the product: INVOICE_REFERENCE (+65), EXACT_AMOUNT (+20), COUNTERPARTY_IBAN (+10), COUNTERPARTY_NAME (+5), POSSIBLE_PARTIAL_PAYMENT (−15) and AMOUNT_EXCEEDS_OUTSTANDING (−25). No pair is suggested without reference, IBAN or name evidence, and a tie at the top score is flagged AMBIGUOUS. The reconciliation page explains the scoring in full; this page focuses on what counts as reference evidence in SEPA data.
How is an RF creditor reference matched?
An RF reference is matched as a sequence of letter-and-digit groups. The reference stored on your invoice is split wherever it contains a space, dash or other separator, and the remittance text must contain those groups in the same order, with nothing but separators (or nothing at all) between them. Letter case is ignored. The groups must also stand alone: the character before the first group and after the last group may not be a letter or digit.
We tested this behaviour against the current rules (version demo-rules-1), using the widely published example reference RF18 5390 0754 7034, whose check digits are valid.
| Reference stored on the invoice | What the payer's bank delivered | Counted as reference evidence? |
|---|---|---|
| RF18 5390 0754 7034 | RF18539007547034 | Yes |
| RF18 5390 0754 7034 | rf18-5390-0754-7034 | Yes |
| RF18 5390 0754 7034 | /RFB/RF18 5390 0754 7034 | Yes |
| RF18 5390 0754 7034 | RF1853 9007 5470 34 (grouped differently) | No |
| RF18539007547034 | RF18539007547034 | Yes |
| RF18539007547034 | RF18 5390 0754 7034 | No |
| RF18539007547034 | RF185390075470345 (extra digit) | No |
The practical rule follows from the table: store the RF reference on the invoice in the grouped, printed form (blocks of four). Stored that way, it matches both the compact form most banks deliver and the grouped form a payer copies from a PDF. Stored compactly, it misses a payer who typed the spaces.
What the engine does not do yet is validate the check digits. ISO 11649 check digits use the same modulo-97 method as IBANs, so a single mistyped digit produces an invalid reference. Today, a mistyped RF reference simply fails to match and the payment falls back to IBAN or name evidence, as the worked example below shows. Flagging "this looks like an RF reference but the check digits are wrong" is PLANNED. Checking a reference before you print it is the subject of the SEPA transfer reference checker page, and the SEPA reconciliation guide explains how the check digits are calculated.
How is free-text remittance parsed?
Most SEPA payments still arrive with an unstructured remittance line such as "Rechnung Nr. 2026-0042, danke". The same whole-token rule applies to these. A few consequences are worth knowing before you rely on it.
- Bank reformatting is tolerated. "INV 2026 0042", "inv2026/0042" and "Ref:INV-2026-0042." all match INV-2026-0042.
- Longer references are not confused with shorter ones. INV-2026-0042 never matches INV-2026-00421, and references shorter than four letters or digits are ignored.
- Prefixes glued to the reference block a match. "XINV-2026-0042" does not match, because a letter sits directly in front of the reference.
- Short references can over-match. If an invoice's reference is only "0042", it will also be found inside "INV-2026-0042", because the dash before 0042 counts as a separator. Use full, unique invoice numbers or RF references, never bare sequence numbers.
- Two invoices in one line are both found, if both are written out. "INV-2026-0203 INV-2026-0204" yields reference evidence for both invoices. An abbreviation such as "INV-2026-0203/0204" yields evidence only for 0203; the engine does not expand shorthand.
- Trailing suffixes still match. "INV-2026-0042-A" counts as evidence for INV-2026-0042, because the dash ends the token. If you issue credit notes or instalments with suffixes, give them a distinct reference.
There is no fuzzy matching, no spelling correction and no language model reading the text. That is a deliberate choice: every suggestion can be traced to a rule you can test yourself.
What about the end-to-end ID?
The end-to-end ID is created by the payer, for the payer. The SCT rulebook says it is only expected to be meaningful to the originator, and if the payer leaves it empty it reads "Not provided". There is one useful exception: some payers' accounting systems copy your invoice number or RF reference into the end-to-end ID rather than the remittance field, because the ISO 20022 usage notes allow the creditor's reference to be quoted there.
Today (DEMO): the transactions CSV has no end-to-end ID column. If your bank export contains one, combine it with the remittance text into the remittance column when you prepare the file, for example "Payment June | E2E: INV-2026-0205". The engine then treats a reference found in either part as reference evidence.
PLANNED: with camt.053 import, the end-to-end ID (EndToEndId) and the structured creditor reference (CdtrRefInf/Ref) will arrive in their own fields. The intended design keeps them as separate, named evidence rather than folding them into one score, because they have different reliability. Payment providers warn that end-to-end IDs can be reused: Plaid's documentation, for example, notes that a repeat payment from a saved payee may carry the original identifier, so an end-to-end ID match should be confirmed with amount and currency, not treated as proof. We will not describe this as available until it is.
A worked example: five SEPA credits
The data below is invented; the scores were produced by running the current rules on these exact inputs, and you can recreate them in the Reconciliation Lab. All amounts are in EUR. The IBAN is the widely published example DE89 3704 0044 0532 0130 00.
Open invoices
| Invoice | Customer | Amount due | Reference on invoice | Stored IBAN |
|---|---|---|---|---|
| INV-2026-0201 | Lindqvist Design AB | 1500.00 | RF63 2026 0201 | (none) |
| INV-2026-0202 | Bauer Logistik GmbH | 720.00 | RF36 2026 0202 | DE89370400440532013000 |
| INV-2026-0203 | Costa Studio Lda | 400.00 | INV-2026-0203 | (none) |
| INV-2026-0204 | Costa Studio Lda | 260.00 | INV-2026-0204 | (none) |
| INV-2026-0205 | Kowalski Media sp. z o.o. | 980.00 | INV-2026-0205 | (none) |
Incoming SEPA credits
| Line | Amount | Remittance as delivered | Payer name |
|---|---|---|---|
| S-01 | 1500.00 | RF6320260201 | LINDQVIST DESIGN AB |
| S-02 | 720.00 | RF36 2026 0220 (payer swapped two digits) | Bauer Logistik GmbH (IBAN as stored) |
| S-03 | 660.00 | INV-2026-0203 INV-2026-0204 | Costa Studio |
| S-04 | 980.00 | (empty; the reference was only in the end-to-end ID) | Kowalski Holding S.A. |
What the engine suggests
| Line | Invoice | Reason codes | Score |
|---|---|---|---|
| S-01 | INV-2026-0201 | INVOICE_REFERENCE, EXACT_AMOUNT, COUNTERPARTY_NAME | 90 |
| S-02 | INV-2026-0202 | EXACT_AMOUNT, COUNTERPARTY_IBAN, COUNTERPARTY_NAME | 35 |
| S-03 | INV-2026-0203 | INVOICE_REFERENCE, AMOUNT_EXCEEDS_OUTSTANDING (AMBIGUOUS) | 40 |
| S-03 | INV-2026-0204 | INVOICE_REFERENCE, AMOUNT_EXCEEDS_OUTSTANDING (AMBIGUOUS) | 40 |
| S-04 | none | Unresolved | none |
How a reviewer works through it
- S-01: compact RF against a grouped invoice reference. The bank delivered the reference without spaces; because the invoice stores it in grouped form, it still matches. The name matches after upper-casing. Score 90; the reviewer approves €1,500.00.
- S-02: a mistyped RF reference. "RF36 2026 0220" fails check-digit validation and does not match the invoice. The suggestion survives on IBAN, name and exact amount, at 35. This is the case that RF validation (PLANNED) would make clearer: the reviewer would see that a reference was attempted and is invalid. The reviewer approves €720.00 after checking the payer.
- S-03: one transfer for two invoices. Both references are present, and the transfer exceeds each invoice, so both candidates score 40 and are flagged AMBIGUOUS. The reviewer approves both. The allocation caps do the arithmetic: €400.00 goes to INV-2026-0203, and the remaining €260.00 of the transfer goes to INV-2026-0204. Both invoices become fully allocated.
- S-04: reference only in the end-to-end ID. The remittance is empty, no IBAN is stored and "Kowalski Holding S.A." is a different name from the invoiced company, so there is no suggestion and the line is listed as unresolved. When the reviewer prepares the file again with the end-to-end ID appended to the remittance column ("E2E: INV-2026-0205"), the line scores 85 (INVOICE_REFERENCE, EXACT_AMOUNT) and can be approved.
The resulting CSV export contains five allocations totalling €3,860.00, each with the approver's name and a timestamp, and the audit log records five approvals.
Who is SEPA invoice matching for?
It fits businesses and bookkeepers who receive SEPA credit transfers against invoices and want each match explained:
- service businesses, agencies and consultancies invoicing EU clients in euro;
- businesses that already print an RF creditor reference or a stable invoice number, or are willing to start;
- accountants who match transfers for several small clients from statement exports (see bank reconciliation for accountants);
- teams that want a named person to approve every allocation.
It is not a fit if you need SEPA direct debit return handling, card or wallet settlements, payments in other currencies, automatic posting to a ledger, or a live bank connection. None of these is offered.
What exists today and what is planned?
| Capability | Status |
|---|---|
| Whole-token matching of invoice and RF references in remittance text | DEMO |
| IBAN and exact-name evidence, amount checks, AMBIGUOUS flag | DEMO |
| Human approval, capped allocations, append-only audit log, CSV export | DEMO |
| RF check-digit validation and "invalid reference" warning | PLANNED |
| Separate end-to-end ID and structured reference fields via camt.053 | PLANNED |
| Saved matching rules (for example, a payer's known reference pattern) | PLANNED |
| Fuzzy name matching or AI interpretation of remittance text | Not planned for matching decisions |
| Bank connections, payment initiation, holding funds | Not planned |
How does this compare with other ways to match SEPA payments?
Tools differ mainly in which evidence they accept and whether they post automatically. The examples below come from the vendors' own public pages, read on 5 November 2026.
| Approach | Evidence used | What happens with a match | Trade-off |
|---|---|---|---|
| Spreadsheet lookup | Whatever you search for, usually invoice number or amount | You mark it paid | Flexible, but reformatted references and duplicates are easy to miss |
| Reference-code matching (PayRequest's published approach) | A unique reference code in the payment description, read from an open-banking feed | Invoice marked paid automatically | Fast when payers copy the code; little room for exceptions |
| Tiered rules (DiKAS documents six levels) | Invoice number with or without amount, name, IBAN, and finally amount alone when exactly one invoice fits | Automatic or manual matching, partial payments recorded | Broad coverage; the last level accepts amount-only matches |
| DIGITAL EUR | Reference token, IBAN, exact name; amount only adjusts the score | Suggestion waits for a named person | Slower for clean cases; never matches on amount alone |
If your customers reliably copy a reference and a wrong posting is cheap to undo, an automatic tool is a reasonable choice. If you want every SEPA allocation explained and approved, that is what this engine is for.
How can you get better SEPA matches from your customers?
The engine can only match what the payment carries. These steps improve the input and are independent of any software:
- Put one unique reference on every invoice, either a full invoice number or an RF creditor reference, never a bare sequence number.
- Print RF references in groups of four and store them on the invoice record in the same grouped form.
- Ask customers to paste the RF reference into the structured reference field of their banking app, and the invoice number into the free-text field when they pay without RF.
- Ask customers who pay several invoices at once to write every reference out in full.
- Record each customer's paying IBAN on future invoices once you have seen it; it is the strongest fallback when the reference is missing.
- When exporting statements, include the end-to-end ID if your bank offers it, and append it to the remittance column.
How are privacy and review handled?
The Reconciliation Lab reads files in your browser; nothing is uploaded or stored, and closing the page discards the data, decisions and audit log. Use synthetic or anonymised files. Every suggestion, including a score of 100, stays pending until a named person approves it, and allocations are capped so that a transfer can never settle more than it carried or more than an invoice owed. Controls required before any customer data is accepted are listed on the security page.
What does it cost and how do you start?
There is nothing to buy yet. The pricing page lists illustrative pre-launch prices before tax: Solo €19, Growth €49 and Agency €129 per month, with no checkout. SEPA matching is part of the same engine in every plan; camt.053 import is listed for Growth. To start today, export a sample of anonymised invoices and SEPA credits as CSV and load them into the Lab.
What are the honest limitations?
- It is a demo: no accounts, no saved work and no stored history.
- RF check digits are not validated yet; an invalid reference simply does not match.
- The CSV format has one remittance column, so structured and unstructured remittance, and the end-to-end ID, are not distinguished.
- Name evidence requires an exact match after normalisation, and letters outside A–Z (for example ü or ł) are dropped before comparing, so "Müller" and "Mueller" are not the same name.
- Abbreviated multi-invoice references are not expanded.
- Matching is limited to one currency per pair and to credits only.
Frequently asked questions
Does DIGITAL EUR validate RF creditor references?
Not yet. RF references are matched as whole tokens today. Check-digit validation, with a warning when a payer's reference is invalid, is planned.
Should I store the RF reference with or without spaces?
With spaces, in groups of four, as printed. That form matches both the compact and the grouped versions that banks and payers produce.
Can the matcher read the end-to-end ID?
Only if you add it to the remittance column of the transactions CSV. A separate end-to-end ID field is planned with camt.053 import.
What happens when one SEPA transfer pays two invoices?
If both references are written out, both invoices are suggested and flagged AMBIGUOUS. Approving both allocates the transfer up to each invoice's outstanding amount.
Will a payment be matched just because the amount is right?
No. An equal amount without a reference, IBAN or name match produces no suggestion; the payment is listed as unresolved.
Is this an AI matching tool?
No. Matching uses fixed, published rules and integer-cent arithmetic. The same files always give the same suggestions.
Does it work with SEPA Instant payments?
Yes, in the same way. An instant credit appears on the statement like any other credit, and the matcher reads the same fields.
Sources
- European Payments Council, SEPA Credit Transfer Scheme Rulebook 2025 version 1.0 (PDF) (accessed 5 November 2026)
- European Payments Council, SCT customer-to-PSP implementation guidelines 2025 (PDF) (accessed 5 November 2026)
- Euro Banking Association, B2B Remittance Data – Challenges and Solutions, discussion paper (PDF) (accessed 5 November 2026)
- ISO 11649:2009, Structured creditor reference to remittance information (accessed 5 November 2026)
- Plaid, Payment Initiation reconciliation (accessed 5 November 2026)
- PayRequest, Payment matching (accessed 5 November 2026)
- DiKAS user manual, Banking and SEPA (accessed 5 November 2026)