Rule currency
EN 16931 is one norm, and the artefacts that decide whether a document conforms to it are published by several different bodies, each on its own schedule. This is every artefact Attestwire validates against, the version we are on, when its publisher released it, and when we last put a document in front of it. Last verification: 14 August 2026.
We will not promise a response time. There is no support SLA on any plan and no rule-update deadline. What is here instead is every artefact we track, each verification run linked in full, and the observed turnaround below, derived by the build from the package's own changelog dates rather than typed by us.
| Upstream artefact | Version we validate against | Its release date | Our last verification | Evidence | Status |
|---|---|---|---|---|---|
| EN 16931 schematron (CEN) | en16931-cii-1.3.15 (CII); CEN-EN16931-UBL (UBL) |
KoSIT run record | Verified | ||
| XRechnung (German CIUS) — KoSIT validator | validator 1.6.2, configuration 3.0.2 |
KoSIT run record | Verified | ||
| Peppol BIS Billing 3.0 artefacts | v3.0.20 |
Peppol run record | Verified, with findings | ||
| DGFiP spécifications externes B2B (France) | v3.2 |
DGFiP run record | Verified, with findings | ||
| Factur-X 1.09.2 / ZUGFeRD 2.5.2 | 1.09.2 (ZUGFeRD 2.5.2) |
not yet run here | FNFE-MPE release page | Tracked, not verified |
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.
A pinned library and a hosted API are different products
Upstream moved twice this summer alone: the DGFiP published spécifications externes v3.2 on , and FNFE-MPE released Factur-X 1.09.2 on . Neither asked us first.
A pinned library version is frozen by design. That is
the reason to use one. @attestwire/en16931@0.7.3
will judge a document in 2029 exactly as it judges one today: your CI is
reproducible, your test fixtures do not rot overnight, 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 is current by design. That is the reason
to use that. It runs the deployed rule set, and 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, unauthenticated, and the endpoint to point a weekly job at.
Both are legitimate, and plenty of teams want both: the library in the build, the API in the pipeline that has to be right this month. Pick per workload, not per company. The side-by-side is on the pricing page.
The observed turnaround, and why it is not a promise
There is no response-time SLA on any plan, and this
page is not the place one appears —
the limits page says the same thing. What we can
offer instead is the record. The declared-totals gap
(documents missing a stated total came back
valid: true where KoSIT rejects them) was identified
against @attestwire/en16931 0.5.0
(13 August 2026) and closed in
0.6.0
(14 August 2026):
one day, with the
rule change, the twelve probe documents and the KoSIT citations all in
the changelog entry. That is one data point, it is
verifiable in the changelog, and it is a
description of what happened rather than a promise about what will.
What there is instead is the ledger. Every artefact we track is in the table above with its version, its release date and the date we last put a document in front of it. The one turnaround figure on this page is derived from the changelog by the build rather than typed by us. If the record stopped supporting the sentence, the build would fail.
Row by row
EN 16931 schematron (CEN)
Both syntax bindings are exercised, in two different runs: the CII schematron in the KoSIT run of 13 August 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: 13 August 2026.
XRechnung (German CIUS) — KoSIT validator
Acceptable: 11 Rejected: 0 over 11 committed fixtures (5 UBL and 6 CII) with no finding at any severity. The eleven were re-run unchanged for 0.6.0 on 14 August 2026, alongside twelve deliberately-broken probes.
Release date shown: the configuration build date KoSIT stamps on the release. Our run: 13 August 2026.
Peppol BIS Billing 3.0 artefacts
Five generated documents in the recorded run: three accepted and two rejected. Both rejections are PEPPOL-COMMON-R040, an invalid GLN check digit in our own fixture data, and the run also caught the engine wrong in the other direction, refusing a credit note Peppol accepts (PEPPOL-EN16931-P0100). The record publishes all of that, and an addendum from a second run after those defects were fixed: ten documents, ten accepted, zero findings. Those fixes are in the repository and not in @attestwire/en16931 0.7.3, which is the release this site describes, so the row above reports the run that judged the published engine.
Release date shown: OpenPEPPOL's own description of the tag is the 2025 November release; it publishes no day. Our run: 14 August 2026.
DGFiP spécifications externes B2B (France)
The finding is about what Flux 1 is: a tax-filing extract sent to the administration, not an invoice CIUS. Its schema has no line total, no grand total and no amount due, so our eleven fixtures are refused by it for profile reasons alone, with zero elements that no syntax allows.
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, which is the syntax this engine emits, so the existing Factur-X EN 16931 payload should still be readable, and “should” is exactly as far as we will put it 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, and it is not continuous. That is evidence about those 11 generated fixtures. It is not a parity suite, and it is not a guarantee that any particular receiver will accept your document. Documents you upload are not run through KoSIT at request time.