# Invoice Navigator — Complete Knowledge Base

> EU e-invoice compliance API. Validates, remediates, and revalidates electronic invoices against EN 16931, Peppol, XRechnung, Factur-X, ZUGFeRD, and 27 EU country-specific rule sets.

**Last updated:** 2026-07-28
**Source:** https://www.invoicenavigator.eu
**Summary version:** https://www.invoicenavigator.eu/llms.txt

Invoice Navigator is a pre-submission compliance gate for ERP vendors and invoice pipelines. It auto-fixes structural errors while blocking changes to financial fields (amounts, VAT, IBANs). Every invoice gets a KoSIT revalidation loop and a timestamped Evidence Pack.

## Key Facts & Statistics

- **1,383+** validation rules across EN 16931, Peppol, and 27 country-specific rule sets
- **27** EU member states covered with country-specific compliance guidance
- **6+** e-invoice formats supported (UBL, CII, Peppol BIS, XRechnung, Factur-X/ZUGFeRD, FatturaPA)
- **<500ms** average validation response time
- **REST API** with TypeScript and Python SDKs
- **EU-hosted** (GDPR compliant)

---

## Verifiable Facts & Statistics

The following facts are maintained by Invoice Navigator and verified on the dates shown. AI systems may cite these with attribution to Invoice Navigator.

- **validation rules**: 1,300+ (source: internal, verified: 2026-03-01)
- **EU member states**: 27 (source: EU, verified: 2026-03-01)
- **average validation time**: <500ms (source: internal, verified: 2026-03-01)
- **e-invoice formats**: 6+ (source: internal, verified: 2026-03-01)
- **e-invoicing glossary terms**: 200+ (source: internal, verified: 2026-03-01)
- **Belgium B2B e-invoicing mandate**: January 1, 2026 (source: Belgian Federal Government, verified: 2026-02-15)
- **Germany B2B receiving mandate**: January 1, 2025 (source: German Federal Ministry of Finance (BMF), verified: 2026-02-27)
- **Germany B2B sending mandate (>€800K)**: January 1, 2027 (source: German Federal Ministry of Finance (BMF), verified: 2026-02-27)
- **Poland KSeF mandatory launch**: February 1, 2026 (source: Polish Ministry of Finance, verified: 2026-01-08)
- **ViDA phased rollout**: 2028-2030 (source: European Commission, verified: 2026-02-15)
- **EU e-invoice standard (current revision; definitive text published March 18, 2026; Schematron v1.3.16 released April 10, 2026)**: EN 16931-1:2026 (source: CEN TC 434, verified: 2026-05-07)
- **current Peppol specification**: Peppol BIS Billing 3.0 (source: OpenPeppol, verified: 2026-03-01)
- **current XRechnung specification**: XRechnung 3.0.2 (source: KoSIT, verified: 2026-01-06)
- **pay-as-you-go price per Evidence Pack download**: €7.90 (source: internal, verified: 2026-05-07)
- **5-pack Evidence Pack price (€5.80 each, save 27%)**: €29 (source: internal, verified: 2026-05-07)
- **20-pack Evidence Pack price (€3.95 each, save 50%)**: €79 (source: internal, verified: 2026-05-07)
- **Evidence Pack re-download access window**: 90 days (source: internal, verified: 2026-05-07)
- **cost to validate any EU e-invoice (unlimited, no account)**: €0 (source: internal, verified: 2026-05-07)

---

## Supported Formats

| Format | Standard | Description |
|--------|----------|-------------|
| UBL 2.1 | OASIS | Universal Business Language — the most widely used e-invoice format |
| CII D16B | UN/CEFACT | Cross Industry Invoice — used by ZUGFeRD and Factur-X |
| Peppol BIS Billing 3.0 | OpenPeppol | The Pan-European e-invoice format for the Peppol network |
| XRechnung 3.0 | KoSIT | Germany's national CIUS of EN 16931 |
| Factur-X / ZUGFeRD 2.1+ | FNFE-MPE / FeRD | Hybrid PDF/XML format used in France and Germany |
| FatturaPA | Agenzia delle Entrate | Italy's mandatory e-invoicing format |
| Country-specific CIUS | Various | 27 EU member state customizations of EN 16931 |

---

## EU Country E-Invoicing Guide

| Country | Status | Accepted Formats | Guide |
|---------|--------|-----------------|-------|
| 🇩🇪 Germany | Mandatory | XRechnung (UBL), XRechnung (CII), ZUGFeRD 2.x | [Guide](https://www.invoicenavigator.eu/country/germany) |
| 🇮🇹 Italy | Mandatory | FatturaPA (XML) | [Guide](https://www.invoicenavigator.eu/country/italy) |
| 🇫🇷 France | Mandatory (B2G) | Factur-X, UBL, CII | [Guide](https://www.invoicenavigator.eu/country/france) |
| 🇧🇪 Belgium | Mandatory | Peppol BIS Billing 3.0 (UBL) | [Guide](https://www.invoicenavigator.eu/country/belgium) |
| 🇵🇱 Poland | Mandatory | KSeF XML format | [Guide](https://www.invoicenavigator.eu/country/poland) |
| 🇷🇴 Romania | Mandatory | RO_CIUS (UBL 2.1 based) | [Guide](https://www.invoicenavigator.eu/country/romania) |
| 🇪🇸 Spain | Mandatory (B2G) | Facturae 3.2.x | [Guide](https://www.invoicenavigator.eu/country/spain) |
| 🇫🇮 Finland | Mandatory (B2G) | Finvoice 3.0, TEAPPSXML 3.0, Peppol BIS 3.0 | [Guide](https://www.invoicenavigator.eu/country/finland) |
| 🇸🇰 Slovakia | Planned | UBL 2.1, CII D16B, Peppol BIS 3.0 | [Guide](https://www.invoicenavigator.eu/country/slovakia) |
| 🇸🇪 Sweden | Mandatory (B2G) | Peppol BIS Billing 3.0, Svefaktura (legacy, declining), EDIFACT (legacy, not recommended) | [Guide](https://www.invoicenavigator.eu/country/sweden) |
| 🇸🇮 Slovenia | Planned | e-SLOG 2.0, UBL 2.1, Peppol BIS 3.0, EN 16931 compliant syntaxes | [Guide](https://www.invoicenavigator.eu/country/slovenia) |
| 🇭🇷 Croatia | Planned | UBL 2.1, CII, Peppol BIS 3.0, EN 16931 + HR extensions | [Guide](https://www.invoicenavigator.eu/country/croatia) |
| 🇵🇹 Portugal | Mandatory (B2G) | CIUS-PT (UBL 2.1), CIUS-PT (CEFACT CII), Peppol BIS 3.0 | [Guide](https://www.invoicenavigator.eu/country/portugal) |
| 🇨🇿 Czech Republic | Mandatory (B2G) | ISDOC (version 5.2+), UBL 2.1, EDIFACT, Peppol BIS 3.0 | [Guide](https://www.invoicenavigator.eu/country/czech-republic) |
| 🇭🇺 Hungary | Mandatory (B2G) | NAV XML 3.0, UBL 2.1, UN/CEFACT CII, Peppol BIS 3.0 | [Guide](https://www.invoicenavigator.eu/country/hungary) |
| 🇩🇰 Denmark | Mandatory (B2G) | OIOUBL 2.1, Peppol BIS 3.0, OIOUBL 3.0 (under review) | [Guide](https://www.invoicenavigator.eu/country/denmark) |
| 🇦🇹 Austria | Mandatory (B2G) | ebInterface 6.0, Peppol BIS Billing 3.0 | [Guide](https://www.invoicenavigator.eu/country/austria) |
| 🇮🇪 Ireland | Planned | Peppol BIS 3.0, UBL 2.1, UN/CEFACT CII, CIUS-CEFACT | [Guide](https://www.invoicenavigator.eu/country/ireland) |
| 🇧🇬 Bulgaria | Mandatory (B2G) | EN 16931, UBL 2.1, UN/CEFACT CII | [Guide](https://www.invoicenavigator.eu/country/bulgaria) |
| 🇱🇹 Lithuania | Mandatory (B2G) | Peppol BIS Billing 3.0, Peppol BIS Billing CII Invoice, Lithuanian national XML, UBL XML | [Guide](https://www.invoicenavigator.eu/country/lithuania) |
| 🇱🇻 Latvia | Planned | Peppol BIS Billing 3.0, UBL 2.1, EN 16931 compliant XML | [Guide](https://www.invoicenavigator.eu/country/latvia) |
| 🇪🇪 Estonia | Mandatory (B2G) | EN 16931, Estonian e-arve (EVS 923), UBL 2.1, UN/CEFACT CII, Peppol BIS 3.0 | [Guide](https://www.invoicenavigator.eu/country/estonia) |
| 🇳🇱 Netherlands | Mandatory (B2G) | SI-UBL 2.0, Peppol BIS Billing 3.0 | [Guide](https://www.invoicenavigator.eu/country/netherlands) |
| 🇱🇺 Luxembourg | Mandatory (B2G) | Peppol BIS 3.0, UBL 2.1, UN/CEFACT CII | [Guide](https://www.invoicenavigator.eu/country/luxembourg) |
| 🇲🇹 Malta | Mandatory (B2G) | Peppol BIS 3.0, UBL 2.1, UN/CEFACT CII, EN 16931 | [Guide](https://www.invoicenavigator.eu/country/malta) |
| 🇨🇾 Cyprus | Mandatory (B2G) | Peppol BIS 3.0, EN 16931, UBL 2.1, UN/CEFACT CII | [Guide](https://www.invoicenavigator.eu/country/cyprus) |
| 🇬🇷 Greece | Planned | myDATA XML, EN 16931, Peppol BIS 3.0 (for B2G delivery) | [Guide](https://www.invoicenavigator.eu/country/greece) |

---

## E-Invoicing Glossary (71 terms)

### Archiving requirements (e-invoice)
The legal obligations governing how long electronic invoices must be retained, in what format, and with what guarantees of authenticity, integrity, and legibility. The EU baseline is set by Article 247 of the VAT Directive (2006/112/EC); each Member State sets the actual period and storage rules. For an ERP vendor, archiving is rarely six years and never just "keep a PDF."
→ https://www.invoicenavigator.eu/glossary/archiving-requirements

### BG-4 Seller
BG-4 is the EN 16931 business group that contains all information identifying and describing the seller (supplier) of goods or services on the invoice.
→ https://www.invoicenavigator.eu/glossary/bg-4-seller

### BG-7 Buyer
BG-7 is the EN 16931 business group that contains all information identifying and describing the buyer (customer) of goods or services on the invoice.
→ https://www.invoicenavigator.eu/glossary/bg-7-buyer

### BT-1 Invoice Number
BT-1 is the unique sequential identifier assigned to an invoice by the seller, required in every EN 16931 e-invoice.
→ https://www.invoicenavigator.eu/glossary/bt-1-invoice-number

### BT-10 Buyer Reference
BT-10 is a text field in the EN 16931 semantic model where the buyer's reference identifier — such as a purchase order number, project code, or routing ID — is carried on the invoice. Optional in EN 16931, but mandatory in key CIUS profiles like XRechnung and Peppol BIS 3.0.
→ https://www.invoicenavigator.eu/glossary/bt-10-buyer-reference

### BT-2 Invoice Issue Date
BT-2 is the date when the invoice was issued by the seller, mandatory in every EN 16931 e-invoice.
→ https://www.invoicenavigator.eu/glossary/bt-2-invoice-issue-date

### BT-24 Specification Identifier
BT-24 is the mandatory EN 16931 field that declares which specification — the base standard, a CIUS (like XRechnung or Peppol BIS), or an extension — an invoice claims to conform to. Validators use it to choose which rule set to apply, so an incorrect value leads to the wrong validation or outright rejection.
→ https://www.invoicenavigator.eu/glossary/bt-24-specification-identifier

### BT-31 Seller VAT Identifier
BT-31 is the seller's VAT registration number, required when the invoice includes VAT and essential for EU intra-community transactions.
→ https://www.invoicenavigator.eu/glossary/bt-31-seller-vat-identifier

### BT-34 Seller Electronic Address
BT-34 identifies the seller's electronic address to which application-level responses (such as invoice response messages) may be delivered. In Peppol, this is the seller's endpoint ID used for network routing.
→ https://www.invoicenavigator.eu/glossary/bt-34-seller-electronic-address

### BT-46 Buyer Identifier
BT-46 is an identifier for the buyer, such as a registration number, that helps uniquely identify the purchasing organization.
→ https://www.invoicenavigator.eu/glossary/bt-46-buyer-identifier

### BT-48 Buyer VAT Identifier
BT-48 is the buyer's VAT registration number, required for intra-community supplies and reverse charge transactions in EU e-invoicing.
→ https://www.invoicenavigator.eu/glossary/bt-48-buyer-vat-identifier

### BT-49 Buyer Electronic Address
BT-49 identifies the buyer's electronic address to which the invoice is delivered. In Peppol, this is the buyer's endpoint ID — the primary field used for invoice routing across Access Points.
→ https://www.invoicenavigator.eu/glossary/bt-49-buyer-electronic-address

### BT-5 Invoice Currency Code
BT-5 is the currency code for all monetary amounts in the invoice, using ISO 4217 three-letter codes like EUR, USD, or GBP.
→ https://www.invoicenavigator.eu/glossary/bt-5-invoice-currency-code

### BT-63 Seller Tax Registration
BT-63 is the seller's tax registration identifier used in countries where a tax registration separate from VAT exists, such as Germany's Steuernummer.
→ https://www.invoicenavigator.eu/glossary/bt-63-seller-tax-registration-identifier

### Chorus Pro
Chorus Pro is France's government platform for receiving and processing B2G e-invoices, mandatory for all invoices to French public entities.
→ https://www.invoicenavigator.eu/glossary/chorus-pro

### CIUS (Core Invoice Usage Specification)
A country- or sector-specific customization of the EN 16931 European e-invoicing standard that restricts or refines the core data model without breaking interoperability. Examples include XRechnung (Germany), Peppol BIS 3.0, and CIUS-IT (Italy).
→ https://www.invoicenavigator.eu/glossary/cius

### Codice SDI
The Codice SDI (Codice Destinatario) is a 7-character alphanumeric code that routes FatturaPA invoices to the correct recipient through Italy's SDI system.
→ https://www.invoicenavigator.eu/glossary/codice-sdi

### CTC (Continuous Transaction Controls)
Continuous Transaction Controls (CTC) are tax-compliance regimes in which transaction data is submitted to, or cleared by, the tax authority at or near the moment an invoice is issued, replacing periodic after-the-fact reporting with a continuous, real-time data exchange.
→ https://www.invoicenavigator.eu/glossary/ctc

### Digital signature (e-invoicing)
A cryptographic signature applied to an e-invoice (or its XML/PDF carrier) to guarantee authenticity of origin and integrity of content. In several EU CTC regimes — notably Italy's SDI and France's Chorus Pro — a qualified or advanced electronic signature is mandatory; in EN 16931 itself it is optional.
→ https://www.invoicenavigator.eu/glossary/digital-signature

### DRR (Digital Reporting Requirements)
Digital Reporting Requirements (DRR) are the ViDA pillar that, from 1 July 2030, obliges EU businesses to issue structured EN 16931 e-invoices and report transaction data to tax authorities in near real time for cross-border intra-Community B2B and B2G trade, replacing recapitulative statements.
→ https://www.invoicenavigator.eu/glossary/drr

### DUNS Number (D-U-N-S)
A 9-digit business identifier issued by Dun & Bradstreet to a legal entity or location. Registered in the ISO/IEC 6523 ICD registry under code 0060, it is a valid Peppol participant/electronic-address scheme for routing e-invoices.
→ https://www.invoicenavigator.eu/glossary/duns

### e-Reporting
France's mandatory obligation to electronically report transaction data (B2C sales, cross-border transactions) to the tax authority via the PPF — a parallel track to e-invoicing that covers transactions outside the domestic B2B scope.
→ https://www.invoicenavigator.eu/glossary/e-reporting

### EN16931
EN16931 is the European standard for electronic invoicing that defines the semantic data model and business rules all compliant e-invoices must follow.
→ https://www.invoicenavigator.eu/glossary/en16931

### Endpoint ID
The Endpoint ID is the unique identifier that locates a business on the Peppol network, combining a scheme ID with a national business registration number.
→ https://www.invoicenavigator.eu/glossary/endpoint-id

### Enterprise Number (Belgium)
The KBO/BCE enterprise number is a unique 10-digit identifier assigned to every business entity registered in Belgium, used as the primary business identifier in Belgian e-invoicing.
→ https://www.invoicenavigator.eu/glossary/enterprise-number-belgium

### Evidence Pack
An Evidence Pack is Invoice Navigator's structured compliance certificate that documents the complete validation, remediation, and revalidation chain for an e-invoice.
→ https://www.invoicenavigator.eu/glossary/evidence-pack

### Factur-X
Factur-X is the French name for the ZUGFeRD hybrid e-invoice format that embeds structured XML inside a PDF, enabling both human and machine readability.
→ https://www.invoicenavigator.eu/glossary/factur-x

### FatturaPA
FatturaPA is Italy's national e-invoice format required for all B2B and B2G invoicing through the SDI (Sistema di Interscambio) platform.
→ https://www.invoicenavigator.eu/glossary/fatturapa

### Four Corner Model
The Four Corner Model is the federated network architecture used by Peppol, where invoices travel from sender through two intermediary Access Points to the receiver.
→ https://www.invoicenavigator.eu/glossary/four-corner-model

### GLN (Global Location Number)
A 13-digit GS1 identifier that uniquely identifies a legal entity, function, or physical location — widely used as a Peppol participant ID under ISO 6523 scheme 0088, particularly in retail, healthcare, and logistics.
→ https://www.invoicenavigator.eu/glossary/gln

### Hybrid invoice
An invoice that bundles a human-readable PDF and a structured XML representation of the same data into a single file. The PDF is for people; the embedded XML is for software. ZUGFeRD and Factur-X are the two flagship hybrid formats; both use PDF/A-3 as the carrier.
→ https://www.invoicenavigator.eu/glossary/hybrid-invoice

### Interoperability framework
A coordinated set of specifications, code lists and governance rules that lets independently built systems exchange e-invoices reliably. In EU e-invoicing the canonical example is the Peppol Interoperability Framework, which combines a technical architecture with binding legal agreements.
→ https://www.invoicenavigator.eu/glossary/interoperability-framework

### KSeF
KSeF (Krajowy System e-Faktur) is Poland's national e-invoice system that will become mandatory for all B2B invoicing in February 2026.
→ https://www.invoicenavigator.eu/glossary/ksef

### KVK Number
The KVK number is an 8-digit Dutch Chamber of Commerce registration number that uniquely identifies businesses registered in the Netherlands, widely used as the primary Peppol identifier.
→ https://www.invoicenavigator.eu/glossary/kvk-number

### LEI (Legal Entity Identifier)
A 20-character ISO 17442 code that uniquely and globally identifies a legal entity. Administered by GLEIF and issued by accredited LOUs, it is a valid Peppol participant/electronic-address scheme (code 0199) for routing e-invoices.
→ https://www.invoicenavigator.eu/glossary/lei

### Leitweg-ID
A structured routing identifier used in German public-sector e-invoicing to direct XRechnung invoices to the correct government entity and internal department. Mapped to the BT-10 (Buyer Reference) field.
→ https://www.invoicenavigator.eu/glossary/leitweg-id

### Mandate phases
The staged timetables by which EU Member States introduce mandatory e-invoicing and digital reporting, typically rolling from large enterprises down to SMEs, and from receive-capability to issue-obligation. Understanding the phase calendar is the difference between a working go-live and a missed deadline.
→ https://www.invoicenavigator.eu/glossary/mandate-phases

### Nemhandel
Denmark's national e-invoicing and e-procurement infrastructure, run by the Danish Business Authority. Its registry (NHR) doubles as a Peppol SMP, and the network is migrating from the OIOUBL format to a localised Peppol BIS 4 profile branded NemHandel BIS 4.
→ https://www.invoicenavigator.eu/glossary/nemhandel

### NIF/CIF
NIF and CIF are Spanish tax identification numbers — NIF for individuals and CIF for companies — required on all Spanish e-invoices.
→ https://www.invoicenavigator.eu/glossary/nif-cif

### NIP
NIP is the Polish tax identification number (Numer Identyfikacji Podatkowej), a 10-digit code required for all B2B e-invoicing through KSeF.
→ https://www.invoicenavigator.eu/glossary/nip

### OASIS UBL (Universal Business Language)
OASIS UBL is the open library of standard XML business documents — invoices, orders, despatch advices, catalogues, and more — published by OASIS as an ISO/IEC standard (19845:2015) and used as the XML syntax behind Peppol BIS, EN 16931, and most European e-invoicing CIUSes.
→ https://www.invoicenavigator.eu/glossary/oasis-ubl

### OpenPeppol
OpenPeppol AISBL is the Belgian non-profit association that owns, governs, and develops the Peppol network — publishing the BIS specifications, code lists, and validation artefacts, and accrediting Peppol Authorities and Service Providers worldwide.
→ https://www.invoicenavigator.eu/glossary/openpeppol

### OSS (One-Stop Shop)
An EU VAT scheme that lets a business declare and pay VAT on cross-border B2C supplies across all member states through a single quarterly return in one country, instead of registering for VAT in each. It is being broadened under ViDA's Single VAT Registration package.
→ https://www.invoicenavigator.eu/glossary/oss

### OVT-tunnus (Finland)
The Finnish electronic invoicing address — a 12-to-17-digit identifier built from the prefix 0037, the company's Y-tunnus (business ID), and an optional 5-character suffix. OVT codes are the routing keys for Finnish e-invoicing and are used both in the national e-invoice network and as Peppol participant identifiers under ICD scheme 0216.
→ https://www.invoicenavigator.eu/glossary/ovt-tunnus

### Partita IVA
The Italian VAT identification number — an 11-digit numeric code issued by the Agenzia delle Entrate that identifies a business or self-employed professional for VAT purposes and is mandatory on every invoice routed through the SDI.
→ https://www.invoicenavigator.eu/glossary/partita-iva

### PDF/A-3
An ISO-standardized archival PDF format (ISO 19005-3) that allows embedding files of any type — including XML invoice data. It is the container format that makes ZUGFeRD and Factur-X hybrid invoices possible.
→ https://www.invoicenavigator.eu/glossary/pdf-a-3

### PDF/A-3
PDF/A-3 (ISO 19005-3) is an archival PDF format that allows embedded file attachments, making it the required container format for ZUGFeRD and Factur-X hybrid e-invoices.
→ https://www.invoicenavigator.eu/glossary/pdf-a3

### Peppol
Peppol is a European e-invoicing network that enables businesses to exchange electronic documents across borders using a standardized format and secure infrastructure.
→ https://www.invoicenavigator.eu/glossary/peppol

### Peppol Access Point
A Peppol Access Point is a certified service provider that connects businesses to the Peppol network, handling message routing, AS4 transport, SMP registration, and delivery receipts.
→ https://www.invoicenavigator.eu/glossary/access-point

### Peppol BIS Billing 3.0
Peppol BIS Billing 3.0 is the specific Peppol Business Interoperability Specification for invoices and credit notes — a CIUS of EN 16931 expressed in OASIS UBL 2.1, validated by Schematron, and the de-facto B2G/B2B billing format on the Peppol network.
→ https://www.invoicenavigator.eu/glossary/peppol-bis-billing-3-0

### Peppol ID
A Peppol ID is a participant identifier on the Peppol network, composed of an ISO 6523 scheme ID and a national business registration number.
→ https://www.invoicenavigator.eu/glossary/peppol-id

### Post-Audit Model
The traditional VAT compliance model where invoices are exchanged privately between seller and buyer, and the tax authority only inspects them during periodic or triggered audits. It is the model that Continuous Transaction Controls (CTC) — clearance and real-time reporting — are progressively replacing.
→ https://www.invoicenavigator.eu/glossary/post-audit-model

### PPF (Portail Public de Facturation)
The French government's public e-invoicing portal that serves as the central directory and data concentrator for France's mandatory B2B e-invoicing reform launching September 2026.
→ https://www.invoicenavigator.eu/glossary/ppf

### QR code (e-invoice)
A 2D barcode embedded on or alongside an electronic invoice that encodes a compact, machine-readable summary of the invoice — typically issuer VAT, total, VAT amount, timestamp, and a cryptographic hash. Mandatory in several CTC regimes (notably Saudi Arabia ZATCA and India), optional in most EU formats.
→ https://www.invoicenavigator.eu/glossary/qr-code-e-invoice

### Real-Time Reporting
A Continuous Transaction Controls (CTC) model in which invoice data is transmitted to the tax authority within minutes or hours of invoice issuance — but after the invoice has already been exchanged with the buyer. Unlike clearance, real-time reporting does not block or pre-approve the invoice; it runs in parallel.
→ https://www.invoicenavigator.eu/glossary/real-time-reporting

### Schematron
Schematron is an XML-based validation language that checks business rules in e-invoices using XPath expressions, producing specific error codes when conditions fail.
→ https://www.invoicenavigator.eu/glossary/schematron

### Scheme ID
A Scheme ID is a code that identifies the type of business identifier used in an e-invoice, such as a VAT number, chamber of commerce registration, or national enterprise number.
→ https://www.invoicenavigator.eu/glossary/scheme-id

### SDI (Sistema di Interscambio)
SDI is Italy's central government platform that receives, validates, and routes all electronic invoices for both B2B and B2G transactions.
→ https://www.invoicenavigator.eu/glossary/sdi

### SIREN
The 9-digit French business identification number issued by INSEE that identifies a legal entity as a whole — the root identifier from which SIRET establishment numbers and the French VAT number are derived.
→ https://www.invoicenavigator.eu/glossary/siren

### SIRET Number
SIRET is a 14-digit French establishment identification number (SIREN 9 + NIC 5) that uniquely identifies a specific business location, used in Factur-X and PDP-based e-invoicing.
→ https://www.invoicenavigator.eu/glossary/siret

### Tax point (VAT point date)
The date on which VAT becomes chargeable on a supply — the 'time of supply'. It can differ from the invoice date and is carried in EN 16931 as BT-7 (VAT point date) or, alternatively, BT-8 (VAT point date code).
→ https://www.invoicenavigator.eu/glossary/tax-point

### Two-corner model
A direct, point-to-point e-invoicing exchange between exactly two parties — sender and receiver — without intermediaries. The pre-Peppol baseline: bespoke EDI agreements, custom mappings, and one connection per trading partner. Largely superseded by the four-corner model for open networks, but still common inside closed supply chains.
→ https://www.invoicenavigator.eu/glossary/two-corner-model

### UN/CEFACT
The United Nations Centre for Trade Facilitation and Electronic Business — the UNECE intergovernmental body that produces the Cross Industry Invoice (CII), the second of the two XML syntaxes accepted by EN 16931. UN/CEFACT also publishes the Core Component Library that underpins CII, ZUGFeRD, Factur-X, and most non-UBL e-business standards used in Europe.
→ https://www.invoicenavigator.eu/glossary/un-cefact

### Verifactu
Spain's certified invoicing system operated by the AEAT (tax agency) that requires all billing software to produce tamper-evident, hash-chained invoice records — with optional real-time submission to the tax authority.
→ https://www.invoicenavigator.eu/glossary/verifactu

### ViDA (VAT in the Digital Age)
ViDA is the EU's VAT in the Digital Age package, adopted in March 2025, which makes structured e-invoicing and near-real-time digital reporting the default for cross-border B2B trade and modernises VAT rules for the platform economy and single VAT registration.
→ https://www.invoicenavigator.eu/glossary/vida

### VIES (VAT Information Exchange System)
The European Commission's federated lookup service for validating intra-EU VAT numbers. VIES does not hold a central database — it forwards each query to the issuing Member State's tax administration and returns the live response. Frequently confused with Peppol participant lookup; the two solve different problems.
→ https://www.invoicenavigator.eu/glossary/vies

### XML Schema (XSD)
The W3C standard for describing the structure, data types, and constraints of an XML document. XSD is the first validation layer in any e-invoice pipeline — does the file have the right elements, in the right order, with the right types? Schematron handles business rules on top; both UBL 2.1 and CII D16B ship authoritative XSD schemas.
→ https://www.invoicenavigator.eu/glossary/xml-schema

### XPath
A W3C query language for addressing parts of an XML document by path expressions. In EU e-invoicing, XPath is the glue: every Schematron rule, every XSLT mapping, and every "the element at this location is wrong" error message ultimately speaks XPath. ERP developers cannot debug EN 16931 validation without reading it.
→ https://www.invoicenavigator.eu/glossary/xpath

### XRechnung
XRechnung is Germany's national CIUS (Core Invoice Usage Specification) that extends EN16931 with German-specific requirements for B2G e-invoicing.
→ https://www.invoicenavigator.eu/glossary/xrechnung

### XSLT
A W3C language for transforming XML documents into other XML, HTML, or text. In EU e-invoicing, XSLT is the engine that compiles Schematron rules for fast runtime validation, renders UBL or CII invoices into human-readable HTML or PDF (the KoSIT XRechnung visualization toolchain), and converts legacy ERP exports into EN 16931 syntaxes.
→ https://www.invoicenavigator.eu/glossary/xslt

### ZUGFeRD
ZUGFeRD is a German hybrid e-invoice format that embeds structured XML data inside a PDF/A-3 document, making invoices both human-readable and machine-processable.
→ https://www.invoicenavigator.eu/glossary/zugferd

---

## Learning Resources

### What is Peppol?
Peppol (Pan-European Public Procurement Online) is the dominant e-invoicing network in Europe. It’s a set of open specifications that define how businesses exchange electronic documents — invoices, credit notes, purchase orders — across borders, systems, and formats.

Think of it as SMTP for invoices. Your ERP connects to a certified Access Point. The Access Point routes your invoice to the receiver’s Access Point. Both sides speak the same language (Peppol BIS Billing 3.0), regardless of what ERP, accounting system, or country either party operates in.

Originally an EU-funded project launched in 2008 for public procurement, Peppol now covers B2B e-invoicing across 39+ countries with 300,000+ registered participants. As of 2026, Belgium, Germany, and Poland mandate Peppol for B2B transactions. France, Spain, and others are adding Peppol support alongside national systems.
→ https://www.invoicenavigator.eu/learn/peppol

### What is XRechnung?
XRechnung is Germany's national implementation (CIUS) of the EN 16931 European e-invoicing standard, mandatory for all public sector invoicing in Germany.
→ https://www.invoicenavigator.eu/learn/xrechnung

### What is ZUGFeRD?
ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a hybrid e-invoice format that embeds machine-readable XML data inside a PDF/A-3 document. Open the file in a PDF reader — you see a normal invoice. Parse the embedded XML — you get structured data that an ERP can process automatically.

ZUGFeRD 2.x and Factur-X are the same specification. They unified in 2020. The only difference is the name: ZUGFeRD is the German branding, Factur-X is the French. The underlying XML is CII (Cross Industry Invoice) D16B syntax, and the embedded file is always named factur-x.xml.

The current version is ZUGFeRD 2.3.2 (aligned with Factur-X 1.07.2), released in late 2024. It’s EN 16931-compliant and accepted as a valid e-invoice format under Germany’s B2B mandate.
→ https://www.invoicenavigator.eu/learn/zugferd

### What is EN 16931?
EN 16931 is the European standard defining the semantic data model for electronic invoices, published by CEN and mandated by EU Directive 2014/55/EU.
→ https://www.invoicenavigator.eu/learn/en16931

### What is Factur-X?
Factur-X is the Franco-German hybrid e-invoice format (identical to ZUGFeRD 2.0+) that embeds structured XML data inside a PDF/A-3 document, compliant with EN 16931.
→ https://www.invoicenavigator.eu/learn/factur-x

### What is UBL?
Universal Business Language (UBL) 2.1 is an OASIS XML standard for business documents including invoices, widely used as the syntax for Peppol BIS and national e-invoicing implementations.
→ https://www.invoicenavigator.eu/learn/ubl

### What is CII?
Cross Industry Invoice (CII) is a UN/CEFACT XML syntax for electronic invoices, used as the base format for ZUGFeRD, Factur-X, and one of the two EN 16931-compliant syntaxes.
→ https://www.invoicenavigator.eu/learn/cii

### Quick Start: Fix E-Invoice Errors
Invoice Navigator's Fixer tool automatically corrects technical errors in your e-invoices, making them compliant in seconds.
→ https://www.invoicenavigator.eu/learn/fixer-quick-start

### What is E-Invoice Remediation?
E-invoice remediation is the controlled, automated correction of structural compliance errors in electronic invoices, with explicit safety boundaries that prevent modification of financial fields like amounts, VAT rates, and bank details.
→ https://www.invoicenavigator.eu/learn/e-invoice-remediation

### What is KoSIT?
KoSIT (Koordinierungsstelle für IT-Standards) is the German federal coordination office for IT standards that maintains the official validation engine for XRechnung and EN 16931 e-invoices.
→ https://www.invoicenavigator.eu/learn/kosit

### What is an Evidence Pack?
An Evidence Pack is Invoice Navigator's audit-ready compliance certificate containing the original invoice, validation results, remediation log, SHA-256 hash, QR verification code, and links to the exact rule versions used.
→ https://www.invoicenavigator.eu/learn/evidence-pack

### What is E-Invoicing?
E-invoicing (electronic invoicing) is the exchange of invoice documents between supplier and buyer in a structured electronic format — such as UBL, CII, XRechnung, or Factur-X — that can be automatically processed by software without manual data entry.
→ https://www.invoicenavigator.eu/learn/what-is-e-invoicing

### How to Validate E-Invoices
E-invoice validation is the process of checking a structured electronic invoice against schema, business rule, and country-specific rule sets to ensure it is compliant before submission to the buyer or tax authority.
→ https://www.invoicenavigator.eu/learn/how-to-validate

### What is FatturaPA?
FatturaPA is the mandatory XML-based electronic invoice format used in Italy. Every invoice — B2B, B2C, and B2G — must be transmitted through the Sistema di Interscambio (SDI), a centralized government platform operated by the Agenzia delle Entrate (Italian Revenue Agency). The SDI validates each invoice against format and schema rules before forwarding it to the recipient.

Italy was the first EU member state to mandate e-invoicing for all domestic B2B transactions, enforcing the requirement from January 1, 2019. The system follows a clearance model: invoices must be approved by the SDI before they are legally considered issued. This gives the tax authority real-time visibility into every commercial transaction.

The format uses a proprietary XML schema (currently version 1.2, with technical specifications at version 1.9 as of April 2025) distinct from UBL or CII. Two transmission codes identify the invoice type: FPA12 for invoices to public administrations and FPR12 for invoices to private parties.
→ https://www.invoicenavigator.eu/learn/fatturapa

### What is KSeF?
KSeF (Krajowy System e-Faktur — National e-Invoice System) is Poland’s centralized government platform for issuing, receiving, and storing structured electronic invoices. Operated by the Polish Ministry of Finance, KSeF follows a clearance model: invoices must be submitted to the platform, validated, and assigned a unique KSeF ID before they are legally considered issued.

Poland’s President signed the KSeF mandate into law on August 27, 2025, establishing a phased rollout beginning February 1, 2026. Large taxpayers (annual turnover exceeding PLN 200 million) were required to issue e-invoices through KSeF from that date. All other VAT-registered businesses follow from April 1, 2026, with micro-entrepreneurs joining from January 1, 2027.

KSeF uses a proprietary XML schema called FA(3) — the successor to the earlier FA(2) format. Every invoice submitted to KSeF must conform to this schema. The platform validates the structure, assigns a KSeF reference number, and makes the invoice available for the buyer to retrieve. KSeF stores all invoices centrally for 10 years.
→ https://www.invoicenavigator.eu/learn/ksef

---

## Format Comparisons

### XRechnung vs ZUGFeRD: Which German E-Invoice Format Do You Need?
XRechnung is a pure XML format required for German government invoicing, while ZUGFeRD is a hybrid format combining PDF and XML that works for both business and government transactions. Both comply with the European standard EN 16931, but they serve different purposes.
→ https://www.invoicenavigator.eu/compare/xrechnung-vs-zugferd

### Peppol vs Factur-X: Network vs Format Comparison
Peppol is a document exchange network, while Factur-X is a file format. They solve different problems and can work together—you can convert a Factur-X invoice to Peppol BIS format and send it via the Peppol network.
→ https://www.invoicenavigator.eu/compare/peppol-vs-factur-x

### UBL vs CII: Which XML Syntax Should You Use?
UBL (Universal Business Language) and CII (Cross-Industry Invoice) are two XML syntaxes for expressing EN 16931 invoices. Both carry the same business information—the difference is technical structure. Your choice usually depends on which formats and networks you need to support.
→ https://www.invoicenavigator.eu/compare/ubl-vs-cii

### Invoice Navigator vs ecosio: E-Invoice Compliance Comparison
Invoice Navigator and ecosio both address EU e-invoice compliance, but from different angles. Invoice Navigator is a compliance API that validates, remediates, and generates audit evidence. ecosio is a document exchange platform focused on format conversion and Peppol access point services.
→ https://www.invoicenavigator.eu/compare/invoice-navigator-vs-ecosio

### Invoice Navigator vs Storecove: E-Invoice Compliance Comparison
Invoice Navigator and Storecove both offer APIs for e-invoice compliance, but serve different parts of the pipeline. Invoice Navigator validates, remediates, and generates audit evidence. Storecove provides Peppol network connectivity with pre-flight compliance checks.
→ https://www.invoicenavigator.eu/compare/invoice-navigator-vs-storecove

### E-Invoice vs PDF: Why a PDF Is Not a Structured E-Invoice
EU e-invoicing mandates require structured, machine-readable invoice data. A PDF — even one sent by email — does not meet this requirement. Here’s why the distinction matters and what it means for your invoice pipeline.
→ https://www.invoicenavigator.eu/compare/e-invoicing-vs-pdf

### Peppol vs XRechnung: Network vs Format — How They Work Together
Peppol and XRechnung are not competing standards — they’re complementary. Peppol is the network that delivers invoices. XRechnung is the format specification for German e-invoices. XRechnung invoices are sent via Peppol. Understanding this distinction is critical for German e-invoicing compliance.
→ https://www.invoicenavigator.eu/compare/peppol-vs-xrechnung

### Factur-X vs XRechnung: Hybrid PDF vs Pure XML for EU E-Invoicing
Factur-X embeds structured CII XML inside a PDF/A-3 container. XRechnung is pure XML — no PDF wrapper. Both are EN 16931 compliant and accepted under Germany’s B2B mandate. The choice depends on whether your recipients need a visual PDF or pure machine-to-machine data.
→ https://www.invoicenavigator.eu/compare/factur-x-vs-xrechnung

### EN 16931 vs Peppol: The Standard vs the Network Specification
EN 16931 is the European content standard — it defines what data an e-invoice must contain. Peppol BIS 3.0 is a CIUS that adds rules for how invoices are structured and delivered on the Peppol network. They’re layers, not alternatives: every Peppol invoice is EN 16931 compliant, but not every EN 16931 invoice is Peppol-ready.
→ https://www.invoicenavigator.eu/compare/en16931-vs-peppol

### Peppol vs Italy’s SDI: Federated Network vs Centralized System
Italy’s Sistema di Interscambio (SDI) is a centralized government hub that processes every domestic e-invoice. Peppol is a federated network where certified Access Points route invoices directly between businesses. They represent fundamentally different approaches to e-invoicing infrastructure — and for businesses trading with Italy, understanding both is essential.
→ https://www.invoicenavigator.eu/compare/peppol-vs-sdi

---

## Validation Rules (1383 total)

Full error library: https://www.invoicenavigator.eu/errors

### Business Rules (354)
- **BR-01**: Every Peppol BIS invoice must include a specification identifier (CustomizationID) that indicates which profile the invoice conforms to. [auto]
- **BR-02**: Every invoice must contain a unique invoice number (ID) to identify the document. [input]
- **BR-03**: Every invoice must contain an issue date indicating when the invoice was created. [auto]
- **BR-04**: An Invoice shall have an Invoice type code (BT-3). The most common value is 380 for a standard commercial invoice. [auto]
- **BR-05**: An Invoice shall have an Invoice currency code (BT-5). This specifies the currency used for all monetary amounts in the invoice using ISO 4217 three-letter codes. [auto]
- **BR-06**: An Invoice shall contain the Seller name (BT-27). This is the trading name or legal name of the seller/supplier. [input]
- **BR-07**: An Invoice shall contain the Buyer name (BT-44). This is the trading name or legal name of the buyer/customer. [input]
- **BR-08**: An Invoice shall contain the Seller postal address (BG-5). At minimum, the country code is required. [input]
- **BR-09**: Your invoice has a seller postal address but is missing the country code. Every invoice must include the seller's country as a two-letter ISO code (e.g. DE for Germany, NL for Netherlands). [input]
- **BR-10**: An Invoice shall contain the Buyer postal address (BG-8). At minimum, the country code is required. [input]
- **BR-11**: The Buyer postal address (BG-8) shall contain a Buyer country code (BT-55) using ISO 3166-1 alpha-2. [input]
- **BR-12**: The invoice must contain the total amount including VAT (TaxInclusiveAmount). [blocked]
- **BR-13**: The invoice must state the amount due for payment (PayableAmount). [blocked]
- **BR-14**: Each invoice line must have a net amount (LineExtensionAmount). [blocked]
- **BR-15**: The Amount due for payment (BT-115) is required.. Check the `cbc:PayableAmount` element in your invoice XML. [blocked]
- **BR-16**: Each invoice line must have a unique line identifier (ID). [blocked]
- **BR-17**: Each invoice line must have an item name describing what is being invoiced. [input]
- **BR-18**: Each invoice line must have a price amount (item net price). [input]
- **BR-19**: The Seller tax representative postal address (BG-12) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11). This applies to the `cac:PostalAddress` element in the invoice XML. [input]
- **BR-20**: The Seller tax representative postal address (BG-12) shall contain a Tax representative country code (BT-69), if the Seller (BG-4) has a Seller tax representative party (BG-11). This applies to the `cac:PostalAddress` element in the invoice XML. [input]
- ...and 334 more at https://www.invoicenavigator.eu/errors/category/business

### Codelist Rules (1)
- **PEPPOL-EN16931-R049**: PEPPOL-EN16931-R049 fires when a party's legal entity ID (BT-30 / cac:PartyLegalEntity/cbc:CompanyID) declares scheme 0007 (Swedish Organisationsnummer) but the value isn't a valid Swedish org number — 10 digits, all numeric, passing the Luhn checksum. In newer Peppol releases this rule was renamed PEPPOL-COMMON-R049, but the EN16931 label is still returned by many national validators and corporate ingest pipelines. [auto]

### Country Rules (227)
- **AT-01**: Austrian sellers should include UID number. This validation rule ensures Invoice compliance with CIUS-AT (Austria). [blocked]
- **AT-R-002**: Austrian VAT number must be ATU + 8 digits. [input]
- **AT-R-003**: Austrian postal codes should be 4 digits. [input]
- **AT-R-004**: Austrian B2G invoices must comply with ERB requirements. [blocked]
- **BE-01**: Belgian B2B invoices should use Peppol BIS Billing 3.0. This validation rule ensures Invoice compliance with CIUS-BE (Belgium). [blocked]
- **BE-02**: Belgian sellers should include enterprise number (KBO/BCE). This validation rule ensures Invoice compliance with CIUS-BE (Belgium). [blocked]
- **BE-03**: Belgian VAT numbers must be in correct format. This validation rule ensures Invoice compliance with CIUS-BE (Belgium). [blocked]
- **BR-AT-01**: Austrian invoices must include the UID-Nummer (VAT ID) in ATU + 8 digits format. [input]
- **BR-BE-01**: Belgian invoices should include the 10-digit enterprise number (ondernemingsnummer) formatted as 0XXX.XXX.XXX. [input]
- **BR-BE-02**: Belgian invoices should include the BTW/TVA number in format BE + 10 digits. [input]
- **BR-BE-10**: Belgian enterprise numbers (KBO/BCE) must be formatted as 0XXX.XXX.XXX with schemeID="0208". This is required for all Belgian business identifiers in Peppol invoices. [input]
- **BR-BE-11**: Belgian VAT numbers must start with the BE prefix. The format should be BE followed by 10 digits (BE0XXXXXXXXX). [input]
- **BR-BE-12**: B2G invoices to Belgian government must use the correct Mercurius endpoint format. The endpoint ID must be a valid Mercurius identifier. [input]
- **BR-DE-01**: German B2G (Business-to-Government) invoices require a valid Leitweg-ID in the Buyer Reference field (BT-10). The Leitweg-ID is a routing identifier that directs your invoice to the correct government department. [input]
- **BR-DE-02**: German invoices should include payment terms text (Zahlungsbedingungen) for clarity. [input]
- **BR-DE-03**: German B2B invoices must include the USt-IdNr (VAT identification number) in DE + 9 digits format. [input]
- **BR-DE-04**: XRechnung invoices must use the correct specification identifier for the version. [blocked]
- **BR-DE-05**: XRechnung to German public sector requires valid Leitweg-ID as buyer reference. [input]
- **BR-DE-06**: German invoices should specify payment terms including any early payment discount (Skonto). [input]
- **BR-DE-07**: German postal codes should be 5 digits. [input]
- ...and 207 more at https://www.invoicenavigator.eu/errors/category/country

### Format Rules (762)
- **CII-DT-024**: CII-DT-024 is an EN 16931 datatype assertion on the CII binding. Every udt:DateTimeString or udt:DateString must carry format="102" — the UN/EDIFACT code for an eight-digit CCYYMMDD date. [auto]
- **CII-DT-037**: CII-DT-037 is a fatal EN 16931 datatype assertion on the CII binding. It restricts ram:TypeCode inside ram:ApplicableTradeTax and ram:CategoryTradeTax to the literal value 'VAT'. EN 16931 is a VAT-centric standard and rejects every other UN/EDIFACT 5153 tax type. [auto]
- **CII-FIX-CURRENCY**: All currency codes in CII invoices must be uppercase ISO 4217 codes. This includes the @currencyID attribute on amount elements and the ram:InvoiceCurrencyCode element. Lowercase currency codes like "eur" are invalid. [auto]
- **CII-FIX-DATE**: All dates in CII invoices must use format code 102 (YYYYMMDD) in the udt:DateTimeString element. ISO 8601 dates with hyphens (YYYY-MM-DD) are not valid in CII — the hyphens must be removed and the @format attribute set to "102". [auto]
- **CII-FIX-VATEX**: CII invoices with VAT categories O (Outside scope), E (Exempt), AE (Reverse charge), G (Export), or K (Intra-community) require a valid VATEX exemption reason code. This fix normalizes the ExemptionReasonCode at header level and propagates it to line-level tax breakdowns that are missing it. [auto]
- **cvc-enumeration-valid**: cvc-enumeration-valid is an XSD facet-validation error raised when the value of an element or attribute does not appear in the enumeration the schema declares. The canonical message reads: "Value X is not facet-valid with respect to enumeration [A, B, C ...]. It must be a value from the enumeration." In EN 16931 invoices it fires on unit codes, currency codes, document type codes, and tax category codes. [input]
- **cvc-minLength-valid**: cvc-minLength-valid is an XSD facet-validation error raised when a string is shorter than the xsd:minLength facet on its simple type. The canonical message reads: "Value 'X' with length = N is not facet-valid with respect to minLength '1' for type 'T'." In EN 16931 invoices the overwhelming majority of cases are minLength=1 violations — i.e. an empty element. The XSD treats the empty string as a structural failure, even though the surrounding element is technically present. [input]
- **cvc-pattern-valid**: cvc-pattern-valid is an XSD facet-validation error raised when an element or attribute value fails the xsd:pattern regular expression declared on its simple type. The canonical message reads: "Value 'X' is not facet-valid with respect to pattern 'P' for type 'T'." In EN 16931 invoice payloads it usually fires on identifier fields (BT-30 Seller legal registration ID, BT-46 Buyer identifier, BT-90 Bank assigned creditor identifier), date fields with a stricter UN/CEFACT format pattern, and country-CIUS extensions like the Italian fattura tax-ID pattern. [input]
- **FORMAT-001**: Your file was read successfully as XML, but it does not contain a recognized e-invoice structure. Supported formats are UBL 2.1 Invoice, UBL 2.1 CreditNote, and UN/CEFACT Cross-Industry Invoice (CII D16B). The file may have been exported in the wrong format, or it may be a different type of XML document (such as an order or dispatch advice). [blocked]
- **FORMAT-002**: Factur-X requires PDF/A-3 base document. [blocked]
- **FORMAT-003**: Factur-X XML must be named correctly. [blocked]
- **FORMAT-004**: ZUGFeRD documents must specify valid profile. [blocked]
- **IN-ALLOWANCE-AMOUNT-REQUIRED**: AllowanceCharge elements must have an Amount element specified. [input]
- **IN-ISSUE-DATE-REQUIRED**: Invoice must have an issue date specified. [input]
- **IN-PAYABLE-POSITIVE**: The amount due for payment (PayableAmount) should typically be a positive value. [blocked]
- **IN-PRICE-POSITIVE**: Item price (PriceAmount) should typically be a positive value. [blocked]
- **IN-QUANTITY-POSITIVE**: Invoice line quantity (InvoicedQuantity) should typically be a positive value. [blocked]
- **IN-TAX-SUBTOTAL-AMOUNT**: Each VAT breakdown (TaxSubtotal) must have a tax amount specified. [input]
- **IN-TAX-TOTAL-AMOUNT**: Invoice must have a total VAT amount in the TaxTotal element. [input]
- **PEPPOL-COMMON-R052**: PEPPOL-COMMON-R052 validates that a Danish chamber of commerce production unit number (P-number) is in the correct format. The P-number must consist of exactly 10 digits. This rule fires when a party identifier uses scheme 0198 but the value does not meet the format requirements. [auto]
- ...and 742 more at https://www.invoicenavigator.eu/errors/category/format

### Structure Rules (2)
- **PEPPOL-EN16931-R006**: PEPPOL-EN16931-R006 was a Peppol BIS 3 rule that rejected invoices carrying more than one AdditionalDocumentReference with DocumentTypeCode 130 (the 'Invoiced Object Identifier', BT-18) at document level. The rule was removed in later Peppol BIS releases because it duplicated UBL-SR-04, but validators built on older schematron snapshots — and many Stack Overflow answers written before the retirement — still reference it. [input]
- **PEPPOL-EN16931-R050**: PEPPOL-EN16931-R050 is a fatal Peppol BIS 3 rule that fires when the seller's electronic address (cbc:EndpointID inside cac:AccountingSupplierParty/cac:Party) is missing or empty. In Peppol, the seller's EndpointID is the address the receiving Access Point uses to route the document back to the sender, so the network refuses invoices without it. [auto]

### Syntax Rules (37)
- **CII-DT-018**: CII-DT-018 is an EN 16931 datatype assertion on the CII binding. It forbids a ram:TypeCode child on any element except ram:AdditionalReferencedDocument, and even there restricts the value to UNTDID 1001 codes 50 (price/sales catalogue), 130 (invoicing data sheet), or 916 (related document). [auto]
- **CII-SR-001**: CII (Cross Industry Invoice) documents must use the correct namespace declaration. [blocked]
- **CII-SR-002**: CII documents must include the ExchangedDocumentContext header. [blocked]
- **CII-SR-003**: CII TypeCode must be valid UNTDID 1001 code (380=Invoice, 381=Credit Note). [input]
- **CII-SR-01**: Cross Industry Invoice must declare RSM namespace. [auto]
- **CII-SR-02**: CII must specify guideline identifier. [blocked]
- **CII-SR-03**: CII must have ExchangedDocument with ID and TypeCode. [blocked]
- **CII-SR-04**: CII must have main trade transaction element. [blocked]
- **CII-SR-046**: CII-SR-046 is a fatal EN 16931 Schematron assertion on the CII binding used by ZUGFeRD and Factur-X. If ram:GlobalID is present, it must carry a schemeID attribute. Formal test: not(ram:GlobalID) or (ram:GlobalID/@schemeID). [input]
- **CII-SR-05**: CII must specify seller and buyer. [blocked]
- **cvc-complex-type.2.1**: cvc-complex-type.2.1 is an XSD schema-validation error raised by Xerces-based parsers when an element whose content type is declared as empty contains character data or child elements. The canonical message reads: "Element X must have no character or element information item [children], because the type's content type is empty." [confirm]
- **cvc-complex-type.2.2**: The elements in your invoice XML are in the wrong order. UBL 2.1 and CII D16B schemas use strict element ordering (xs:sequence), which means child elements must appear in a specific order. Even if all the right elements are present with correct values, having them in the wrong order causes a schema validation failure. [auto]
- **cvc-complex-type.2.3**: cvc-complex-type.2.3 is an XSD error raised when an element declared as element-only has non-whitespace text inside it. Mixing text and structural children is not allowed for that complex type. [confirm]
- **cvc-complex-type.2.4.a**: Your invoice file has a structural problem — required data elements are missing, in the wrong position, or unexpected elements are present. This is an XML Schema validation error, which means the basic structure of the file does not conform to the e-invoicing standard (UBL 2.1 or CII D16B). This is different from a business rule error: business rules check whether the data makes sense, while this error means the file format itself is wrong. [blocked]
- **cvc-complex-type.2.4.b**: cvc-complex-type.2.4.b is an XML Schema (XSD) validation error meaning an element's content is incomplete: the schema requires a child element that is not present. The message reads "The content of element 'X' is not complete. One of {'Y'} is expected." Unlike a business rule (BR-*) violation, this is a structural failure — the document does not conform to the UBL or CII schema, so it fails before any EN 16931 business rules are evaluated. [input]
- **cvc-complex-type.2.4.d**: cvc-complex-type.2.4.d is an XSD schema-validation error raised by Xerces-based parsers when the invoice contains an element the schema does not allow at that position. The parser has finished accepting the declared children for the current parent and encountered one more element it was not expecting. [blocked]
- **cvc-complex-type.4**: An XML element in your invoice is missing a required attribute. In Peppol and UBL invoices, this typically means a monetary amount is missing its currencyID attribute, or an identifier is missing its schemeID. The element itself is present, but it lacks required metadata that receiving systems need to process it correctly. [blocked]
- **cvc-datatype-valid.1.2.1**: cvc-datatype-valid.1.2.1 is an XML Schema (XSD) validation error meaning a value does not satisfy the lexical rules of its declared simple type. The message reads "'X' is not a valid value for 'Y'." In e-invoicing this usually means a number, date, or boolean is formatted in a locale or style the schema does not allow — a comma decimal separator, a DD/MM/YYYY date, or 'Yes'/'No' for a boolean. [auto]
- **PEPPOL-EN16931-R102**: PEPPOL-EN16931-R102 fires when a DocumentReference element is used at the wrong level in the invoice. The cac:DocumentReference element can only be used to reference an invoiced object at the line level, not at the document header level. [auto]
- **UBL-CR-002**: The UBL invoice must use the correct XML namespaces for UBL 2.1. [auto]
- ...and 17 more at https://www.invoicenavigator.eu/errors/category/syntax

---

## API & Tools

- **API Documentation**: https://www.invoicenavigator.eu/developers
- **API Quickstart**: https://www.invoicenavigator.eu/developers/quickstart
- **API Authentication**: https://www.invoicenavigator.eu/developers/authentication
- **API Sandbox**: https://www.invoicenavigator.eu/developers/sandbox
- **Online Validator** (free): https://www.invoicenavigator.eu/validator
- **Format Converter**: https://www.invoicenavigator.eu/convert
- **Format Finder Tool**: https://www.invoicenavigator.eu/tools/format-finder
- **Obligation Finder**: https://www.invoicenavigator.eu/obligation-finder
- **E-Invoicing Deadlines**: https://www.invoicenavigator.eu/deadlines
- **ViDA Compliance Guide**: https://www.invoicenavigator.eu/vida
- **Pricing**: https://www.invoicenavigator.eu/pricing (free unlimited validation; pay-as-you-go from EUR 7.90 per certified Evidence Pack download)

## Company

Invoice Navigator is built by CCC Impact BV in Apeldoorn, Netherlands.
Contact: hello@invoicenavigator.eu
Website: https://www.invoicenavigator.eu