What to Do When a German Recipient Rejects an Invoice

When a German recipient rejects an invoice, retain the exact file and actual response before editing anything. Determine whether the problem concerns source data, document structure, business rules, routing or another receiving requirement. Repeatedly resubmitting guessed corrections can obscure the original cause and create conflicting versions.

The XRechnung preparation workflow keeps those stages distinct. The current creator has no submission or rejection-status integration. A local export result cannot tell you what the customer’s system received or why it refused a document.

Capture the actual event

Record the file version, submission route, time and available response or status reference. Keep the complete diagnostic material through your appropriate business process. A paraphrase such as XML failed may omit the rule or location needed for repair.

Confirm which document was sent. A folder can contain earlier drafts with similar names, and a corrected workspace does not update an existing download. Do not investigate the latest preview as though it proves the contents of an earlier submission.

Keep an upload acknowledgement separate from the later rejection or processing status. Those events can concern different checks. Assign who monitors the actual route and retains evidence rather than relying on the preparer’s local screen.

Confirm the receiver requirement

Compare the submitted format, profile, version and destination with the current instruction. A general German-format assumption is insufficient. Another public body or private customer may use a different route or required reference.

Check that the invoiced entity and routing values match the intended recipient. A structurally plausible identifier from an old sample can still be wrong. Resolve disputed source facts with the responsible party rather than inventing a replacement.

Do not assume a legal mandate explains every technical rejection. The actual error and receiving requirements need review. Use current official guidance and qualified advice for legal or tax questions outside this preparation process.

Classify the reported issue

A parse or schema failure concerns a different layer from a disallowed code, missing business fact or inconsistent total. A delivery problem may occur before the document’s contents are fully checked. Identify the layer before choosing a repair.

Use the validation-report review to interpret the available evidence. Keep configuration and file identity with the message. A previous local pass may have used another rule set or tested a different revision.

A technical pass also does not establish every factual input. Wrong buyer identity, unsupported treatment or an incorrect quantity can require source review even if the file is structurally valid.

Repair the source or implementation

Correct factual errors from confirmed records. Repair mapping or generation rules in the final provider’s implementation where possible. Do not delete legitimate data, change tax treatment or alter commercial quantities merely to make the report quieter.

If a required capability is absent, use suitable software rather than disguising the gap in notes. The creator does not provide XRechnung export, credit-note handling, formal validation or transmission. Its application JSON cannot be renamed into the requested document.

Keep a short change record showing the issue, source evidence, repair and expected result. This makes the resolution explainable and helps prevent the next invoice from repeating the same failure.

Regenerate and check again

Produce a fresh final file through the corrected workflow and run the required checks. An earlier report does not cover the repaired version. Review affected readable and supporting material too, especially where references or amounts changed.

Use fictional reproduction cases for technical troubleshooting where practical. Do not upload real customer information to an unfamiliar checker simply to compare results. Keep data handling appropriate to the separate external process.

Resubmit through the agreed authorised route only after the cause and correction are understood. Preserve the new submission evidence and actual receiver response. Do not report acceptance before the relevant operational evidence exists.

Retain a useful resolution record

Keep the original rejected version, diagnostic evidence, corrected output and result distinguishable under your record process. An issued-document correction can require more than silently replacing a draft; use the appropriate business workflow.

Record whether the repair concerned data, mapping, rules or delivery. A general note saying fixed cannot help a later colleague identify which requirement was missed. Concrete evidence supports future review without guaranteeing every later invoice will pass.

The creator remains useful for supported source preparation and arithmetic. Rejection handling, formal document correction and delivery need an implemented final workflow. The goal is a traceable resolution based on the actual failure, not an unsupported assurance that a newly downloaded file is automatically accepted.

For a rejection log, keep the original file, response, diagnosed layer, confirmed source evidence, repair owner and corrected version in separate entries. Do not overwrite the original record while investigating. If the issue was an old file being sent, changing valid source data would create a second problem rather than fix the first.

After resubmission, record the actual observed result and its scope. An acknowledgement should not be labelled final acceptance unless the receiving process establishes that status. This makes the resolution useful to a later colleague and prevents repeated attempts from becoming an untraceable collection of similar filenames.