E-invoicing basics

Last reviewed 26 September 2026.

A structured e-invoice contains data that software can read directly. It may be an XML file or, with formats such as ZUGFeRD / Factur-X, XML embedded inside a readable PDF. This guide explains the pieces involved, how they fit together and what a validator can and cannot tell you. It is written for developers and finance teams meeting e-invoicing for the first time.

Three ideas carry most of it:

• A format defines how the data is written, such as UBL or CII.
• A standard defines what it means: EN 16931 sets out what a European invoice must say.
• Additional rules apply in particular contexts: the Peppol network, invoices to German public bodies, or a ZUGFeRD / Factur-X profile.

The three formats at a glance

The rest of this guide explains what sits behind each column, then the exact identifiers and releases.

What makes an invoice structured

A PDF or a scanned image looks like an invoice to a person, but a program has to guess where the invoice number, the totals and the VAT are. A structured invoice states every value in a named element: the invoice number in one element, each line with its quantity, price and net amount, the VAT breakdown, the totals, and the seller and buyer with identifiers such as VAT numbers.

Because the structure and its meaning are agreed in advance, the receiver can load the invoice directly, check it and match it to an order.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
    <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
    <cbc:ID>EX-2026-0001</cbc:ID>
    <cbc:IssueDate>2026-06-15</cbc:IssueDate>
    <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
    <cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
    <!-- the supplier, the customer, the invoice lines and the VAT breakdown -->
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="GBP">740.00</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="GBP">740.00</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="GBP">888.00</cbc:TaxInclusiveAmount>
        <cbc:PayableAmount currencyID="GBP">888.00</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

Syntax, semantics and usage rules

Three layers answer three different questions about an e-invoice.

Syntax: how is it written?

The syntax is the XML vocabulary: the element names, their order and their data types. Two syntaxes matter in Europe: UBL 2.1 (Universal Business Language) and the UN/CEFACT Cross Industry Invoice (CII). A schema check (XSD) tells you whether a document is well-formed in its syntax, not whether it is a complete invoice.

Semantic model: what must it say?

EN 16931, the European standard for electronic invoicing, defines the core invoice model: the information an invoice carries and the rules between it. Each piece of information is a business term with an identifier, such as BT-1 for the invoice number and BT-106 for the sum of the line net amounts; related terms form groups (BG-). Business rules (BR-) must hold across them: BR-CO-10, for example, requires BT-106 to equal the sum of the invoice line net amounts. EN 16931 does not define a syntax of its own; its technical specifications bind the model to UBL 2.1 and to CII D16B.

Usage rules: how does this community use it?

A core invoice usage specification (CIUS) adapts the core model to a particular context. It may make optional information mandatory, restrict code lists and add rules, but it must stay a subset of the core and must not break any of the core rules. An extension goes the other way and adds information that the core does not define.

• Peppol BIS Billing 3 is a CIUS of EN 16931, defined by OpenPeppol and written in UBL.
• XRechnung, the German standard for invoicing public-sector buyers, consists of the CIUS XRechnung and the Extension XRechnung.
• ZUGFeRD / Factur-X defines profiles: the EN 16931 profile follows the core model, MINIMUM and BASIC WL carry less than a complete EN 16931 invoice, and EXTENDED carries more.

A validator works through these layers in order: is the file well-formed XML, does it match the schema of its syntax, do the EN 16931 rules hold, and do the usage rules hold. Ironfang reports each layer separately, so an invalid document is distinguishable from a service failure and you can see where a problem starts.

Syntaxes, identifiers and releases

UBL and CII can carry the same EN 16931 information with different element names. The invoice number, for example, is cbc:ID at the top of a UBL invoice and ram:ID inside rsm:ExchangedDocument in CII. Every document also declares which rules it follows, in its specification identifier: cbc:CustomizationID in UBL, or the ram:ID of ram:GuidelineSpecifiedDocumentContextParameter in CII. Validators use that declaration to choose the rules to apply.

ZUGFeRD and Factur-X are the same standard under two names: ZUGFeRD 2.5.2 corresponds to Factur-X 1.09.2. A hybrid invoice is a PDF/A file, a readable page with the invoice XML embedded in it, so one file serves both the person and the program.

Ironfang Finance validates these releases, and every result names the exact release it was checked against:

• Peppol BIS Billing 3.0, the May 2026 release, for UBL invoices and credit notes.
• XRechnung 3.0.2, in KoSIT's technical bundle of 31 August 2026, in UBL and CII.
• ZUGFeRD 2.5.2 / Factur-X 1.09.2 in the MINIMUM, BASIC WL, BASIC, EN 16931 and EXTENDED profiles, as a PDF or as XML. The XRECHNUNG profile inside a ZUGFeRD PDF is recognised and reported as not yet supported, never checked as something else.

The format guides go deeper: XRechnung and ZUGFeRD / Factur-X.

What validation establishes

A passing result means that the document, exactly as sent, met every rule the validator checked for a named release of its specification, at the time it was checked. Errors fail a document; warnings are worth reading but do not.

It does not establish that:

• the invoice was sent, delivered, received or accepted by the buyer;
• the content is commercially right: a validator can check that the totals add up, not that you charged the right price;
• the buyer's own requirements beyond the published rules are met;
• the invoice meets every legal or tax obligation that applies to you.

Some things are outside what an XML check can see. For a ZUGFeRD / Factur-X PDF, for example, Ironfang reports that it has not compared the visible PDF page with the embedded XML: only the XML is the invoice data that was checked.

Peppol the network is a separate thing

"Peppol" names two things. Peppol BIS Billing 3 is the document specification described above. The Peppol network is how documents travel: organisations send and receive business documents across it through a Peppol-accredited service provider of their choice, and both sides only need one provider to reach everyone else on the network.

Validating a Peppol BIS invoice checks the document; it does not send it. Ironfang validates documents. It does not send invoices, operate a Peppol Access Point or register participants on the network.

Try it: check a sample and fix an error

You can go from a broken invoice to a fixed one in a few minutes, with no account:

1. Open the Peppol validator and choose Try a sample with errors. The result reports two EN 16931 errors on the invoice totals, BR-CO-10 and BR-CO-13.
2. Read the explanation of BR-CO-10: the declared sum of the line amounts must equal the sum of the lines. In this sample the lines come to 740.00 but the total declares 750.00.
3. Compare it with the annotated valid example, where cbc:LineExtensionAmount in the totals is 740.00. Correct the declared amount and validate the file again.
4. Open the same file in the invoice viewer to read the UBL invoice as a document.

The same approach works for the other families. The XRechnung validator has a CII sample without its buyer reference (the Leitweg-ID), which XRechnung requires, so it reports BR-DE-15. The ZUGFeRD / Factur-X validator has a sample PDF with two mistakes, one in its PDF metadata and one in its XML. When a finding names a rule, the rule reference explains what it checks and how to fix it.

Building it into software

• Validate from code: a runnable quickstart that sends a sample invoice to the Finance API and reads the result.
• Finance API V1 and V2: which API version covers which format, and how results differ.
• Invoice generation: produce a Peppol BIS UBL invoice from JSON.
• How Peppol invoice validation actually works and Understanding EN 16931 validation errors: the validation layers and rule families in more depth.

Explore the e-invoicing learning hub for more guides, tools and examples, organised by task.

Sources

Standards claims on this page were checked against these primary sources on 26 September 2026:

• European Commission: Required syntaxes: EN 16931 defines the content, not the syntax; UBL 2.1 and UN/CEFACT CII D16B are the two syntaxes bound to it.
• European Commission: EN 16931 compliance: What a compliant invoice must contain, and that a CIUS is a subset of the core that does not break its rules.
• OpenPeppol: Peppol BIS Billing 3.0: Peppol BIS Billing 3.0 is a CIUS of EN 16931 in UBL, and its specification and business process identifiers.
• OpenPeppol: For end users: Organisations send and receive over the Peppol network through a Peppol-accredited service provider of their choice.
• KoSIT (xeinkauf.de): XRechnung: XRechnung is the CIUS XRechnung and the Extension XRechnung, operated by KoSIT for the IT Planning Council, in UBL 2.1 and UN/CEFACT CII.
• FeRD: ZUGFeRD / Factur-X: ZUGFeRD embeds structured XML invoice data in a PDF/A-3 document, and is Factur-X in France with FNFE-MPE.
• FeRD: ZUGFeRD 2.5.2: ZUGFeRD 2.5.2 corresponds to Factur-X 1.09.2 and is based on UN/CEFACT CII D22B.
• FNFE-MPE: Factur-X: Factur-X is the same standard as ZUGFeRD, a hybrid PDF plus XML invoice, with the MINIMUM, BASIC WL, BASIC, EN16931 and EXTENDED profiles.

The releases Ironfang validates come from its own ruleset registry, which every result names. This guide explains the standards; it is not legal or tax advice.