Sign in Open validatorValidator

Czech e-invoice validator: ISDOC

Check an ISDOC invoice before you send it: the ISDOC 6.0.2 schema, the rules the standard publishes and how its VAT summary and totals add up, with every finding on its line. Nothing is uploaded.

Check an invoice Try it with an example

E-invoicing in the Czech Republic in short

Between businesses e-invoicing is not required. A tax document may be paper or electronic, and an electronic one needs the customer's consent (§ 26 of the VAT Act, 235/2004 Sb.). In practice Czech companies exchange ISDOC, the national XML format that most Czech accounting software reads and writes. It was defined by the ICT Unie working group and is maintained by the Ministry of the Interior; the current version is 6.0.2 of 23 March 2022.

Public bodies have to receive e-invoices. Central government bodies and their organisations accept the European formats and ISDOC 5.2 or later since 31 December 2018 (government resolution 347/2017). Under the public procurement act (134/2016 Sb., § 221), contracting authorities may not reject an e-invoice that follows the European standard EN 16931: the state and the Czech National Bank since 1 April 2019, all other contracting authorities since 1 April 2020. The law binds the buyer; a supplier may still send paper. Cross-border invoices between EU businesses become electronic by 1 July 2030, under the ViDA directive.

How to check a Czech invoice

  1. Open the validator with the ISDOC 6.0.2 profile. A file with the ISDOC namespace picks it on its own.
  2. Paste the XML or drop the .isdoc file, then press Validate. For an .isdocx package, unzip it and validate the .isdoc file inside.
  3. For an invoice to a public body in the European format, pick EN 16931 UBL Invoice, the CII one, or Peppol BIS 3.0 Invoice if it goes over Peppol.

What is checked

First the ISDOC 6.0.2 schema, then the rules the standard publishes as Schematron, named here after the section of the standard that states them: a credit or debit note must refer to the original document (ISDOC-4.1.1), a document in a foreign currency gives every amount in it too (ISDOC-4.1.2) and one in the local currency gives none and a rate of 1 (ISDOC-4.1.3), and the rules on non-VAT documents, batches and item identifiers. Two of the published tests are not valid XPath and one rule could never run; they are fixed here.

Then the rules of the standard's appendix A that its Schematron leaves out, written by us: the VAT summary adds up to its total (XV-CZ-04), the totals match the summary (XV-CZ-05), advance payments and rounding lead to the amount to pay, with paid advances as positive amounts (XV-CZ-12), and no empty UUID. A Czech company number (IČO) with a wrong check digit and a DIČ of the wrong form are warnings.

Profiles to check with

  • ISDOC 6.0.2: The Czech format for electronic invoices, read by most Czech accounting software, checked against its schema, its Schematron rules and the amount rules of the standard. Validate
  • EN 16931 Invoice (UBL): A UBL invoice checked against the schema and the business rules of the European e-invoicing standard EN 16931: mandatory fields, code lists and totals. Validate
  • EN 16931 Credit Note (UBL): A UBL credit note checked against the schema and the EN 16931 business rules. Validate
  • EN 16931 Invoice (CII): A Cross Industry Invoice checked against the D16B schema and the EN 16931 business rules: the XML inside Factur-X and ZUGFeRD (EN 16931 profile). Validate
  • Peppol BIS Billing 3.0 Invoice: A Peppol invoice checked the way an access point does: UBL 2.1 schema, EN 16931 rules and the Peppol BIS Billing 3.0 rules. Validate

Rules invoices break most

Each one has a page with what it checks, its test and, for many, how to fix it.

  • ISDOC-4.1.1: Pro typ dokladu 2, 3 a 6 musí existovat vazba na původní doklad. Konkrétně tedy pro DocumentType = 2, 3, 6 musí existovat element OriginalDocumentReference a mu...
  • ISDOC-4.1.2: Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat v...
  • ISDOC-4.1.3: Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro...
  • XV-CZ-04: TaxTotal/TaxAmount (…) must equal the sum of TaxAmount of every TaxSubTotal (…), in the foreign currency too (ISDOC 6.0.2, A.10).
  • XV-CZ-05: LegalMonetaryTotal/TaxExclusiveAmount (…) must equal the sum of TaxableAmount in the VAT summary (…), in the foreign currency too (ISDOC 6.0.2, A.11).
  • XV-CZ-12: PayableAmount (…) must equal DifferenceTaxInclusiveAmount + PayableRoundingAmount - PaidDepositsAmount (…); paid advance payments are given as positive amounts...

Questions

Is the invoice uploaded?

No. The schema check and the rules both run in your browser. Only the API and URL monitors validate on our servers.

Does it read ISDOC.PDF or .isdocx?

Not yet. An .isdocx file is a ZIP and an ISDOC.PDF is a PDF/A-3 with the .isdoc file attached: take the .isdoc file out and validate it.

Is ISDOC the same as the European standard?

No. ISDOC is based on UBL but has its own namespace and elements, such as amounts in two currencies and advance payments. Public bodies accept both, and the procurement act requires them to accept EN 16931.

An example from the ISDOC package fails. Why?

The sample priklad2-egov.isdoc of the ISDOC 6.0.1 package breaks the standard's own appendix A: a tax rate has its Difference amounts swapped, the tax total is not the sum of the rates, and paid advances are negative. Our example follows the rules.

Can I check invoices from code?

Yes: the API and the command-line client with --schema isdoc-6.0.2, or --schema auto for a folder of mixed invoices.

Official sources

Other countries