XRechnung · Validator · Help

XRechnung: two validators return different results

Compare complete rule bundles, scenarios and versions when the same XRechnung passes one check and fails another.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

The same XRechnung format number does not guarantee identical validation rules. Different rule bundles, scenarios or embedded libraries can produce different findings. First compare exactly the same XML bytes and the first differing rule, including severity and location. Then identify the compatible validator bundle actually loaded. Replacing individual Schematron files without their matching environment can introduce new technical failures rather than establish correct validation.

Source basis: Q1 · Q2

Applies to
Covers technical differences between XRechnung validation configurations. The original report concerns 3.0.2 rules; format version, rule release, validator and recipient scenario require separate records.
How to verify the result
The same document yields reproducible findings under the intended scenario and recorded rule bundle, with valid and deliberately invalid controls classified appropriately for the target requirements.
Your first check

Do both checks use the same rule bundle and scenario?

Record validator version, configuration release, Schematron artefacts and selected profile alongside the XRechnung label. The format version alone is insufficient.

The same XML file is marked valid internally but rejected by a recipient or another tool. Both interfaces display XRechnung 3.0.2. A Mustang report illustrates why that label is insufficient: the actual validation artefacts can be different ages. Updating only part of the stack can also introduce a separate integration failure. Q1

The format label is not the full configuration

A useful comparison includes the validator, configuration bundle, rule artefacts and selected scenario. KoSIT publishes configuration releases identifying related components and changes in rule severity. Q2 An unchanged format label therefore does not guarantee identical validation behaviour.

Make the difference reproducible

  1. Preserve identical input. Compare hashes of the XML files actually checked. XML extracted from a PDF and a separately supplied export may represent different document versions despite similar filenames.
  2. Record both configurations. Note tool version, configuration release, rule files and relevant settings. With an embedded library, identify the deployed artefacts rather than relying solely on a dependency declaration in the source project.
  3. Compare scenario and profile. Do both tools evaluate the same syntax and intended exchange context? Different scenario detection can activate different rules. Preserve that decision in the evidence.
  4. Trace one conflicting rule. Start with the first specific difference in rule ID, location and severity. Compare it with published change information. A validation failure, warning and processing exception are not interchangeable outcomes.
  5. Test a compatible bundle. Evaluate a documented combination in a separate environment. Avoid replacing a single XSL file with an arbitrary newer copy. An exception introduced by the change may indicate integration incompatibility rather than a defect in the invoice.

Define a maintainable checking process

Choose a traceable validation configuration for the intended technical exchange and document its update process. Keep representative regression files covering significant previously failing and successful cases. If the recipient requires another configuration, include that requirement in the comparison; an unrelated green online check does not replace it.

For handoff, prepare both complete reports, a version matrix and a minimised example. This guide concerns technical rule application. It does not determine tax treatment or provide legal approval of an invoice. Record which configuration produced each stored decision so that future rule updates do not make historical results impossible to interpret.

Frequently asked questions

Which validator is right?

The interface alone cannot answer that without input identity, scenario and rule versions. Begin with the concrete conflicting rule.

Should I immediately install the newest individual rule file?

No. Use a compatible bundle tested with your integration and keep the change traceable.

Describe your case

Support with this issue

We can compare the active validation configurations and prepare a reproducible check.

Describe your case →Related service: Data & improvements

Sources