What our 'Accepted' verdict means — and what it doesn't

A receiver who submits an invoice to a validator typically has one of two questions in mind, and the two are not always distinguished.

The first is structural: is the document well-formed against its declared CIUS? Are the required fields populated, do the code-list values come from the prescribed lists, does the internal arithmetic reconcile? An affirmative answer guarantees that the file will be accepted by any compliant receiving system as a syntactically valid instance of the format it claims to be.

The second is jurisdictional: is the document sufficient under the receiver's national VAT law? Is it complete enough to support input VAT deduction, and does it carry the narrative notes the law requires for the kind of transaction it represents? An affirmative answer is the practical precondition for booking the document into the receiver's accounts.

A single validator cannot answer both. The remainder of this article concerns the boundary between the two — where it lies, why it lies there, and what a careful receiver does about it.

What 'Accepted' means

An "Accepted" verdict on the validation report concretely guarantees the following:

• The document conforms to the CIUS its CustomizationID points at. A file that declares itself an XRechnung passes the XRechnung schematron — EN 16931 plus the BR-DE-* family. A file that declares itself Factur-X / ZUGFeRD passes the Factur-X schematron — EN 16931 plus the profile rules. Different CIUSes employ different rule sets; the kind of check is the same.
• All required fields are populated and code-list values are drawn from the prescribed sources: ISO 4217 currencies, UN/CEFACT units of measure, UNTDID 4461 payment means, UNTDID 5305 VAT categories.
• Internal arithmetic is consistent — line totals sum to the invoice net total, net plus VAT equals gross, and the VAT breakdown by category reconciles.
• Structural conventions of the format are observed — required cardinalities, mutual exclusions, and conditional sub-blocks are all in order.

This is what makes interoperable electronic invoicing possible: two systems that have never communicated with each other can exchange invoices because they both subscribe to the same shape.

What 'Accepted' does not mean

The same green report is silent on whether the document is sufficient under any particular country's VAT law. The gap manifests itself in three recognisable patterns.

Cardinalities that national law tightens beyond the CIUS. The EN 16931 core treats some fields as conditional that national VAT laws make universally mandatory. The time of supply, for instance, can be expressed in BT-7, BT-8, BT-72 or BT-73/74; the core requires only one of those to be present if applicable. Several national laws — German §14 Abs. 4 Nr. 6 UStG among them — require it on every B2B invoice without exception. A document with none of those fields populated may pass a CIUS schematron and nevertheless fail the relevant national requirement.

Free-text fields whose required content a schematron cannot inspect. National VAT laws routinely demand specific narrative content in BT-22 (invoice note) or BT-120 (VAT exemption reason): a reverse-charge declaration, a citation of the legal basis for an intra-community-supply exemption, a small-business-scheme reference. A schematron is able to verify that those fields are present; it is not able to verify that the text actually says what the law requires.

Documents that pass a CIUS designed for a different jurisdiction. A German seller's Factur-X invoice passes the Factur-X schematron — correctly. The Factur-X CIUS, however, is a Franco-German specification, and was not designed to enforce the seller's national VAT-content rules specifically. The green result establishes that the file is a valid Factur-X document; it establishes nothing about whether it satisfies the issuing country's VAT-law requirements.

Why the architecture is built this way

CIUSes standardise form. Tax law specifies content in a country-specific way. Combining the two would render every CIUS jurisdictionally narrow and would dismantle the cross-border interoperability that EN 16931 was designed to deliver. The separation is deliberate, and it is a feature: any EN 16931-compliant receiver can read any EN 16931-compliant document, regardless of which national VAT-content rules govern the underlying transaction.

The cost of that clarity is the gap documented above. The structural layer is the layer receivers and accounting software encounter first; the content layer is the layer the tax administration encounters later.

What a careful receiver does

A green CIUS report should be treated as necessary, not sufficient. The file is in good shape for any structural processing — posting to accounting, archival under the relevant national records-retention regime, forwarding to a downstream system. Whether it constitutes a complete VAT invoice under the receiver's national law is a separate question.

Where possible, an additional check tuned to the receiver's jurisdiction should be run. Most accounting software with a VAT-return module performs this check internally — inspecting the structured fields against its built-in knowledge of the local tax code. Specialised tools publish such checks transparently, with citations to the relevant statutes.

In ambiguous cases — whether a particular reverse-charge phrasing satisfies the applicable VAT law, whether a small-business-scheme exemption note is sufficiently explicit — the findings should be treated as items to review with the issuer or a tax advisor, not as verdicts.

Common scenarios

Three brief examples make the pattern concrete.

A German receiver receives a Factur-X invoice from a German seller. A green Factur-X report establishes that the file is a valid Factur-X document. It does not establish whether the seller's tax identifier is present, whether the time of supply is recorded, whether the appropriate reverse-charge note appears in BT-22. Those determinations are content checks under German VAT law.

A German receiver receives an XRechnung. A green report covers structural conformance together with a substantial portion of the German VAT-content concerns — the BR-DE-* family was drafted with that law in mind. A handful of national requirements nevertheless sit outside the schematron's reach, and free-text content (notes, exemption reasons) is examined for presence rather than for wording.

A French receiver receives a ZUGFeRD invoice from a German seller. The same shape obtains as in the first case, reversed: a green Factur-X result, but French VAT-content requirements are not what the Factur-X schematron examines.

In every case the structural verdict carries the same meaning — the document is well-formed against its declared CIUS. The second question remains unanswered.

Facturion VAT-rule packs

The gap is closed by a separate, opt-in layer of content checks. Each pack covers one country's VAT-law requirements as a set of concrete rules with stable identifiers (FCT-VAT-DE-01, FCT-VAT-DE-02, …) and citations to the statute from which each rule derives (e.g. §14 Abs. 4 Nr. 2 UStG). Findings appear alongside CIUS-schematron findings in the validation report and carry the tag facturion, so that it is clear they originate with us and not with a published standard.

The packs are pattern checks against the structured invoice. They flag, for example, that an invoice carrying VAT category AE (reverse charge) lacks the explanatory note §14a Abs. 5 UStG requires; or that a document with no VAT charged and no seller VAT-ID may require a §19 UStG reference. They do not interpret the underlying transaction — that judgment belongs to the issuer and, in unclear cases, to a tax advisor. The findings are decision-support, not legal advice.

The German pack (FCT-VAT-DE-*) is live today. Further country packs will follow as they are drafted and reviewed.