# E-invoice versions and update checks

LuaBill 0.1.30 records which validator and rule resources are active and which
document profile was checked. Open **Help → E-invoice standards and updates**
for this information. The dialog follows the interface language (EN/DE/FR/IT/RU).
It has separate views for installed components, the last document generated in
the current session, and update-check results. **Copy details** copies the
displayed information for support or an audit record.

## Generation log and retained evidence

Generating XML, XRechnung or ZUGFeRD writes version details into the generation
log. Successful electronic outputs also include a `.validation-info.json`
sidecar beside the existing Mustang `.validation.xml` report. Keep both files
with the issued PDF/XML. The sidecar identifies the LuaBill version, actual JAR
version and SHA-256, active and original bundled rule metadata, document guideline/profile and
information from the validator report. The original structured Mustang report
remains available for other tools.

From LuaBill 0.1.30 an electronic output bundle consists of the PDF, XML,
Mustang `.validation.xml`, current EN 16931 `.validation-rules.xml` and version
`.validation-info.json`. The `.validation-rules.xml` file is the original SVRL
report produced by the additional current CII rules stage. Its hash, rule
version, status and error/warning counts are also retained under
`validation_stages.latest_en16931` in the JSON audit. Keep all five files
together when retaining the validation evidence.

The installed inventory and document declaration describe different things.
For example, an XRechnung guideline declares the 3.0 family, while a specific
Schematron resource can identify its own release as 2.4.0 and its compatibility
as XRechnung 3.0.2. A list of resources in the JAR is not a claim that every
listed rule was executed for every document. The `rules` section describes the
effective classpath resources; `rules_bundled` preserves the original resources
inside the unchanged Mustang JAR. Missing or unproven release
metadata is shown as unknown instead of being inferred from a folder name.

## Current rules supplied with LuaBill

LuaBill 0.1.30 supplies the official **EN 16931 CII rules 1.3.17** and
**XRechnung CII Schematron 2.6.0**, compatible with XRechnung 3.0.2, in a separate
verified rule package. Mustang CLI remains at 2.26.0. Its original JAR contains
EN 16931 rules 1.3.16 and XRechnung Schematron 2.4.0; those original versions are
shown separately in the audit details rather than being presented as the active
rules.

Every XML, XRechnung and ZUGFeRD generation runs the current official EN 16931
CII stylesheet as an explicit mandatory validation stage, using the Saxon
processor already present in Mustang. This ensures that the current general
rules run even for profiles where Mustang would otherwise select its own
Factur-X-specific stylesheet. The result and rule identity are retained in the
validation protocol and version audit.

The generation command also places the reviewed package before the original
JAR on Java's classpath. Mustang therefore loads the current CII resources from
that package where its profile requires them, including the current XRechnung
rules. Its PDF/A checks, Factur-X resources, XML schemas and packaging code
continue to come from the original JAR. No additional Java runtime or full TeX
distribution is bundled for this change.

The upstream XRechnung 2.6.0 stylesheet uses a newer SVRL metadata element than
the XML reader embedded in this Mustang release accepts. A small LuaBill XSLT
adapter imports the unchanged official stylesheet and omits this informational
metadata element from its output. It preserves the validation assertions,
messages, identifiers, locations and severity flags. Both the official resource
and adapter have separate hashes and retained source and license information.
The adapter does not turn failed rules into successful ones.

Only the reviewed Mustang JAR and rule package combination is activated. A
different JAR selected through `LUABILL_MUSTANG` retains its own native rules
unless its combination is explicitly supported. Missing or damaged required
resources must not silently result in a successful check using older rules.
The version dialog identifies a rule package that cannot be verified instead of
claiming that its rules are current.

Ordinary PDF generation does not perform electronic-invoice validation. Opening
an old project does not recreate the historical validation environment: use the
version sidecar retained when its electronic output was generated.

## Checking for newer releases

Use **Check for updates** for an explicit check of official public metadata:

| Component | Official release source |
| --- | --- |
| Mustang CLI | [Mustang releases](https://github.com/ZUGFeRD/mustangproject/releases) |
| EN 16931 validation artefacts | [ConnectingEurope releases](https://github.com/ConnectingEurope/eInvoicing-EN16931/releases) |
| XRechnung Schematron | [KoSIT Schematron releases](https://github.com/itplr-kosit/xrechnung-schematron/releases) |
| KoSIT XRechnung validation configuration | [KoSIT configuration releases](https://github.com/itplr-kosit/validator-configuration-xrechnung/releases) |
| ZUGFeRD / Factur-X | [FeRD current information package](https://www.ferd-net.de/standards/zugferd/) |

GitHub checks use the repository's `releases/latest` API and accept stable,
non-draft release metadata only. The FeRD check reads the current-package
section of its public standards page. If the source cannot be reached or its
format is no longer recognized, the result is unavailable, not “up to date”.
The local KoSIT configuration date cannot be established merely from the
Schematron version, so its official release is shown as information where a
reliable installed comparison is unavailable.

Enable **Check automatically once a week when LuaBill starts** to run the same
check in the background when due. It is disabled by default. The option and
results belong to the current user's application preferences, not a `.luabill`
project. Opening the dialog or refreshing local information does not itself
start a network request.

Only public release pages and metadata are requested. No invoice, customer,
project, XML or document filename is uploaded. The contacted services receive
the usual connection information, such as the client's IP address. A check
does not download or install a new validator, replace XSLT files or alter an
invoice. Install a reviewed LuaBill release when updating the validation bundle
or its separately versioned rule package.

## Interpreting a notification

A newer validator or rule release is a reason to review an update. It does not,
by itself, prove that existing invoices are invalid or that a legal transition
deadline has arrived. Normative standards, technical rule releases and a
particular recipient's accepted submission formats have separate version and
effective dates. Consult the linked official release notes and the recipient's
requirements.

The validator can itself be current while its bundled rules are older. This is
why LuaBill compares both levels, using the effective reviewed rules rather
than the historical versions inside the JAR. The application does not silently
download and replace individual rule files: compatibility, profiles and
third-party notices are reviewed before a new LuaBill rule package is released.

## Verified baseline on 28 October 2026

The pinned Mustang JAR's own metadata identifies the following original
resources, alongside the active LuaBill 0.1.30 resources. These are a dated
baseline, not a permanently current version list.

| Item | Original JAR evidence | Active in LuaBill 0.1.30 | Official release observed |
| --- | --- | --- | --- |
| Mustang CLI | `Implementation-Version: 2.26.0` in `META-INF/MANIFEST.MF` | 2.26.0, unchanged JAR | 2.26.0, published 25 August 2026 |
| EN 16931 CII rules | XSLT header: 1.3.16, last update 30 March 2026 | 1.3.17, official current CII XSLT | 1.3.17, published 12 October 2026 |
| XRechnung CII rules | XSLT title: Schematron 2.4.0, XRechnung 3.0.2 compatible | 2.6.0, official current CII XSLT with the SVRL adapter | Schematron 2.6.0, release date 31 August 2026, published 2 September 2026 |
| Factur-X | Schematron release metadata: 1.09.2, released 4 August 2026, effective 1 September 2026 | Factur-X 1.09.2 / ZUGFeRD 2.5.2 | Factur-X 1.09.2 / ZUGFeRD 2.5.2 |
| veraPDF | `org/verapdf/release/library.properties`: 1.30.2 | 1.30.2 | Separate online freshness comparison is not provided |

Official rule sources:

- [EN 16931 validation artefacts 1.3.17](https://github.com/ConnectingEurope/eInvoicing-EN16931/releases/tag/validation-1.3.17)
- [XRechnung Schematron 2.6.0](https://github.com/itplr-kosit/xrechnung-schematron/releases/tag/v2.6.0)

Do not infer ZUGFeRD 2.5.0 from a `ZF_250` directory name: the resource's explicit
Factur-X metadata says 1.09.2. The
[FeRD release description](https://www.ferd-net.de/publikationen-produkte/publikationen/detailseite/zugferd-252-deutsch)
maps it to ZUGFeRD 2.5.2 and states its effective date.

[KoSIT's normative version overview](https://xeinkauf.de/xrechnung/versionen-und-bundles/)
states that XRechnung 3.0 remains in force at least until 31 July 2027. The
XRechnung 4.0.0 specification published on 15 September 2026 is a preview, not a
production version. This information is checked as a dated reference; the
application's release comparison is not an automatic assessment of changes in
law.