Drop e-invoices in. Get one spreadsheet out.

Formats

• Factur-X / ZUGFeRD — a PDF/A-3 with a factur-x.xml attachment (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 Invoice and CreditNote.
• FatturaPA — Italy's FatturaElettronica, including files carrying several invoice bodies at once, and .xml.p7m containers that most tools refuse to open.
• Facturae 3.2 — Spain's national format, including signed .xsig files, 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_1 and are unreadable by eye.
• ebInterface 4.x – 6.x — Austria's national format, which federal bodies have required since 2014. Its root element is also called Invoice, so a reader that identifies formats by that name treats it as UBL and produces a row with no number, no party and no amount — no error, just a blank line. It is identified by its contents instead.
• ISDOC 6.x — the Czech national format, which every Czech accounting package has exported for over a decade. Its root element is also called Invoice, so it is identified by namespace and contents rather than by name. Its variabilní symbol is what a Czech bank statement is matched on, not the invoice number, so it is carried through.
• Finvoice 3.0 — Finland's bank-network format, which is how most Finnish invoices actually arrive. Its dates are CCYYMMDD, its reference number (the one the Finnish bank statement is matched on) sits in a separate block and carries a check digit, and the standard rate has been 25.5% since September 2024 — a rate that any reader treating percentages as whole numbers reports as 25% or 26%.
• Spanish invoice QR — Veri*factu (Orden HAC/1177/2024) and TicketBAI. Unlike the Portuguese one, this code is a link to the tax office's checking service and carries exactly four fields: the issuer's NIF, the invoice number, the date and the total. Those four are read; net and VAT stay empty rather than zero, because a zero makes the sheet's total look right while none of the figures are. The date is dd-mm-yyyy — read as ISO, 4 March becomes 3 April and the row still looks fine.
• Portuguese invoice QR — the code that has been mandatory on every Portuguese invoice since 2022 (Despacho n.º 8632/2022). It is not a URL: it is the invoice itself in fixed fields — both VAT numbers, date, document number, ATCUD, and the taxable base and VAT for each band. The rate is computed from those amounts rather than copied from a table: the code names the band, and the same band is 23% on the mainland, 22% in Madeira and 16% in the Azores.
• myDATA (AADE) — the file every Greek invoice is reported to the tax office in, and therefore the one every Greek company has. Its VAT rate is written as a code: the standard 24% rate is 1, so a reader that copies the number through reports a 24% invoice as 1%. One file normally holds a batch of invoices, not one, and withholding tax makes the total legitimately differ from net plus VAT.
• NAV Online Számla 3.0 — Hungary's real-time reporting format, which every invoice issued there is filed in. Its VAT rate is a fraction (0.27), so a reader that copies the number through reports the EU's highest standard rate as 0.27%.
• Romanian e-Factura — UBL with the RO_CIUS rules, and the ZIP you download from SPV: the semnatura_*.xml inside it is the tax authority's signature rather than an invoice, so it is skipped instead of reported as an unreadable file.
• Swiss QR-bill payment data — the block inside the QR code on every Swiss invoice (Swiss Payments Code). It carries what the invoice body often does not: the creditor IBAN and the reference the Swiss bank statement is matched on. Two combinations there are rejected by every bank — a QR-IBAN without a QR reference, and a QR reference on an ordinary IBAN — and both are checked, along with the reference's own check digit. The code is read straight off the PDF page — which is how a Swiss bill almost always arrives — as well as from the exported text block.
• 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

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.

07 — 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?

10 per batch and 20 a day on the free tier — the day resets at midnight. Unlimited with Pro. Hundreds at a time is fine — the processing runs on your own machine.

Not sure what you are looking at?

• Open a CAMT.053 or MT940 statement — one row per transaction, with the closing balance recomputed from the opening balance.
• Check a SEPA payment or direct debit file — drop the pain.001 or pain.008 your accounting system produced and see the IBANs verified, the control sum recomputed, and anything that looks like the same invoice paid twice.
• InvoiceNow invoices, as a spreadsheet — the Singapore network runs on Peppol, so the document is the European one.
• Irish e-invoices, as a spreadsheet — Peppol UBL from a public body or a supplier, read against the EN 16931 rules by number.
• Converting invoices without uploading them — what is actually in the file, and the two-minute check that works against any tool, this one included.
• Is my country's invoice read? — the menu at the top switches the site's language; this is the other list: country by country, including what is not read.
• ISDOC invoices, as a spreadsheet — the Czech format whose root element is also called Invoice, and the variabilní symbol a Czech bank statement is matched on.
• myDATA invoices, as a spreadsheet — the Greek reporting XML, where the VAT rate is a code (24% is written 1) and the EU prefix is EL while the file says GR.
• Portuguese invoice PDFs, as a spreadsheet — between businesses in Portugal there is no e-invoice XML, but every invoice carries a mandatory QR code with the whole invoice inside it (em português).
• Τιμολόγια myDATA σε Excel — the same page in Greek, for the people who actually receive those files.
• Faturas em PDF para Excel — the Portuguese page, where that QR code is everyday knowledge.
• Facturas en PDF a Excel — the Spanish page: the Veri*factu QR carries four fields, and saying which four matters more than saying "Spain is supported".
• CFDI 4.0 a Excel — Mexico. Nearly every figure sits in an attribute, so a reader built for UBL opens the file, does not fail, and hands back a blank row.
• Facturas AFIP a Excel — Argentina. The structured file goes to AFIP, not to you; the printed QR has the total but never the net, and a number means nothing without its point of sale.
• DIAN y SUNAT a Excel — Colombia and Peru. Both invoice in UBL; what differs is where identity lives — the CUFE in cbc:UUID, the RUC behind a numeric scheme that cannot be taken on trust.
• MyInvois XML to Excel — Malaysia. UBL again, with the TIN in PartyIdentification and the line name in Description: read by the European letter, three columns come out empty without one error.
• Hóa đơn điện tử sang Excel — Vietnam. Tag names are Vietnamese abbreviations, and TSuat can be a status code like KCT rather than a rate — forced to a number it becomes NaN, which in a table looks exactly like "nothing was read".
• Egyptian ETA JSON to Excel — Egypt. The currency is only on the lines, netAmount is after the discount, and T1 is VAT while T4 is withholding — three ways to get the totals wrong.
• ZATCA invoice QR to Excel — Saudi Arabia. The XML goes to ZATCA, not to you: the QR on the page is the only machine-readable part of what arrives, and it carries no invoice number at all.
• DTE del SII a Excel — Chile. Folios run per document type, so invoice 1842 and credit note 1842 both exist; and the exempt amount is part of the net.
• e-Fatura XML'den Excel'e — Türkiye. Standard UBL, except the VKN sits in PartyIdentification and the KDV rate hangs on TaxSubtotal: a European reader leaves both tax-number columns empty and prints ?%, without one error.
• GST e-invoice JSON to Excel — India. The one structured invoice here that is not XML: dd/mm/yyyy dates, and IGST or CGST + SGST as an either/or.
• XML da NF-e para Excel — Brazil. ICMS is inside the price, so the European sum of net plus tax marks every invoice as out of balance; and a cancelled NF-e looks exactly like a valid one until you read cStat.
• NAV Online Számla XML Excelbe — the Hungarian page, for the same reason.
• ISDOC faktura do Excelu — and the Czech one.
• Online Számla XML, as a spreadsheet — the file every Hungarian invoice is reported to NAV in, where 27% is written 0.27 and a column headed "VAT %" will happily show it as 0.27.
• Luxembourg: three countries of suppliers — Peppol UBL, Factur-X and XRechnung in one table.
• Australian e-invoices, as a spreadsheet — Peppol A-NZ is the same EN 16931 file the rest of the world sends, and the ABN is a delivery address whose check digit we verify
• Every rule this checker applies — all 62 checks with what each one means in one sentence, and where the rule comes from (which decides who can waive it)
• Verkkolasku Exceliin — for Finnish readers: Peppol BIS and Finvoice 3.0 are both read, and why the Y-tunnus is a delivery address rather than a name
• E-faktura till Excel — for Swedish readers: the organisation number is a delivery address, the OCR number is not the invoice number, and the check digit cannot tell a company from a person
• OIOUBL-faktura til Excel — for Danish readers: OIOUBL and Peppol are the same kind of file, the CVR number is the only number a Danish company has, and where the payment reference belongs
• EHF-faktura til Excel — for Norwegian readers: why EHF is Peppol BIS under another name, why the organisation number is a delivery address rather than a name, and where the KID belongs
• Which e-invoice format is this? — telling UBL, CII, Factur-X, FatturaPA, Facturae and KSeF apart by looking at the file, why the same norm has six national names, and what a conversion has to get right

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.