Changelog

A manually-curated record of what ships in InvoiceSpec — spec-version bumps, new endpoints, and breaking changes — with one dated entry per release. The changelog starts from the documentation competitive-uplift body of work and grows forward from here; it is not backfilled with historical entries.

Each entry is backed by a typed data registry, so adding a future entry is a data change rather than an inline page edit. When a supported spec version or rule set changes, or a new endpoint or breaking change lands, add the entry here as part of that release's own change description.

XRechnung Generator: full-field support, clear errors, and more document types

The free public XRechnung Generator now supports every field the backend can serialize, shows clear non-technical error messages, and accepts all eight UNTDID 1001 document type codes — including German construction invoice types.

Added

  • The generator form now exposes every field the backend canonical invoice and XML serializers can represent — including seller tax registration number (BT-32), purchase order reference (BT-13), and delivery location identifier (BT-71), which were previously collected but silently dropped by the CII/UBL serializers (#134).
  • All eight UNTDID 1001 document type codes are now selectable: 380 (Commercial Invoice), 381 (Credit Note), 384 (Corrected Invoice), 389 (Self-billed Invoice), 326 (Partial Invoice), 875 (Partial Construction Invoice), 876 (Partial Final Construction Invoice), and 877 (Final Construction Invoice).
  • A full-field audit test verifies that every form input appears in the generated XML for both CII and UBL syntaxes, preventing silent field drops in future changes.

Changed

  • Generation and validation errors are now translated into clear, non-technical, actionable messages. Instead of "Something went wrong" or raw EN 16931 rule codes (BR-33, BR-S-05…), users see guidance like "Add a reason to your discount in the Invoice Discounts section" or "Invoice number must not be blank".
  • The tool is now named "Generator" (not "Creator") throughout the UI and documentation. The route remains `/tools/xrechnung/create` because `create` is the route verb.
  • The invoice type code field in the Invoice JSON Schema docs now lists all eight supported UNTDID 1001 codes instead of only mentioning 380.

Fixed

  • Discounts with a blank reason no longer crash generation — the reason defaults to "Discount" to satisfy EN 16931 BR-33 (every document-level allowance must carry a reason or reason code).
  • Switching a line or discount from a zero-rate VAT category (E, Z, AE, K, G) back to Standard (S) now restores a positive VAT rate, preventing EN 16931 BR-S-05 failures.
  • Empty line items (blank description) and zero-amount discounts added by clicking "Add Line" / "Add Discount" are now filtered before sending to the engine, preventing HTTP 400 validation errors.
  • CII D16B, CII D22B, and UBL 2.1 serializers now correctly emit purchaseOrderReference (BT-13), seller taxRegistrationIdentifier (BT-32), and delivery locationIdentifier (BT-71).

ZUGFeRD profile selection — EXTENDED, MINIMUM, BASICWL + early validation

Generation now accepts all six ZUGFeRD/Factur-X profiles (MINIMUM, BASICWL, BASIC, EN16931, XRECHNUNG, EXTENDED). MINIMUM/BASICWL suppress line items from the embedded XML; EXTENDED stamps the URN without modeling extension-only fields. Unsupported profiles are now rejected at spec resolution time with HTTP 400 UNSUPPORTED_SPEC instead of HTTP 500 GENERATION_FAILED. Validation emits a PROFILE-SCOPE advisory warning for MINIMUM/BASICWL documents.

Added

  • ZUGFeRD generation accepts EXTENDED, MINIMUM, and BASICWL profiles in addition to the existing BASIC, EN16931, and XRECHNUNG. All six are generated from the same canonical EN 16931 invoice data.
  • MINIMUM and BASICWL profiles suppress SupplyChainTradeLineItem elements from the embedded CII XML (the PDF is the legal invoice for these profiles; the PDF renderer still shows full line data).
  • EXTENDED profile stamps the conformant URN (urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended) without modeling extension-only fields (sub-invoice-lines, line-level ship-to, sales agent, logistics service fees).
  • Validation emits a PROFILE-SCOPE advisory warning (severity WARNING) when validating a MINIMUM or BASICWL document, reminding the caller that line items are intentionally absent from the embedded XML.

Changed

  • The specs-list catalog endpoint now surfaces all six ZUGFeRD profiles in the profiles array for the ZUGFERD spec entry.
  • The config.profile field documentation now lists all accepted values and describes the MINIMUM/BASICWL line-suppression and EXTENDED URN-stamping behaviour.

Fixed

  • Unsupported ZUGFeRD profiles are now rejected at spec resolution time with HTTP 400 UNSUPPORTED_SPEC (with the list of supported profiles in the message) instead of reaching the packager and throwing HTTP 500 GENERATION_FAILED.

ZUGFeRD version 2.5.2 — official FeRD Schematron rules

ZUGFeRD validation now uses the official FeRD Schematron rules for the embedded CII XML alongside PDF/A-3 conformance checks, and the supported version is bumped from 2.4.0 to 2.5.2, aligning with the latest FeRD release and the config-driven version lifecycle.

Added

  • ZUGFeRD validation now checks the embedded CII XML against the official FeRD Schematron rules for all Factur-X profiles (MINIMUM, BASIC-WL, BASIC, EN16931, EXTENDED) and XRechnung 3.0 / 2.1 CII documents, in addition to the existing PDF/A-3 conformance check.

Changed

  • The ZUGFeRD version is bumped from 2.4.0 to 2.5.2, matching the latest FeRD release. The request.version field now accepts "2.5.2"; the previous "2.5" example in the docs is updated.
  • The ZUGFeRD validate endpoint (POST /v1/invoice/zugferd/validate) returns a single merged validation report covering both the embedded XML and the PDF/A-3 container, with the zugferd-2.5.2 version and CII syntax.

Spec version lifecycle — scheduled activation & auto-sunset

Spec entries and validation packages in specs-config.yaml now support effectiveDate and sunsetDate, so a new version can be deployed in advance and auto-activate on the authority's effective date, and an old version auto-disappears after its sunset — no redeploy needed. The GET /v1/invoice/specs catalog now exposes both dates so developers can see when a version will sunset.

Added

  • Spec entries and validation packages in specs-config.yaml support two optional ISO-8601 date fields: effectiveDate (the entry is invisible until this date) and sunsetDate (the entry auto-disappears the day after this date). This enables scheduled activation on authority effective dates and auto-sunset after the coexistence window — no redeploy required.
  • The GET /v1/invoice/specs catalog response now includes effectiveDate and sunsetDate on each SpecOption, so developers can see when a version became available and when it will be rejected with UNSUPPORTED_SPEC.

Changed

  • An entry is now 'resolvable' iff active is true AND today is on/after effectiveDate AND today is on/before sunsetDate. The 'latest' version wildcard only matches resolvable entries, so listing a new version above an old one makes it the default automatically once its effectiveDate passes.
  • The GET /v1/invoice/specs catalog now omits not-yet-effective and past-sunset entries in addition to inactive ones, so the catalog only shows versions a developer can actually use right now.

Documentation competitive uplift

A bundle of public-documentation improvements closing evidenced gaps against competing e-invoicing API docs, while preserving and extending InvoiceSpec's existing structural advantages (guided onboarding, interactive explorers, real engine-generated sample artifacts).

Added

  • Three per-endpoint Invoice JSON Schema explorers (XRechnung, EN 16931, ZUGFeRD) replace the single shared explorer, so every `required` badge and constraint is guaranteed to apply to the endpoint you are calling (#90).
  • A Business Term & Requirement Mapping derives each field's per-spec requiredness from the actual vendored XSD/Schematron rule files, with auto-extracted presence-check rules distinguished from manually-verified overrides — so the explorers cannot silently drift from what the validators enforce (#93).
  • A public `/docs/glossary` page defines the e-invoicing domain terms used across the docs — EN 16931, CII, UBL, XRechnung, ZUGFeRD, Factur-X, Peppol BIS, PDF/A-3, BT, BG, BR, CIUS, Schematron, KoSIT, Leitweg-ID, AUTO mode, profile, syntax (#91).
  • A centralized `/docs/errors` page lists every API error code in one searchable place, rendered directly from the same per-endpoint error data as the API Reference so the two views can never drift (#94).
  • Real, engine-generated sample artifacts (XRechnung XML, ZUGFeRD PDF/XML, and a new EN 16931 XML sample) are surfaced directly inside Getting Started and the API Reference, not only on marketing pages (#95).
  • This `/docs/changelog` page, backed by a typed data registry, with this initial entry (#97).

Fixed

  • Documented precisely what `BR-DE-15` checks for `buyerReference` / Leitweg-ID: presence and non-blank only — not format or checksum. The clarification appears in the Glossary and inline near `buyerReference` in the XRechnung schema explorer, and explicitly frames the absence of Leitweg-ID format/checksum validation as an industry-wide gap in the standard KoSIT tooling rather than an InvoiceSpec-specific defect (#92).