Changelog

Notable public-facing changes to the Beliq API and documentation site, reverse-chronological.

Notable changes to the Beliq API surface, reverse-chronological. For implementation-artefact version pins (Schematron, XSD bundles, validator JARs), see the validation artifacts — version changelog.

2026-07-11: PDF templates are referenced by a short id

Stored PDF templates now carry a short ref — a k3d-9mp-style code shown next to each template in the dashboard (click it to copy). Pass that ref as pdfTemplateId on POST /v1/generate to brand the rendered PDF. The ref is unique within your organization and is the accepted form of the reference.

2026-06-20: Custom PDF templates and visualization PDFs

POST /v1/generate now renders PDF output in two kinds. ZUGFeRD / Factur-X produce a hybrid PDF/A-3 with the legal XML embedded inside it. The XML-only standards (xrechnung, peppol-bis, fatturapa, facturae, eslog) have no hybrid form, so a pdf request returns a visualization PDF: a human-readable rendering with no embedded XML (the legal artifact stays the XML, fetched with output: "xml"). The new x-pdf-kind response header tells you which kind you received. Styling comes from either template: "standard" (the built-in layout) or the new pdfTemplateId, a custom template you design visually in the dashboard (logo, colours, fonts, layout). Stored templates are org-scoped, so a pdfTemplateId request must be authenticated; two new error codes, PDF_TEMPLATE_AUTH_REQUIRED and PDF_TEMPLATE_NOT_FOUND, cover the failure cases. See POST /v1/generate styling the PDF and the PDF template errors.

2026-06-13: Netherlands NLCIUS promoted to fully-verified

The netherlands_peppol_nlcius profile is now fully-verified. The full 120-fixture NPa SI-UBL 2.0 authority testset (Tier-1; the expected ok / warning / error outcome is encoded in each filename) is vendored and asserted by a Schematron-only harness that fires the SI-UBL 2.0 XSLT over every fixture and checks both the document outcome and per-rule SVRL firing. A rule-coverage audit confirms a Tier-1 negative the engine rejects for every critical rule family (BR-NL-*, BR-CO-15, BR-S-08, BR-CL, UBL-CR-561, UBL-SR, and the EN 16931 base BR-* rules); two residuals are documented and do not block promotion (UBL-SR-09 / UBL-SR-15 reject via an upstream XSLT XPTY0004 crash, and BR-NL-34 fires under the BR-NL-32 id). No API surface change: POST /v1/generate and POST /v1/validate behave exactly as before. See the Netherlands NLCIUS format reference.

2026-06-11: Slovenia e-SLOG 2.0 as a new standard

POST /v1/generate now accepts standard: "eslog" with the single profile eracun (the default when profile is omitted) and emits Slovenia’s national e-SLOG 2.0 XML: root Invoice in namespace urn:eslog:2.00 wrapping an M_INVOIC EDIFACT segment structure (GZS-published, ePOS-stewarded, EN 16931-aligned at the semantic level). Credit notes are supported on the same message shape (documentType: "creditnote" emits document type code 381 in S_BGM; invoices emit 380). POST /v1/validate recognises e-SLOG documents by root namespace (or via the new format=eslog hint) and validates against the authority XSD bundle (eSLOG20_INVOIC_v200.xsd plus the xmldsig companion, invoice package 08-2020, pinned as 2.0-08-2020). The path is XSD-only: GZS/ePOS publish no machine-readable business rules, so there is no Schematron layer and no BR-* rule IDs; structural failures carry ruleId: "XSD". Response metadata adds sloveniaEslogXsdBundle and sloveniaEslogRuntimeVersion, with profileDetected: "slovenia-eslog-v2-0". The slovenia_eslog_eracun profile enters at provisional (promotion is gated on the authority publishing machine-readable validation schemes). UJP submission, ZIERDED e-route provider services, and XML-DSig signing stay BYOC. See the new Slovenia e-SLOG format reference and the updated Slovenia country guide.

2026-06-09: Netherlands NLCIUS overlay on Peppol BIS UBL

POST /v1/generate now accepts standard: "peppol-bis" with profile: "netherlands-nlcius" and emits UBL with the current urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0 CustomizationID URN. POST /v1/validate recognises Dutch NLCIUS documents by URN prefix and fires the vendored SI-UBL 2.0 XSLT (NPa version 2.0.3.13 from the 2026-05-21 release; MIT-licensed; sourced from peppolautoriteit-nl/validation direct — no Helger wrapper). Response metadata adds netherlandsNlciusVersion alongside the existing ciusVersion. The NLCIUS XSLT covers both Invoice and CreditNote (single-file split, distinct from Romania’s two-XSLT pair). BR-NL-1 / BR-NL-10 legal-entity requirements (Dutch suppliers + domestic customers MUST provide KvK or OIN) are satisfied by routing the Party.peppol block through EAS 0106 (KvK) or 0190 (OIN); Beliq’s ISO 6523 ICD CompanyID emission handles the PartyLegalEntity wiring. The netherlands_peppol_nlcius profile shipped at provisional; Digipoort / Logius B2G submission stays Peppol-AP-routed BYOC. See the new Netherlands NLCIUS format reference.

2026-06-04: Sweden + Denmark + Netherlands Peppol BIS coverage

Sweden, Denmark, and the Netherlands are now documented engine-supported countries on the Peppol BIS slice. Three new country guides land together: Sweden (B2G mandatory since 2019 via DIGG / SFTI; Swedish endpoint addressing is orgnr-not-VAT — explicit peppol = {schemeId: "0007", id: <orgnr>} block required; Sweden is excluded from the per-country default VAT-scheme fallback); Denmark (B2G mandatory since 2005 via NemHandel — one of Europe’s oldest mandated systems; B2B rolling out per the Danish accounting-act 2024 (Bogføringsloven) phase-in; CVR routing via EAS 0184); Netherlands (B2G mandatory since 2017 via Digipoort / Logius; NL:VAT routing via EAS 9944 + secondary 0106 KvK + 0190 OIN). All three profiles (sweden_peppol, denmark_peppol, netherlands_peppol) are supported (Belgium / Ireland / UK / Slovenia parity — they ride the shared fully-verified Peppol BIS pipeline). NLCIUS (real Dutch national CIUS overlay maintained by STPE / NEN with BR-NL-* Schematron rules) and OIOUBL (Danish legacy XML format used historically via NemHandel) are both honestly documented as out of scope in their respective country guides — NLCIUS parked as a Romania-shape demand-driven candidate; OIOUBL not parked due to low/declining demand. The Country Guides sidebar gains Denmark, Netherlands, and Sweden entries (alphabetical).

2026-06-04: Slovenia Peppol BIS coverage

Slovenia is now a documented engine-supported country on the Peppol BIS slice. The new Slovenia country guide covers the regulatory landscape (B2G receive-mandate live since ~2015 via UJP — Slovenia’s public-payments admin; B2B mandatory from January 2028; ViDA alignment July 2030), the integration architecture (Beliq covers the Peppol BIS path; UJP submission is BYOC via Access Point), and a worked generation example with SI:VAT (EAS 9949) + EUR. The Country Guides sidebar gains a Slovenia entry. The slovenia_peppol profile is supported (Belgium / Ireland / UK parity — rides the shared fully-verified Peppol BIS pipeline). The country guide is explicit that Slovenia’s domestic e-SLOG 2.0 format (developed by GZS, the Slovenian Chamber of Commerce) is a separate XML standard, not a Peppol CIUS overlay, and is out of scope for Beliq today — parked as a future demand-driven slice. For Slovenian customers needing an e-SLOG-only domestic B2G flow, that path is BYOC until the e-SLOG slice lands.

2026-06-03: Ireland + United Kingdom Peppol BIS coverage

Ireland and the United Kingdom are now documented first-class countries. Both ride standard Peppol BIS Billing 3.0 UBL with no national CIUS. New Ireland country guide covers the B2G receive-mandate live since 2019 + B2B mandatory from November 2028 per the Revenue.ie roadmap; IE:VAT (EAS 9935) endpoint scheme. New United Kingdom country guide covers the B2B + B2G mandate from April 2029 (confirmed at UK Budget 2025); UK:VAT (EAS 9932) endpoint scheme; GBP currency. The UK profile ships on the OpenPeppol UK WG pre-publication assumption of Peppol BIS 3.0 + 4-corner Peppol model (UK Gov explicitly rejected a centralized SDI-style portal); HMRC + DBT formal standards publication is expected with Budget 2026 (widely anticipated in November 2026), and Beliq re-verifies the UK profile against the published standard on a calendar-enforced schedule. Both ireland_peppol and uk_peppol profiles are supported (Belgium parity, riding the shared Peppol corpus). Northern Ireland / Windsor Framework Peppol routing is flagged in the UK guide as an open question. Making Tax Digital remains a separate compliance regime (VAT-return submission, not e-invoicing). Country Guides sidebar gains Ireland + United Kingdom entries.

2026-06-03: Romania country guide + ANAF e-Factura readiness

Romania is now a documented first-class country. The new Romania country guide describes the regulatory landscape (mandate live since 2024-07-01 for B2B; 2022 onward for B2G), the integration architecture (what Beliq does, what your ANAF-immatriculée intermediary does), and a worked generation example. The Country Guides sidebar gains a Romania entry. The technical contract (UBL fields, validation pipeline, response metadata) stays in the Romania RO_CIUS format reference; the country guide complements it with regulatory context, not duplicate details. ANAF SPV submission, certificate-based signing, and “sistemul național de facturare electronică” retention obligations remain out of scope (BYOC) per the new romania-anaf-readiness governance rule.

2026-06-02: Romania RO_CIUS on Peppol BIS UBL

POST /v1/generate now accepts standard: "peppol-bis" with profile: "romania-ro-cius" and emits UBL with the current CIUS-RO:1.0.1 CustomizationID URN. POST /v1/validate recognises Romanian CIUS-RO documents by URN (current + legacy RO_CIUS:1.0.0.2021) and fires the two-XSLT Schematron pair vendored from the Helger phive-rules-cius-ro 4.3.5 JAR (Apache-2.0, Maven Central). Response metadata adds romaniaRoCiusVersion alongside the existing ciusVersion; see Validation artifacts → API response metadata. The UBL builder gains two generic data-driven additions usable by any profile: cbc:CountrySubentity (BT-39, when address.countrySubentity is set) and cbc:TaxCurrencyCode plus a second cac:TaxTotal block carrying BT-111 (when taxCurrencyCode and taxTotalInAccountingCurrency are set, satisfying BR-RO-030 / BR-53 for cross-border invoices). The romania_peppol_ro_cius profile is currently provisional; ANAF SPV submission, RAS integration, and certificate-based signing are out of scope (BYOC). See the Romania RO_CIUS format reference.

2026-05-30: /v1/convert: structured lostElements[] audit trail

POST /v1/convert now surfaces the full structured audit trail on a new X-Lost-Elements response header — a single line of JSON encoding the list of acceptable-loss entries (path, value, reason, severity, acceptableLoss). Until now only the count was exposed via X-Lost-Elements-Count; the structured list lived only inside the engine. Callers can now display the exact XPaths that got dropped (Peppol endpoints stripped when leaving Peppol BIS, PDF envelopes dropped when converting to non-PDF-able targets, France CTC Flux 2 BusinessProcess codes dropped when opting in via ?dropFranceCtcOverlay=true) and route accordingly.

The header is always present (empty array on a clean conversion) with a defensive 6KB cap that downgrades to a truncation sentinel for the (currently hypothetical) case of a conversion emitting hundreds of entries. The X-Lost-Elements-Count header stays for cheap “did anything get lost?” checks; binary body pass-through semantics are unchanged. See the POST /v1/convert reference for the entry shape + a worked Peppol example.

2026-05-29: POST /v1/convert (EN 16931 cross-format conversion)

POST /v1/convert is live. The route converts an EN 16931-family invoice from one format to another in a single call — CII ↔ UBL via Mustang cii2ubl and Helger en16931-ubl2cii, ZUGFeRD ↔ Factur-X via profile-URN swap, XRechnung CII ↔ UBL via syntax conversion, and Peppol BIS UBL → plain EN 16931 UBL with cbc:EndpointID stripping. Hybrid PDFs are supported in both directions: the engine extracts the embedded CII from a ZUGFeRD/Factur-X PDF, runs the conversion, and (when the target has a PDF spec) re-wraps via Mustang --action combine so the visual envelope is preserved.

Lossy conversions are split into two buckets with very different behaviour. Fail-closed cases — France CTC Flux 2 BusinessProcess codes on UBL targets, and synthesising a Peppol BIS endpoint pair from a non-Peppol source — return 422 CONVERSION_LOSSY_FAILCLOSED with the un-mappable XPath(s) in error.details.unmappablePaths. Callers can opt in to known-acceptable losses (the France CTC overlay drop) via ?dropFranceCtcOverlay=true. Acceptable losses — Peppol endpoint strips and PDF envelope drops — return 200 OK with the count surfaced in X-Lost-Elements-Count. The full structured lostElements[] payload arrives in a future release.

Out of scope. FatturaPA, Facturae, KSeF, and SDI messaggio sources or targets are not supported (no published EN 16931-equivalent converter). Use /v1/generate to produce these from structured JSON. See the /v1/convert API reference and the cross-format conversion notes.

2026-05-28: Belgium B2B (Peppol BIS 3.0) support

Belgium is now a documented first-class country. Its B2B mandate (live 2026-01-01) uses standard Peppol BIS Billing 3.0 UBL with no national format and no national CIUS, so Belgian invoices generate + validate through the existing Peppol pipeline: POST /v1/generate with standard: "peppol-bis", addressed with the Belgian enterprise-number scheme (KBO/BCE, Peppol EAS 0208) or the BE:VAT fallback (EAS 9925). The belgium_peppol profile is supported (rides the fully-verified Peppol BIS pipeline; one Belgium-specific Peppol-common rule, PEPPOL-COMMON-R043, enforces the KBO/BCE checksum). Peppol Network transmission stays with your Access Point (BYOC); the 2028 e-reporting (5-corner) layer is out of scope. See the Belgium country guide and the Peppol BIS format reference.

2026-05-26: Spain Facturae 3.2.2 invoice support

POST /v1/generate now accepts standard: "facturae" and produces XML against the MINECO authority XSD bundle for Facturae 3.2.2 (ordinaria). POST /v1/validate validates Facturae invoice XML when detected by namespace (or via format=facturae) — XSD-only, no EN 16931 Schematron layer (Facturae’s lineage is the Spanish Ministry of Economy spec, not CEN). Response metadata includes spainFacturaeRuntimeVersion and spainFacturaeXsdBundle; see Validation artifacts → API response metadata for the full field list. VeriFactu real-time reporting and FACe B2G submission are out of scope (BYOC) — see the Facturae format reference.

2026-05-02: Italy SDI MessaggiTypes XSD validation

POST /v1/validate now accepts format=sdi_messaggio (or auto-detects known messaggio roots). XSD-only — this is file messaggio validation (notifications, receipts), distinct from FatturaPA invoice validation. Operator interchange (SOAP transmission, signing, UPO handling) is out of scope: SDI submission belongs to your SDI intermediary. Surfaced in the response via italySdiMessaggiXsdBundle and italySdiMessaggiXsdVersion. See Validation artifacts → Current versions for the bundle pin.

2026-05-01: Italy FatturaPA invoice support

POST /v1/generate now accepts standard: "fatturapa" and produces XML against the authority XSD bundle for FatturaPA ordinaria/PA (VFPR/VFPA 1.2.3) and semplificata (VFSM 1.0.2). POST /v1/validate validates FatturaPA invoice XML when detected by namespace — XSD-only, no EN 16931 Schematron layer (FatturaPA’s lineage is the AdE specification PDF, not CEN). Response metadata includes italyFatturapaRuntimeVersion and italyFatturapaXsdBundle; see Validation artifacts → API response metadata for the full field list.