Your invoice was rejected by ANAF. What it means and what to fix
A rejection means the file reached ANAF but failed validation — so the invoice is NOT considered transmitted. It is not a fine and it does not fix itself: you correct the cause and upload a new file.
The rejection message has three parts. Only one of them tells you what to do.
How to read the ANAF message
The answer arrives in a form that looks alarming but is simple:
tipAssert — severity. E means error: it stops the transmission.
codEroare — the internal code of the broken rule. Useful only when calling ANAF.
textEroare — the plain-language explanation. This is the only part that tells you what to fix.
The most frequent causes, and what to fix
The Bucharest address is missing the sector
textEroare=... RO-B ... sector ...The Romanian e-invoicing specification requires Bucharest addresses to carry the city as "Sector 1"…"Sector 6", not "București". It is the single most common rejection for companies in the capital.
Fix: set the city to "Sector 3" (or whichever), on both your company details and the client's.
The buyer's tax ID is invalid
codEroare=ERRIdentif; textEroare=CUI cumparator incorectEither the code is mistyped, or the RO prefix is missing for a VAT-registered client, or it carries stray spaces. ANAF checks the control digit, so one wrong digit stops the invoice.
Fix: take the exact code from the public registry — you can check it free with our tax ID lookup.
The buyer's address is missing or incomplete
textEroare=... adresa cumparator ... obligatoriuAn electronic invoice is not complete without both parties' addresses — a requirement of the European standard behind e-invoicing, not an ANAF formality.
Fix: fill in the buyer's street, city and county.
The buyer's name is missing
textEroare=... denumire cumparator ... lipsaUsually seen on invoices imported from another program, where the name stayed in a column that was not mapped.
Fix: enter the client's exact registered name.
Totals or VAT do not add up
textEroare=... total ... nu corespunde ...The standard checks the arithmetic: line amounts must sum to the total, and VAT must follow from the line rates. The usual cause is rounding — a total typed rather than computed.
Fix: check the VAT rate on each line and let the total be computed.
What to do after fixing
- Fix it where the data lives, not on the invoice: otherwise the next invoice goes out with the same mistake.
- Generate the file again. The rejected one cannot be edited — ANAF expects a new transmission.
- Upload it again and watch the response. If the message held several problems and you fixed one, the second rejection shows the rest.
- Keep the receipt from the successful transmission. That is the proof the invoice arrived — not the email to the client.
Where this list comes from
From the causes our application recognises and translates into plain language when an invoice comes back from ANAF — built on real invoices, really rejected. The message shape in the examples is one measured on a rejected invoice, not invented for illustration.
It is not a complete list of every validation rule: the specification has hundreds, and most are never met in practice.
If your message is not on the list
Read textEroare and look for the field name inside it: "cumparator", "furnizor",
"linie", "total". The field tells you where to look, even when the rest is cryptic.
Want to stop reading these in raw form?
In Fivanto, a rejected invoice shows you what is wrong and where to fix it — in plain language, not codes. And most causes are caught before sending. The first 5 invoices a month are free, no card.
Try it free