EN 16931: The Semantic Model Behind European eInvoicing
EN 16931 is the European Standard that defines what data a legal electronic invoice must contain. Every format this converter works with — UBL, CII, Factur-X, FatturaPA — is built on top of this model. Understanding EN 16931 helps you catch conversion problems before they cause downstream rejections.
What EN 16931 Actually Is
EN 16931 is not a file format. It is a semantic data model — a format-neutral description of every piece of information that a compliant invoice must or may carry. Think of it as a master field list: 176 named invoice elements, each with a clear business meaning, a data type, and a cardinality rule (mandatory, conditional, or optional).
CEN (the European Committee for Standardization) published EN 16931-1 in 2017. Two official XML syntax bindings were released alongside it: one for UBL 2.1 and one for UN/CEFACT CII. Both encode the same 176 fields — they just use different tag names and namespace structures.
When this tool converts a FatturaPA or Factur-X file into UBL, the conversion is guided by EN 16931 field mapping. Fields that exist in the source but have no EN 16931 equivalent are dropped. Fields that EN 16931 requires but the source left empty will cause a validation warning.
The Five Information Groups
EN 16931 organises its 176 elements into five logical groups. Knowing these groups helps you understand where a conversion failure is coming from:
Mandatory Business Terms
EN 16931 marks certain fields as mandatory (cardinality 1..1). If any of these are absent, the invoice is not EN 16931 compliant and will be rejected by validators. The table below covers the ones most often missing in real conversion scenarios:
| Field ID | Name | Why it matters in conversion |
|---|---|---|
| BT-1 | Invoice number | Must be unique; often reformatted during conversion |
| BT-2 | Invoice issue date | Format differs (YYYY-MM-DD vs YYYYMMDD) between UBL and FatturaPA |
| BT-9 | Payment due date | Conditional mandatory when payment terms are present |
| BT-31 / BT-32 | Seller VAT ID or tax number | FatturaPA uses CodiceFiscale; UBL uses schemeID; mapping must be explicit |
| BT-48 | Buyer VAT identifier | Frequently missing in B2C source files; causes B2B validation failure |
| BT-112 | Invoice total with VAT | Must equal sum of line net amounts plus total VAT; any rounding difference fails |
| BT-115 | Amount due for payment | Must match BT-112 minus any prepayments; often incorrectly copied as-is |
| BT-118 | VAT category tax amount | Must be consistent with rate × taxable base at both line and total level |
| BG-25 | Invoice line (group) | At least one line is mandatory; some conversions lose lines when amounts are zero |
Common Compliance Mistakes in Production
These are the problems that appear most often when teams convert real invoice files between formats:
1. VAT amount inconsistency between lines and totals
EN 16931 requires that the tax total (BT-110) equals the sum of all line-level VAT amounts. When a source file calculates VAT per line with rounding and the target recalculates from totals, you can end up with a 1–2 cent difference that causes rejection. Fix this by preserving the source tax amounts instead of recalculating them.
2. Missing or wrong VAT category code
EN 16931 requires every invoice line to carry a VAT category code (BT-151): S for standard rate, AE for reverse charge, Z for zero-rated, E for exempt. FatturaPA uses its own nature codes (N1–N7) for non-standard VAT. When converting to UBL, each nature code must be mapped to the correct EN 16931 category — not defaulted to S.
3. Party identifier scheme mismatch
UBL carries company identifiers with a schemeID attribute (e.g. 0208 for Belgian KBO numbers). FatturaPA stores them as plain text in IdFiscaleIVA or CodiceFiscale. Dropping the schemeID during conversion produces a structurally valid file that fails business-rule validation at the receiving end.
4. Date format drift
UBL requires ISO 8601 dates: 2025-06-15. FatturaPA uses the same format but some ERP exports produce 15/06/2025 or 20250615. Always normalise dates to ISO 8601 before mapping to a target format.
5. Zero-amount line items silently dropped
Some converters skip invoice lines where the net amount is zero (discounts, free items). EN 16931 allows zero-amount lines and many downstream systems rely on them for order matching. Check that your output contains the same number of lines as the source.
6. Currency code not propagated to every amount field
In UBL, every monetary amount element carries a currencyID attribute. If a converter copies the amount but omits the attribute, the file fails XSD validation. EN 16931 BT-5 (invoice currency) must match the currency declared on every amount field.
How This Converter Handles EN 16931 Compliance
Every conversion path in this tool maps source fields to EN 16931 business term IDs before writing the target syntax. This means a FatturaPA-to-UBL conversion does not guess at tag positions — it resolves each source element to its BT or BG identifier and then writes the correct UBL tag for that identifier. Fields that EN 16931 requires but the source omits are flagged rather than silently skipped.
Continue Reading
- European eInvoicing Overview
- Peppol BIS 3.0 — identifiers, network, validation layers
- Country formats — Italy, Germany, France, Poland
- Conversion matrix — every supported path
- implementation-guide — onboarding steps for ERP/accounting teams