What to Ask Before Creating an XRechnung for a German Recipient

Before preparing an XRechnung for a German recipient, ask which receiving system, production specification, syntax and route it uses. Collect required identifiers and references from the responsible party. A German address or a request for an electronic invoice does not identify all those facts.

The XRechnung preparation workflow records the answers before formal export. The current creator cannot generate or validate XRechnung, so the enquiry also establishes what a separate final provider must implement.

Identify the invoiced entity

Confirm the exact buyer and its billing instructions. A contact person’s office, central procurement team or shared brand may not be the legal or commercial entity being invoiced. Keep the agreed party record and recipient system connected.

Ask who can confirm technical requirements if the purchasing contact is unsure. A finance or portal instruction may be more precise than an informal request. Preserve the source and confirmation date so later revisions can be checked against it.

Do not assume another German customer’s successful invoice is a universal template. Its routing values, order relationships and accepted delivery route can be different. A sample is useful only with its scope and accompanying specification.

Ask for the exact output

Record the required XRechnung production context and accepted syntax. UBL and CII are different structures, and a provider supporting one combination does not automatically support every release or scenario.

Ask whether a readable copy or supporting evidence is also required and how it should be delivered. A processing document and human review copy can be separate items. Avoid sending contradictory representations without an agreed process.

KoSIT publishes specification and bundle information, including archived and future material. Confirm the actual accepted version rather than selecting the newest visible document or recording only latest.

Collect routing and references

Where the public recipient supplies a Leitweg-ID, obtain the exact value and intended role. Keep it distinct from order, contract and payment references. Do not fabricate one from a department name or reuse another authority’s identifier.

For a private-business recipient, do not assume a public-sector routing identifier is required simply because the format is XRechnung. Follow the actual buyer-reference instruction and applicable current requirements. KoSIT’s FAQ distinguishes these contexts.

Ask which reference supports internal matching and which identifies the technical delivery destination. A billing email is another role. Preserve components separately for final software rather than merging them into one unexplained text string.

Confirm conditional data

Ask about required contact information, payment instructions, supporting documents and transaction-specific fields. A simple example may omit conditions that your invoice needs. Compare the actual supply and arrangement with the final provider’s supported scope.

Keep tax and commercial determinations separate from technical requirements. The recipient can specify its data format without establishing the correct treatment of your supply. Obtain the appropriate review for those decisions.

Use the country-selector capability explanation when planning the handoff. The current tool’s German context does not populate missing typed identifiers, add a national adapter or connect to the receiving portal.

Confirm validation and submission responsibilities

Ask which rule set or validation configuration the final workflow uses and what evidence it returns. Distinguish schema and business-rule validation from a successful basic parse. Keep the report tied to the exact file and version.

Identify who sends the output, through which authorised route, and who checks the result. A local export does not prove delivery or acceptance. The creator has no government or Peppol submission integration.

If registration or access is needed for a separate service, use its appropriate authorised process. Do not put credentials or authentication codes into invoice notes or a static repository to simulate a connection.

Turn the answers into an implementation brief

Record the receiving entity, output combination, required source values, known gaps, final provider, validator and delivery owner. Mark unresolved answers explicitly. A clear action is better than a completed-looking form containing assumptions.

You can prepare supported source details locally, but preserve missing components separately for the final system. Its application JSON and printable output are not a completed XRechnung, regardless of the country selected or a format name in notes.

Use a representative fictional test before relying on the workflow for a real invoice. Compare the actual generated file and evidence with the confirmed requirement. The result should be a receiver-led, reproducible preparation plan, not an unsupported promise of legal validity, authority acceptance or automatic delivery.

For a concise recipient enquiry, prepare a draft requirement record with the known entity and supply, then leave separate blanks for accepted syntax, production release, routing role and submission route. Ask the responsible receiver to confirm those items explicitly. Do not combine them into one yes-or-no question about accepting electronic invoices. A general yes cannot establish which file or identifier is expected.

After confirmation, compare the answer with the final provider’s implementation scope. Record disagreements as actions before generation. This prevents a purchasing contact’s informal request and a provider’s broad support claim from being treated as a complete technical agreement when neither identified the actual production combination.

Retain the confirmed instruction.