XRechnung in UBL vs CII: Choosing a Supported Syntax

Choose UBL or CII from the recipient’s accepted XRechnung requirement and the final provider’s real implementation. They are different message structures, not two file extensions for the same serialisation. Supporting one syntax does not automatically establish support for the other.

The XRechnung preparation workflow records that choice before mapping. The current creator exports neither syntax as XRechnung, and its application JSON is not a formal binding waiting to be renamed.

Confirm the accepted combination

Ask the responsible receiver which production specification and syntax it processes. Record any profile or additional instructions, source and confirmation date. Do not choose from an unrelated sample or a generic statement that XML is accepted.

KoSIT’s documentation relates XRechnung to the specified UBL and CII bindings. Read the actual target release rather than assuming the newest general syntax publication is the required combination. A broader format family’s capabilities do not override the accepted binding.

Keep document type in view. An invoice and credit note have their own structures and supported scenarios. The current creator prepares ordinary positive invoices, not a formal correction or credit-note workflow.

Compare implemented provider support

Ask which syntax and release the final exporter genuinely generates and which validation configuration it uses. Request representative fictional output and known limitations. A screenshot or broad XRechnung badge is weaker evidence than the actual implementation and test results.

Do not choose solely by which XML sample looks shorter or easier to read. Technical familiarity can help maintenance, but the chosen workflow still needs correct fields, calculations, codes and required conditions for the receiver.

Use the version and bundle record to keep the exact combination reproducible. The software’s own version is another identifier and cannot substitute for the target specification and rule-set context.

Review source-data requirements

Both options need the correct business facts under the required binding. Choosing a syntax cannot recover missing party identifiers, routing values, reasons or references. Collect confirmed components before relying on generation.

The creator has limited reference fields, free-text units and multiline addresses. Some target facts therefore need separate preparation records and a suitable adapter. A sentence in notes does not create a typed source role.

Do not invent missing values to satisfy the selected syntax. A technically valid string assigned to the wrong role remains a semantic error. Preserve source evidence and mapping decisions with the handoff.

Preserve commercial relationships

Check quantity, unit, price basis, adjustments and tax-group relationships in the actual output. A mapper must express the transaction accurately under the chosen target rules. A matching total cannot establish every intermediate role.

If the transaction needs document allowances, prepaid reconciliation or another unsupported feature, use a final financial model that implements it. Do not modify line prices to conceal a gap in the current creator.

Tax determination remains separate from syntax selection. The mapper expresses confirmed treatment; choosing UBL or CII does not establish which category, rate or reason applies to the supply.

Test the real binding

Use fictional data with distinguishable party and reference values, nontrivial lines and relevant conditional facts. Inspect the generated structure and required validation report. A basic XML parse is not evidence that the complete XRechnung context was tested.

Include a known unsupported case and verify clear reporting rather than silent defaults. A final provider should be able to explain what it implements and which requirements remain outside scope.

If conversion between syntaxes is proposed, treat it as another mapping with its own tests. Do not assume every source structure transfers without checking cardinalities, conditions and meaning under the actual target release.

Finalise and deliver accurately

Keep the chosen syntax, specification, exporter configuration, exact file and validation evidence together. Repeat affected checks after source or implementation changes. Earlier reports remain tied to the versions they tested.

Assign delivery separately through the accepted route. A correct syntax does not submit the file, establish receipt or guarantee acceptance. The creator has no government or Peppol integration to perform that action.

The useful choice is a receiver-compatible implementation with accurate source facts and reproducible evidence. Current printable output, application JSON and line-item CSV can support preparation within their scope, but they are not a substitute for verified UBL or CII XRechnung output.

For a provider comparison, send the same fictional source brief to each supported implementation and ask it to state the generated syntax, target context and known gaps. Compare meanings and validation evidence rather than XML length or visual presentation. The same source facts can have different structural locations without changing their intended roles.

Include a fact the current creator cannot represent as a typed field, such as a separately required component confirmed in the working record. Check whether the final provider accepts it explicitly, reports a gap or invents a default. This tests the real handoff boundary rather than assuming a general UBL or CII claim guarantees complete XRechnung coverage. Preserve the exact production requirement beside both results.

Compare actual generated document identity, not just the declared file type.