E-Invoice Identifier
Before you validate an e-invoice, you have to know what it is. Paste the XML and get its syntax, kind and profile — and which validator applies.
🔒 Your data never leaves your browser.
Why this is the front door
An EN 16931 invoice can arrive in two completely different XML shapes — OASIS UBL
(root Invoice or CreditNote) and UN/CEFACT CII
(root CrossIndustryInvoice) — carrying the same information in unrelated element
trees. A validator built for one cannot read the other. So the first question is never
“is it valid”; it is “which one is this, and which rules apply”.
The CustomizationID is the field that decides everything
One element, CustomizationID, declares which specification the invoice claims to
follow. It is the single most useful fact about an e-invoice, because the most common
real-world rejection is not a broken business rule — it is a document sent to a receiver
running a different profile from the one it declares. The document is fine; it just
says it follows rules the receiver is not checking.
| Profile | What it is |
|---|---|
| Peppol BIS Billing 3.0 | The Peppol network profile of EN 16931 — adds the rules needed to deliver an invoice over the Peppol network. |
| XRechnung (extension) | The German CIUS of EN 16931, extension variant — XRechnung rules on top of the core standard, with the German additions. |
| XRechnung | The German CIUS of EN 16931 — required for invoicing German public authorities, and widely used in German B2B. |
| EN 16931 (core, no national rules) | The European core invoice standard with no country-specific rules layered on. Valid, but a receiver that expects a national profile may still reject it. |
The profile URNs are verified, not remembered
Every CustomizationID this tool recognises was taken from a primary source, not typed from
memory: the Peppol value from the Peppol specification, the XRechnung values extracted from
KoSIT’s
published Schematron. XRechnung is matched as a family, so both the current
xeinkauf.de namespace and the older xoev-de one are recognised, and
the version is read out of the identifier itself.
Three layers, and why a valid invoice still gets rejected
EN 16931 is the core. A national or network profile — Peppol, XRechnung — is a customisation that adds rules on top: Peppol adds what the network needs, XRechnung adds what German receivers need. An invoice can satisfy the core and still fail the layer the receiver runs. Knowing which layer applies is exactly what this identifier answers before you spend time on the rules.
What this does not do
It does not check business rules — it identifies and routes. Where a matching validator exists on this site it is named; a CII document is identified but the invoice validators here read UBL. It is the map, not the journey.
Every check this tool runs (11 rules)
IDD-P01 The XML is not well formed
Before anything can be said about which standard a document follows, it has to parse. A tag that never closes, a stray angle bracket or a broken entity stops the reader at a known position — and every downstream validator will stop there too.
Fix: Fix the markup at the position given, then identify the document again.
Source: OASIS — Universal Business Language (UBL) Version 2.1
IDD-S01 The syntax is identified
An EN 16931 invoice comes in one of two XML syntaxes: OASIS UBL, whose root is Invoice or CreditNote, and UN/CEFACT CII, whose root is CrossIndustryInvoice. They carry the same information in completely different element trees, and a validator built for one cannot read the other.
Source: OASIS — Universal Business Language (UBL) Version 2.1
IDD-S02 This is not an e-invoice syntax we recognise
The root element is neither a UBL Invoice or CreditNote nor a CII CrossIndustryInvoice. It may be a different business document, a different standard, or XML that was never an invoice — but it is not one this identifier, or the validators it routes to, can read.
Fix: Check that this is actually an EN 16931 UBL or CII invoice.
Source: OASIS — Universal Business Language (UBL) Version 2.1
IDD-K01 The document kind
Whether the document is an invoice or a credit note is decided by its root element, not by any amount inside it. A credit note validated as an invoice fails rules that do not apply to it, and the reverse hides rules that do.
Source: OASIS — Universal Business Language (UBL) Version 2.1
IDD-K02 Recognised syntax, but not an invoice or credit note
The document is valid UBL or CII, but its root is some other document type — an order, a despatch advice, or similar. The invoice validators do not apply to it.
Fix: Use the tool that matches this document type; this identifier and the invoice validators are for invoices and credit notes.
Source: OASIS — Universal Business Language (UBL) Version 2.1
IDD-C01 No specification is declared
The CustomizationID is the field that tells the receiver which set of rules the document claims to follow. Without it the document is a well-formed invoice that names no specification, and the receiver has to guess which rules to apply — or reject it for not saying.
Fix: Set the CustomizationID to the profile the document is built for.
IDD-C02 The declared specification is recognised
The CustomizationID matches a known profile, so the rules that apply are known. This is the single most useful fact about an e-invoice: it is what decides which validator the document must pass, and the most common real-world rejection is a document sent to a receiver running a different profile from the one it declares.
IDD-C03 A specification is declared, but not one we recognise
The document names a CustomizationID that is not one of the profiles known here. It may be a national profile from a country not yet covered, a newer version, or a value that was mistyped. A receiver that does not run that exact profile will reject the document even if every business rule inside it is correct.
Fix: Confirm the CustomizationID is exactly the value the receiver expects.
IDD-R01 Which validator applies
Identifying the profile is only useful if it tells you what to do next. Where a matching validator exists on this site, it is named so the document can be checked against the right rules rather than a generic guess.
IDD-M01 CII is identified here, but the invoice validators read UBL
This identifier recognises CII and reads its context, but the invoice validators on this site currently check UBL documents. A CII document is identified and its profile named, so you know what it is; validating its business rules needs a CII-aware checker.
IDD-V01 The syntax version
UBL and CII each have their own version, separate from the invoice profile. It is reported where the document states it, because a validator or receiver built for one version can trip on another even when the profile matches.
Source: OASIS — Universal Business Language (UBL) Version 2.1
This tool identifies and routes; it does not validate business rules. The profiles it recognises are listed above, each from a verified source.