Schema Errors vs Business-Rule Errors in an XRechnung Check

A schema error concerns the structural rules of the applicable XML syntax. A business-rule error concerns additional required relationships or constraints in the chosen invoice context. Both matter, and a successful basic parse is not proof that either complete validation layer ran.

The XRechnung preparation workflow uses the actual target and validation configuration. The current creator does not export XML or run formal schema or business-rule validation, so its field checks should not be relabelled as XRechnung results.

Identify the structural layer

Check the intended syntax, document root, namespace and schema version. UBL and CII are different structures. A file can be well formed while failing the required schema because elements, types or order do not match the target.

KoSIT’s FAQ explains that XRechnung uses underlying syntax schemas rather than one separate universal XRechnung XSD. Its validation configuration brings relevant components together. Do not look for an invented schema that alone represents every requirement.

Keep the actual validator configuration with the report. A check against a different syntax or release cannot establish this document’s status. Similar filenames do not make the rule contexts equivalent.

Identify the business-rule layer

Additional rules can address codes, conditions, calculations and profile-specific relationships. A broader syntax schema may permit structures that the required context restricts. The final workflow needs the applicable rule sets, not only structural validation.

A missing reason, disallowed code or inconsistent total can require a different repair from an invalid element sequence. Read the rule and target definition before deciding which source or mapping fact is wrong.

Do not turn every business-rule failure into tax advice. Some rules test representation or relationships, while the actual treatment determination still needs appropriate review. Preserve factual and professional evidence separately.

Keep the diagnostic context

Retain file version, specification, syntax, validator configuration, message and location where available. A short screenshot of an error can omit information needed to reproduce it. Keep the complete report through the appropriate business process.

Use the validation-report review to summarise the result without overstating it. A message identifies a tested condition, not every issue in the invoice. Another failure may become visible after the first structural problem is repaired.

If two tools disagree, compare their actual inputs and configurations. Do not assume that the tool showing fewer errors is more correct. A narrower or outdated rule set can produce a reassuring but incomplete result.

Repair without changing the transaction

Correct wrong source facts from confirmed evidence and mapping defects in the implementation. Avoid deleting valid content or inventing identifiers simply to make a report pass. A technically acceptable placeholder can still misrepresent the recipient or supply.

Do not change quantities or tax categories to silence an amount error without understanding the calculation model. Preserve the agreed commercial meaning and required treatment. A matching final sum cannot justify unrelated field changes.

Where practical, repair the generation rule and regenerate instead of hand-editing every download. Keep the change traceable and repeat affected checks. This makes the solution reproducible on the next invoice.

Test the layers separately

Use a fictional valid baseline and introduce one structural defect in a separate test. Confirm the intended schema workflow detects it. Keep all business values fixed so the result is attributable to the structure change.

Create another case with valid structure but a documented business-rule defect. Record the expected response under the selected configuration. These contrasting cases establish more useful evidence than one file containing many unrelated errors.

Keep input, generated output and actual reports with the test. A claim that the provider validates XRechnung should be backed by observed implementation scope and known limits, not a generic valid label.

Finish the full workflow

After correction, run the relevant complete checks on the intended final file. Review source accuracy and any readable or supporting representations separately. An earlier report does not cover later edits.

A technical pass still does not submit the invoice, prove tax correctness or guarantee customer acceptance. The creator’s supported JSON, CSV and printable output remain preparation outputs. Use an implemented final exporter, appropriate validation and the agreed delivery process, retaining the evidence for each stage at its actual scope.

A focused test register can contain one schema-valid baseline, one controlled structural failure and one documented business-rule failure with otherwise valid structure. Keep source meanings and unrelated values fixed in each mutation. Record expected and actual responses separately.

The register should identify which component checked each layer and which configuration supplied its rules. If the provider reports only a single generic status, ask for the scope needed to interpret it. A successful baseline alone cannot establish that the negative checks are active. Retain the failing cases after repair so future updates can be checked against the same known defects. This gives practical evidence of implementation behaviour without assuming automated validation determines the real-world correctness of every invoice fact.

For a reported schema error, retain the surrounding target structure as diagnostic context; an isolated leaf value may not explain the failure.