Short answer
Bank reconciliation software for accountants should let a practice match each client's incoming euro transfers to that client's open invoices, show every exception with its reason, and leave evidence a reviewer can check. DIGITAL EUR does the matching and review today in a free in-browser demo, one client file at a time. Multi-client workspaces, saved history and ledger exports are planned, not available.
What does a practice's reconciliation month actually look like?
For a bookkeeping or accounting firm, the arithmetic of reconciliation is rarely the hard part. The hard part is doing the same careful work for twenty, forty or eighty clients, each with a different bank, a different export format and a different idea of what "I sent you everything" means. A typical month-end cycle for a practice looks like this:
- Collect. Request bank statements or CSV exports from each client, plus an up-to-date list of open sales invoices. Some clients send files on time; others send a PDF, a screenshot or nothing.
- Normalise. Bring each bank's export into a shape your tools can read: one row per transaction, consistent dates, a sign or direction column, one decimal convention.
- Match. Pair incoming credits with the invoices they settle. Most are easy. A minority (payments without a reference, combined payments, part payments, payers whose name differs from the customer on the invoice) take most of the time.
- Query. Ask the client about anything you cannot explain: "Who is Unknown Payer Example and what was €950 for?"
- Review and sign off. A second person checks the matches, especially judgement calls, before the period is closed.
- Post and report. Record the results in the client's ledger and, where useful, tell the client which customers still owe money.
Practitioners describing this work in public forums keep returning to the same pain points: work spread across many spreadsheets, unmatched items that are hard to chase, and losing track of where each client stands. Vendor guides written for practices make the same observation from the other side: at thirty or more clients, the bottleneck is tracking status and review, not the matching formula.
DIGITAL EUR is aimed at step 3, with direct support for steps 4 and 5: it ranks candidate matches with visible reasons, flags what needs a decision, and records who decided what. It does not replace the client's accounting system, and it does not collect files from clients for you.
Is this full bank reconciliation, or something narrower?
It is narrower, and the difference matters for an accountant.
In accounting, a bank reconciliation usually means agreeing the bank balance with the cash-book balance: every receipt and payment in the ledger is ticked against the statement, timing differences such as uncleared items are listed, and the two balances are proved to agree at the period end.
DIGITAL EUR reconciles incoming bank credits against open sales invoices. It answers "which invoice did this transfer settle, and how much is still open?" It does not process outgoing payments (debit lines are left unresolved by design), supplier bills, payroll, loan movements or the cash-book balance. Think of it as accounts receivable payment matching that feeds the full reconciliation you already perform, not as the full reconciliation itself.
| Task in a client's month-end | Handled by DIGITAL EUR today? | Where it is done instead |
|---|---|---|
| Matching customer transfers to sales invoices | Yes, in the demo, one client file at a time | — |
| Flagging part payments, overpayments and ties | Yes, with reason codes | — |
| Recording who approved each allocation | Yes, append-only audit log (kept only while the page is open) | — |
| Outgoing payments, supplier bills, payroll | No | The client's accounting system |
| Proving bank balance equals ledger balance | No | The client's accounting system |
| Posting entries to the ledger | No | The client's accounting system |
What does DIGITAL EUR do today, and what is planned?
DEMO (available now, free, no account): the Reconciliation Lab runs in your browser. You paste or load one invoice CSV and one bank transaction CSV, review suggestions, approve or reject them under a reviewer name, and export the approved allocations as CSV. Files are read locally and are not uploaded or stored; reloading the page discards everything.
PLANNED (not available, no date promised):
- a multi-client workspace with one separate organisation per client;
- saved matching history so last month's decisions are still there next month;
- bulk import and export across clients;
- an approval workflow that separates preparer and reviewer roles;
- bank statement import in camt.053 format, described on our bank statement import page;
- export layouts designed for accounting systems, described on our accountant export page.
The illustrative Agency plan on our pricing page lists 10 client organisations and a multi-client workspace at €129 per month. That is a pre-launch test price; there is no checkout and nothing can be bought.
How does the matching decide?
Every suggestion is built from four pieces of evidence, each with a fixed weight, and two penalties. The score is a transparent rule total, not a probability.
| Reason code | Points | What it means |
|---|---|---|
| INVOICE_REFERENCE | +65 | The invoice reference appears as a whole token in the remittance text |
| EXACT_AMOUNT | +20 | The transfer equals the invoice's amount due |
| COUNTERPARTY_IBAN | +10 | The payer's IBAN equals the IBAN stored for the customer |
| COUNTERPARTY_NAME | +5 | The payer's name equals the customer name after normalisation |
| POSSIBLE_PARTIAL_PAYMENT | −15 | The transfer is less than the amount due |
| AMOUNT_EXCEEDS_OUTSTANDING | −25 | The transfer is more than the amount due |
Four rules matter in a practice setting:
- No evidence, no suggestion. A transfer that only happens to have the same amount as an invoice produces no candidate. There must be a reference, IBAN or name match.
- Whole references only. A reference must match as complete tokens, so INV-12 never matches INV-123, while separators are flexible: "A 2026 103" matches A-2026-103.
- Names must match exactly after normalisation. Case and punctuation are ignored, so "Example G.m.b.H." equals "Example GmbH", but "Example GmbH Berlin" does not. A trading name or parent company will not match.
- Ties are shown, not broken silently. When two invoices share the top score, both are marked ambiguous and a person chooses.
Every suggestion, including a perfect 100, stays pending until someone approves it. Allocations are capped at the invoice's outstanding amount and the transfer's remaining amount, so one approval cannot over-allocate either side. The full rule description is on the reconciliation product page.
Worked example: one client's month, with synthetic data
The data below is invented. Alder Design Example OÜ is a fictional client of a fictional practice. We ran these exact files through the matching code that powers the demo.
Open invoices (client's export):
| invoice_id | customer_name | amount_due | reference | customer_iban |
|---|---|---|---|---|
| A-2026-101 | Kestrel Example BV | 1200.00 | A-2026-101 | NL00EXAMPLE0000000101 |
| A-2026-102 | Kestrel Example BV | 800.00 | A-2026-102 | NL00EXAMPLE0000000101 |
| A-2026-103 | Lumen Example SARL | 2450.00 | A-2026-103 | FR00EXAMPLE0000000103 |
| A-2026-104 | Moss Example Kft | 600.00 | A-2026-104 | — |
| A-2026-105 | Moss Example Kft | 600.00 | A-2026-105 | — |
Bank lines (client's bank CSV):
| transaction_id | amount | remittance | direction | counterparty_name |
|---|---|---|---|---|
| B01 | 2000.00 | A-2026-101 A-2026-102 | CRDT | Kestrel Example BV |
| B02 | 2450.00 | Invoice A 2026 103 | CRDT | Lumen Example SARL |
| B03 | 600.00 | Moss Example payment | CRDT | Moss Example Kft |
| B04 | 950.00 | Consulting fee October | CRDT | Unknown Payer Example |
| B05 | 12.50 | Account maintenance fee | DBIT | Example Bank |
What the engine returned:
| Transfer | Candidate invoice | Score | Reasons | Flag |
|---|---|---|---|---|
| B01 | A-2026-101 | 55 | reference, IBAN, name, exceeds outstanding | Ambiguous |
| B01 | A-2026-102 | 55 | reference, IBAN, name, exceeds outstanding | Ambiguous |
| B02 | A-2026-103 | 100 | reference, exact amount, IBAN, name | — |
| B03 | A-2026-104 | 25 | exact amount, name | Ambiguous |
| B03 | A-2026-105 | 25 | exact amount, name | Ambiguous |
| B04 | — | — | no reference, IBAN or name evidence | Unresolved |
| B05 | — | — | outgoing debit, not matched | Unresolved |
How a reviewer would work through it:
- B02 → A-2026-103. Every signal agrees. Approve; €2,450.00 is allocated and the invoice is fully allocated.
- B01, the combined payment. Kestrel paid two invoices in one transfer. Each candidate scores 55 because the €2,000 exceeds each invoice on its own, and the tie is flagged. That is the right outcome: the software should not guess. The reviewer approves both. The first approval allocates €1,200.00 to A-2026-101; the second allocates the remaining €800.00 to A-2026-102. Both invoices are closed and the transfer is fully used.
- B03, the ambiguous €600. Moss Example Kft has two identical invoices and paid one without a reference. The evidence cannot say which. The practice should ask the client, or apply the client's documented policy (for example, oldest invoice first), and record that decision under the reviewer's name.
- B04, the unknown payer. No evidence links it to any open invoice. This goes on the client query list. It may be a sale invoiced outside the export, a deposit, or a payment that belongs to another entity.
- B05, the bank fee. Outgoing lines are outside the scope of receivables matching. It belongs in the full bank reconciliation in the client's ledger.
At the end, the export contains three approved allocations (B02, and B01 split over two invoices), each with the reviewer's name and timestamp. The open items for the client email are B03 (which invoice?) and B04 (what is it?).
How should a practice handle exceptions across many clients?
An exception list is only useful if it leads to a decision. We suggest classifying every open item into one of five buckets, because each bucket has a different owner:
| Exception type | Typical cause | Who resolves it | Evidence to keep |
|---|---|---|---|
| Ambiguous tie | Same payer, same amount, no reference | Client confirms, or documented policy applies | Client's reply or policy reference |
| Part payment | Instalment, deduction, dispute | Client confirms the reason | Note on whether the balance is still due |
| Overpayment or combined payment | Several invoices in one transfer, or a duplicate | Reviewer splits; client confirms duplicates | Split amounts per invoice |
| Unknown payer | Parent company, private card, third party | Client identifies the payer | Client's reply |
| Out of scope | Fees, refunds, loans, owner transfers | Handled in the ledger reconciliation | Ledger reference |
Today, the demo gives you this view for one client at a time. A practice using it would run each client's files separately and copy the open items into its own tracker. A cross-client accounting exceptions dashboard, showing open items by client and by age, is part of the planned multi-client workspace; it does not exist yet.
What should a client send you so matching works?
Most matching problems are created before the file reaches you. A short request letter to clients saves hours:
- The open-invoice list as CSV, with at least invoice number, customer name, currency, amount due and the payment reference printed on the invoice. Add the customer's IBAN if the client knows it.
- The bank export as CSV for the same period, including the remittance text, the payer's name and IBAN, and a column that distinguishes credits from debits.
- Dot decimals and comma separators. The demo reads comma-separated files with amounts such as 1250.00. Exports using decimal commas or semicolons need converting first. Files may be up to 2 MB and 20,000 rows.
- A note on known exceptions: deposits received, customers paying via a parent company, and invoices cancelled or credited.
The column names the demo expects are listed in the Lab itself. If you regularly receive malformed exports, our bank statement CSV validator is designed for checking files before you start.
There is also a longer-term fix: encourage clients to print a structured reference on every invoice. The European Payments Council's SEPA Credit Transfer rulebook gives the remittance field 140 characters, requires banks to pass it on in full and without alteration, and recommends the ISO 11649 structured creditor reference (the "RF" reference) for payments that refer to a single invoice. Our SEPA reconciliation guide explains how to adopt it.
How does this compare with what a practice uses today?
| Approach | Strengths | Weaknesses for receivables matching |
|---|---|---|
| Spreadsheet with lookups | Free, flexible, familiar | Matches on one field at a time; no record of who decided; easy to overwrite |
| Matching inside the client's accounting system | Bank feeds, posting in one place, rules per client | Works only for clients on that system; rule logic is often opaque; evidence for judgement calls varies by product |
| Dedicated enterprise reconciliation platforms | High volumes, many entities, configurable rules | Usually priced and sized for finance teams, not small practices |
| DIGITAL EUR demo (today) | Visible reasons per suggestion, ties never auto-resolved, capped allocations, audit log, safe CSV export | One client file at a time, nothing saved, no bank feeds, no posting, euro receivables only |
Cloud accounting suites such as Xero and Zoho Books include bank reconciliation with feeds and matching suggestions, and for clients already on those systems they are often the right place to work. DIGITAL EUR is meant to sit in front of the ledger: useful when a client's data arrives as files, when you want to see exactly why each match was suggested, or when you need an evidence trail of judgement calls. A balanced side-by-side is on our Xero alternative comparison, and the general trade-offs are covered in automatic vs manual reconciliation.
What about client data and GDPR?
Client bank statements contain personal data: payer names, IBANs and remittance text about named people. When a practice uses software to process that data on a client's behalf, the GDPR's processor rules apply along the chain. Article 28 requires processing to be governed by a contract that sets out, among other things, the subject matter, duration, nature and purpose of processing, the type of personal data and the categories of data subjects, and requires the processor to act only on documented instructions.
Today the question is simpler: the demo processes files in your browser and does not upload or store them, so DIGITAL EUR receives no client data. Even so, use synthetic or anonymised files in the demo. Before hosted accounts open, we plan to offer a data processing agreement, tenant isolation and a published retention policy; the full list of planned controls is on our security page. This is a description of our plans, not legal advice on your engagement letters.
How to evaluate any reconciliation tool for your practice
Use the same checklist on us and on anyone else:
- Run one real client month. Use a recent, anonymised month with known answers. Count how many suggestions were right, how many were wrong and how many were missed.
- Inspect a wrong suggestion. Can you see why it was made? If not, you cannot explain it to a reviewer or a client.
- Test the hard cases: a combined payment, a part payment, two identical invoices, and a payment from a parent company.
- Check that nothing posts without approval. Ask whether exact matches are booked automatically and whether that can be switched off.
- Check client separation. Can a user who works on client A see client B's data? Ask how this is tested.
- Check the export. Open it in a spreadsheet. Are amounts exact, are references intact, and is formula injection neutralised?
- Check the evidence. Is there a log of who approved what, and is it append-only?
- Price per client, not per user. For a practice, cost per client organisation is the useful comparison.
- Ask what happens on exit. Can you export every client's history in an open format?
The DIGITAL EUR demo passes points 2, 3, 4, 6 and 7 for a single client file today. Points 5, 8 and 9 depend on the planned hosted product and cannot be tested yet.
Who is this a good fit for, and who should look elsewhere?
Likely fit: small practices and freelance bookkeepers whose clients invoice in euro and are paid mainly by bank transfer; practices that receive client data as files rather than through a shared ledger; reviewers who want each judgement call documented.
Not a fit today: practices that need bank feeds, automatic posting, multi-currency matching, card or direct-debit settlement reports, or a saved history across months. None of these exists yet. If you serve agencies or consultancies, our pages on agency receivables and consultancy payment reconciliation describe the patterns you will see in their files.
Frequently asked questions
Can I reconcile several clients in DIGITAL EUR today?
Only one at a time. The demo holds one invoice file and one bank file per session and keeps nothing after you reload. The matching code already keeps a tenant identifier on every row and never pairs an invoice with a transaction from a different tenant, but the multi-client workspace that would use this is planned, not built.
Does it connect to my clients' banks?
No. There are no bank feeds and no bank logins. You work from files the client exports. Reading bank accounts directly would require a licensed account information service, which we do not offer.
Will it post matches to my client's ledger?
No. It produces a CSV of approved allocations, marked as a demo export and not an accounting entry. Ledger-ready export layouts are planned; see the accountant export page.
What happens to payments that match nothing?
They are listed as unresolved, together with all outgoing debits. That list is your starting point for client queries.
Is the score a confidence percentage?
No. It is the sum of fixed rule points. A score of 55 means "reference, IBAN and name found, but the amount is higher than this invoice", which is exactly what a combined payment looks like.
Can I use real client data in the demo?
Files stay in your browser, but we still recommend synthetic or anonymised data until hosted accounts with a data processing agreement exist.
How much will the multi-client plan cost?
The illustrative Agency plan is €129 per month for 10 client organisations. It is a test price, excludes VAT and cannot be purchased.
Sources
- European Payments Council, SEPA Credit Transfer Scheme Rulebook 2025 version 1.0 (PDF), section on remittance information (accessed 5 November 2026)
- Regulation (EU) 2016/679 (GDPR), Article 28, as adopted, via legislation.gov.uk and EUR-Lex (accessed 5 November 2026)
- AAT Community, "Has anyone else found bank rec a bit of a nightmare with multiple clients?" — practitioner description of multi-client pain points (accessed 5 November 2026)
- Xenett, How to do a bank reconciliation (29 May 2026) — vendor guide on reconciliation at 30+ clients (accessed 5 November 2026)
- Xero, Bank reconciliation guide for accountants and bookkeepers (14 June 2026) — bank feeds and matching in Xero (accessed 5 November 2026)
- Zoho Books Help, Match and categorise transactions — bank feeds, statement import and suggested matches in Zoho Books (accessed 5 November 2026)