Why is an electronic invoice rejected?
- min read
- 7 min read
- Published
- Published
- Updated
- Updated
- Written for :
- Finance and order-management teams, IT project leads and integrators facing rejections they cannot interpret.
Short answer
Why is my electronic invoice being rejected?
An electronic invoice is rejected because the structured data accompanying it fails a check by the recipient or the platform, not because the document is unreadable. The most frequent causes are a mandatory field that is missing or wrongly formatted, a business rule not honoured (amount consistency, VAT, identifiers), content that does not match the profile the channel expects, or an incorrect recipient identifier. The PDF can be perfectly correct and the invoice still be refused.
The starting misunderstanding: what is validated is not the PDF
An electronic invoice in the strict sense is a set of structured data. The PDF, where one exists, is a representation for the human eye — in a Factur-X file it carries the XML, but it is not what validation looks at.
Every check therefore applies to the data: presence of fields, format, consistency between them, conformance to the channel profile. That is why a visually flawless invoice can be refused, and why fixing the layout never resolves a rejection.
The five most frequent causes, in order of frequency
- 01Mandatory field missing or wrongly formatted. An identifier, an order reference, a date, a country code: present but in a format the recipient does not accept, or absent although required for this transaction type.
- 02Business rule not honoured. The structure is valid but a check fails: line totals not matching the header, an unexpected VAT rate for the country/product pair, a missing required mention, non-conforming rounding.
- 03Wrong content profile. The document is valid XML but does not honour the profile the channel requires. Syntactic validity and profile conformance are two distinct checks, and one does not guarantee the other.
- 04Incorrect recipient identifier. The target company is not registered under the identifier used, or is registered under a different one. The symptom is misleading: sending appears to succeed and nothing arrives.
- 05Wrong data upstream. The flow works correctly; the data coming out of the ERP is what is wrong. Reworking the mapping would change nothing — the fix belongs upstream.
How to work out which one applies
- 01Retrieve the message actually transmitted, not the preview or the PDF. It is the only artefact the recipient evaluated.
- 02Read the response in full, including secondary codes: the headline reason is often generic and the useful detail sits lower down.
- 03Compare the message against the applicable specification or profile, field by field, on the rule cited.
- 04Check whether the same invoice passes on another channel. If it does, the cause is the profile or the recipient, not the business content.
- 05Trace back to the source data in the ERP. If it is already wrong there, the flow is not the problem.
What separates a one-off rejection from a systemic one
An isolated rejection on an atypical invoice is usually about the data: a customer with an incomplete identifier, a line with an unusual rate, a discount calculated outside the system.
A rejection affecting every invoice to one recipient, or appearing all at once on a specific date, almost always points to a specification or configuration change. Hunting through individual records at that point wastes a great deal of time.
The real cost of a rejection
A rejection does not only cost reprocessing time. It delays cash: until the invoice is accepted it is not treated as received, and the payment clock does not start.
A steady volume of rejections also has a lasting side effect: teams build manual workarounds to compensate, and those workarounds long outlive the fix to the original problem.