LedgerdropCZ

ISDOC → spreadsheet

ISDOC invoices, as a spreadsheet

Pohoda, Money, ABRA and Helios have all exported ISDOC for well over a decade. It is an open Czech format — and it is not EN 16931, so most European tools read nothing out of it.

Drop the files here →

ISDOC 6.xvariabilní symbolIBAN check digitsPeppol BIS 3.0

01 — The trap with no error message

Its root element is also Invoice

A UBL invoice and an ISDOC invoice both open with an element called Invoice. A reader that identifies formats by that name treats the Czech one as UBL — and then there is no error, just a row where everything is empty: no number, no supplier, no amount.

Here the namespace is checked first (isdoc.cz), and if the export stripped it, at least two elements that only ISDOC has must be present. One is not enough — plenty of unrelated documents have a single matching tag.

02 — The field the bank actually uses

Variabilní symbol, not the invoice number

A Czech bank statement matches payments on the variabilní symbol. Reconcile on the invoice number alone and nothing lines up, however carefully the numbers are read.

So it is carried into its own column, alongside the account — IBAN when the file has one, otherwise the domestic number/bank code pair. IBAN check digits are recomputed (ISO 13616, mod 97-10), which catches a typo without asking anyone.

Two dates that are not the same date

ISDOC carries both an issue date and a tax point date (DUZP), and Czech period allocation follows the tax point. They are kept apart: the tax point never overwrites the issue date, and is only used if the issue date is missing.

Collapsing two dates into one column is worse than leaving one empty. An empty cell is visible; a wrong date that looks plausible gets booked.

Advance payments, and totals that legitimately differ

When deposits have been paid, the payable amount is not the tax-inclusive total — and that is correct, not an error. A checker that insists on "net + VAT = total" flags every such invoice. Here that rule is simply not applied in that case: not because it is unimportant, but because it does not hold there.

What else lands in a Czech inbox

The same drop zone reads Peppol UBL and CII, Factur-X and ZUGFeRD PDFs, German XRechnung, Italian FatturaPA (including signed .p7m), Spanish Facturae, Polish KSeF, Romanian e-Factura, Austrian ebInterface, Hungarian NAV and Finnish Finvoice — plus ZIP archives and .eml / .msg emails. Each one is held against the EN 16931 rules by number where that standard applies, and where it does not, the compliance column says so instead of leaving a bare dash.

Trying it

Drop files on the main page — up to 10 invoices per export and 20 a day, free, no account, and the count resets at midnight. Pro lifts both limits for 29 € once, with no renewal.

Nothing is uploaded

The files are read in the browser. There is no server they could go to, and it takes two minutes to confirm: open the developer tools, the Network tab, and drop an invoice in — no request goes out. Or load the page, disconnect the network, and drop it anyway. It still works. Why that check matters.