01 — What it reads
Read from the XML, not from the page
Since 2025 most EU invoices carry structured data alongside the human-readable page. Ledgerdrop reads that data directly, which is why the numbers come out exact rather than approximately right. Drop a plain PDF with no embedded data and Ledgerdrop will tell you so instead of quietly inventing numbers.
- Duplicates across batches
An invoice you exported in March is flagged when it turns up again in April's folder. Only the invoice numbers are remembered, per client, in your own browser — and there is a button to forget them.
- Currencies stay apart
Totals are per currency, and the export gets one total row per currency. Adding 12,000 EUR to 18,800 PLN produces a number that looks perfectly normal and means nothing — which makes it more dangerous than a blank cell.
- IRPF, stamp duty, withholding
Spanish and Italian document totals legitimately differ from net plus VAT. Those are reconciled before an invoice is called wrong, so the flag column keeps meaning something.
- Ledger, CSV or DATEV
An .xlsx with a ledger sheet and a summary sheet by month and supplier, a plain CSV, or a Buchungsstapel in DATEV's EXTF 700 format with all 125 columns.
Formats
- Factur-X / ZUGFeRD — a PDF/A-3 with a
factur-x.xmlattachment (UN/CEFACT CII), including ZUGFeRD 1.0 from 2014, which German systems still emit and which most current tools quietly skip. - XRechnung — both the CII and the UBL flavour, embedded or standalone.
- Peppol BIS Billing 3.0 — UBL 2.1
InvoiceandCreditNote. - FatturaPA — Italy's
FatturaElettronica, including files carrying several invoice bodies at once, and.xml.p7mcontainers that most tools refuse to open. - Facturae 3.2 — Spain's national format, including signed
.xsigfiles, where the XAdES signature sits inside the XML itself. - KSeF FA(2) and FA(3) — Poland's national e-invoice, whose fields are numbered
P_1,P_2,P_13_1and are unreadable by eye. - Romanian e-Factura — UBL with the RO_CIUS rules, and the ZIP you download from
SPV: the
semnatura_*.xmlinside it is the tax authority's signature rather than an invoice, so it is skipped instead of reported as an unreadable file. - Structured payment references — the Belgian gestructureerde mededeling, the Swiss QR reference, the Norwegian KID: in those countries the bank's remittance text carries that number rather than the invoice number, so matching on the invoice number alone cannot work. Ledgerdrop reads it (BT-83) and matches on it too.
- EN 16931 in general — the semantic model the European formats conform to.
What lands in the spreadsheet
- Invoice number, issue and due date, buyer reference, currency
- Supplier and customer names with their VAT identifiers
- Net, VAT and gross totals — plus a check that they actually add up
- Line item descriptions, merged per invoice
- An EN 16931 check on every invoice that carries structured data
- Enter your own VAT ID and each invoice is marked purchase or sale, which also gives you a VAT summary by rate — output tax, input tax, and the difference
02 — Compliance
Is this invoice actually compliant?
Receiving a non-compliant invoice is your problem, not only the sender's: if the document does not meet the requirements, the input VAT may not be deductible. But the requirements live in an XML file nobody can read by eye. Ledgerdrop checks each invoice against EN 16931 and shows the rule numbers, so you can quote them back to the supplier.
Being precise about the limits: this is a subset of EN 16931, chosen because those rules are unambiguous. Rules that turn on code lists, VAT category semantics or national extensions are not implemented — a half-right compliance verdict is worse than an honest gap. Where an invoice carries no structured data at all, the column simply reads "—" rather than passing it.
| BR-01 … BR-16 | Mandatory fields: specification identifier, invoice number and date, type and currency code, both parties with postal address and country, totals, and at least one line |
| BR-CO-10, BR-CO-13 … 16 | Arithmetic: line amounts sum to the stated line total, allowances and charges reconcile, VAT adds up, amount due follows from the total less prepayments |
| BR-S-08, BR-S-09 | Per VAT rate: the taxable amount at each rate matches the lines at that rate, and the VAT is that rate applied to that base |
Sending invoices too? The same check, on one file at a time, is free at /validate/ — the rules that get an invoice rejected are the same ones, seen from the other side.
03 — Reconciliation
Drop the bank statement in too
Ledgerdrop reads CAMT.053 (ISO 20022) and MT940 statements from the same box, then matches payments to invoices: the invoice number in the payment reference, the amount, the counterparty name and a sensible date window. Matching an invoice to its payment needs both sides at once — which is exactly what you already have open here.
- Paid or open, per invoice
Every invoice comes out marked, and statement entries that match nothing stay visible instead of disappearing.
- No guessing
Where the signals are not strong enough, no match is made. A wrong match is harder to notice than a missing one, so the tool leaves those to you.
- Balance check
The statement is checked against its own opening and closing balance. If the file is truncated you find out immediately rather than three reconciliations later.
04 — Privacy
Verify the privacy claim yourself
Invoices carry VAT numbers, amounts and the names of everyone you trade with. That should not be uploaded to a stranger's server to be turned into a spreadsheet.
- Open the Network panel while you process a batch — there are no upload requests.
- Disconnect from the internet once the page has loaded; everything still works.
- No accounts, no server, no database. The licence key is verified offline by signature.
- The site's Content-Security-Policy forbids outbound connections, so the browser enforces this rather than asking you to trust a promise.
05 — Pricing
One payment, no renewal
Free
- 10 invoices per batch
- Every parser, no limits on formats
- Export carries one attribution line
Office
- 5 licence keys, one per colleague
- Per-client profiles: accounts and tax keys stay separate
- Everything in Pro
- One payment, no renewal
06 — Questions
Questions
- How do I convert a Factur-X or ZUGFeRD PDF to Excel?
- Drop the PDF in. Ledgerdrop opens the embedded XML attachment and reads the fields from it, so no OCR and no layout guessing is involved.
- Can it handle a plain XML file from Peppol?
- Yes — UBL 2.1 Invoice and CreditNote documents parse directly, as do standalone CII files.
- What about Italian .p7m files?
- Drop them in. Ledgerdrop reads the invoice out of the CAdES container so you do not have to unwrap it first. To be precise about what that means: it reads the signed document, it does not verify the signature — use your certified provider's portal if you need that. An Italian invoice can also carry several invoice bodies in one file; each becomes its own row.
- I have invoices in several currencies. Are they added together?
- No. Totals are shown per currency, and the exported ledger gets one total row per currency. Adding 12,000 EUR to 18,800 PLN produces a number that looks perfectly normal and means nothing — which makes it more dangerous than a blank cell.
- Why does my Spanish invoice total not equal net plus VAT?
- Because Spanish invoices from freelancers and professionals carry an IRPF withholding that is subtracted from the total: 3,900 € at 21 % VAT with 15 % withheld comes to 4,134 €, not 4,719 €. Ledgerdrop applies the Facturae formula before deciding a total is wrong, so it does not flag nearly every Spanish invoice. The withholding is not VAT, so it stays out of the VAT summary.
- Why does my Italian invoice total not equal net plus VAT?
- Because it legitimately may not — stamp duty, pension-fund contributions and withholding tax all move the document total. Ledgerdrop reconciles those before deciding whether a total actually looks wrong, so it does not flag every Italian invoice you own.
- What happens with a scanned or plain PDF?
- It is reported as having no embedded invoice data. Ledgerdrop will not fabricate values it cannot read.
- Does it detect duplicates?
- Invoices sharing a number are highlighted in the table and flagged in the export. Booking the same invoice twice is the expensive mistake this is designed to catch.
- Are credit notes supported?
- Yes, including negative totals, and they are labelled as credit notes in the ledger.
- I handle several clients — do I re-enter the accounts every time?
- No. Create a client at the top of the page; accounts and tax keys are stored per client. Switching clients clears the workspace, so documents from two clients cannot end up in the same batch — a mistake that otherwise surfaces only at audit time.
- Can I import the result into DATEV?
- Yes — the export produces a Buchungsstapel in DATEV's EXTF 700 format, correctly encoded and with all 125 columns present. Accounts and tax keys are not guessed: you enter them once and they stay on your device. An invoice carrying several VAT rates is refused by name rather than booked with a single averaged key, because that would be wrong.
- How many invoices at once?
- Ten per batch on the free tier, unlimited with Pro. Hundreds at a time is fine — the processing runs on your own machine.
Building software that reads these files?
The parsing core behind this site — every format above, no server, no telemetry — might be worth licensing as a library. It is not built as a product yet, and the developers page says so plainly; it is there to find out whether anyone would use it.