What shipped, and when.

From then, rulesetArtifacts also lists the syntax schema an EN 16931 document was checked against: ubl_xsd, cii_xsd, cii_xsd_d22b, or a Factur-X profile's schema under facturx_schematron. The schema decides verdicts too: a document it rejects never reaches a business rule. rulesetSha256 includes it, so the fingerprint of every XRechnung, Peppol, Factur-X, ZUGFeRD and other EN 16931 result changes once. No rule and no verdict changes. A document the schema rejects gets both fields, where today it has neither. If you store rulesetSha256 and compare it over time, expect this one move, or compare rulesetArtifacts rows. FatturaPA, Facturae and e-SLOG are unchanged.

Two new fields let an invoice carry its VAT total in the currency the seller accounts VAT in. taxCurrencyCode is that VAT accounting currency (BT-6), and taxTotalInAccountingCurrency is the VAT total in it (BT-111). You do the conversion; Beliq applies no exchange rate. Send both or neither, and never a taxCurrencyCode equal to currencyCode: either is a 400, because BR-53 and PEPPOL-EN16931-R005 would reject the document. Both reach UBL and CII outputs, Factur-X MINIMUM excepted. This is what makes a Romanian invoice in EUR possible: BR-RO-030 requires RON as its VAT accounting currency.

Five fields you could already send now appear in the output. registrationId is the legal registration identifier, BT-30 on the seller and BT-47 on the buyer, and the one BR-CO-26 falls back to when an invoice carries no VAT number. buyerItemId (BT-156) is new on both syntaxes. itemId (BT-155) and taxId (BT-32) now reach UBL as well as CII. address.state is emitted as the country subdivision (BT-79) when countrySubentity is absent; send countrySubentity where you can, it is the field EN 16931 defines. Together with a VAT rate that is no longer forced onto an out-of-scope line, this closes VAT category O. If you send both peppol and registrationId, the UBL company id is now the one you sent.

itemId (BT-155) went into every CII document, the Factur-X and ZUGFeRD BASIC profile included. BASIC declares no slot for it: its item group stops at the name. A BASIC document carrying an itemId therefore failed XSD validation, ours and everyone else's, which is a document you could not send. BT-155 is now emitted from the en16931 profile up and dropped below it, so BASIC output is schema-valid again. If you rely on the seller item identifier, ask for en16931 or extended. Nothing else about BASIC changes.

Every CII invoice Beliq generated carried an actual delivery date (BT-72) set to the invoice date, a value you never sent. The Factur-X MINIMUM profile was the only exception, because it has no slot for one. It was a fabrication and a tax auditor reads it literally, so we now emit BT-72 only when you send delivery.date. Under the current rulesets your verdicts do not change. One case does: on a German domestic invoice whose document type is not 386, validated with Beliq-Ruleset: previous or a facturx_schematron:1.08 pin, BR-FX-EN-04 requires BT-72 and the document goes from valid to invalid. Send delivery.date and it passes either way. Pinning the outgoing ruleset is not the escape here: it is what selects the rule.

Delivery information (BG-13 and BG-15) and the SEPA direct debit group (BG-19) now reach the document. Send delivery with a date (BT-72), a deliver-to name, a location id and an address whose only required field is countryCode (BT-80), and paymentMeans with mandateReference, creditorId, debitedAccountId and information. That closes VAT category K, intra-community supply of goods, which could not produce a valid document on any output before: BR-IC-11 wants the delivery date and BR-IC-12 the deliver-to country, both fatal, and no field carried either. Nothing reaches a Factur-X MINIMUM document, which declares no slot for any of it.

On 3 September we said Beliq-Ruleset: previous would reach Peppol BIS Billing 3.0.20 until 3 March 2027. We are withdrawing that half. OpenPEPPOL made 3.0.21 mandatory on 17 August 2026, so a document built to 3.0.20 no longer clears the network and a channel should not pick it for you. A Peppol request on previous now resolves latest and reports rulesetFellBack: true. The exact pin peppol_bis_billing_schematron:3.0.20 is unchanged and still reproduces an earlier verdict until 3 March 2027: a pin names a version, previous asks us to choose one. Peppol only. Factur-X 1.08, France CTC 1.3.1 and XRechnung 2.5.0 still reach through previous, because no authority has made their successors mandatory.

A correction-only FNFE-MPE pack, serving now. Nine BR-FXEXT rules were meant to apply only to DETAIL lines but addressed a sibling element as a child, so the scope never applied and every line was judged as one: invoices with GROUP lines were failing rules that were never meant to reach them. Several monetary checks move from number() to xs:decimal() so totals stop tripping on float representation, BR-FR-CO-07 now accepts more than one payment due date, and BR-FR-20 accepts B2CINT. Nothing we measured newly fails. The Factur-X specification is unchanged at 1.09.2 — only the pack moved. 1.3.1 stays pinnable until 16 May 2027.

The FNFE-MPE bump announced on 20 August moves now rather than on 20 November 2026: nobody is pinned to the outgoing packs. The France half is the wider one. The Flux 2 pack raises 141 of its CII rules and 145 of its UBL rules from warning to fatal without changing a rule id, so a France CTC invoice that came back valid with BR-FR findings among its warnings now comes back invalid, in both syntaxes. On Factur-X, four of the five profiles gain assertions, and BR-CO-25 leaves BASIC, BASIC_WL and EN16931, where it is now an advisory. Rule ids move too: the packs emit upstream ids beside the generated FX-SCH-A ones. Pin facturx_schematron:1.08 or france_ctc_schematron:1.3.1, or Beliq-Ruleset: previous, until 16 May 2027.

We re-confirmed the mandate timelines for Belgium, Denmark, France, Germany, Ireland, Netherlands, Slovenia, Sweden and the United Kingdom against each country's own authority on 2026-08-24. Seven hold exactly as published. Two moved. Denmark gains a milestone: the Bookkeeping Act phase-in completed on 1 July 2026 for businesses on custom and in-house systems, and NemHandel registration became opt-out on the same date. The United Kingdom gains the month, April 2029 rather than a bare 2029, from HMRC's Tax Update of 23 June 2026, which also confirms Peppol as the core interoperability network on a four-corner model with no e-reporting at launch. The dates the API and the docs publish come from the same source this check reads.

KoSIT published the 2026-08-31 XRechnung bundle: Schematron 2.6.0 plus a new validator configuration. Still breaking, but latest moves to it now rather than on 11 December 2026: nobody is pinned to the outgoing pair, and 2.5.0 rejects conforming documents. Two things now fail, and neither is a new rule. BR-TMP-2 goes from warning to fatal in both syntaxes: BT-124 External document location must be an absolute URL with a scheme, so a bare path or www host is rejected. And CII-SR-465 and CII-SR-466 go from warning to error on CII: a contact must not carry both a person name and a department name. Going the other way, an empty OrderReference/ID no longer fails. Pin xrechnung_schematron:2.5.0, or Beliq-Ruleset: previous, until 11 June 2027.

OpenPEPPOL made Peppol BIS Billing 3.0.21 mandatory on 17 August 2026 and Beliq now validates against it. There is no date to act before: the change is already in force on the network, so latest moved straight to it. Two things now fail that used to pass. The electronic-address codelist behind PEPPOL-EN16931-CL008 drops 14 schemes the authority calls unusable, among them 0202, 0212 and 0217, so a party addressed with one is rejected outright. And four Danish rules go from warning to fatal: PEPPOL-COMMON-R052 and R053 in both syntaxes, DK-R-003 and DK-R-017 in UBL. Pin peppol_bis_billing_schematron:3.0.20, or Beliq-Ruleset: previous, to reproduce an earlier verdict until 3 March 2027.

We re-check each pinned format against its authority on a calendar rather than when upstream announces something, so this entry exists whether or not anything moved. On 26 August 2026 we re-read both Spanish surfaces and neither had changed. Facturae is still 3.2.2, and the ministry still publishes the specification and the XSDs only, with no machine-readable business-rule pack, which is why it carries a Schema-checked badge rather than Authority-checked. VeriFactu is a reporting regime rather than a format, and your invoicing software submits to it, not Beliq; its dates are unchanged, 1 January 2027 for companies filing Impuesto sobre Sociedades and 1 July 2027 for everyone else.

Our 20 August notice described the France half of the 1.4.0.03 bump as a corrected XPath affecting BR-FR-01/02/03 on UBL documents. That understated it. The new pack raises 141 of its CII rules and 145 of its UBL rules from warning to fatal without changing a single rule identifier, so any France CTC invoice that today comes back valid with BR-FR findings among its warnings comes back invalid, in both syntaxes. The date was later brought forward to 10 September 2026, in the entry above. The pin that preserves the old behaviour is the one the original notice named, france_ctc_schematron:1.3.1, and Beliq-Ruleset: previous still reaches it.

An XRechnung Extension or CVD invoice declares the base profile with a further fragment appended, and we matched that identifier exactly, so those documents were validated against EN 16931 alone and no BR-DEX rule ran on one. Peppol had the same bug: a national CIUS layered onto the Peppol BIS identifier, such as Norwegian EHF, met no Peppol rule. We also applied the Schematron's raw severities rather than KoSIT's per-scenario ones. Both now follow the authorities' own rules, which took our disagreements with the KoSIT validator across a 271-document corpus to none. Expect more findings on Extension, CVD and layered CIUS documents, and fewer codelist rejections on plain XRechnung.

FNFE-MPE released Factur-X 1.09.2 and France CTC 1.4.0.03, a bump we classified as breaking. The France side is wider than we first described it, corrected in the 31 August entry below. Four of the five Factur-X profiles gain assertions, so a document that passes today can fail afterwards with no change on your side. One rule goes the other way: 1.09.2 drops BR-CO-25 from BASIC, BASIC_WL and EN16931, which becomes an advisory rather than a failure. That date was later brought forward to 10 September 2026, in the entry above. Rule identifiers move too: the new packs emit upstream ids alongside the generated FX-SCH-A ones and renumber the latter, so anything matching on rule ids has to re-map.

A generate call with verify: false came back with valid: true even though nothing had validated the document. Responses now carry a verified flag, and valid means verified as valid, so the skipped case reports valid: false, verified: false. If you gate a pipeline on valid, it refuses an unchecked document instead of passing it.

Quota enforcement read the calendar month while the reset date was computed from the wall clock, so in a non-UTC process the two disagreed by a month for part of every day. Enforcement, the resetsAt field on GET /v1/me and the Retry-After on a QUOTA_EXCEEDED now all count to the end of your organisation's billing window. The sandbox allowance still resets on the 1st, because it really is metered per calendar month.

status.beliq.eu publishes 90-day availability for the API and the dashboard, probed from outside our network by an independent service, with incident history. The uptime figure on the homepage reads from that probe rather than from a number we typed.

beliq.eu/de serves the site, the pricing, this changelog and the legal documents in German. The German legal texts are originals rather than translations of the English, because German is the language they take effect in.

The rate limit is a burst allowance plus a sustained rate; the account-level throttle is a separate mechanism. A throttled request now returns its own ACCOUNT_THROTTLED error code instead of the generic rate-limit error, so a client can tell which one it hit and back off accordingly.

Send Accept: application/json to /v1/generate and the document comes back base64-encoded in the response body next to the validation verdict, the ruleset fingerprint that produced it, and the SHA-256 of the exact bytes, so run sha256sum on what you saved and you can check it against what we say we sent. The binary response is unchanged.

Every organisation has test keys alongside live ones. A test key runs the same pipeline and counts against a separate sandbox allowance instead of your plan quota, and its jobs are marked test mode in the dashboard, so a rehearsal is distinguishable from real traffic after the fact.

The template designer binds {placeholder} fields as its primary mechanism, embeds its own font set so a layout renders the same wherever it is opened, and offers starting points rather than a blank page: per-rate VAT breakdown tables, individual address atoms, seller imprint and payment account blocks. Templates are referenced by a short id instead of a UUID.

When a request fails on our side, the response carries an incidentId. Quote it to support and we can find the exact failure in our own records without asking you to reproduce it.

The PDF template designer gained inline logo images, a wider colour palette, and a SEPA payment QR that fills from the invoice. SVG fields are sanitized server-side before they render.

Validation responses now return the SHA-256 of your uploaded bytes and of the exact ruleset that ran, and GET /v1/rulesets publishes the artifact hash catalog, so you can check for yourself that the artifact we pin is the one we ran.

Send Beliq-Ruleset on a validate request to pick which rules run: latest, previous, or an exact artefact and version to pin. Your organisation also carries a default channel, so a whole account can sit on previous while a bump lands, and GET /v1/me reports which one it is. The channel is per format, because previous only holds a distinct ruleset once a breaking bump takes effect: until then it resolves to latest and the response sets rulesetFellBack so you can tell the difference between a pin that held and one that had nothing to hold. The response names the artefacts that actually ran either way.

Design a PDF layout in the dashboard and generate by template ID: your branded Factur-X or ZUGFeRD comes out as PDF/A-3b with the structured XML embedded, validated the same as the default output.

ZUGFeRD and Factur-X produce a hybrid PDF/A-3 with the legal XML embedded inside it. The XML-only standards have no hybrid form, so asking for PDF there returns a visualization: a human-readable rendering, with the XML itself still the legal artifact. A new x-pdf-kind response header says which one you received, so a pipeline can branch on it instead of inferring it from the format.

The ZUGFeRD CII profile is now a first-class supported format, backed by a public positive corpus and validated in the same round-trip as Factur-X.

Subscription lifecycle events now emit as signed webhooks, so billing state changes can drive your own automation.

Every webhook attempt is recorded in the dashboard with its response code and a one-click resend.

The Dutch NLCIUS profile now runs against the full 120-fixture authority testset, with the expected outcome asserted for every fixture and every critical rule family covered by a case the engine correctly rejects. Nothing changes in the API: generate and validate behave exactly as before. The status change is the point, that the claim is now backed by the authority's own corpus rather than by ours.

Webhooks carry an HMAC-SHA256 signature over a signed timestamp. Signing secrets rotate from the dashboard.

generate accepts standard eslog and emits Slovenia's national e-SLOG 2.0 XML, invoices and credit notes on the same message shape. validate recognises e-SLOG documents by namespace and checks them against the authority XSD bundle. This path is XSD-only: the Slovenian authority publishes no machine-readable business rules, so there is no Schematron layer and a structural failure carries the rule id XSD rather than a BR- identifier. The profile enters provisional.

generate accepts the netherlands-nlcius profile on Peppol BIS and emits UBL carrying the current NLCIUS customization URN. validate recognises Dutch NLCIUS documents and fires the SI-UBL overlay published by the Dutch Peppol authority, covering invoices and credit notes in one pass. The Dutch legal-entity requirements are met by routing the party block through the KvK or OIN scheme. The profile enters provisional.

Four more countries ride the shared Peppol BIS pipeline with no national overlay, so they generate and validate through the path that is already fully verified, and all four profiles ship supported. Each gains a country guide covering its mandate timeline and its endpoint scheme. Sweden is the one to read first: its endpoints address the organisation number rather than the VAT number, so it is excluded from the per-country VAT fallback and the scheme has to be set explicitly.

Both ride standard Peppol BIS Billing 3.0 with no national overlay, and both profiles ship supported, with country guides covering Ireland's live B2G mandate and 2028 B2B date and the UK's 2029 mandate confirmed at Budget 2025. The UK profile rests on the pre-publication assumption of Peppol BIS with a four-corner model. The formal HMRC and DBT standards are expected around Budget 2026, and the profile is re-checked against them on a calendar-enforced schedule rather than when someone remembers.

generate accepts the romania-ro-cius profile on Peppol BIS and emits UBL carrying the current CIUS-RO customization URN. validate recognises Romanian documents by URN, current and legacy, and fires the two-part CIUS-RO Schematron. Two additions land for every profile rather than just this one: the country-subentity field, and a second tax-total block carrying the VAT amount in the accounting currency, which is what a cross-border Romanian invoice needs. A country guide covers the mandate. The profile enters provisional.

A conversion that loses something acceptable now returns the whole list on an X-Lost-Elements response header: the path, the value, the reason and the severity for each one. Until now only the count was exposed, so you knew something went missing without knowing what. The header is always present, empty on a clean conversion, and capped so a pathological case truncates to a sentinel instead of filling your log line.

Convert an EN 16931 invoice from one format to another in one call: CII and UBL in both directions, ZUGFeRD and Factur-X by profile swap, XRechnung across syntaxes, and Peppol BIS UBL down to plain EN 16931. Hybrid PDFs work both ways, with the visual envelope re-wrapped when the target has a PDF form. Losses split in two: the ones you should not silently accept fail closed and name the un-mappable paths, the ones you can are returned with a count. FatturaPA, Facturae and KSeF are neither sources nor targets, because no published EN 16931 equivalent converter exists for them.

Belgium's B2B mandate uses standard Peppol BIS Billing 3.0 with no national format and no national overlay, so Belgian invoices generate and validate through the Peppol pipeline that already exists. Address them with the enterprise-number scheme or the Belgian VAT fallback. The profile ships supported, and one Belgium-specific rule enforces the enterprise-number checksum. A country guide covers the mandate.

generate accepts standard facturae and produces XML against the authority XSD bundle for Facturae 3.2.2. validate checks Facturae invoices detected by namespace. This path is XSD-only with no EN 16931 Schematron layer, because Facturae descends from the Spanish ministry specification rather than from CEN, so there are no BR- rule identifiers to report against it.

The Dutch SI-UBL overlay was re-checked against the NPa and NEN golden fixtures. No drift.

validate accepts the sdi_messaggio format and checks the notification and receipt messages the Italian exchange system produces. That is a different document class from a FatturaPA invoice and it validates against a different bundle, which is why it needs its own format rather than being auto-detected as an invoice. XSD-only. The bundle and its version come back in the response metadata.

generate accepts standard fatturapa and produces ordinaria XML (FPR12) against the authority XSD bundle. validate checks FatturaPA invoices detected by namespace and covers all three variants, ordinaria and PA alongside semplificata. XSD-only with no EN 16931 Schematron layer, because FatturaPA descends from the Italian revenue agency specification rather than from CEN. The bundle versions come back in the response metadata.

Core CII and UBL semantic rules updated to the CEN 1.3.16 validation release and pinned to its published tag.

The OpenPeppol spring release was pinned and validated against the published BIS Billing test set.

KoSIT's January Schematron release for the XRechnung 3.0.2 specification was pinned across the UBL and CII syntaxes.

MINIMUM through EXTENDED Factur-X 1.08 profiles wired for PDF/A-3 generation and validation.