Factura a fost respinsă la ANAF. Ce înseamnă și ce corectezi
Your invoice was rejected by ANAF. What it means and what to fix
O respingere înseamnă că fișierul a ajuns la ANAF, dar nu a trecut validarea — deci factura NU e considerată transmisă. Nu e o amendă și nu se repară singură: corectezi cauza și încarci un fișier nou.
Mesajul de respingere are trei părți. Una singură îți spune ce să faci.
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.
Cum se citește mesajul de la ANAF
Răspunsul vine într-o formă care sperie, dar e simplă:
How to read the ANAF message
The answer arrives in a form that looks alarming but is simple:
tipAssert — cât de grav e. E înseamnă eroare: oprește transmiterea.
codEroare — codul intern al regulii încălcate. Folosește-l doar dacă suni la ANAF.
textEroare — explicația în română. Asta e singura parte care îți spune ce să corectezi. Citește-o pe ea, restul e context.
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.
Cele mai frecvente cauze, și ce corectezi la fiecare
The most frequent causes, and what to fix
Localitatea din București nu conține sectorulThe Bucharest address is missing the sector
textEroare=... RO-B ... sector ...Specificația românească a e-Facturii cere ca adresele din București să aibă localitatea scrisă ca „Sector 1"…„Sector 6", nu „București". E cea mai frecventă cauză de respingere pentru firmele din Capitală — și cea mai nedreaptă, fiindcă adresa e corectă în limba română, doar nu în forma cerută.
Corectezi: schimbi orașul în „Sector 3" (sau ce sector e), atât la datele firmei tale, cât și la cele ale clientului. Se aplică la amândouă adresele, nu doar la cumpărător.
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.
CUI-ul cumpărătorului este invalidThe buyer's tax ID is invalid
codEroare=ERRIdentif; textEroare=CUI cumparator incorectFie codul e scris greșit, fie lipsește prefixul RO la un client plătitor de TVA, fie are spații sau puncte în plus. ANAF verifică cifra de control, deci o singură cifră greșită oprește factura.
Corectezi: iei CUI-ul exact din registrul public. Îl poți verifica gratuit, fără cont, cu unealta de verificare CUI — care îți spune și dacă firma e plătitoare de TVA, deci dacă are nevoie de prefixul RO.
Either 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.
Adresa cumpărătorului lipsește sau e incompletăThe buyer's address is missing or incomplete
textEroare=... adresa cumparator ... obligatoriuO factură electronică nu e completă fără adresa părților. Nu e o formalitate a ANAF: e o cerință a standardului european pe care îl folosește e-Factura.
Corectezi: completezi strada, orașul și județul cumpărătorului. Dacă e din București, vezi prima cauză de mai sus.
An 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.
Numele cumpărătorului lipseșteThe buyer's name is missing
textEroare=... denumire cumparator ... lipsaApare mai ales la facturi importate din alt program sau dintr-un fișier, unde denumirea a rămas pe o coloană care nu s-a mapat.
Corectezi: completezi denumirea exactă a clientului, așa cum apare în registru — nu o prescurtare de-a ta.
Usually 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.
Totalurile sau TVA-ul nu corespundTotals or VAT do not add up
textEroare=... total ... nu corespunde ...Standardul verifică aritmetica: suma liniilor trebuie să dea totalul, iar TVA-ul trebuie să rezulte din cotele liniilor. Cauza obișnuită e rotunjirea — un total scris de mână, nu calculat — sau o linie cu altă cotă decât se aștepta.
Corectezi: verifici cotele de TVA pe fiecare linie și lași totalul să fie calculat, nu scris. Dacă factura vine dintr-un import, verifică întâi coloana de cotă.
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.
Ce faci după ce ai corectat
- Corectezi acolo unde stau datele, nu pe factură: dacă e sectorul sau CUI-ul, le repari la firmă sau la client, altfel următoarea factură pleacă cu aceeași greșeală.
- Generezi din nou fișierul. Cel respins nu se editează — ANAF așteaptă o transmitere nouă, cu un identificator nou.
- Îl încarci din nou și urmărești răspunsul. Dacă mesajul conținea mai multe probleme și ai reparat doar una, a doua respingere ți le arată pe celelalte.
- Păstrezi recipisa de la transmiterea reușită. Ea e dovada că factura a ajuns, nu e-mailul către client.
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.
De unde vine lista asta
Din cauzele pe care aplicația noastră le recunoaște și le traduce pe înțeles atunci când o factură se întoarce de la ANAF — construite pe facturi reale, respinse real. Forma mesajului din exemple e cea măsurată pe o factură respinsă, nu una inventată pentru ilustrație.
Nu e o listă completă a tuturor regulilor de validare: specificația are sute, iar cele mai multe nu se întâlnesc niciodată în practică. Sunt cele care chiar opresc facturi, la firme adevărate.
Dacă mesajul tău nu e în listă
Citește textEroare și caută în el numele câmpului: „cumparator", „furnizor",
„linie", „total". Câmpul îți spune unde să te uiți, chiar dacă restul mesajului e criptic. Dacă
tot nu se lămurește, codul din codEroare e ce trebuie să-i dai celui de la ANAF —
nu textul întreg.
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.
Vrei să nu mai vezi mesajele astea în forma brută?Want to stop reading these in raw form?
În Fivanto, o factură respinsă îți arată direct ce e greșit și unde se corectează — în română, nu în coduri. Iar cele mai multe cauze sunt prinse înainte de trimitere, la validare. Primele 5 facturi pe lună sunt gratuite, fără card. 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.
Încearcă gratuitTry it free