Why Selecting Germany Does Not Create an XRechnung

Selecting Germany in the creator does not create an XRechnung. The country choice supplies context in the application’s own model; it does not add a national semantic mapping, formal validator or submission connection. The supported output types remain the same.

The XRechnung preparation workflow identifies what a separate final system must implement. Use the current tool for its actual preparation features rather than assuming that a familiar country name establishes compliance.

Understand the implemented context

The creator stores supported party information and invoice values in its own schema. It provides line calculations, a preview, field checks and documented local draft/export functions. Those are real capabilities within the current model.

Its country selector does not determine tax treatment or select an official national profile. Rates and categories remain manually entered. A German address does not prove that a chosen rate, exemption or reason is appropriate.

The app also does not populate missing official identifiers, endpoint schemes or routing values. Those facts need confirmation from their proper sources and typed representation where the final target requires it.

Understand what XRechnung requires

A genuine implementation needs the accepted specification and syntax binding, required semantic fields and applicable validation. KoSIT’s documentation explains conformance through more than a readable invoice or arbitrary XML.

A product could store information relevant to an XRechnung without being able to export one. Source preparation and standards implementation are different stages. A preview containing seller, buyer and total is not proof of the required target structure.

Use the UBL and CII selection review to confirm the accepted final combination. The current creator exports neither formal syntax. Its own JSON is structured application data, not a ready-made XRechnung adapter.

Keep output labels accurate

Printable output is a readable document produced through the browser. Save as PDF, where offered by that environment, does not embed the required structured invoice XML or create a hybrid standard.

Application JSON uses invoice-workspace/1 and explicitly states that standards validation has not been performed. CSV contains line items rather than a complete formal invoice model. Neither becomes XRechnung by changing its extension.

A note naming the standard, a badge or a filename containing Germany cannot implement the missing capability. Keep planned support separate from current feature claims so customers know what the downloaded file actually contains.

Preserve useful preparation work

You can still collect confirmed party data, document facts and supported lines here. Review quantities, prices and manual tax inputs against the appropriate records. Preserve facts the current model cannot type separately for the final provider.

Do not force routing identifiers into email boxes or alter prices to simulate unsupported adjustments. Those workarounds change meanings rather than complete a standards mapping. Keep a clear gap list and use appropriate final software.

The final provider should explain how it imports supported data, collects missing components and validates the intended target. A generic converter cannot responsibly infer every fact from one readable note.

Test the actual boundary

Use a fictional draft, change the country context and inspect the supported output types. The test should not be reported as national compliance testing. It demonstrates the current application behaviour and limits.

A future XRechnung adapter would need its own implementation, representative tests and required validation evidence. Adding one visible selector option is not enough. The actual generated file must implement the accepted context.

Keep technical and factual review separate. Even a future formally valid target could contain an incorrect identifier or treatment decision. The current country selection cannot establish either aspect automatically.

Complete the required workflow elsewhere

If the recipient requires XRechnung now, choose software that genuinely implements the accepted specification, syntax and scenarios. Inspect output and validation evidence, then assign actual delivery through the agreed route.

You can prepare supported invoice data locally, but the tool has no government or Peppol submission integration. A downloaded file is not evidence of transmission, receipt or acceptance by the customer.

Keep the confirmed requirement, source facts, final output and operational evidence together. The country context can help organise preparation, while standards export, formal validation, tax determination and delivery remain distinct capabilities that need real implementation before broader claims are justified.

A simple product-boundary demonstration can use one fictional draft exported under two country contexts. Inspect the application schema and available output types rather than assuming a national adapter appeared. The demonstration should be labelled as a test of current behaviour, not as a tax or compliance test.

Then write a separate requirement record for a real XRechnung adapter: target release, typed source facts, mapping rules, calculations, validation and delivery boundaries. Compare that record with the implemented feature list. The difference explains why a country option is useful context but insufficient evidence of national format support. A future feature can close those gaps only through actual implementation and tests, not by changing the selector wording or adding a standards logo to the preview.

Check that application JSON still reports standards validation as not performed after a country-context change.