How to Keep XRechnung Creation Separate from Portal Submission

Creating an XRechnung and submitting it through a portal are different actions. Generation produces the document; validation checks it under a defined configuration; submission sends it through an authorised route; later responses describe what happened there. Evidence of one stage does not automatically establish the others.

The XRechnung preparation workflow assigns each responsibility explicitly. The current creator performs supported local preparation and exports, not formal XRechnung generation, government submission or recipient-status monitoring.

Confirm the route independently

Use the actual receiving organisation’s current instruction. Do not infer a portal from the customer’s country, a routing identifier’s shape or another supplier’s earlier experience. The accepted route can depend on the receiver and workflow.

Record who is authorised to submit and what access process applies. Keep service credentials and authentication information out of invoice notes and static source code. A text box cannot activate a missing integration.

If a provider handles transmission, ask what it supports and what evidence it returns. A general statement that invoices can be sent leaves questions about target format, recipient information and status handling unresolved.

Keep generation evidence separate

Retain the exact final file, exporter configuration and target specification. The creator’s application JSON or printed PDF is not an XRechnung simply because it can be selected in an upload dialog.

Use implemented final software that produces the accepted document. Preserve source facts and model gaps rather than renaming a file or hiding missing information in notes. A successful local download proves only that a local export occurred.

Review readable copies and supporting evidence where required. A separately generated page should not contradict the processing document. Keep the intended final package identifiable before submission.

Keep validation evidence separate

Run the required technical checks on the exact file intended for delivery. Record the syntax, specification and validation configuration. A report for an earlier revision cannot approve a file changed afterwards.

Technical success does not establish every business fact or tax decision. Retain the appropriate source and professional review alongside the validation result. A portal may also apply its own operational or receiving requirements.

Do not weaken required checks merely to reach an upload stage. Resolve the actual issue, repair the source or implementation and regenerate. A quieter report is not the same as a correct invoice.

Record the actual submission event

Identify the file sent, route, time and available acknowledgement or reference. Keep the response with the exact version. A file picker opening, local export or draft message is not evidence that the receiving system accepted an upload.

An upload acknowledgement can differ from later processing or business acceptance. Read the actual service’s status definitions and assign who monitors them. Do not summarise every intermediate success as final acceptance.

The creator has no integration to retrieve those events. If another provider performs them, preserve its actual evidence separately from the application preview or field-check result.

Handle corrections deliberately

If the route rejects the document, retain the original file and report before editing. Use the rejection investigation process to distinguish content, mapping, validation and delivery causes. Avoid repeated guessed resubmissions.

A corrected workspace does not update a file already uploaded. Generate a fresh output through the appropriate final system, validate it and follow the route’s required correction or resubmission process. Keep versions distinguishable.

An already issued invoice may need a business correction workflow beyond a draft edit. The current creator does not implement credit notes or a formal correction chain. Use suitable software and responsible review for the actual event.

Keep privacy and access appropriate

The current app’s local processing does not authorise sending customer contents to every external service. Use the agreed provider and appropriate data handling. Fictional files are better suited to unfamiliar integration tests.

Review attachments and external links as well as the visible invoice. The complete package can expose information not obvious on the first page. Keep credentials, unnecessary personal data and internal discussion outside the submitted document.

A useful status record has separate entries for prepared, generated, validated, sent and observed receiver result, each supported by its own evidence. It avoids turning a local file or one successful technical check into an unsupported claim of legal validity, authority approval or completed delivery.

A practical status sheet can identify the final file once, then record generation, validation, submission acknowledgement and observed receiver response as separate events. Include the responsible system or person and the evidence reference for each. Empty events should remain unresolved rather than inheriting success from the previous column.

For a fictional rehearsal, simulate a generated file that passes local validation but has no submission record. The correct status is not delivered. In a separate authorised route test, distinguish an upload acknowledgement from any later processing result. This exercise checks reporting discipline without sending experimental customer invoices. It also makes clear which operational integration is missing from the creator and which responsibilities belong to the separate final provider.

Retain the receipt reference with the exact file version used for submission.