Prepare for an XRechnung request by obtaining the German recipient’s actual instructions, collecting the required source facts and choosing software that implements the accepted specification and syntax. A country selection, readable invoice or arbitrary XML file is not an XRechnung implementation. The final document needs its required representation and checks.
You can prepare supported invoice details locally with the creator, but it does not export or formally validate XRechnung. Its current outputs are printable output, application JSON and line-item CSV. It also has no government-portal or Peppol submission connection.
Confirm the actual recipient requirement
Identify the organisation, billing entity and receiving system. Public-sector and private-business workflows should not be assumed identical. A German address alone does not establish the exact format, reference or route the customer requires.
Use the recipient enquiry checklist to obtain the required specification version, supported syntax, references and delivery instructions. Keep the source and confirmation date. A sample from another customer illustrates a case, not your receiver’s complete production requirement.
Keep legal applicability questions separate from technical preparation. This cluster does not determine which mandate applies to every transaction. Use current official guidance and appropriate qualified review where necessary rather than inferring legal obligations from a product selector.
Distinguish the specification from its implementation
KoSIT publishes XRechnung’s specification and technical components. A final provider should identify what it actually implements and which configuration it validates against. A generic XML export option is not sufficient evidence of support.
Confirm the production version rather than assuming the newest visible draft is in force. A specification release and technical bundle can change on different schedules. Record both where relevant so a later report can be traced to the actual tested context.
Use the version and validation-bundle review to document that decision. Keep archived and future material distinguishable from the receiver’s accepted production combination. Avoid the untraceable label latest.
Preserve seller and buyer identity
Collect the confirmed supplier and customer names, addresses and relevant identifiers with their roles. A purchasing contact, central office or payment recipient may be related without being the invoiced entity. Resolve those facts before mapping.
The creator’s multiline address and limited identifier fields do not implement every typed component a final profile may require. Preserve missing components separately and give the final provider their confirmed meanings and sources.
Do not invent a registration value or endpoint to satisfy a required field. A plausible-looking string can pass a technical shape check while belonging to the wrong party. Factual confirmation needs its own evidence alongside document validation.
Collect routing and reference facts
Where the public recipient supplies a Leitweg-ID or other routing instruction, preserve it exactly with its intended role. Do not substitute a purchase-order number or assume one generic reference can satisfy every required relationship.
Use the Leitweg-ID and order-reference comparison to keep those purposes distinct. KoSIT’s guidance distinguishes public-sector routing context from ordinary private-business buyer-reference choices. Follow the actual recipient instruction instead of requiring a Leitweg-ID for every German customer.
A technical endpoint and an in-document buyer reference also have different roles. The same characters may be used in more than one context under a particular arrangement, but that must be confirmed rather than inferred. The creator does not discover endpoints or transmit invoices.
Prepare lines and financial facts
Confirm supplied scope, quantity, units and price basis from the accepted records. Keep typed item identifiers, periods and coded units separately where the target requires them. A description containing those facts is not automatically a formal mapping.
Identify discounts, allowances, charges and prior payments according to their actual roles. The creator implements percentage line discounts but not every financial structure a formal document may need. Do not change commercial quantities or prices merely to make its narrower preview show a desired balance.
Obtain tax determinations from the appropriate review. The final mapper expresses confirmed categories, rates and reasons; it does not establish their legal basis from a German country label or a zero tax result.
Review contact and payment information
Collect the contact roles and details the accepted target requires. A billing email, seller contact and electronic endpoint should not be merged simply because each helps communication. Preserve the source components and mapping responsibilities.
Payment method, account destination, terms and reference also need distinct treatment. The current app’s payment text does not implement every formal payment group or verify bank details. Keep authorisation and banking checks separate from file validation.
If the payee differs from the seller, a mandate is involved or the amount due depends on unsupported settlement features, use a final system that genuinely implements the arrangement. A note can explain a fact without creating the missing calculation or structure.
Choose an implemented final exporter
Confirm whether the final provider supports the required UBL or CII binding and exact XRechnung context. Inspect representative fictional output and known limitations. Do not infer equivalence from a file extension or a screenshot.
Keep the source-to-target record and gap list available. Required facts may need collecting outside the creator before transfer. A converter cannot recover a missing buyer instruction or responsibly invent a tax reason.
Use fictional data for technical testing, including distinct references and relevant conditional cases. Protect real invoice and supporting-document contents when choosing external services. Local preparation does not authorise an unrelated upload.
Validate the exact file
Use the validation-report review to distinguish structural checks, business rules and real-world factual review. KoSIT’s materials explain that validation configuration and underlying rule components matter. A previous successful report may not cover a changed file or configuration.
Retain the generated file, target version, validator configuration and result together. Do not report a basic XML parse as complete XRechnung validation, or technical success as government or customer acceptance.
For supporting evidence, confirm permitted representation and receiver or portal restrictions separately. A filename in notes is not an embedded attachment. Review the full package for unnecessary sensitive information before delivery.
Keep submission and acceptance separate
Assign who submits the file through the agreed route and who monitors its actual status. A local download, successful validation and portal upload are different events. Preserve the evidence for each rather than combining them into one unsupported success claim.
The creator does not provide those transmission or status integrations. If a receiver rejects a file, retain the actual report and investigate its scope before changing source facts. Do not resubmit repeatedly without understanding whether the problem concerns data, format, routing or another requirement.
Use the final supplier checklist to confirm the requirement, source facts, implemented output, validation and delivery responsibilities. A completed preparation record should make unresolved actions visible and repeatable. It does not guarantee legal validity, tax correctness, authority acceptance or successful delivery; those claims require the appropriate real implementation and evidence.
A small supplier can organise the handoff in a single working record with separate sections for recipient instruction, confirmed source facts, unsupported model requirements, final producer, validation evidence and delivery evidence. Each section should identify its owner and current status. The record need not become another invoice; it exists to stop a missing stage being hidden by a complete-looking preview.
For a fictional rehearsal, ask a colleague to locate the buyer routing value, order reference and final file using only that record. They should also be able to tell which checks ran and who will submit the output. If the answer depends on a private explanation, clarify the handoff before relying on it. This practical exercise tests process completeness without making a legal or technical conformance claim about the creator.