What an ISDOC File Is and How to Process It

You run into ISDOC everywhere in the Czech Republic where an invoice gets sent between two companies that both run Czech accounting software. POHODA, Money S3, HELIOS, ABRA, Premier, FlexiBee, iDoklad — all of them handle it. When an .isdoc or .isdocx attachment lands in your inbox, it is a structured invoice that your software can load without manual re-typing. And when you integrate invoicing, sooner or later you will have to read or generate it yourself.

This article explains what ISDOC is, where it came from, how it relates to the European standard and PEPPOL, and how to process it in .NET so it does not break on the first invoice that looks a little different.

What ISDOC Is

ISDOC is the Czech national standard for a structured electronic invoice. Structured means it is not a PDF or a scan — it is XML, from which software reads amounts, line items, company IDs, VAT IDs, the due date, and everything else as data, not as text to be copied by hand.

It exists in two forms:

• .isdoc — a single XML file, a single invoice.
• .isdocx — a ZIP package containing the same XML plus attachments. Typically a visual PDF of the invoice so a person can view it, but it can hold other documents too.

The format is defined by a publicly published XSD schema. That matters: you have a precise contract that tells you whether an invoice is valid before you even start processing it.

Where ISDOC Comes From (and Where Stormware Fits In)

I often hear the shorthand "Stormware made ISDOC." That is not quite accurate.

ISDOC was created in a working group of the SPIS consortium — today named ICT Unie. It originated as a Czech localization of the international OASIS UBL 2.0 standard and was first published between 2008 and 2009. It was a multi-party effort by several vendors, not the product of one company.

Stormware, with its POHODA software, was one of the first and largest implementers and actively pushed the format. That is why ISDOC is associated with it. But the author of the standard is the consortium, not a single vendor. In practice this means one useful thing: ISDOC is not a proprietary format locked into one piece of software. It is an open standard supported by a whole range of accounting programs, and you can integrate with it independently of who issued the invoice.

How ISDOC Relates to PEPPOL and the European Standard

Here is where things often get conflated. ISDOC, PEPPOL, and EN 16931 are three different things.

• ISDOC is a Czech customization of UBL 2.0. Conceptually the XML is close to UBL, but it is not identical to PEPPOL BIS 3.0 or to UBL 2.1, which are used for the European standard.
• EN 16931 is the European semantic invoice model. PEPPOL BIS (built on UBL 2.1) is its extended syntax for cross-border exchange within the EU.

An interesting detail: ISDOC is richer than the EN 16931 semantic model in a number of fields. When you convert ISDOC to UBL per EN 16931, you can lose some information. There is an open-source converter for this, isdoc2ubl (on GitHub), but expect the mapping to be lossy — not every field has a counterpart in the target format.

In practice, ISDOC and PEPPOL coexist in the Czech Republic; one does not replace the other:

• Domestic B2B between two companies on Czech accounting software stays on ISDOC.
• Public procurement above EU thresholds (B2G, the NEN platform) and cross-border invoicing run over PEPPOL BIS (UBL 2.1) for interoperability within the EU.

And under ViDA, the EU-mandated cross-border format will be built on EN 16931. That means ISDOC remains a domestic format, not a cross-border standard. If you invoice only in the Czech Republic, ISDOC is enough. As soon as you deal with public-sector contracts or cross-border trade, you will hit PEPPOL and will need a mapping between the two.

How to Open ISDOC

When an .isdoc or .isdocx simply arrives by email, the easiest path is to import it into accounting software you know — POHODA, Money, HELIOS, iDoklad, and others load it directly and pre-fill the invoice for you. There is also a standalone reader, ISDOCReader, that displays the file as a normal invoice.

That, however, is the end-user view. When you are building an integration, opening ISDOC means parsing it in code. This is where it pays to do it properly.

How to Process ISDOC in .NET

ISDOC is plain XML against a published XSD. The tempting shortcut is to parse it by hand via XDocument and pull values by element names. That works right up until the first invoice with a field you did not anticipate. The reliable path goes through the schema.

1. Generate C# Classes From the Official XSD

Instead of reading elements by hand, generate classes directly from the ISDOC XSD. Tools: dotnet-xscgen, LinqToXsd, or the legacy xsd.exe. You get typed classes that match the schema exactly. No typos in element names, no guessing types.

2. Read and Write via Serialization

Put XmlSerializer (System.Xml.Serialization) on the generated classes for both reading and writing, or XDocument (System.Xml.Linq) when you need finer control. That gives you the invoice as a typed object you work with normally in C#, not as a tree of strings.

3. Validate Against the XSD

Before processing, confirm the file is a valid ISDOC. Use XmlReaderSettings with an XmlSchemaSet loaded from the ISDOC XSD. That catches corrupted or non-standard invoices right at the input, not three layers down where the error shows up as a mysterious null.

4. For .isdocx, Unpack First

.isdocx is a ZIP. Open it via System.IO.Compression.ZipArchive, pull out the inner XML, and only then parse it. Retrieve the attachments (PDF and others) from the package separately if you need to archive or display them.

5. For Interoperability, Map to EN 16931

When you need to turn ISDOC into UBL or CII per EN 16931 — for a public contract or cross-border exchange — use the XSLT from isdoc2ubl or write your own mapping. And keep in mind what was said above: the mapping is lossy. Verify that the fields you care about have a counterpart in the target format.

In short: generated serialization plus validation against the schema beats a hand-written parser every time. Less code, fewer silent errors, and when the schema is extended, you regenerate the classes instead of hunting through XDocument.

Where We Can Help

We build e-invoicing and structured invoices into production. For invoicing connected to the Polish KSeF, we delivered over 40,000 documents with a 100% success rate, and during a forensic recovery we tracked down 15,141 invoices that a previous pipeline had silently lost. ISDOC, PEPPOL, and EN 16931 are part of the same domain — the structured invoice, validation against a schema, reliable processing.

If you are dealing with reading or generating ISDOC, mapping to PEPPOL for public contracts, or preparing for ViDA, get in touch. We will tell you where it is straightforward and where it gets lost in the details.

FAQ

What is an ISDOC file?

ISDOC is the Czech national standard for a structured electronic invoice. It is an XML file based on a publicly published XSD schema. The .isdoc extension is a single invoice, .isdocx is a ZIP package with the XML and attachments, typically a PDF.

Where does ISDOC come from, and is it related to Stormware?

ISDOC was created within the SPIS consortium (today ICT Unie) as a Czech localization of the OASIS UBL 2.0 standard, first published between 2008 and 2009. Stormware, with its POHODA software, was an early and major implementer, not the sole author of the format. It was a multi-party effort.

How do you parse ISDOC in .NET?

Generate C# classes from the official ISDOC XSD using dotnet-xscgen or LinqToXsd and read them via XmlSerializer or XDocument. Validate against the XSD using XmlReaderSettings and XmlSchemaSet. For an .isdocx file, first unpack it via ZipArchive and then parse the inner XML.