How to Handle Supporting Documents in an XRechnung Workflow

Handle supporting documents according to the accepted XRechnung workflow and receiver instructions. A document reference, external link and embedded attachment are different representations. A filename in invoice notes is not the supporting file itself, and a valid invoice file does not establish that all portal constraints are satisfied.

The XRechnung preparation workflow assigns those requirements to implemented final software. The current creator has no formal attachment or XRechnung export capability. Preserve evidence requirements separately rather than implying they are completed by a readable note.

Confirm what evidence is needed

Ask the receiver which supporting material substantiates the charge and how it should be provided. An approved service summary may be sufficient where an internal timesheet contains unrelated information. Do not attach everything merely because it is available.

Record the actual purpose and authorised scope. Keep fuller internal evidence in the appropriate business records rather than exposing unnecessary details in the customer package. A technical attachment option does not decide disclosure suitability.

Use the accepted specification and route instructions to establish supported representations. A sample containing one attachment does not prove that every file type or evidence scenario is permitted.

Separate document and portal rules

KoSIT’s FAQ distinguishes specification questions from restrictions imposed by portal operators, including practical size constraints. Confirm the actual receiving service’s requirements rather than inventing one universal limit from a general format description.

Ask the final provider which attachment features it implements under the target release and syntax. Record known limits and how unsupported files are reported. A broad XRechnung support claim is not evidence of every evidence-packaging capability.

Do not assume a normal PDF containing arbitrary XML is an acceptable replacement for the requested processing document. Follow the actual target format and recipient instructions. Packaging and supporting-document roles need genuine implementation.

Review the complete evidence file

Inspect all relevant pages, sheets, comments and metadata where appropriate. A first-page view can hide internal prices, employee details or another customer’s information. Use the approved evidence version rather than an entire copied email chain.

Keep credentials, private tokens and unnecessary personal data out of attachments and external links. A file accompanying an invoice may circulate beyond the immediate contact. Local invoice creation does not control later sharing.

If an external link is used, review access and availability through the authorised process. A temporary browser link may not work for the recipient, while an access-bearing URL may disclose more permission than intended.

Keep references and contents consistent

The invoice should identify the intended evidence accurately. A correct filename pointing to an outdated report can still substantiate the wrong service period or quantity. Compare the file contents with the current invoice scope.

If lines or amounts change, revisit supporting evidence rather than regenerating only the main invoice. A prior attachment may survive unchanged while the charge is revised. Keep the intended final package clear.

Use the validation-report review to understand what the technical report covers. A successful XML check may not establish that a supporting file’s contents are relevant, authorised or factually correct.

Test with fictional evidence

Create a small fictional supporting document with no real customer or account information. Generate the intended target through the actual provider and inspect the reference or recovered attachment. Compare the contents with the source, not just whether the invoice mentions its name.

Include a missing-file or unsupported-type case where applicable. The workflow should report the issue clearly rather than silently omitting evidence while claiming a complete result. Keep exact inputs, configuration and expected outcomes.

If operational testing is required, use an authorised test route rather than uploading experimental files to a live recipient. Real evidence and production data need the appropriate handling decision.

Retain the delivered package

Keep the approved evidence version, generated invoice, required validation report and actual submission record together. These establish different things and should not be merged into one vague valid status.

After corrections, create a fresh package and repeat affected checks. Earlier downloads and reports retain their earlier contents and scope. Distinguish the intended delivered version from test files and superseded attempts.

The creator remains useful for supported invoice preparation, but it does not implement evidence attachment, formal validation or delivery. A reliable final workflow preserves the correct supporting relationship, protects unnecessary information and records the checks and operational events actually performed without guaranteeing legal validity or acceptance.

A useful evidence review record identifies the approved source file, its purpose, intended invoice relationship, authorised disclosure scope and actual final representation. Keep a copy of the recovered or delivered evidence where appropriate, rather than relying only on the main invoice’s filename list.

For a fictional package test, revise the service period on the invoice and check whether the supporting report still matches. A package can remain structurally valid while containing stale evidence. Then remove the required test file and confirm that the final workflow reports the problem clearly. This checks relationship and failure handling without exposing real employee, customer or payment information to an unfamiliar service.

Keep failures reproducible.