Repairing a ZUGFeRD Invoice That Was Refused
The message rarely says more than 'invoice rejected'. Somewhere between you and your customer, a piece of software opened the XML inside your ZUGFeRD file, tested it against the EN 16931 rules, and threw the whole document out. Until the data is fixed, nobody books the invoice and nobody pays it. Upload the file above: the editor unpacks every field into a form, you correct what is broken, and a minute later you have a valid ZUGFeRD invoice to send again.
Where ZUGFeRD invoices get stuck
Germany has no central B2B invoicing portal, so the rejection usually happens at the receiving end: the buyer's accounts payable software, an invoice inbox service, or the DATEV import at their tax advisor. Each of these runs the official Schematron rules over the embedded XML and refuses files that fail. Public-sector invoices are stricter still: the federal platform (OZG-RE) and the state portals validate XRechnung submissions on upload and bounce them immediately with a list of rule violations.
Typical errors behind a rejection
Most refused ZUGFeRD files fail on one of a few recurring points:
- Tax totals that disagree: the 19% and 7% groups do not match the line amounts, or rounding was done in the wrong place
- No usable seller identification: the VAT ID (USt-IdNr.) and tax number are both absent
- An IBAN missing even though the payment means says credit transfer
- A missing Leitweg-ID on an invoice to a public authority
- Wrong or empty country codes in the addresses
- A profile mismatch: the XML declares one ZUGFeRD profile but carries the fields of another
Every one of these is a value in a field, and a field can be edited. There is no need to rebuild the invoice from a blank page or to chase the software that produced it.
Fix the file in the browser, keep the rest intact
Drop the refused invoice into the editor and it reads the CII XML out of the PDF/A-3 (a standalone XML file works too). The parties, dates, references, line items, tax rates, and payment data all land in an editable form. Change only what is wrong: whatever you leave alone, including embedded attachments, notes, and document-level charges, is written back into the regenerated file exactly as it arrived. The result is validated against EN 16931 before the download starts, so the same error cannot ride along twice.
When the broken invoice is one you received
Since the E-Rechnungspflicht took effect, every German business must be able to receive e-invoices, and sooner or later a supplier will send one your software cannot swallow. Repairing it here gets your bookkeeping unblocked: extract, correct, reimport. For the VAT record, ask the supplier for a corrected original as well; under German VAT law (Paragraph 14 UStG) the invoice document is theirs to fix, and the GoBD expects you to archive what you actually received.
Verify first, then resend
If you want to see the complete rule report before deciding what to change, validate the original file first. The validator names each violated rule and the field behind it, which makes the edit afterwards a two-minute job:
- Validate a ZUGFeRD invoice and read the rule report
- Validate an XRechnung file against the German CIUS rules
Editing has a limit: booked invoices need a Gutschrift
Correcting and resending is legitimate while the invoice is still in transit, meaning it was refused before anyone recorded it. An invoice that your customer has already accepted and posted must stay as it is; German practice corrects it with a credit note (kaufmaennische Gutschrift, type code 381) that references the original:
New to the format, or unsure which profile your customer expects? The guide covers the file structure, the profiles, and the mandate deadlines: