ISDOC, UBL, and CII
Three families of electronic invoicing standards. They differ in origin, not in what they can express — their content is very similar. We can handle all of them both on input and output.
ISDOC
A Czech standard, currently at version 6.0.2. Its advantage is that it is supported by almost every Czech accounting software. The downside is that it is virtually unknown outside of the Czech Republic.
We generate version 6.0.2 as a standalone .isdoc file. On input, we can read
older versions 5.x and the ISDOCX package, which is a ZIP file with XML
and an attached PDF — from which the PDF is saved as the original document. We do not
generate ISDOCX on output.
UBL 2.1
An international standard from OASIS. It underpins the European Peppol network (BIS Billing profile 3.0) and the German XRechnung (3.0.2). When you send an invoice abroad or to a public authority in the EU, they almost certainly want this format.
Credit notes in UBL are separate documents called CreditNote, not an invoice with a negative sign. Amounts are calculated from the sum of line items, not from read totals — otherwise, the document would fail the internal consistency check by the recipient. Address and electronic address of the parties are derived from DIČ.
CII D16B
A standard from UN/CEFACT. It is used by the German ZUGFeRD and the French Factur-X. Both are hybrid: the result is a PDF within which XML is embedded. A person sees the invoice, but a machine reads the data. You can choose bare XML (ZUGFeRD) or the entire PDF/A-3b with embedded XML (ZUGFeRD PDF). We can recognize such a PDF on input and read XML from it without a schema.
Which to Choose
| Situation | Format |
|---|---|
| Czech accounting software | ISDOC, or directly with Pohoda or Money S3 |
| Public administration in the EU | Peppol BIS 3.0 |
| German customer | XRechnung or ZUGFeRD PDF |
| French customer | ZUGFeRD PDF (Factur-X) |
| Custom system | JSON |
Validation
We monitor both the structure and business rules of the output (XSD, Schematron EN 16931 and Peppol) during development, not with every download. What can be verified before downloading is data: validation findings indicate incorrect totals or missing DIČ, and documents of another type cannot be converted into the invoicing format at all. If the recipient still rejects the file, please send us their error message and document identifier.