XRechnung vs ZUGFeRD: Questions to Ask Before Choosing

Ask the recipient which format, profile and version its receiving system accepts before choosing XRechnung or ZUGFeRD. The names describe different specifications and implementations, not visual invoice templates. A readable PDF and an XML file are not interchangeable merely because they show the same amounts.

The format-selection workflow follows the receiver’s actual requirement. The current creator exports neither verified XRechnung nor ZUGFeRD. Its country selector provides context; choosing Germany does not add a standards adapter or a submission connection.

Clarify the recipient and workflow

Identify the organisation receiving the invoice and the system used by its finance team. Do not assume every German customer has identical requirements. A public-sector instruction, a private customer’s platform and an internal approval copy may involve different deliverables.

Obtain the named specification, accepted profile and version, required references and delivery route. Ask for the current official or recipient instruction rather than relying on an old sample found through a general search. Preserve the source and date of the confirmation.

Keep legal applicability questions separate from technical acceptance. This article helps choose an output for an identified receiver; it does not determine which mandate applies to a particular transaction. Use the appropriate current official guidance and qualified review for that decision.

Understand the document distinction

KoSIT describes XRechnung through defined invoice data, syntax and business-rule requirements. Its conformance explanation includes more than the presence of XML. A file must represent the specified meaning and satisfy the applicable structure and rules.

FeRD describes ZUGFeRD’s hybrid form as readable PDF/A-3 combined with structured XML invoice data. Packaging, profile and consistency requirements matter. A normal printed PDF without the required payload is not that implementation.

These descriptions identify different implementation questions. For XRechnung, confirm the accepted syntax and specification context. For a hybrid output, confirm the required profile, packaging and consistency checks. Do not choose based only on which preview is more attractive.

Confirm profile and version explicitly

Record exact identifiers and versions rather than “German XML” or “latest PDF”. A receiver may require a particular supported production combination. A future draft or a newer broad syntax does not automatically replace that requirement.

KoSIT publishes current versions and technical bundles separately. The software provider should state what it implements and which validation configuration it uses. A bare claim of XRechnung support leaves important testing context unresolved.

For ZUGFeRD, confirm the recipient’s accepted profile and release with the implementing provider. Do not assume every profile contains the same data coverage or meets every customer requirement. A logo is not evidence of the exact profile in the file.

Check required source facts

Compare the recipient’s needs with your available seller, buyer, reference, line, tax and payment data. Some required facts may have no typed field in the current creator. Preserve them separately before choosing a final exporter.

A missing endpoint, routing value or coded tax explanation cannot be recovered reliably from a polished preview. Do not invent values or place them in unrelated fields to satisfy an export button. Obtain confirmed information from the appropriate source.

Use the unsupported-format handoff when the current creator cannot produce the requested document. Retain useful preparation work while choosing software that genuinely implements the required output. This is more accurate than relabelling application JSON or browser PDF as a standards invoice.

Keep delivery separate

Ask how the customer expects the document to arrive and who is responsible for sending it. A portal upload, network delivery and readable email copy are distinct actions. Producing an accepted file format does not complete those actions automatically.

The current app has no government submission, Peppol integration or automated email service. A locally downloaded file has not been received or accepted by the customer simply because export succeeded. Keep the required transmission evidence separate from the validation report.

If a customer wants both a processing document and a review copy, establish the relationship and consistency expectations. Do not send conflicting representations and expect the receiver to decide which one is authoritative.

Test the chosen workflow

Use a representative fictional invoice with the references and tax situations the real workflow needs. Inspect the actual exported fields, profile indicators and validation result. For hybrid output, review both the readable and structured representations.

Record the tested specification, bundle or profile and exact file version. A previous successful example does not prove that a later document or different recipient is compatible. Repeat relevant checks after meaningful changes.

The useful outcome is a documented receiver-led choice with an implemented exporter, confirmed source data and assigned validation and delivery steps. It does not guarantee legal validity, tax-authority approval or recipient acceptance, and it does not change the current creator’s limited output capabilities.

A concrete enquiry can ask the receiver to confirm its accepted format/profile/version combination and the exact delivery route in one reply. Keep that confirmation with a fictional test output and its report. If the provider supports only one of the requested combinations, mark the alternative as unsupported instead of leaving a general German-format claim in the capability record.