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.

Current versions

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.

Validation pipeline

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.

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

API response metadata

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.

Business rule reference

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)

Update policy

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.

Nightly content-SHA drift detection

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: 19 SHA-pinned artefacts across 7 structural shapes. New artefacts pinned by SHA are picked up automatically — the engine’s enumeration-coverage test fails loud if a SHA is added without a paired URL.
• 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.

XRechnung release cycle

XRechnung follows a fixed release schedule:

• New versions are published on January 31 and July 31
• Each version becomes mandatory 6 months after publication
• During the 6-month transition, both old and new versions are accepted by government portals

Beliq adopts new XRechnung versions promptly after publication and runs them through the full test suite before deployment.

Version changelog