The e-invoice validator recognises the format of your file automatically. For each format we check the structure against the official XML schema. Where official business rules are publicly available, we check those too. Below you can see the e-invoice formats by country and what exactly is checked.
E-invoice formats by country
| Country | Format | Structure (XSD) | Business rules |
|---|---|---|---|
| Belgium | Peppol BIS Billing 3.0 (UBL)The format of the Belgian mandate. Peppol BIS has no separate Belgian rules. | Yes | Yes |
| UBL.BE / e-FFFOlder Belgian variant: structure only (UBL 2.1). | Yes | No | |
| Netherlands | Peppol BIS Billing 3.0 (UBL)Including the Dutch Peppol rules. | Yes | Yes |
| SI-UBL 2.0 and NLCIUS (UBL and CII) | Yes | Yes | |
| Energie eFactuurUBL structure only. | Yes | No | |
| Germany | XRechnung 3.0 (UBL and CII) | Yes | Yes |
| ZUGFeRD / Factur-X (all profiles)Checked against version 2.5.2. ZUGFeRD 2.0: structure only. | Yes | Yes | |
| Peppol BIS Billing 3.0 (UBL)Including the German Peppol rules. | Yes | Yes | |
| France | Factur-X (all profiles) | Yes | Yes |
| CTC Flux 2 and EXTENDED-CTC-FR (UBL and CII)CII is checked against the CII D22B schema. | Yes | Yes | |
| CDAR (status messages) | Yes | No | |
| PPF Flux 1 and Flux 10 | No | No | |
| Italy | FatturaPA 1.2 (FPA12 and FPR12)Signed .p7m files too. The checks of the SdI itself are not performed. | Yes | No |
| Peppol BIS Billing 3.0 (UBL)Including the Italian Peppol rules; not the additional AGID rules. | Yes | Yes | |
| Spain | Facturae 3.0 to 3.2.2The signature and VeriFactu are not checked. | Yes | No |
| Poland | KSeF FA(1), FA(2) and FA(3) | Yes | No |
| Austria | ebInterface 3.0 to 6.1 | Yes | No |
| Peppol BIS Billing 3.0 (UBL) | Yes | Yes | |
| Hungary | NAV Online Számla 2.0 and 3.0 | Yes | No |
| Czechia | ISDOC 6.0 | Yes | No |
| Sweden | Peppol BIS Billing 3.0 (UBL)Including the Swedish Peppol rules. | Yes | Yes |
| Svefaktura 1.0 | Yes | No | |
| Norway | EHF Billing 3.0 / Peppol BISIncluding the Norwegian Peppol rules. Other EHF documents: structure only. | Yes | Yes |
| Denmark | Peppol BIS Billing 3.0 (UBL)Including the Danish Peppol rules. | Yes | Yes |
| OIOUBLUBL structure only. | Yes | No | |
| Finland | Finvoice 1.3 to 3.0 | Yes | No |
| TEAPPSXML 2.7.2 and 3.0 | Yes | No | |
| Peppol BIS Billing 3.0 (UBL) | Yes | Yes | |
| Greece | Peppol BIS Billing 3.0 (UBL)Including the Greek Peppol rules. myDATA is not supported. | Yes | Yes |
| Iceland | Peppol BIS Billing 3.0 (UBL)Including the Icelandic Peppol rules. | Yes | Yes |
| Portugal | CIUS-PT (UBL)You can select the EN 16931 core rules in the list; the Portuguese rules are not included. | Yes | Partly |
| Romania | CIUS-RO (UBL)You can select the EN 16931 core rules in the list; the Romanian rules are not included. | Yes | Partly |
| Croatia | eRačun (UBL)You can select the EN 16931 core rules in the list; the Croatian rules are not included. | Yes | Partly |
| eIzvještavanje (e-reporting) | Yes | No | |
| Serbia | SEF (UBL), eOtpremnica and ePrijemnica | Yes | No |
| Türkiye | UBL-TR / e-FaturaThe envelope (Zarf) is not supported. | Yes | No |
| Saudi Arabia | ZATCA / FATOORA (UBL)Signature, QR code and ZATCA rules not checked. | Yes | No |
| Peppol outside Europe | Peppol PINT (A-NZ, JP, MY, SG, AE, OM)UBL structure only. | Yes | No |
| Other EU countries | EN 16931 (UBL and CII) | Yes | Yes |
| Peppol BIS Billing 3.0 (UBL) | Yes | Yes |
Not supported: Brazilian NF-e, Greek myDATA, VeriFactu, PPF Flux 1 and 10, Turkish Zarf envelopes and formats that are not XML based.
The validator checks the structure against the official schema and, where available, the official business rules. The result is an aid, not a guarantee that a recipient, Access Point or government platform will accept the document. National platforms (such as SdI, KSeF or the PPF) and recipients may perform additional checks, for example on signatures, numbering or registrations. Your file is processed only in your browser.
A validator for each e-invoice format
For the most requested formats we have a dedicated page, with the validator already set to the right country:
- XRechnung validator (Germany).
- Factur-X validator (France and Germany): PDF with embedded XML.
- SI-UBL validator (Netherlands): SI-UBL 2.0 and NLCIUS.
- KSeF validator (Poland).
- FatturaPA validator (Italy).
- Facturae validator (Spain).
Two checks: structure and business rules
Every file goes through two checks. First, we check whether it follows the structure of the official schema: the right elements, in the right order and with the right type of data. Then we check the business rules, such as mandatory fields, calculations and code lists. For Peppol BIS, XRechnung, Factur-X and the Dutch and French rules, these business rules are publicly available. For other formats, no public rule set exists. In those cases we therefore only check the structure.
How does the validator choose the rules automatically?
When you choose “Automatic”, we first read a few details from your file. Based on those, we choose the rules. Below the result, “Detected by” shows which details decided the choice. We look at three things:
- The format: UBL or CII, or a PDF with embedded XML such as Factur-X or ZUGFeRD.
- The specification ID (BT-24): in UBL the field
CustomizationID, in CIIGuidelineSpecifiedDocumentContextParameter. That ID states which rules the sender follows. It carries the most weight. - The French invoicing mode: a code from B1 to M9 in
ProfileIDorBusinessProcessSpecifiedDocumentContextParameter. That code points to the French rules.
Recognisable parts of the specification ID
| Part of the ID | Rules |
|---|---|
poacc:billing:3.0 | Peppol BIS Billing 3.0 |
poacc:selfbilling:3.0 | Peppol BIS Self-Billing 3.0 |
kosit:xrechnung | XRechnung (Germany) |
kosit:extension:xrechnung | XRechnung Extension |
nen.nl:nlcius | SI-UBL 2.0 / NLCIUS (Netherlands) |
nen.nl:gaccount | SI-UBL 2.0 with G account |
factur-x.eu:1p0 | Factur-X / ZUGFeRD, in the profile from the ID (MINIMUM, BASIC WL, BASIC, EXTENDED) |
cpro.gouv.fr | EN 16931 with the French rules (BR-FR) |
extended-ctc-fr | EXTENDED-CTC-FR (France) |
urn:cen.eu:en16931:2017 | EN 16931, the European standard (when nothing follows) |
A specification ID we do not know
A specification ID consists of layers. Each layer starts with #compliant# (a restriction of the standard) or #conformant# (an extension). If we do not know the full ID, we remove the last layer and try again. That way, an unknown variant of XRechnung is still checked with the XRechnung rules. If it is an extension we do not know, we warn that elements from that extension may show up as errors.
Is the choice wrong? Then choose the country yourself, or pick the exact rule set under “Advanced”. A Peppol invoice or credit note is always checked with the Peppol rules of the current release.
Why one validator for e-invoice formats from several countries?
Belgian businesses send their invoices via Peppol, in the Peppol BIS Billing 3.0 format. Still, you also receive invoices from abroad, or you send invoices to customers in Germany, France or Italy yourself. Moreover, many software packages use one export format for all countries. With this validator you therefore check every file in the same place, without first having to know which format it is.
What the validator does not check
National platforms such as the SdI in Italy, KSeF in Poland or the PPF in France perform additional checks, for example on signatures, numbering or registrations. Those checks fall outside this validator. The result is therefore an aid, not a guarantee that a recipient or platform will accept the document. Do you want to check a Belgian Peppol invoice? Then use the e-invoice validator, and for an error message read the explanation of the Peppol error codes.
Sources
Schemas and rules: OASIS (UBL), UN/CEFACT (CII), CEN (EN 16931), OpenPeppol, KoSIT, FNFE-MPE and the national publishers, brought together by Philip Helger in phive-rules (Apache 2.0). XML schema check with libxml2 (xmllint-wasm, MIT).