All three, depending on which layer is asking. VAT law lists 15 mandatory particulars in Article 226 of the VAT Directive, rising to 17 on 1 July 2030. ViDA’s digital reporting will transmit exactly 10 of those 17 to the tax authority for a cross-border supply. EN 16931’s core invoice model defines around 170 business terms — 176 by the most-cited count, and even that figure is contested — of which roughly 25 are mandatory. And the UBL syntax that carries all of it has no published field count at all.
That gives three numbers and one non-answer to “what’s on an invoice” — and the part that breaks data models is that the sets are not nested. Each layer makes something mandatory that the others don’t ask for. There is no superset invoice to model against.
The three layers, and what each one is actually for
The confusion is structural, not sloppy. Each layer was defined by a different body answering a different question.
- The legal invoice — Article 226 of the VAT Directive. Question: what must a document say to establish a VAT position? Roughly 15–17 particulars, and it is a closed list.
- The reportable set — Article 264 as replaced by ViDA. Question: what does the tax authority need transmitted? Ten data points for cross-border B2B, fixed EU-wide.
- The core invoice — EN 16931, built by CEN/TC 434 under Directive 2014/55/EU. Question: what must two systems agree on to process an invoice automatically across borders? Around 170 business terms.
- The commercial invoice — the UBL 2.1 or UN/CEFACT CII document that actually gets sent. Question: what could a trading document ever need to carry? Effectively uncountable.
Only the first is law. The second is law about the first. The third is a standard the law now points to. The fourth is a container.
The legal layer: Article 226 is a closed list of 15, going to 17
Article 226 opens by saying that only the details it lists are required for VAT purposes. The word “only” is doing real work: this is a ceiling, not a floor. The European Commission’s own explanatory notes on the 2010 invoicing rules make the point explicitly when discussing exchange rates — a requirement to state the conversion method would be a detail above those required in Article 226, and therefore not permitted.
The list runs to 15 numbered points: issue date, sequential number, the supplier’s VAT number, the customer’s VAT number where they’re liable, the full name and address of both parties, quantity and nature of the supply, the supply date, the taxable amount per rate, the VAT rate, the VAT amount, exemption or reverse-charge references, and the special-scheme mentions. Points 7a (cash accounting) and 11a (“Reverse charge”) sit inside that structure as insertions rather than extensions.
The floor is much lower than most product teams assume. Under Article 226b, a simplified invoice needs five details — issue date, identification of the supplier, identification of the type of goods or services, the VAT amount payable or the information needed to calculate it, and, for a corrective document, a reference to the original. The fifth is conditional, so the practical minimum is four. Article 220a makes simplified invoices available where the invoice does not exceed EUR 100.
Council Directive (EU) 2025/516 — ViDA — adds two points with effect from 1 July 2030: point 16, the sequential number of the corrected invoice on a corrective invoice, and point 17, the supplier’s bank account numbers, virtual account numbers, or any other identifier unambiguously identifying the accounts the invoice can be paid into. Point 11a also gains a “triangular transaction” mention. Seventeen points, from a single date.
Be careful with secondary sources here. A large amount of published commentary still describes the ViDA proposal, which added three points — the third being the payment due date — with effect from 2028. The adopted directive contains two, from 2030. If your data model has a mandatory payment-due-date field because of ViDA, it was built from a draft.
The reporting layer: ViDA transmits 10 of the 17, and the buyer’s name isn’t one
This is the number almost nobody has, because it requires reading Article 264 as replaced by ViDA rather than a summary of it. From 1 July 2030, for an intra-Community supply under Article 138(1) and for supplies where the customer is liable under Articles 194 to 197, the data transmitted is: Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17 — plus 11a where applicable. Ten data points, eleven with the reverse-charge mention.
What’s missing from that list is more instructive than what’s in it:
- Point 5 — the full name and address of both parties. Not reported. The VAT identification numbers are, and the authority resolves identity through VIES.
- Points 9 and 10 — the VAT rate and the VAT amount. Not reported by the supplier. An intra-Community supply under Article 138 is exempt, so there is no rate to report.
The asymmetry goes further. For intra-Community acquisitions under Article 20, Article 264(c) requires points 1 to 4, 6, 7, 8, 9, 10, 11, 16 and 17 — twelve. The acquirer reports the rate and the amount that the supplier didn’t, because in the acquirer’s country the transaction is taxable. Supplier and customer report the same transaction with different field sets. Any model that assumes one invoice produces one report will be wrong on both counts.
Two more constraints matter for anyone building this:
Cross-border is fixed; domestic is not. Recital 18 of ViDA states the reportable data should be the same in every member state, with no possibility for them to request additional data. But Article 271b(4), governing optional domestic digital reporting, says member states determine the data to be transmitted themselves. So there is no single reporting layer — there is one harmonised set for intra-EU, and up to 27 national sets for domestic. Greece’s myDATA already illustrates the shape: SAP’s implementation guide for Greek e-invoicing records the XML as carrying invoice type, total amount, net amount, VAT category, classification category and classification type, with the platform returning a MARK, a UID and a QR code that then have to be printed back onto the document.
The structured requirement attaches to the reportable subset, not the document. The new Article 217 defines an electronic invoice as one issued, transmitted and received in a structured electronic format allowing automated processing — “at least in relation to the data referred to in Articles 262 and 271b”. That qualifier is why hybrid formats survive: ZUGFeRD and Factur-X are compliant because the reportable data sits in the XML, whatever the PDF layer does.
The core layer: EN 16931, and why nobody agrees on the count
The directive asked CEN to build a semantic data model of the core elements of an electronic invoice. The Euro Retail Payments Board’s 2016 working group report quotes the directive’s own definition of those core elements: the essential information components an e-invoice must contain to enable cross-border interoperability, including what’s needed for legal compliance — to which the ERPB added, pointedly, that fiscal compliance is included too.
Ask how many business terms that produced and you get four answers. Material from CEN/TC 434’s own presentations describes about 160 elements in 33 element groups, with some 25 mandatory and 9 datatypes. Aleksandra Bal, writing in Forbes in January 2025, says over 160 semantic data fields. ValidateFin’s guide says approximately 170 business terms and business term groups. InvoStaq says 176. Nobody is lying: BT identifiers aren’t contiguous, business groups (BG) can be counted as fields or as containers, and the standard has been revised.
For a data team the useful number is the mandatory one — roughly 25 — because that’s the validation floor. Everything else is optional, conditional, or narrowed by whichever Core Invoice Usage Specification applies. CIUS restricts (Peppol BIS Billing 3.0 is a CIUS of EN 16931 on UBL 2.1); Extensions widen, and the European Commission maintains a registry of both. The German XRechnung Extension for the construction sector adds sub-invoice lines beneath a single invoice line and lets GAEB data ride along as an embedded XML attachment — an entire industry’s data model bolted onto the side of the core.
Here is the collision with the legal layer. EN 16931 makes fields mandatory that VAT law never asks for: CustomizationID (BT-24), ProfileID (BT-23) and BuyerReference (BT-10) are required for a valid Peppol BIS invoice and have no existence in Article 226 at all. They are routing and validation metadata. Article 226 says “only these”; the standard says “also these”. Both statements are true, because they are different instruments doing different jobs — and ViDA’s Article 218(4) confirms it by requiring member states to ensure e-invoices do two separate things: include the information required by the Directive, and respect the technical standards. Two tests, not one.
When they genuinely conflict, tax law wins over the technical standard. That’s the ordering to encode.
The commercial layer: UBL has no field count, and that’s the point
The UBL 2.1 Invoice element has roughly fifty direct children, and reading them tells you what layer you’re in. Alongside ID and IssueDate sit ProfileExecutionID, CopyIndicator, PricingCurrencyCode, PaymentAlternativeCurrencyCode, AccountingCostCode, LineCountNumeric and WithholdingTaxTotal. None of those is a VAT concept. Several aren’t an invoicing concept.
Asking for the total field count is an ill-posed question. UBL splits elements into cbc (common basic components — the leaves) and cac (common aggregate components — containers that expand recursively into addresses, parties, items, prices and tax categories, each drawn from a shared library used by every UBL document type, not just invoices). OASIS designed UBL as a generic interchange format to be restricted or extended per industry, aligned with ISO 20022 and built to carry invoice financing, factoring and letters of credit. The invoice is a projection of a much larger library, so the count depends entirely on where you stop expanding the tree — which is why no authoritative figure is published, and why claims of “thousands of fields” can’t be sourced to OASIS.
The practical consequence: Peppol BIS Billing 3.0 doesn’t ship its own XSD. It reuses the UBL 2.1 schema unmodified and layers Schematron rules on top. The constraint lives outside the syntax, because the syntax constrains almost nothing.
What the gap costs: a real mapping table
SAP Hellas’s August 2024 implementation guide for Greek e-invoicing contains the artefact most articles on this topic don’t have — an actual field mapping, ERP to tax-authority message. The proxy structure runs to around 170 distinct field names across eleven structures: header, B2G details, issuer, counter party, recipient, distribution details, payment details, line details (separately for SD and FI documents), taxes, summaries, VAT analysis and contract order details. The marker “NP” — not provided — appears more than 120 times.
That ratio is the story. The message schema carries slots for VAT_MEDIATOR, TRANSPORTER, SENDER, DISPATCH_ADVICE, LOT_NUMBER, ORDER_CODE, BANKS and MISCELLANEOUS_DATA, and for a normal Greek B2G invoice every one of them is empty. Meanwhile the fields that are populated pull data from places no invoice model would predict:
- CPV codes. Required by the tax authority for B2G, maintained in table T604F, and mapped per material on the International Trade tab of the material master. The guide notes that for FI invoices to public bodies a material code and plant have to be maintained during posting purely so the CPV code can be derived — a pure accounting document forced to carry logistics master data.
- The contracting authority. Carried by a special partner record whose Name1 through Name4 fields hold the authority name, authority code, contract type code and contract reference code. Four legal identifiers stuffed into four name fields, because the data model had nowhere else to put them.
None of those fields is in Article 226. None is in the ViDA reportable ten. Two of them aren’t in EN 16931’s core. They are the expensive ones anyway, because field-level mismatches surface as exceptions — and exceptions are where the cost lives. Billentis’s 2017 business case puts typically 20–30% of all invoices into exception handling under scan-and-capture or image-PDF workflows, against Finnish State Treasury estimates of about 10 euros to process an invoice semi-automated and about 1 euro fully automated.
Why the layers don’t nest, and how to model them anyway
Take four fields and check them against each layer:
- Buyer name and address — required by Article 226(5), required by EN 16931, not reported under ViDA.
- CustomizationID (BT-24) — required for a valid Peppol BIS invoice, absent from VAT law entirely.
- Supplier IBAN — absent from VAT law until 1 July 2030, then mandatory under Article 226(17), and reported.
- CPV code — not in VAT law, not in the EN 16931 core, mandatory for Greek B2G.
No layer contains another. Which gives four concrete rules:
Don’t build a canonical superset invoice. There is no schema that is simultaneously the legal minimum, the reportable set, the interoperable core and the syntax. Model the semantics once and project into each target, rather than growing one table until it satisfies everybody.
Model the legal set as the closed list it is. Seventeen points from July 2030, sourced from Article 226 — not inherited from whatever XSD your access point handed you.
Treat the reporting set as two things, not one. Ten fixed fields for intra-EU, set by Article 264 and identical in every member state. And a per-country data set for domestic reporting, defined nationally under Article 271b(4), which means the domestic reporting layer is a configuration surface, not a constant.
Bind to syntax at the edge. EN 16931 is syntax-neutral by design, with UBL 2.1 and UN/CEFACT CII as the two official bindings and lossless conversion between them. Model against the semantic layer; serialise late.
Frequently asked questions
Is EN 16931 the same thing as UBL?
No. EN 16931 is a semantic data model — it defines what an invoice means. UBL 2.1 is one of two XML syntaxes officially bound to it; UN/CEFACT CII is the other, used by ZUGFeRD, Factur-X and optionally XRechnung. The same EN 16931 invoice can be expressed in either, and converted between them without loss.
How many EN 16931 fields are actually mandatory?
Around 25 of roughly 160–176, depending on whose count you use. But a CIUS can make an optional core field mandatory in a given country or network, so the real answer is: 25 plus whatever your target CIUS adds. Validate against the CIUS, not the core.
Does a VAT-compliant invoice automatically pass EN 16931 validation?
No, and the reverse is also false. A paper invoice carrying every Article 226 detail is legally valid and fails EN 16931 outright. An EN 16931 invoice can be technically conformant while missing something national tax law requires. ViDA’s Article 218(4) treats these as two separate tests precisely because they are.
What exactly will ViDA report to the tax authority?
For an intra-EU B2B supply from 1 July 2030: Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17, plus 11a where relevant — ten data points, eleven with the reverse-charge mention. Not the parties’ names and addresses. Not the VAT rate or amount, for exempt intra-Community supplies. The customer’s report of the same transaction carries twelve.
Which layer wins when they conflict?
Tax law, over any technical standard. In practice the sharper version of the question is which representation wins inside a hybrid invoice — and in Germany, the structured part governs where the PDF and XML disagree.