Collect routing information directly from the responsible public recipient or its confirmed billing instructions. Record each identifier’s value, role and source, together with the intended delivery route. A familiar department name, address or earlier invoice does not establish the correct destination for the current document.
The XRechnung preparation workflow keeps routing separate from invoice content and transmission. The current creator does not discover endpoints, verify authority identifiers or submit to government systems.
Identify the responsible receiving unit
Confirm the invoiced organisation and the unit or system handling its invoices. A purchasing contact can help establish the supply without knowing every technical instruction. Obtain clarification from the responsible receiver where necessary.
Keep the accepted buyer identity and routing instruction connected. A shared office address does not prove that two public bodies use the same identifier or route. Do not substitute an instruction from a nearby authority because it looks similar.
Record the source document or contact and confirmation date. If instructions change, preserve which version applies to the current invoice. A reproducible record is more useful than a value remembered from an earlier conversation.
Collect each identifier with its role
Where supplied, preserve the Leitweg-ID as the recipient directs. Keep buyer reference, purchase order, contract and technical electronic address distinct. Similar character strings do not make their roles equivalent.
Do not infer an endpoint scheme or fabricate a missing identifier from a business name. The final provider needs the actual value and required context. A structural check cannot establish ownership or suitability for this receiver.
Use the electronic-address review when the route involves technical endpoints. A billing email address, in-document reference and delivery identifier are separate facts even if the same organisation manages them.
Confirm the accepted document
Record the required production specification, syntax and version alongside the route. Correct destination information cannot make an unsupported document format acceptable. Conversely, a valid file cannot reach the right receiver through an unimplemented route.
Ask about conditional references or source fields relevant to the transaction. A short sample may not expose the requirements for your supply, supporting evidence or payment arrangement. Preserve gaps before selecting final software.
The creator’s German country context does not implement those requirements. Its limited references and application-owned exports need a separate confirmed handoff where formal XRechnung is required.
Confirm the submission process
Identify which authorised portal, provider or other route the recipient expects. Record who has responsibility for submission and monitoring the result. Do not infer the route from an identifier’s appearance alone.
Keep access and credentials out of invoice notes and static code. A separate service’s registration or authentication process must be handled through its authorised mechanism. The creator has no submission integration that can be activated by pasting a password into a field.
Record what evidence the route returns and what each status means. A file download, upload acknowledgement and recipient processing result are different events. Avoid a single unqualified submitted label for the whole workflow.
Review consistency before handoff
Compare the party identity, routing value, required references and route with their confirmed sources. Check for conflicting instructions from an old order attachment or copied draft. Resolve the discrepancy rather than combining incompatible values.
A practical working sheet can list fact, intended role, source, current status and responsible owner. Mark missing values explicitly. This helps the final provider distinguish a source-data gap from an adapter or validation failure.
Do not assume a value is verified because the preview displays it clearly. The creator preserves entered strings, not independent confirmation. Keep the authorisation and technical evidence separate.
Test without risking live misdelivery
Use fictional data for mapping tests and an authorised test environment for operational checks where appropriate. Inspect actual target roles and required validation results. Deliberately incorrect routing values should not be sent to live recipients as a casual experiment.
After a legitimate correction, generate and validate the final file again. Keep the exact version and delivery evidence identifiable. An earlier successful invoice does not establish that a later receiver instruction is unchanged.
The useful outcome is a confirmed routing record with assigned final actions. It does not establish legal validity, tax correctness or acceptance. The current creator can support source preparation, while verified mapping, authorised submission and status handling need an implemented final workflow.
A routing collection sheet can list receiving entity, responsible unit, in-document reference, technical address, scheme where required, route and confirmation source. Each cell has a different purpose. Do not fill an unknown value by copying another merely because both are called identifiers in informal correspondence.
For a fictional test, give the billing email, routing reference and endpoint different values and trace all three. Then remove one required component and check the final workflow’s response. The expected result should identify the missing fact rather than silently borrowing an unrelated value. Keep operational tests separate from generation tests so an intentionally invalid mapping file cannot be mistaken for a production submission.
Keep current production recipient confirmation separate from fictional mapping-test evidence.