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.

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).