XRechnung Version vs Validation Bundle: What to Record

Record the XRechnung specification and technical validation context separately. A specification version identifies the normative target, while a bundle or validator configuration supplies related implementation artefacts. A successful test is difficult to reproduce if the record says only latest XRechnung.

The preparation workflow confirms the receiver’s accepted production combination before generation. The current creator does not implement or validate any XRechnung release, regardless of the version named in notes.

Check production status first

At this review, KoSIT’s versions page identifies XRechnung 3.0 as in force and lists a 3.0.2 Summer 2026 Bugfix bundle. It separately identifies the September 2026 XRechnung 4.0 publication as a preliminary version. Do not confuse the visible draft with the current production target.

Recheck official status and the recipient’s instruction when preparing an actual file. Future publication plans can change, and a receiver’s accepted combination needs explicit confirmation. This article is not an automatic migration instruction for every customer.

Keep the source URL, confirmation date and relevant release identity with the record. Archived material may remain available for reconstruction without being recommended for new submission. A general search result should not silently choose the production version.

Separate specification from technical artefacts

A technical bundle can update implementation components without representing a new normative specification. KoSIT’s FAQ explains that validation combines European and XRechnung components, so changes in underlying rule sets can affect results.

Record the actual validator configuration and related bundle used by the final provider. The main specification number alone cannot identify every check that ran. Likewise, the provider’s application version is not the same as the invoice specification or validator release.

Ask for known limitations or release notes relevant to your scenario. A generic support claim leaves too much context unresolved. The final implementation should state which production combinations and transaction types it actually covers.

Tie the result to the exact file

Retain the generated invoice, source-data version, exporter configuration and validation report together. A report for an earlier revision cannot approve a file changed afterwards, even if its filename is unchanged.

If the recipient reports a different result, compare actual configurations before changing business facts. A new rule set can expose an issue that an older test did not flag. That possibility should be investigated, not used to dismiss every rejection as a version problem.

Use the schema and business-rule comparison to identify which layer reported the failure. A syntax mismatch, business-rule defect and wrong source value need different repairs.

Review implementation changes deliberately

When the final provider updates a bundle or adapter, repeat the cases affected by the change. Include representative positive and negative examples. Do not assume a previous simple invoice proves the new configuration handles every conditional scenario.

Preserve input facts during a focused configuration comparison. Changing prices, identifiers and validator versions at once makes it difficult to find the cause of a difference. Isolate one question before combining results.

Use fictional files for technical tests where practical. The creator’s local processing does not authorise uploading customer invoices to an unfamiliar online validator simply to discover which release it uses.

Keep recipient requirements visible

A provider offering a newer option does not establish the receiver accepts it. Confirm the exact production requirement and migration process through the appropriate channel. Avoid a default rule that newest always means compatible.

Similarly, an old accepted file is evidence of that earlier event, not a permanent guarantee. A later invoice may have different data, rules or destination context. Retain the actual receiving instruction with the current test.

The current creator’s printable output, application JSON and CSV remain application outputs. Renaming a file with a version number does not implement the required schema, rules or profile. Use suitable final software for the accepted target.

Record a reproducible decision

A useful release record identifies recipient, specification, syntax, bundle/configuration, exporter, exact file and observed result. Keep current and superseded combinations distinguishable under your business process.

For a fictional regression test, run the same source case through the old and proposed configurations and compare reported differences. Record which changed checks are expected and which need investigation. Do not treat an unexplained pass as a substitute for understanding the implemented scope.

Version-specific evidence helps diagnose technical issues, but it does not establish tax correctness, legal validity, transmission or recipient acceptance. Those need their own review and operational evidence in the final workflow.

A reproducible release worksheet can have separate columns for normative specification, technical bundle, syntax, exporter build and validation configuration. Populate them from actual sources rather than repeating one version number across the row. Link the exact tested file and observed result.

When a provider proposes an update, keep the original row and create a new one for the proposed combination. Run the same fictional baseline and relevant negative cases through it. Investigate differences before approving production use. This preserves a comparison record instead of overwriting the context that explained the earlier successful result.

Record rule component versions when the provider supplies them.