Know exactly which payments belong to which invoices

Short answer

DIGITAL EUR is bank transfer reconciliation software for euro receivables. It reads an invoice CSV and a bank statement CSV, suggests which credit settles which invoice, shows a score with named reasons, and records every approval in an audit log. Today it runs as a free in-browser demo; accounts, stored data and camt.053 import are planned.

Who is this reconciliation software for?

It is designed for small and mid-sized businesses, and for the bookkeepers and agencies who work for them, that receive many euro bank transfers against invoices and currently match them by hand in a spreadsheet. In practice that means invoice-to-bank reconciliation for businesses across Europe: a SEPA invoice matching step that sits in front of your accounting system rather than replacing it.

It fits best when:

• customers pay by SEPA credit transfer or SEPA Instant, and most of them quote an invoice number or RF creditor reference;
• you can export open invoices and bank statements as files;
• you want suggestions you can check, rather than matches that are posted without you;
• more than one person needs to see who allocated which payment, and why.

For payment reconciliation in a small business, the value is usually not speed but certainty: knowing which invoices are really open before a reminder goes out. For accountants, it works as an accounts receivable reconciliation tool that produces evidence a client can check.

It is not a fit if you need direct bank connections, card or direct-debit settlement reports, multi-currency matching or automatic posting to a ledger. None of these is offered today. For the underlying manual process, read our SEPA reconciliation guide.

How does the matching work?

To match a bank transfer to an invoice, the engine compares every incoming credit with every open invoice in the same currency. A pair becomes a suggestion only when there is at least one piece of identifying evidence: the invoice reference in the remittance text, the customer's IBAN, or the customer's name. An amount that happens to be equal is never enough on its own.

Each suggestion receives a rule score from fixed weights. The score is a transparent sum, not a probability.

The maximum score is 100: reference, exact amount, IBAN and name together. A score never goes below zero.

A few rules decide what counts as evidence in transaction reference matching and SEPA transfer matching to invoices:

• References are matched as whole tokens. Spaces, dashes, slashes and letter case are ignored, so "inv 2026 0042" matches INV-2026-0042. INV-12 never matches INV-123, and references shorter than four letters or digits are not used.
• Names are compared exactly after normalisation. Upper-casing and removing punctuation and spaces means "Acme GmbH" equals "ACME GMBH.", but "Acme" does not equal "Acme GmbH". There is no fuzzy name matching.
• Only credits are considered. Debits such as bank fees or supplier payments are never matched to receivables.
• Currencies must agree. A credit in one currency is never suggested for an invoice in another.
• Ties are flagged. If two or more invoices share the top score for the same credit, each is marked AMBIGUOUS and a person must choose.
• Credits with no evidence stay visible. They appear in an unresolved list instead of being forced onto an invoice.

All amounts are parsed into integer euro cents and compared exactly. The same files always produce the same suggestions, and each result records the rules version that produced it.

A worked example: six bank lines, four invoices

The example below uses invented companies and the widely published example IBAN DE89 3704 0044 0532 0130 00. Every score below was produced by running the current rules (version demo-rules-1) on these inputs; you can recreate the same rows as two CSV files in the Reconciliation Lab and check them.

Open invoices

Each invoice's reference is its invoice number, and all amounts are in EUR.

Bank statement lines

What the engine suggests

T-03 and T-06 receive no suggestion and appear in the unresolved list.

How a reviewer works through it

1. T-01 is the clean case. The reviewer approves it, €2,400.00 is allocated and INV-2026-0101 becomes fully allocated. The second candidate scores 0 because the same payer's IBAN and name are present but the amount is far above that invoice; it can be rejected.
2. T-02 is a partial payment. The reference survived the bank's reformatting ("Rechnung INV 2026 0102"), so INVOICE_REFERENCE still applies; the partial-payment penalty takes the score from 80 to 65. After approval, €590.00 is allocated and INV-2026-0102 shows €10.00 still open. Whether those €10.00 are deducted charges to write off or a balance to chase is a decision for your accounting policy, not the software.
3. T-03 matches an invoice amount exactly, yet there is no suggestion. The payer wrote no reference, the invoice has no stored IBAN, and "Atelier Moreau" is not the same normalised name as "Atelier Moreau SARL". This is deliberate: an equal amount is not evidence. The reviewer investigates, and the lasting fix is to store the customer's IBAN on future invoices.
4. T-04 is approved and INV-2026-0110 becomes fully allocated.
5. T-05 is a duplicate payment. It scores 85 as well, because on its own it is a perfectly plausible payment. When the reviewer tries to approve it, the engine refuses: the invoice is already fully allocated, and approving would over-allocate it. The reviewer rejects T-05, and the credit stays unallocated for a refund or credit decision.
6. T-06 is a bank fee. Debits are never matched to invoices; it is listed so the reviewer can confirm what it is.

The export then contains three allocations, totalling €3,840.00, each with the approver's name and time. The audit log shows every approval and rejection, and the refused approval leaves no allocation behind.

What happens after a suggestion is made?

The payment allocation workflow is deliberately strict. Every suggestion starts as pending, including a perfect score of 100. Nothing is final until a named person approves it.

• Approval is capped. An allocation can never exceed what is still outstanding on the invoice, nor what is still unallocated on the transaction. Approving a duplicate payment against an invoice that is already fully allocated is refused.
• Partial and combined payments are handled by allocation. A partial payment leaves the invoice partially allocated with the remainder visible. A transfer that names two invoices can be allocated to both, up to each invoice's outstanding amount and the transfer's total.
• Rejection is explicit. Rejecting a suggestion that was already approved releases the allocated amount and is recorded as a reversal, not a deletion.
• The audit log is append-only. Each approval, rejection or reversal records the person, the time, the invoice, the transaction and the amount. Earlier entries are never changed.
• Exports are formula-safe. Approved allocations export as CSV. Cells that a spreadsheet might execute as a formula (starting with =, +, -, @, a tab or a carriage return) are prefixed so they are read as text. In the demo, each exported row is labelled as a demo export, not an accounting entry.

In the current demo, approving a suggestion allocates the largest amount the caps allow. Choosing a smaller amount by hand is supported by the engine but not yet exposed in the interface.

How are exceptions handled?

Bank reconciliation exception management is where most of the real work sits. DIGITAL EUR does not try to make exceptions disappear; it makes each one visible and leaves the decision with a person.

The unresolved list works as an on-screen unreconciled transactions report: every bank line without a suggestion, credit or debit, in one place. In the demo it is shown in the review screen but not exported; the CSV export contains approved allocations only.

What does a review session look like?

The Reconciliation Lab follows five steps, the same sequence planned for the full product.

1. Import. Load the synthetic sample, paste CSV text, or choose two files. Validation errors name the line, and the column where relevant, so a bad export is caught before any matching happens.
2. Preview. Check that the invoices and transactions were read as expected: amounts in euro, credits and debits separated, IDs unique.
3. Review. Suggestions appear with their score, reason codes and an AMBIGUOUS flag where two invoices tie. Unresolved transactions are listed separately, so nothing disappears quietly.
4. Approve. Enter your name as reviewer, then approve or reject each suggestion. The invoice summary updates to open, partially allocated or fully allocated, and the audit log grows with each decision.
5. Export. Download the approved allocations as CSV once at least one suggestion has been approved.

A useful way to evaluate the engine is to feed it the awkward cases from your own experience, using anonymised data. If the suggestion and its reasons are what an experienced bookkeeper would expect, the rules are doing their job. If not, the reason codes show exactly where they differ.

How does it compare with other ways to match bank transfers to invoices?

Most bank reconciliation automation software and payment matching software aims to remove the human step for clear cases. Visma eAccounting, for example, documents automatic posting when the invoice number, the amount and either the name or the IBAN correspond, on accounts with direct bank integration; easybill documents posting only unambiguous matches and handling partial and bulk payments manually. Automatic invoice reconciliation of that kind is reasonable when your bank feed is clean and a wrong posting is cheap to undo.

DIGITAL EUR makes the opposite trade-off: it proposes, explains and waits. The table shows how the three common approaches behave on the cases from the worked example.

None of these approaches is right for everyone. If you want hands-off posting from a live bank feed, an accounting package will suit you better. If you want every allocation checked and explained, that is what this tool is for.

How should you evaluate any reconciliation tool?

Whether you choose DIGITAL EUR or another product, these questions separate tools that reduce risk from tools that hide it.

Which file formats are supported?

DIGITAL EUR is a CSV reconciliation tool first. You import bank CSV and invoice files directly, so bank statement import works without accounting software and without a bank login.

DEMO (available now): CSV. The Reconciliation Lab accepts two comma-separated files, pasted or chosen from disk.

Amounts must be non-negative with a dot as decimal separator and at most two decimals (for example 1250.00); the direction column (CRDT or DBIT) carries the sign. Each file may be up to 2 MB and 20,000 data rows. Duplicate invoice or transaction IDs, missing columns and malformed amounts are rejected with the line number.

PLANNED: ISO 20022 camt.053. For camt.053 reconciliation, importing the end-of-day XML statement would let the structured creditor reference, end-to-end identification and counterparty details arrive in their own fields, without spreadsheet clean-up. That is the main advantage of ISO 20022 bank statement matching over a CSV export. It is not available yet, and we will not describe it as available until it is.

Not planned: live bank connections or payment initiation.

Can it reconcile several bank accounts?

There is no multi-bank reconciliation dashboard, and one is not on the published plan. What works today is simpler: you can combine statement exports from several accounts into one transactions CSV, as long as every transaction ID is unique. Because the file has no account column, prefix each ID with a short account label (for example DE-01-0457 and AT-02-0457) so you can still tell, in the review screen and the export, which account a payment came from. Matching itself does not depend on the receiving account; it depends on the reference, amount and payer.

How is data handled today, and what is planned?

DEMO (today):

• The Reconciliation Lab runs entirely in your browser. Files are read locally and are not uploaded or stored.
• There are no accounts, no server-side database and no login.
• Closing or reloading the page discards the data, the decisions and the audit log, so export anything you want to keep.
• Use synthetic or anonymised data; the demo is not intended for confidential customer files.

PLANNED (required before any customer data is accepted): server-side tenant isolation with tests, secure sessions and MFA-ready authentication, XXE-safe parsing for camt.053, encryption in transit and at rest, append-only stored audit events, idempotent imports, tested backups, a written retention and deletion policy, and data processing agreements. The full list is on our security page. We do not claim certifications.

What will it cost?

Nothing can be bought yet. The pricing page shows illustrative pre-launch prices before tax: Solo at €19 a month (up to 100 matched transactions), Growth at €49 a month (up to 1,000 matched transactions, camt.053 import and saved matching rules) and Agency at €129 a month (multi-client workspace for accountants). They may change after customer interviews. Every planned plan includes the same matching rules, human approval, audit log and CSV export.

What are the honest limitations?

• It is a demo. There are no accounts, no saved work and nothing to subscribe to yet.
• CSV only. Semicolon-separated files and decimal commas, both common in European bank exports, must be converted before import.
• Exact name matching. Trading names, legal suffixes and transliterations that differ will not count as name evidence, as T-03 above shows.
• Suggestions only. A pair that the engine did not suggest cannot be allocated in the demo; fix the input data, for example by adding the customer IBAN, and run it again.
• Single currency per pair. Cross-currency payments are not matched.
• No write-off or credit-note handling. A short payment caused by deducted charges remains partially open; the write-off decision belongs in your accounting system.
• No direct posting. Exports are files for you to review and import; nothing is posted to a ledger.
• Fixed rules. The weights cannot be configured and nothing is learned from past decisions. Saved matching rules are a planned feature, not a current one.

Reconciliation is one part of receivables. Related modules cover invoice payment tracking and human-approved collections.

Frequently asked questions

Is this the same as bank reconciliation software?

Not quite. Bank reconciliation software usually checks that your ledger agrees with your bank balance. DIGITAL EUR works one level down: it decides which incoming transfer settles which invoice, and hands the approved result to your accounting system.

Does DIGITAL EUR connect to my bank?

No. It works from files you export from online banking. There is no bank login, and DIGITAL EUR never holds, sends or moves money.

Is the score a probability that the match is correct?

No. It is the sum of fixed weights for the evidence found, from 0 to 100. Two suggestions with the same top score are flagged as ambiguous rather than ranked arbitrarily.

Will exact matches be posted automatically?

No. Every suggestion, including a score of 100, waits for a named person to approve it, and the approval is written to the audit log.

Does it detect duplicate payments?

It prevents them from being booked twice. A second payment for the same invoice is still suggested, because it looks plausible on its own, but approving it is refused once the invoice is fully allocated.

Can I import camt.053 or MT940 files?

Not yet. CSV is supported in the demo today. camt.053 import is planned. No other statement formats have been announced, so use your bank's CSV export for now.

What happens to a payment that matches no invoice?

It appears in the unresolved list for a person to investigate. It is not allocated simply because its amount equals an open invoice.

Can I use it with real customer data now?

We advise against it. The demo processes files only in your browser and stores nothing, but it is built for evaluation with synthetic or anonymised data until the planned security controls are in place.

Sources

• European Payments Council, SEPA Credit Transfer Scheme Rulebook 2025 version 1.0 (PDF) (accessed 5 November 2026)
• ISO 20022, Message definitions catalogue (accessed 5 November 2026)
• Visma eAccounting help, Match bank transactions (accessed 5 November 2026)
• easybill, Automated payment matching (accessed 5 November 2026)
• OWASP, CSV Injection (accessed 5 November 2026)