How to Read an XRechnung Validation Report Without Treating It as Acceptance

Read a validation report as evidence about a particular file under a particular configuration. Identify what was checked, which rules failed and what the result does not establish. A technical pass is not automatically proof of tax correctness, legal validity, delivery or acceptance by the customer.

The XRechnung preparation workflow keeps those stages separate. The current creator does not run formal XRechnung validation. Its application field-check result should not be presented as a report from a standards validator.

Identify the exact tested file

Match the report to the generated invoice version and source state. A later edit can change identifiers, references or totals without updating an earlier report. A familiar filename alone is insufficient if files are overwritten.

Record the target specification, syntax and validation configuration. KoSIT’s FAQ explains that underlying European and XRechnung components can affect results. The main specification label alone may not identify every check applied.

If a customer or provider reports a different result, compare actual files and configurations before changing business facts. A technical difference needs investigation rather than an assumption that either system must be wrong.

Read the failed rule and context

Keep the rule identifier, message, severity and location where supplied. Locate the relevant target group using an appropriate XML-aware tool. An error pointing to one element may arise from an earlier missing component or relationship.

Use the schema-versus-business-rule comparison to understand the failure layer. A structural error, invalid code and inconsistent monetary relationship require different repairs. Do not delete legitimate data randomly until the report becomes quieter.

Treat the message as diagnostic evidence, not a substitute for the specification. Confirm the actual requirement and source meaning. A short validator message may not explain every business condition behind the rule.

Separate technical and factual review

A structurally valid identifier can still belong to the wrong buyer. A complete reason can reflect an incorrect tax determination. A consistent total can be calculated from the wrong quantity or price. Automated checks cannot establish every real-world fact.

KoSIT’s conformance explanation includes semantic use as well as technical checks. Preserve the appropriate factual and professional review alongside the validator result. Do not describe a pass more broadly than its evidence supports.

The current app can help review supported source values and arithmetic, but it does not verify registries, bank ownership or tax treatment. A formal report produced elsewhere does not silently add those capabilities to the creator.

Repair the correct layer

If a source fact is wrong, correct it from the confirmed record. If the mapping is wrong, repair the adapter and regenerate. If the target requirement is unclear, obtain clarification rather than inventing a value to satisfy a rule.

Keep changes traceable. Repeated manual edits to downloaded XML can become undocumented implementation logic and disappear on the next invoice. A reproducible generation process is easier to review and maintain.

Do not weaken a required validator or change a tax category solely to force a pass. Resolve the cause under the accepted target and transaction facts. A quieter report is not the same as a correct invoice.

Revalidate the intended final version

After meaningful corrections, regenerate and run the appropriate checks again. Keep the new file, configuration and report together. Earlier success or failure remains evidence of that earlier state.

Use fictional cases for integration troubleshooting where practical. Do not expose a real customer’s invoice to an unfamiliar online validator merely to compare messages. Local preparation and external checking have different data flows.

Review the readable representation too if one accompanies the processing document. A technical report may not establish consistency with a separately generated PDF or supporting evidence. Keep the scope of each review explicit.

Record submission and response separately

A validated file still needs delivery through the agreed route. An upload acknowledgement and final customer processing status can be different events. Assign who monitors the actual result and retains its evidence.

The creator has no government or Peppol transmission integration. A successful local download or field check cannot establish acceptance. Do not tell a customer a document was submitted because a file exists in the browser’s downloads.

A useful report summary states the file version, target context, checks performed, observed outcome, unresolved issues and next owner. It preserves the value of formal validation while avoiding unsupported promises about facts or operational events outside the validator’s scope.

A useful report summary has separate entries for tested file, target context, structural result, business-rule result, factual review and delivery status. Populate each only from evidence of that stage. A technical pass should not automatically fill the factual or delivery entries.

For a fictional rehearsal, validate one file, change its buyer reference and retain both versions. Ask a colleague which report covers which file. If the record cannot answer, improve version identification before using the process for real invoices. This checks evidence traceability, not merely validator execution, and helps prevent a valid-looking report from being attached to a later untested revision.

A report should identify the actual revision it tested.