Specification versions

Which versions of the specifications this release implements, where they come from, and how a new Peppol release reaches the library.

This release

Specification	Version	Source
Peppol BIS Billing 3.0	3.0.21 (May 2026)	OpenPEPPOL/peppol-bis-invoice-3, branch 2026-Q2-MR
EN 16931 rules (CEN TC 434 Schematron)	1.3.15	the Schematron shipped inside Peppol BIS 3.0.21
EN 16931 unit tests	1.3.16	ConnectingEurope/eInvoicing-EN16931, tag validation-1.3.16
UBL	2.1	OASIS UBL 2.1 schemas

The EN 16931 rules come from the Schematron embedded in the Peppol release, because that is what Peppol validators run; the newer CEN repository supplies test cases only. In code, the versions are SPEC_VERSIONS of @facturometro/core and SPEC of @facturometro/validator, and each ruleset constant carries them in spec.

How versions are pinned

Every artefact is pinned by commit SHA and sha256 in spec/spec.lock.json, because upstream branches move and tags lag behind releases. pnpm spec:fetch downloads them into spec/vendor/, which is never committed or published: OpenPEPPOL's terms do not allow redistribution. What the packages ship is the code generated from them (model types, runtime schema, code lists, rule tables), which is committed so a new release shows up as a reviewable diff.

A nightly job compares the pins with the moving upstream branches and opens an issue when a newer release would change something.

Release policy

OpenPEPPOL publishes BIS Billing releases twice a year, in May and November. Adopting one is a minor release of these packages, since new or changed rules can reject documents that passed before. Upgrading means re-pinning (pnpm spec:fetch --update), regenerating (pnpm codegen), reviewing the generated diff, implementing new rules until the coverage gate passes, and adding a changeset.