Rule updates

rules change. This is when we last checked.

See the standards Attestwire follows, the versions we use and when we last tested against them. Last verification: 25 September 2026. Each record below links to the test results and their limits.

The table names the German rules (XRechnung, checked by KoSIT, the German office that publishes the official checker), the European base standard (EN 16931), the rules of the Peppol network many European buyers receive invoices through, and the French tax administration’s specifications. Each row says which version we checked against and when.

verified

Verified — we ran our own documents against the official artefact and nothing failed.

verified-with-findings

Verified, with findings — we ran them and something failed. The record names what, including where the defect turned out to be ours.

tracked

Tracked, not verified — we watch the release and have not yet put a document in front of it. The version and date come from the publisher, not from a run of ours.

Machine-readable, same data, built from the same module as this table: /rule-currency.json. A build test fails if the page and the feed ever disagree.

Who applies rule updates?

Upstream moved twice this summer alone: the DGFiP, the French tax administration, published its spécifications externes v3.2 on 30 April 2026, and FNFE-MPE, the French e-invoicing forum, released Factur-X 1.09.2 (the French format for a PDF invoice with the XML attached inside it) on 4 August 2026. Libraries and hosted services need to track these changes.

A pinned library version does not change. @attestwire/en16931@0.14.0 will judge a document in 2029 as it judges one today: your CI is reproducible, your test fixtures keep passing, and no upstream release can change a verdict between your staging run and your deploy. It is MIT licensed and free at any volume.

The hosted API runs the current rule set. Every metered response carries a provenance block naming the engine version, rule set and profile that judged that document, so a verdict is attributable after the fact. The deployment as a whole answers at GET /v1/versions, free and unauthenticated, which is the endpoint to point a weekly job at.

Many teams use both: the library in the build, the API in the pipeline that has to be right this month. The side-by-side is on the pricing page.

The observed turnaround

We do not commit to a turnaround for rule updates, and there is no response-time SLA on any plan (the limits page says the same). The one example so far: a totals defect (documents missing a stated total came back valid: true where KoSIT rejects them) was found against @attestwire/en16931 0.5.0 on 13 August 2026 and fixed in 0.6.0 the next day, on 14 August 2026.

The rule change, the twelve probe documents and the KoSIT citations are in the changelog entry. Those dates are read from the changelog by the build.

Row by row

EN 16931 schematron (CEN)

Both syntax bindings (the rule files for the CII and UBL formats) are exercised, in two different runs: the CII schematron in the KoSIT run of 24 September 2026, and CEN-EN16931-UBL.sch in the Peppol run of 14 August 2026 (that record counts the assertions that fired, per document).

Release date shown: the date of the redistribution we pinned, the KoSIT XRechnung configuration 3.0.2. CEN publishes no release date for the bundled schematron itself, so this is the most precise date that is true. Our run: 24 September 2026.

XRechnung (German CIUS) — KoSIT validator

KoSIT, the German government’s validator, accepts all eleven sample invoices this library generates. One of them draws a warning from a European rule that KoSIT itself has marked as broken and replaced; it passes the replacement. None draws an error. Validator 1.6.3, XRechnung configuration 3.0.2 (build of 31 August 2026), CEN CII schematron 1.3.16, XRechnung CII schematron 2.6.0; recorded 24 September 2026 against engine 0.10.0. Acceptable: 11 Rejected: 0. The warning is CII-SR-475 on the extended CII fixture, a rule that miscounts attachments when an invoice has more than one (CEN issue 508). KoSIT’s configuration lowers it to information and checks BR-TMP-4 instead, which passes. The twelve probe documents broken on purpose were all rejected by the same validator and configuration on 7 September 2026.

Release date shown: the configuration build date KoSIT stamps on the release. Our run: 24 September 2026.

Peppol BIS Billing 3.0 artefacts

Ten generated documents, ten accepted, zero findings; and nine probe documents, eight of them broken on purpose, draw the same rule ids at the same severity from the official rules as from this engine. The first run, on 14 August 2026, accepted three of five: both rejections were PEPPOL-COMMON-R040, an invalid GLN check digit in our own fixture data, and it caught the engine refusing a credit note Peppol accepts (PEPPOL-EN16931-P0100).

Both were fixed in 0.7.0; @attestwire/en16931 0.14.0 carries the fixes. The record publishes all three runs.

Release date shown: the date of publication on docs.peppol.eu; the release is mandatory from 17 August 2026. OpenPEPPOL has published no GitHub tag for it. Our run: 25 September 2026.

DGFiP spécifications externes B2B (France)

Flux 1 is one of the DGFiP's data flows: a tax-filing extract sent to the administration, not an invoice format. Its schema has no line total, grand total or amount due, so our eleven fixtures (the sample invoices kept in the repository for testing) are refused by it for profile reasons alone; none of them contains an element the syntax forbids.

Release date shown: as published on impots.gouv.fr. Our run: 14 August 2026.

Factur-X 1.09.2 / ZUGFeRD 2.5.2

This row is sourced from the publisher, not from a run of ours. The release is built on CII D22B and is documented as backward compatible with D16B, the version of the XML format this engine writes, so the existing Factur-X EN 16931 payload should still be readable. We will not say more than “should” until a document has been through it.

Release date shown: as announced by FNFE-MPE. Source: https://fnfe-mpe.org/factur-x/factur-x_en/.

What this page does not claim

A verification is a run against those artefacts with those documents on that date. It is not continuous, and it does not mean a particular receiver will accept your document. The KoSIT record states its limits in full.

Read the KoSIT record Take the JSON feed