Before final delivery, confirm the receiver’s requirement, source facts, implemented XRechnung output, validation and submission responsibilities. Keep unresolved actions visible. A completed form or country selection cannot establish that the whole workflow is ready.
Use this checklist after the XRechnung preparation workflow. The current creator supports local data entry, arithmetic, preview, field checks and its documented outputs. It does not generate or validate XRechnung, verify tax treatment or submit through government or Peppol systems.
Confirm the recipient instruction
Identify the invoiced entity and receiving system. Record the accepted specification, syntax, production version and route. Preserve the current instruction rather than relying on a sample from another customer or an old delivery.
Use the recipient enquiry checklist to resolve vague requests. A demand for electronic invoicing or XML is not enough if the actual profile, identifiers and submission requirements remain unknown.
Keep legal applicability questions separate from technical selection. Use current official guidance and appropriate review for the actual transaction rather than inferring obligations from a German address.
Check parties and routing
Confirm seller and buyer identities, addresses and relevant identifiers from their proper sources. Preserve roles and schemes. Do not combine one entity’s name with another’s number merely to fill a required field.
Where a public recipient supplies a Leitweg-ID or other routing instruction, retain it exactly with its intended role. Keep order, contract, payment and electronic delivery references separate. Do not assume every German private buyer needs the same public-sector identifier.
Check contact details against the required target and authorised business records. A billing email, named invoice contact and technical endpoint can be distinct. The creator’s limited fields do not implement every typed component automatically.
Check lines, amounts and treatment
Review supplied scope, quantities, units and price basis against the accepted records. Confirm any required coded units, item identifiers or periods the current app does not collect separately. Preserve those components for the final provider.
Keep discounts, document adjustments and payments in their actual roles. The creator’s line percentage model does not implement every formal financial structure or payable balance. Do not force a target total by changing commercial prices.
Obtain the appropriate tax determination and preserve category, rate, reason and required group relationships. A zero result or supported percentage does not establish legal treatment. Mapping expresses the confirmed decision; it does not create its basis.
Check payment and supporting evidence
Compare authorised destination, method, due date, currency and reference with the agreement. The creator does not verify bank ownership or process payment. A formal field or report also cannot establish every banking fact.
Review any required supporting document for relevance, approved version and unnecessary sensitive content. Confirm its permitted representation and the receiving route’s constraints. A filename in notes is not an attachment.
Keep real data handling appropriate to the external process. Local preparation does not authorise uploading customer files to an unfamiliar converter or validator. Use fictional records for capability tests where practical.
Check the implemented output
Ask the final provider which exact specification, syntax, release and scenarios it supports. Inspect actual target fields and known limits. A badge, extension or screenshot is not sufficient evidence of an XRechnung implementation.
Use representative fictional positive and negative tests. Give roles distinguishable values and include relevant conditional fields. The workflow should report missing facts and unsupported scenarios rather than silently inventing defaults.
Review the exact final file under the required validation configuration. Keep the report, source state and exporter context together. Earlier results do not cover later edits or another profile.
Check actual delivery responsibility
Identify who submits the file through the authorised route and who monitors the result. Generation, validation, upload and recipient processing are separate events. Retain evidence appropriate to each stage rather than one generic success claim.
You can prepare supported source fields locally, but the current exports remain printable output, application JSON and line-item CSV. If XRechnung is required, complete the formal stages in suitable implemented software.
After corrections, generate a fresh final version and repeat affected checks. Keep earlier drafts distinguishable, and use the appropriate business process where an issued document needs correction. The creator does not manage that formal document history.
A completed checklist should name confirmed facts, open gaps, responsible owners and the intended final file. It supports a reviewable handoff, not a guarantee of legal validity, tax correctness, authority approval or customer acceptance. Those broader outcomes need the actual implementation and evidence required by the final workflow.
For a final readiness rehearsal, give a colleague the receiver instruction, source-evidence index, gap list, generated test output and validation record. Ask them to identify the exact intended file, supported production combination, remaining open action and delivery owner. They should not need an informal explanation to distinguish a draft from the final version.
If one answer is missing, record a concrete action before delivery. This does not turn the checklist into a conformance certificate. It checks whether the human handoff is understandable and whether each technical and operational responsibility has evidence appropriate to its scope, which is especially useful when a small supplier relies on a separate software provider.