Hand your accountant evidence, not spreadsheets

Short answer

An accountant-ready reconciliation export is a file your accountant can check without rebuilding your work: which payment settled which invoice, for how much, who approved it and when. DIGITAL EUR's demo exports approved allocations as a formula-safe CSV and keeps an append-only audit log on screen. Exporting the audit log and invoice summary is planned.

What does "accountant-ready" mean here?

Most small businesses hand their accountant two things: a bank statement and a spreadsheet of invoices marked "paid" by hand. The accountant then has to redo the matching to trust it. An accountant-ready export removes that step by carrying the decision and its evidence with every line.

We use four tests. An export is accountant-ready when:

1. Every line is traceable to one invoice ID and one bank transaction ID that exist in the source files.
2. Every amount is exact, in cents, with the currency stated, and never larger than either the invoice or the payment allows.
3. Every line names a decision-maker and a time, so responsibility is clear.
4. The file is safe and portable: it opens in any spreadsheet or accounting import without running formulas, and without needing our software.

What the export is not: it is not a journal entry, a ledger posting or proof that money arrived. In the demo, each row says so explicitly. Posting remains a job for your accounting system and your accountant.

What is in the export today?

The Reconciliation Lab produces one file, digital-eur-demo-approved-allocations.csv, once at least one suggestion has been approved. It is generated in your browser.

The file follows the conventions of RFC 4180, the informational specification for CSV: records end with CRLF, fields containing commas, quotes or line breaks are enclosed in double quotes, and a quote inside a field is doubled. One row is written per allocation, so a payment split across two invoices produces two rows, and two partial payments for one invoice produce two rows.

How do split and partial payments appear?

Because the file has one row per allocation, the same transaction ID or the same invoice ID can appear more than once. That is intended, and it is how an accountant can see what happened:

To check the file, sum the amount column by transaction_id and compare it with the bank statement, then sum it by invoice_id and compare it with the invoice totals. Neither sum can exceed the original amount: the engine refuses any approval that would allocate more than a payment carried or more than an invoice owed.

What stays on screen and is not exported yet?

We list these openly because an accountant asking "what was left open?" needs the unresolved list and the outstanding balances, not just the matches. Until those exports exist, copy the on-screen tables or take the open items from your invoice system. Closing or reloading the Lab discards everything, including the audit log, so export before you leave.

How does the audit trail work?

A reconciliation audit trail is a chronological record of who decided what, and when. In DIGITAL EUR it is append-only: every approval, rejection and reversal adds a new event, and earlier events are never edited or deleted. Each event records:

• a sequential ID (evt-0001, evt-0002, …);
• the time, in UTC;
• the reviewer's name;
• the action: APPROVE, REJECT or REVERSE_AND_REJECT;
• the invoice and the bank transaction;
• the amount allocated or released.

Corrections never rewrite history. If an approved allocation turns out to be wrong, rejecting it releases the amount and writes a REVERSE_AND_REJECT event; the original approval stays in the log. The export, by contrast, shows the current state: the reversed allocation disappears from the file, and the correct one appears. The two together answer both questions an auditor asks: what is the position now, and how did it get there.

A worked example: a correction your accountant can follow

The data is invented; the IBAN is the widely published example NL91 ABNA 0417 1643 00. Every result below was produced by running the current rules (demo-rules-1) on these inputs.

Open invoices: INV-2026-0301 and INV-2026-0302, each €1,000.00 to Harbour Events BV with the IBAN above stored; INV-2026-0303, €2,400.00 to Atelier Vidal SL.

Bank lines: B-101, €1,000.00 from Harbour Events BV, remittance "October services"; B-102, €1,200.00 from Atelier Vidal SL, "INV-2026-0303 first half"; B-103, a €45.00 debit, "Card terminal fee".

Suggestions: B-101 scores 35 for both Harbour invoices (EXACT_AMOUNT, COUNTERPARTY_IBAN, COUNTERPARTY_NAME), and both are flagged AMBIGUOUS because nothing in the payment says which invoice it pays. B-102 scores 55 for INV-2026-0303 (INVOICE_REFERENCE, POSSIBLE_PARTIAL_PAYMENT, COUNTERPARTY_NAME). B-103 is a debit and is listed as unresolved.

What the reviewer does: approves B-101 against INV-2026-0301; then the customer confirms by email that the payment was for INV-2026-0302. The reviewer rejects the first allocation and approves the second. Finally, the reviewer approves B-102 as a partial payment.

Audit log

Exported CSV

invoice_id,transaction_id,amount,currency,approved_by,approved_at,note
INV-2026-0302,B-101,1000.00,EUR,A. Novak,2026-11-05T08:02:00.000Z,"DEMO export - not an accounting entry, no payment made"
INV-2026-0303,B-102,1200.00,EUR,A. Novak,2026-11-05T08:03:00.000Z,"DEMO export - not an accounting entry, no payment made"

Invoice status on screen: INV-2026-0301 open, €1,000.00 outstanding; INV-2026-0302 fully allocated; INV-2026-0303 partially allocated, €1,200.00 outstanding.

The accountant can now see that the reversal was a correction, not a lost payment; that B-103 was never treated as a receipt; and that INV-2026-0303 is half paid. The one thing the file cannot show is why the reviewer changed their mind. Keep the customer's email with your records; a note field per decision is a sensible addition we are considering, not a commitment.

Why is the export formula-safe?

Payment references, names and IDs come from third parties. A spreadsheet treats a cell that starts with certain characters as a formula, which can run commands or leak data when the file is opened. The OWASP CSV Injection page describes this risk. DIGITAL EUR prefixes any cell that starts with =, +, -, @, a tab or a carriage return with a single quote, so the spreadsheet reads it as text.

Two honest notes. OWASP also lists line feeds and full-width variants of these characters as possible triggers; our prefix rule does not cover them, although imported values are trimmed of leading line breaks. And OWASP warns that no escaping method is reliable in every spreadsheet program after a file has been saved and reopened. Treat any CSV from an external source with normal care.

How should your accountant open the file?

• Use the import wizard, not a double-click, if your spreadsheet uses a decimal comma (common in Germany, France, Bulgaria and elsewhere). Otherwise 1000.00 may be read as text or as a different number. Tell the wizard that the separator is a comma and the decimal mark is a dot.
• Keep IDs as text. IDs such as 0457 can lose their leading zero if a column is converted to numbers.
• Remember timestamps are UTC. An approval at 23:30 UTC on 31 October is 1 November in Sofia or Berlin. For month-end cut-offs, convert to your local time zone.
• Match totals. The sum of the amount column should equal the receipts you consider settled; anything else on the bank statement belongs to the unresolved list.

What is planned for accountants?

The following are on our product plan for after the demo. They are PLANNED, with no release date:

• user accounts, so approvals are tied to a signed-in person rather than a typed name;
• stored, append-only audit events and an audit-log export;
• exports of the invoice status summary, unresolved transactions and the reason codes behind each allocation;
• an accountant invitation with limited access, which can be revoked;
• a multi-client workspace and bulk export for firms (listed in the Agency plan on the pricing page).

Export layouts for specific accounting packages are not committed. CSV remains the format we design for, because every accounting system can import it. For the wider view of how accounting firms might use DIGITAL EUR, see bank reconciliation software for accountants.

Where does the export fit in a month-end close?

The export is one step in a longer routine. A typical month-end for a small business that invoices in euro could look like this:

1. Export open invoices and the month's bank statement from your invoicing tool and online banking. The bank statement import page lists the file rules and the checks to make before you download.
2. Match and review in the Lab. Suggestions, scores and exceptions are explained on the bank transfer reconciliation software page; SEPA-specific evidence such as RF creditor references is covered on the SEPA invoice matching page.
3. Resolve what you can, approve allocations, and note decisions that need an explanation (a customer email, a credit note).
4. Export the approved allocations and copy the open items and partial payments from the screen.
5. Hand over the export, the original bank statement and the notes to your accountant, who posts the entries and ties the bank balance to the ledger.
6. Follow up open items. Unexplained receipts may be refunds to make or payments for invoices not yet issued; short payments may be bank charges to write off or balances to chase. Those are accounting decisions, not software decisions.

Our SEPA reconciliation guide describes the full manual process, including a month-end checklist, if you want to see what the software is replacing.

How does this compare with what accounting tools offer?

Vendors' public documentation, read on 5 November 2026, shows a range of approaches:

Balance-level tools answer "does the ledger agree with the bank?". DIGITAL EUR answers a narrower question, "which payment settled which invoice, and who decided?", and is meant to sit beside your accounting system, not replace it. If you need an audit pack with opening and closing balance tie-outs, that comes from your bookkeeping software; our export supplies the receivables detail behind it.

What should an accountant check in any reconciliation export?

Use this checklist for DIGITAL EUR or any other tool:

1. Can every exported line be traced to a source invoice and a source bank line?
2. Are amounts exact, in cents, with currency, and capped at what was owed and what was paid?
3. Does each line name a person and a time?
4. Are corrections recorded as reversals rather than deletions?
5. Are open items, partial payments and unexplained receipts visible somewhere?
6. Are formula-trigger characters neutralised?
7. Can the file be opened without the vendor's software?
8. Does the vendor say clearly which parts are live and which are planned?

DIGITAL EUR's demo meets 1, 2, 3, 4, 6, 7 and 8 for allocations; item 5 is met on screen but not yet in the export.

How is data handled?

Everything in the demo runs in your browser. Nothing is uploaded, stored or sent to us, and the audit log disappears with the page. The reviewer name is whatever you type; it is not verified. Use synthetic or anonymised data. Controls that must exist before any customer data is accepted are listed on the security page.

What are the honest limitations?

• The audit log, invoice summary and unresolved list are not exported yet.
• The reviewer name is not authenticated.
• Nothing is saved between sessions.
• The export holds allocations, not journal entries, balances or tax information.
• Amounts use a dot decimal; spreadsheets with comma decimals need the import wizard.
• Retention periods for business records differ by country; ask your accountant how long to keep exports.

Frequently asked questions

Can I send the export straight to my accountant?

Yes. It is a plain CSV generated in your browser. In the demo, every row is labelled as a demo export and not an accounting entry.

Does the export include the audit trail?

Not yet. The audit log is shown in the Lab and is append-only, but exporting it is planned.

What happens to an allocation I reversed?

It disappears from the export, which shows the current state. The audit log keeps both the original approval and the reversal.

Is the export an accounting entry?

No. It records approved allocations of payments to invoices. Your accountant posts the entries in your accounting system.

Which accounting software can import it?

Any software that imports CSV, after mapping the columns. Ready-made layouts for specific packages are not committed.

Why are some cells prefixed with an apostrophe?

To stop a spreadsheet from executing them as formulas. Depending on the program, the apostrophe may stay visible; it only marks the cell as text.

Are timestamps in my local time?

No. They are in UTC, so convert them for month-end cut-offs.

Sources

• IETF, RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files (accessed 5 November 2026)
• OWASP, CSV Injection (accessed 5 November 2026)
• Certinia, Bank Reconciliation Report (accessed 5 November 2026)
• Docyt, Reconciliation Center: export data as CSV (accessed 5 November 2026)
• Oracle, Exporting transactions to CSV format (Account Reconciliation) (accessed 5 November 2026)
• Terra Insight, Bank reconciliation audit request list and evidence export checklist (accessed 5 November 2026)