Why invoices get rejected

A rejection is not a fault. It is a message. The difference between a company that manages them and a company they manage is who reads the message, and when.

Most of what gets rejected has nothing to do with integration. It comes back to the data inventoried at station six — which is exactly why that station was written before this one.

First step: which layer

Station five separated three layers, and they are the entire diagnostic instrument.

Layer	The shape of the error	Who fixes it
Your system	A missing field or an invalid value	Finance or sales — whoever owns the data
Signing	An invalid stamp, an expired certificate	IT
The authority or provider	Connection failure, a service interruption	The provider — and it may not be your error

The first question on every rejection: which layer? Anyone not asking it sends everything to the vendor.

The six recurring causes

The cause	How it appears	The real fix
Missing or wrong tax number	Rejection at party validation	Clean customer data — not the invoice
An address not in the required form	A mandatory field empty	Fix entity or customer data
An unapproved unit or item code	A value outside the permitted list	A coding table in item data
Tax arithmetic that does not reconcile	The total does not equal the sum of the lines	Tax and rounding configuration, not an arithmetic slip
An expired signing certificate	A complete, sudden stoppage	A renewal calendar with an owner
A broken or duplicated sequence	Rejection or warning	Number sequence configuration

Row four deserves a pause, because it confuses people most: the invoice is accounting-correct and is rejected because your rounding differs from the expected rounding by one fils. The fix is a setting rather than a manual review. Treating it by correcting each invoice means correcting a million invoices instead of one setting.

Row five is the most dangerous because it does not degrade. One or two invoices are not rejected — all issuance stops in a single moment. Put every certificate’s expiry date in a shared calendar with a named owner and a sixty-day alert.

How the error is read

Rule: no error is fixed before its original text is read.

Which is why station seven made so much of the original error message. A message saying “transmission failed” turns every rejection into a two-hour investigation; a message naming the field turns it into a two-minute correction.

Three questions per rejection, in this order:

1. Which field exactly? Not “the invoice is wrong”.
2. Where does that field come from? Master data, a calculation, or a setting?
3. How many other invoices will fail for the same reason? That question is the difference between treating a case and treating a cause.

The daily watch

One report, every morning, with a named owner.

• How many documents were submitted yesterday, how many accepted, how many rejected.
• The oldest unresolved rejection — the real danger indicator.
• Any cause that recurred more than three times — that is structural rather than a one-off.

The second indicator is the one that saves you. A rejection a day old is an administrative problem. A rejection three weeks old is a collection problem, because the customer never received an invoice they could pay against.

Three numbers for management

The status report on this file is three numbers rather than three pages.

Indicator	How it is read	The threshold that demands action
First-attempt acceptance rate	Accepted ÷ submitted, weekly	Below 98%
Age of the oldest unresolved rejection	In days	Over 3 days
Most frequent rejection cause	The field name, and its count	More than 3 occurrences = structural

The first alone is not enough. A company at 99% acceptance with twenty rejected documents three weeks old has a collection problem rather than a quality problem — and the first number cannot see it.

The third is the real improvement indicator. In a healthy system the “most frequent cause” changes every month, because last month’s cause was fixed with a setting. Anybody seeing the same cause at the top for three consecutive months is treating cases rather than causes — and that is the exact phrasing to put to management.

The monthly reconciliation

The step that gets skipped and is paid for at the return.

The count and value of invoices in your books, against the count and value that actually reached the authority — monthly, before the return.

Any difference is explained in writing. Anybody who does not reconcile learns of the gap from the authority rather than finding it themselves, which is the difference between a correction and a penalty.

What you actually do in this station

• Build the daily report with the three indicators, and name its owner.
• Classify one real rejection by the three layers and the three questions.
• Aggregate a month of rejection causes and rank them by frequency — then fix the top one with a setting rather than a correction.
• Put certificate expiry dates in a shared calendar with a sixty-day alert.
• Run one monthly reconciliation and write the explanation of the difference.

The three commonest mistakes

One: handling rejections case by case. A hundred documents get corrected in a month while one cause could be fixed in an hour.

Two: ignoring the age of the oldest rejection. Documents pile up that never reached their customers, and the effect shows in collections rather than in a system report.

Three: skipping the monthly reconciliation. The gap is then discovered by the authority.

The acceptance test for this station

1. Name the three layers and who fixes each.
2. Name the six causes and the fix for each.
3. State the three questions put to every rejection.
4. Show the daily report and its owner.
5. Show one month’s reconciliation and the explanation of the difference.

What comes next

Operations have settled. The last station is about the year that follows: after the mandate — archiving, audit, and what changes once everything has become routine.