Lesson 5 — The E-Invoicing Status report, and the column that must not be merged
This is the screen you will actually live in, and the reason it is built the way it is happens to be the sharpest design decision in the module.
Open it at Accounting → Reporting → E-Invoicing Status. It answers three questions on one screen: how did each month go, what is stuck, and why are things being rejected. Take them in that order.
Per month, four figures: in scope, reported, in flight, not reported. The definition that carries all the weight is the second one. "Reported" means the FTA cleared it — not that you sent it, not that your provider took it. Documents handed to the ASP with no result yet are counted as in flight, in a column of their own, because this module is corner 1 of a five-corner model and does not know the outcome until the ASP says so.
A single percentage that swallowed the in-flight column would climb during an ASP outage — exactly when it should fall. That sentence deserves numbers, so here is a month of 400 in-scope documents, first in a normal month, then in the month your provider had a two-day outage that fell across the month-end billing run, when most of a month's invoices are issued.
| Figure | A normal month | The month of a two-day ASP outage |
|---|---|---|
| In scope | 400 | 400 |
| Reported — the FTA cleared it | 384 | 260 |
| In flight — handed over, no result yet | 8 | 136 |
| Not reported | 8 | 4 |
| The honest percentage: reported ÷ in scope | 96% | 65% |
| If in flight were counted as reported | 98% | 99% |
Look at the last two rows together. The honest figure falls from 96% to 65%, which is the truth: in the outage month you can evidence FTA clearance for 260 documents out of 400. The merged figure rises, from 98% to 99%, and it rises for a reason more uncomfortable than a rounding artefact. An outage suppresses bad news along with good. No results arrive at all, so the rejections that would normally have landed in not reported are sitting in in flight too — that is why not reported falls from 8 to 4. A metric that absorbs in-flight documents therefore looks its best exactly when it knows the least, and it would have reported a green 99% in the worst month of your year.
The second panel is the retry queue: what is waiting, how long it has waited, and in red, what has stopped being retried. That colour is doing real work. A document nothing is attempting any more looks identical to one still in the queue unless something says so — same status, same age, same row — and the difference between them is whether the system is working on it or waiting for you.
The third panel is rejection reasons, grouped by cause and ordered by frequency. The ordering is the insight: forty rejections with one cause is a configuration problem you can fix this afternoon, while forty rejections with thirty-nine causes is a data-quality programme. The panel tells you which one you have before you open a single document. Export the whole report to XLSX with the button; the sheet follows the dates on screen, so set the period first and export second.
Now the incident, because everything above only matters at speed. Tuesday 8 December, 09:00. A project billing run posts 96 invoices; all 96 generate, validate and queue, and the dispatcher takes them. By 09:20 the retry queue shows 96 documents waiting, 0 stopped. The question that decides your whole morning is whether this is the transport or the documents — and you can answer it from this one screen.
| Signal | Transport failure — the ASP | Data problem — the documents |
|---|---|---|
| Which documents | Everything queued in the window, regardless of customer | A subset with something in common: one customer, one product, one tax treatment |
| Where they sit | Retry queue, waiting, ages rising together | Rejected / Failed, each with a reason |
| Rejection reasons panel | Empty or unchanged — no results are arriving at all | One cause at the top, count rising |
| In flight column | Rising sharply | Roughly normal |
| Reported column | Flat since the incident began | Still rising |
| What fixes it | Nothing inside Odoone; the provider restores service and the ladder drains it | A configuration or data change, then Retry |
| The mistake to avoid | Pressing Retry, which resets counters and changes nothing | Pressing Retry before fixing the cause |
How that Tuesday actually resolves. All 96 are queued, no rejection reasons are arriving, and reported has been flat since 09:00 — that is the transport, and there is nothing to do in Odoone but tell the business that invoices are late, not lost. On the ladder from Lesson 3 the batch exhausts its attempts at 16:45 and turns red as stopped. The provider confirms service at 18:10. You press Retry, the counters reset, and 84 documents leave the queue within the hour. The remaining 12 land in Rejected / Failed under a single cause — a customer address the access point would not accept, on invoices that had passed your own checks because someone archived that mandatory-field rule — which was always a data problem hiding behind a transport problem. You restore the rule, fix 12 contacts, press Retry on those 12, and the month closes at 96 of 96.
One practical constraint to plan around: the guide documents Retry as a button on the invoice's UAE E-Invoicing tab and on the document, and does not describe a bulk retry. Do not design an incident response that assumes one exists — that is a good reason to keep billing runs to a size a person can work through, and a better reason to fix causes rather than re-pressing buttons.
A healthy report, in four lines: in flight is small and ageing in hours rather than days; the red stopped count is zero; rejection reasons is a long tail with no single dominant cause; and reported plus in flight plus not reported reconciles to in scope, with reported being the only number you quote to anyone. The daily check is those four lines and takes five minutes.
The failure mode is not technical at all — it is the sentence "we're at 99% compliant" in a board pack, computed by someone who added two columns together because it looked more sensible. If you are asked for one number, give the honest percentage and the in-flight count beside it. Two figures, one of which is an admission that you do not yet know, beat one figure that cannot fall when things go wrong.
The idea to carry forward: in flight is not a rounding error. It is the difference between knowing and hoping, and it is the only column that tells the truth during an outage.