How to Prepare Contact Information for an XRechnung Handoff

Prepare contact information according to the accepted XRechnung specification and receiver instruction. Keep the contact role, name and required communication details distinguishable from seller identity, billing email and electronic endpoint. Similar-looking values can serve different purposes.

The XRechnung preparation workflow gives those confirmed facts to an implemented final exporter. The current creator has supported party email fields, but it does not provide a complete verified XRechnung contact group or determine every required component.

Identify which contact is needed

Ask who is responsible for invoice questions and which role the target field represents. A salesperson, purchasing contact, accounting team and technical delivery operator may be different people or services. Do not use whichever address is easiest to find.

Confirm that the contact belongs to the intended seller or other required role. A shared organisation domain does not prove the person is responsible for this transaction. Keep the source and scope of the instruction.

Use the current accepted specification to establish mandatory and conditional components. Do not infer a universal rule from a short example or assume a general application email field satisfies every target requirement.

Collect components separately

Where required, preserve contact name or functional designation, telephone information and electronic communication details as separate facts. Give each the intended role. A multiline note containing all of them is not a formal typed mapping.

Do not put a person’s name into a seller legal-name field merely because the current editor lacks a dedicated contact control. Seller identity and contact identity are different meanings, even when a sole business uses the same person in both roles.

Keep a working record of unsupported components for the final provider. The absence of a source field does not justify inventing a value or borrowing a buyer contact to complete a seller group.

Review accuracy and disclosure

Use authorised business contact details suited to invoice handling. Avoid unnecessary personal numbers, private addresses or internal commentary in the customer-facing document. An invoice may circulate beyond the immediate purchasing contact.

If the contact changes during preparation, obtain the updated instruction and revise affected values consistently. A copied draft can retain an earlier person’s details even after the seller name or buyer is changed.

The creator does not verify mailbox ownership, telephone availability or responsibility for the invoice. A correctly formatted email is not evidence that the contact is current or appropriate. Preserve the relevant confirmation externally.

Keep electronic addresses distinct

A structured electronic address can have a scheme and delivery-related role separate from a human contact email. Do not assume identical appearance means the same target field. The final mapper needs the intended definition and context.

Use the electronic-address preparation review when those requirements arise. Preserve both facts independently and record any confirmed relationship. A generic note saying use this email everywhere is not a verified mapping rule.

The creator’s German country context does not add contact-group validation or endpoint discovery. Its application field checks remain useful for supported inputs, but should not be described as complete XRechnung readiness.

Review the final implementation

Ask the provider which contact fields and conditions it implements under the required release and syntax. Inspect actual generated values and required validation evidence. A complete-looking preview is not proof that the typed contact group exists.

Use fictional contact data for a test, with seller contact and buyer billing address visibly different. Trace each into the target role. Include a missing required component case and confirm clear reporting rather than silent copying from another field.

Keep expected results, actual file and configuration together. A technical pass does not establish the real person’s authority or ongoing responsibility. Source-fact review and formal validation need separate evidence.

Complete the handoff

Give the provider confirmed contact components, source, target context and unresolved actions. Assign who obtains missing facts and who reviews the final file. Avoid leaving a required contact as an unspecified detail to fix after delivery.

After revisions, create and validate a fresh output in the appropriate final system. Earlier files retain old values. Keep the intended delivered version distinguishable from drafts and demonstration files.

The creator’s JSON, CSV and printable output support preparation within their scope. They do not guarantee XRechnung conformance, legal validity, successful contact or recipient acceptance. A precise contact record makes the remaining mapping work actionable without forcing unsupported facts into unrelated source fields.

For a fictional contact test, use separate seller invoice-contact and buyer billing-contact values. Include a contact designation and clearly labelled demonstration telephone information where the target requires it. Trace each component into the intended party context, then remove one required component in a separate negative case.

The final workflow should report the actual gap without borrowing the other party’s contact or replacing the seller’s formal name. Keep the source roles fixed while testing. This makes it possible to distinguish a missing field from a role reversal. Retain the generated file and report so the implemented behaviour can be reviewed without exposing a real person’s private details.