Validation artifacts

Versions, sources, and checksums of the validation artifacts used by the Beliq e-invoice engine.

Beliq validates every generated and uploaded e-invoice against official standards artifacts. This page lists the versions currently used in production. The same Italy FatturaPA XSD bundle applies to POST /v1/generate (standard: "fatturapa") and to POST /v1/validate when FatturaPA invoice XML is detected — POST /v1/parse accepts UBL 2.1 and CII only (FatturaPA and SDI messaggio inputs are validated, not parsed). Italy SDI file messaggio XML (MessaggiTypes) uses a separate vendored XSD graph and is validated only on POST /v1/validate when format=sdi_messaggio is set or when a known messaggio root is auto-detected — it is not FatturaPA invoice validation.

For the machine-readable version of this inventory, call GET /v1/rulesets: the same pinned versions and artifact hashes, keyless and with no quota cost.

Cross-validation tooling

These artifacts are not used to validate customer traffic; they are used internally to cross-check the T3 spec-derived fixtures we ship are validated against an independent reference implementation.

Beliq runs these artifacts as their publishers released them. Every pack, schema and JAR listed above is vendored byte-for-byte from the upstream release: no rule is added, no assertion is edited and nothing is recompiled. The one exception is the Peppol BIS Billing Schematron, whose XSLT is transpiled from the upstream .sch with SchXslt2 because OpenPEPPOL ships no compiled form; the rules themselves are untouched.

This section is the attribution those licences ask for.

The EUPL is worth singling out, because it is the one licence here whose terms reach a hosted service rather than only a shipped download. Running the EN 16931 Schematron behind an API counts as providing access to its functionality, so the licence applies to Beliq even though customers never receive the files. What it asks in return is this notice and the link above. It would ask for more only if Beliq modified the rules, which it does not: a test in the engine fails the build if either pack stops carrying the notice it was published with.

Every invoice goes through a validation pipeline before a result is returned.

For UBL 2.1 and CII instances in the EN 16931 family, the chain is:

Input → XSD Schema → EN 16931 Schematron → CIUS Schematron → Result

For Italy FatturaPA XML (FatturaElettronica / FatturaElettronicaSemplificata in the Italian namespaces) and Spain Facturae XML (Facturae 3.2.2 in the MINECO namespace), the engine runs W3C XSD validation only against the authority schema graph pinned in the engine (no EN 16931 Schematron layer; responses omit schematronVersion and carry country-specific metadata instead).

1. XSD schema validation checks XML structure (UBL 2.1, CII D16B/D22B, Factur-X profile subset, FatturaPA XSD, or Facturae XSD)
2. EN 16931 Schematron checks core business rules (not run for FatturaPA or Facturae)
3. CIUS Schematron checks country- or network-specific rules when the document declares a recognised customization:
   • XRechnung (KoSIT) — when the CustomizationID matches an XRechnung URN
   • Peppol BIS Billing 3.0 (OpenPeppol) — when the CustomizationID matches urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0. UBL only — Peppol Network only transports UBL, so Peppol rules are not applied to CII payloads even if they happen to carry the URN.
   • Factur-X / ZUGFeRD (FNFE-MPE / FeRD) — when the CustomizationID carries a factur-x.eu fragment, which the MINIMUM, BASIC_WL, BASIC and EXTENDED profiles do. The Factur-X EN 16931 profile’s URN is the bare urn:cen.eu:en16931:2017, indistinguishable from a plain EN 16931 CII document, so it is covered by step 2 alone.

For PDF output (ZUGFeRD/Factur-X), additional steps also run:

4. Mustang CLI embeds validated XML into a PDF/A-3 document
5. VeraPDF validates the resulting PDF against PDF/A-3b

Validation responses include the artifact versions used:

These fields show which rule versions were applied to your invoice. Validation responses also carry sha256 (the exact bytes validated) and rulesetSha256 + rulesetArtifacts (the rule artifacts that judged them, hashed); see Verify a hash to reproduce both and cross-check the ruleset against the public catalog.

EN 16931 and related standards use rule IDs with these prefixes:

Official rule references:

• EN 16931 validation rules (GitHub)
• XRechnung rules (GitHub)
• Peppol BIS Billing 3.0 (GitHub)

A standard’s text and the Schematron published for it are two different things, and they do not always agree. A rule can sit in the normative text while the published artifact omits it, which means an invoice can pass one validator and be rejected by another that implements the text more fully.

Beliq runs the pinned artifact and nothing else: that is what makes rulesetSha256 meaningful, and valid is decided by those artifacts alone. But staying silent about a known divergence is not neutral either, so where all four of the following hold, Beliq reports the violation as an advisory (severity: "info" in warnings, never affecting valid, see Advisory findings):

1. The obligation is in a normative text and citable by clause.
2. No artifact that judged the document enforces it.
3. At least one named independent implementation does enforce it, so the advisory describes a real risk of downstream rejection rather than a Beliq opinion.
4. The absence upstream is disputed or unexplained, rather than a decision Beliq agrees with. A rule the standards body deliberately dropped for reasons Beliq accepts gets documented, not advised on.

BR-CO-25 (payment due date or payment terms)

“In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) shall be present.” EN 16931-1:2017+A1:2019 § 6.13.7.

The rule was removed from the EN 16931 Schematron in release 1.3.16 (April 2026). CEN’s technical committee had agreed in 2020 to drop it, on the grounds that it mis-fires where payment terms are agreed outside the invoice and is illogical for credit notes. That removal is now contested: in July 2026 a committee member argued on the upstream tracker that BR-CO-25 is a rule of EN 16931, was not withdrawn in the 2026 revision, and should be restored to both the UBL and CII bindings. The question is open (issue #500, #511).

While it is open, these validators still enforce it, and an invoice Beliq calls valid can be rejected by one of them:

• the Mustangproject Factur-X BASIC, BASIC-WL, EN 16931 and EXTENDED packs,
• the FNFE-MPE France EXTENDED-CTC-FR overlay,
• the Romanian RO-CIUS overlay.

So documents Beliq judges with the Factur-X packs, the French EXTENDED overlay or the Romanian overlay have the rule applied as an ordinary error. Documents judged by the EN 16931, XRechnung, Peppol BIS or NLCIUS artifacts do not, and those are the ones that draw the advisory. If a future EN 16931 release restores the rule, the advisory retires itself: the artifact enforces it, so the finding arrives as an error from the artifact and Beliq stops adding anything of its own.

BR-CO-27 (“either the IBAN or a Proprietary ID (BT-84) shall be used”) gets no advisory, for a different reason: there is nothing unenforced to advise on. The same committee member confirmed it is not an EN 16931 rule and belongs in the CII syntax layer, which is where the obligation now lives. The EN 16931 CII artifact carries it as CII-SR-470 and applies it as a fatal error, so every CII document Beliq validates against an EN 16931 or XRechnung CII profile already has it checked. In UBL the question does not arise: UBL carries the payment account identifier in a single field, so there is no IBAN-versus-proprietary choice to make, and the presence of BT-84 itself is covered by BR-50 and BR-61.

One difference is worth knowing if you pin an older ruleset. The Factur-X 1.08 edition, selectable until it is retired on 16 May 2027, states the rule as exactly one of the two, and rejects a document that carries both an IBAN and a proprietary identifier on a credit-transfer payment means. CII-SR-470 requires at least one and accepts both. The current rulesets follow CII-SR-470.

Beliq does not auto-update validation artifacts. Version updates are reviewed and tested before rollout. For how versions are classified (safe vs breaking), announced, and how to pin a channel per request or org-wide, see Ruleset versioning.

Beyond reviewing official release announcements, the engine runs a nightly content-SHA check against every pinned artefact. If an authority re-publishes an artefact without bumping its version tag (a real failure mode for FNFE-MPE Factur-X bundles and the AdE FEL XsdProject.jar), the workflow opens a tracking issue on the engine repository within 24 hours.

• Cadence: every day at 04:00 UTC.
• Workflow: .github/workflows/check-artifact-updates.yml, Layer 3 (the Python module tools/sha_drift).
• Coverage: every SHA-pinned artefact in the engine’s third-party/versions.json. The set is enumerated from the file rather than listed by hand, and a handful of pins are skipped by construction because they have no upstream to re-fetch (a file byte-identical to a sibling in the same bundle, or a profile the authority has retired from its own site). The engine’s enumeration-coverage test fails loud if a SHA is added without a paired URL and without being declared skipped, so a new artefact cannot silently fall out of the nightly check.
• Signal-only: the workflow never auto-bumps anything. Each detected drift creates an issue for human review; vendor / re-pin happens explicitly via scripts/upgrade-artifact.sh.
• Status visibility: drift status is visible in the engine’s GitHub Actions run logs and as tracking issues on the engine repository.

KoSIT does not publish XRechnung on a fixed calendar, and there are two kinds of release with different timing.

• Normative releases carry the specification, the syntax binding and a bundle together, and take effect on a date KoSIT sets per release. The last two landed on the 1 February / 1 August rhythm: 3.0.0 was published 2023-07-31 for 2023-08-01, 3.0.1 was published 2023-11-15 for 2024-02-01. The gap between publication and validity is set release by release, not by a rule. KoSIT states the 3.0 line stays in force until at least 2027-07-31.
• Bugfix bundles inside a line land whenever they are ready and are valid from their own publication date, with no transition window. The 3.0.2 line has taken several since 2024-07-02, which is why the release date beside the XRechnung Schematron pin in Current versions is also the date that bundle became the one to validate against.

The authority publishes no grace period for a superseded bundle, so the buffer is Beliq’s rather than KoSIT’s: the outgoing ruleset stays selectable on the previous channel for at least 6 months, until the retirement date its changelog row names (see Ruleset versioning). When KoSIT ships a bundle that is valid the day it lands, what compresses is the announcement window, not the pin.

Two version numbers travel together here: the bundle and the specification are XRechnung 3.0.2, and the Schematron pack that judges against them is 2.6.0. The XRechnung format reference says which one each response field reports.