Fiecare factură trimisă în RO e-Factura este verificată de validatorul ANAF înainte de a ajunge la cumpărător. Dacă factura trece de validare, statusul devine ok și factura există legal. Dacă nu, primești nok și un mesaj de eroare, iar factura aceea nu a fost transmisă, chiar dacă în ERP este înregistrată corect și clientul a primit deja PDF-ul. Între timp, termenul de 5 zile lucrătoare pentru transmitere nu se oprește.
Problema este că mesajele ANAF sunt tehnice: coduri precum BR-CO-15 sau BR-RO-100, unele în română, altele în engleză, fiecare cu un identificator de câmp de tipul BT-112, greu de corelat cu factura la care se referă. Am adunat mai jos erorile care apar cel mai des în practică, cu explicații pentru fiecare tip de eroare: ce verifică de fapt ANAF, de unde vine problema în datele tale și cum o rezolvi. Mesajele sunt redate după documentația oficială și după fișierele de răspuns publicate de utilizatori, așa că textul poate varia ușor de la o versiune la alta a validatorului.
Cum citești răspunsul ANAF
Răspunsul la o factură respinsă are două tipuri de linii. Cele care încep cu F: sunt erori de structură: un element obligatoriu lipsește sau fișierul nu respectă schema XML. Cele care încep cu E: validari globale SCHEMATRON eroare sunt erori de conținut, adică reguli ale standardului pe care factura nu le respectă, identificate prin codul regulii între paranteze drepte. Regulile naționale, cu prefixul BR-RO, sunt scrise în română; regulile europene din standardul EN 16931, cu prefixe precum BR-CO sau BR-CL, sunt în engleză. Ordinea contează: validatorul se oprește la erorile de structură și nu mai verifică regulile de conținut, așa că după ce le corectezi pe primele pot apărea altele noi.
Pe lângă ok și nok mai există două stări. in prelucrare înseamnă că ANAF nu a terminat validarea, iar XML cu erori nepreluat de sistem înseamnă că fișierul a fost respins chiar la încărcare, înainte de validarea de conținut, de obicei pentru că nu este un XML corect sau nu respectă schema.
Cele mai frecvente erori RO e-Factura
1Totalurile și TVA-ul nu se închid
Este eroarea cea mai întâlnită și vine sub mai multe coduri: [BR-CO-10]-Sum of Invoice line net amount (BT-106), [BR-CO-15]-Invoice total amount with VAT (BT-112), [BR-CO-17]-VAT category tax amount (BT-117) sau, în română, Valoarea TVA pentru fiecare categorie de TVA (BT-117), urmată de cele două sume care nu se potrivesc. Tot aici intră și Numărul maxim permis de zecimale este 2.
ANAF verifică calculele din factură: totalul fără TVA trebuie să fie egal cu suma liniilor, totalul cu TVA trebuie să fie egal cu totalul fără TVA plus TVA-ul, iar TVA-ul pe fiecare cotă trebuie să fie egal cu baza înmulțită cu cota, rotunjit la două zecimale. Diferențele de ordinul banilor apar când ERP-ul rotunjește pe fiecare linie și apoi adună altfel, când o cotă de TVA lipsește din configurare sau când datele vin dintr-un Excel cu mai multe zecimale. Un discount înregistrat ca linie negativă în loc de reducere (AllowanceCharge) produce același efect.
Soluția este să calculezi totalurile din sumele deja rotunjite ale liniilor, să rotunjești TVA-ul pe fiecare cotă o singură dată și să nu trimiți niciodată mai mult de două zecimale.
2Sectorul din București și codul județului
Două reguli naționale generează frecvent erori la primele facturi transmise. [BR-RO-110] cere ca județul să fie codificat după standardul ISO 3166-2:RO, deci RO-B, RO-IF sau RO-CJ, nu „București”, „Ilfov” sau „Cluj” ca text. [BR-RO-100] cere ca, atunci când județul este RO-B, localitatea să fie unul dintre sectoare, SECTOR1 până la SECTOR6, nu „București”. Aceleași reguli se aplică și adresei de livrare, prin [BR-RO-200] și [BR-RO-210].
Cauza este aproape întotdeauna fișa partenerului din ERP, în care orașul este „București” și județul este scris în clar. Rezolvarea stă în datele de bază: mapezi județele pe codurile ISO și, pentru București, completezi sectorul în câmpul de localitate.
3Cumpărătorul nu are identificator
[BR-RO-120] spune că identificatorul de înregistrare legală al cumpărătorului (BT-47) sau identificatorul de TVA (BT-48) trebuie completat. O variantă a aceleiași probleme este verificarea proprie a ANAF, Nu a fost identificat cif-ul cumpărătorului, care apare când CUI-ul din factură nu există în registrul ANAF, de exemplu la o firmă abia înființată, sau când factura a fost trimisă pe canalul greșit.
Pentru cumpărătorii din România, CUI-ul se completează în BT-47 și, dacă sunt plătitori de TVA, codul cu prefixul RO se completează în BT-48. Pentru cumpărătorii din afara țării, fără cod de identificare românesc, factura se încarcă cu parametrul extern=DA. Pentru persoanele fizice, raportarea B2C are canalul ei propriu de încărcare, obligatoriu din 31 martie 2025, iar dacă cumpărătorul nu are niciun cod de identificare, în locul lui se trece un cod format din 13 cifre de zero. Înainte de emitere merită să verifici CUI-ul cumpărătorului, ca să identifici din timp codurile inexistente sau neînregistrate în scopuri de TVA.
4Nu aveți drept în SPV sau token-ul a expirat
Mesajul Nu aveti drept in SPV pentru CIF=... nu are legătură cu factura, ci cu autorizarea. Persoana al cărei certificat sau cont a fost folosit pentru conectare nu este înrolată în SPV pentru CUI-ul respectiv, sau CUI-ul din apel nu este cel al emitentului din XML. Apare de obicei imediat după înrolarea în SPV sau după reînnoirea certificatului digital, când sistemul ANAF poate avea nevoie de un interval de timp pentru a recunoaște certificatul nou. Doar persoanele fizice pot deține mandatul în SPV, așa că firma are nevoie de o persoană înrolată pentru fiecare CUI.
Înrudit este răspunsul Forbidden, primit fără niciun avertisment după luni de funcționare normală: token-ul de acces, adică cheia prin care aplicația ta se identifică la ANAF, a expirat. Token-ul se reîmprospătează automat pentru o perioadă, dar autorizarea de bază are o limită anuală, după care o persoană trebuie să reautorizeze aplicația în SPV, cu certificatul. Dacă nu o face nimeni, transmiterea se oprește fără nicio notificare. Ține evidența datei autorizării și reînnoiește-o înainte de termen.
5Unități de măsură, țări și monede din afara listelor
Factura electronică nu acceptă text liber acolo unde standardul are o listă de coduri. [BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 apare când unitatea de măsură este „buc”, „ore” sau „lună”; codurile corecte sunt C62 pentru bucată sau unitate, H87 pentru piesă, HUR pentru oră, MON pentru lună, DAY pentru zi, KGM, LTR și MTR pentru kilogram, litru și metru. [BR-CL-15] apare la codurile de țară care nu sunt ISO 3166-1, cel mai frecvent caz fiind Grecia: EL este valid doar ca prefix de TVA, ca țară se scrie GR. [BR-CL-03] apare la monede, de regulă „LEI” în loc de RON.
Rezolvarea este o mapare făcută o singură dată în ERP sau în exportul către e-Factura, de la unitățile și codurile interne la cele din standard.
6Adresa incompletă și câmpuri prea lungi
Trebuie furnizată adresa poştală. (BR-RO-080) și Localitatea trebuie furnizată. (BR-RO-090) apar când strada sau orașul lipsesc din fișa partenerului sau a propriei companii. Dacă elementul lipsește complet, eroarea vine la nivel de structură: elementul 'StreetName' ar fi trebuit sa apara de minimum 1 ori. Pe partea opusă sunt limitele de lungime din CIUS-RO: 20 de caractere pentru codul poștal, 50 pentru localitate, 100 pentru denumirea articolului, 150 pentru prima linie de adresă, 200 pentru numele părților și numărul facturii, 300 pentru note și termeni de plată. Descrierile lungi de produse din ERP depășesc cel mai des limita de 100 de caractere, iar atașamentele nu pot depăși 3 MB.
Verifică datele de bază înainte de export și trunchiază denumirile de articole la 100 de caractere, cu detaliile mutate în notă.
7Taxare inversă, scutiri și prefixul RO
Pentru fiecare categorie de TVA, standardul are reguli proprii. [BR-AE-10] cere ca, atunci când factura are linii cu taxare inversă, sumarul de TVA al acelei categorii să aibă un cod de motiv de scutire (BT-121) sau textul „Reverse charge”; [BR-E-10] cere același lucru pentru operațiunile scutite. [BR-O-11] spune că o factură cu operațiuni neimpozabile (categoria O) nu poate conține și alte categorii de TVA. Iar [BR-CO-09] cere ca identificatorul de TVA să aibă prefixul de țară: un plătitor de TVA care își trimite CUI-ul fără RO în câmpul de cod de TVA primește exact această eroare.
Regulile de urmat: o singură categorie de TVA pe linie, cod de motiv pentru categoriile AE, E, O și Z (pentru taxarea inversă intracomunitară, de exemplu, VATEX-EU-AE), iar prefixul RO doar pe codurile de TVA, niciodată pe identificatorul legal din BT-47.
8Antetul facturii: tip, număr, monedă, specificație
Câteva reguli nu verifică conținutul, ci elementele de identificare ale documentului. [BR-RO-001] cere ca identificatorul de specificație (BT-24) să fie exact urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1; orice altă versiune este respinsă. [BR-RO-020] acceptă doar tipurile de factură 380 (factură), 389 (autofactură), 384 (factură corectată), 381 (notă de creditare) și 751. [BR-RO-010] cere ca numărul facturii să conțină cel puțin o cifră. [BR-RO-030] cere ca, atunci când factura este în altă monedă, moneda de TVA să fie RON.
Tot aici intră și o confuzie frecventă: o notă de creditare validată ca factură obișnuită este respinsă la nivel de schemă, pentru că documentul începe cu elementul CreditNote, nu cu Invoice. La validare se folosește tipul FCN, iar la încărcare parametrul standard=CN.
9Factura trimisă de două ori
Nu este un mesaj de eroare, ci un efect al stării in prelucrare: validarea durează uneori câteva minute, un utilizator apasă din nou pe „Trimite”, iar la final ambele încărcări trec. Din ianuarie 2024, ANAF respinge a doua încărcare a unui fișier identic și înregistrează factura o singură dată, dar două fișiere aproape identice, de exemplu cu seria completată diferit, trec ca două documente distincte. Odată validată, factura nu mai poate fi ștearsă din SPV: dublura se rezolvă cu o stornare, nu cu un mesaj către ANAF.
Regula simplă este să nu retrimiți cât timp statusul este in prelucrare și să ai o evidență din care reiese, pentru fiecare factură, ce s-a trimis deja și cu ce rezultat.
10Fișierul nu mai poate fi descărcat
Fisierul nu mai poate fi descarcat pentru ca a trecut perioada de 60 de zile este mesajul pe care îl primești când cauți o factură mai veche în SPV. ANAF ține mesajele disponibile 60 de zile, iar lista de mesaje nu poate fi cerută pentru o perioadă mai veche de 60 de zile. După aceea, arhiva sigilată, adică XML-ul cu semnătura Ministerului Finanțelor, originalul legal al facturii, nu mai este servită; poate fi cerută punctual prin formularul de contact din SPV. Tot aici intră limitele API-ului: 1.000 de apeluri pe minut, 10 descărcări pe mesaj pe zi, 100 de interogări de stare pe mesaj pe zi, iar ignorarea lor repetată poate duce la blocarea accesului.
Concluzia practică este că facturile primite și cele trimise trebuie descărcate și arhivate pe măsură ce apar, nu în momentul în care devin necesare, iar interogările trebuie menținute în limitele permise.
Termenul de 5 zile lucrătoare și ce înseamnă, de fapt, un nok
De la 1 ianuarie 2026, factura se transmite în RO e-Factura în 5 zile lucrătoare de la data emiterii, dar nu mai târziu de 5 zile lucrătoare de la data-limită legală pentru emitere, adică a 15-a zi a lunii următoare. O factură cu statusul nok nu a fost transmisă: o corectezi și o retrimiți, cu același număr, în interiorul termenului. Dacă termenul este depășit, amenda pentru transmiterea cu întârziere este între 5.000 și 10.000 de lei pentru contribuabilii mari, între 2.500 și 5.000 de lei pentru cei mijlocii și între 1.000 și 2.500 de lei pentru ceilalți. Netransmiterea unei facturi B2B și înregistrarea în contabilitate a unei facturi primite în afara sistemului se sancționează cu 15% din valoarea facturii. În 2026 nu mai există nicio perioadă de grație. Am detaliat regimul sancțiunilor în articolul despre temerile antreprenorilor legate de RO e-Factura.
Cum corectezi o factură deja validată
O factură cu statusul ok nu mai poate fi modificată sau retrasă. Dacă ai descoperit o greșeală după validare, recomandarea ANAF din sesiunile sale de întrebări și răspunsuri este să stornezi factura inițială printr-un document de tip 380 cu valori negative și să emiți factura corectă ca tip 384, cu referință la factura inițială. Codul 381 rămâne valid după reguli, dar ANAF descurajează folosirea lui pentru corecții. Mesajele de tip răspuns (RASP) sunt rezervate cumpărătorului care contestă o factură, nu stornărilor.
Cum te ajută Latitude App
În modulul e-Factura din Latitude App, fiecare factură este validată înainte de plecare după același set de reguli pe care îl aplică ANAF, așa că erorile de mai sus le vezi în platformă, cu explicația lor, înainte să ajungă în SPV. Când ANAF respinge totuși o factură, respingerea rămâne atașată facturii, cu textul complet al erorii, în aceeași listă cu toate celelalte, iar erorile tehnice temporare ale ANAF se reîncearcă automat. Platforma verifică și dacă o factură a mai fost transmisă, pentru a evita dublurile, iar la emitere datele partenerului se completează automat de la ANAF, după CUI, ceea ce elimină o mare parte din erorile de adresă și de identificator.
Pentru fereastra de 60 de zile, Latitude App scanează SPV-ul continuu și stochează fiecare arhivă sigilată imediat ce apare, în ambele direcții, iar token-ul ANAF îl reîmprospătează singură atât cât permite ANAF și te avertizează cu mult înainte să fie nevoie de reautorizarea manuală. Dacă facturezi și în alte țări, aceleași facturi pleacă din aceeași platformă prin Peppol, SDI sau platformele agreate din Franța.
Poți testa cu propriile facturi: îți creezi un cont, conectezi SPV-ul pe mediul de test al ANAF și vezi răspunsul validatorului înainte de prima factură reală.
Întrebări frecvente
Ce înseamnă statusul nok în e-Factura?
Că ANAF a găsit cel puțin o eroare și factura nu a fost transmisă cumpărătorului. Mesajul de eroare este în răspunsul ANAF, cu codul regulii încălcate. Corectezi datele și retrimiți factura, cu același număr, în termenul de 5 zile lucrătoare.
De ce primesc erori în engleză și erori în română?
Pentru că regulile vin din două surse. Regulile europene din standardul EN 16931, cu coduri precum BR-CO-15 sau BR-CL-23, sunt scrise în engleză. Regulile naționale din CIUS-RO, cu prefixul BR-RO, sunt scrise în română. Validatorul le aplică pe toate, în ordine: mai întâi structura, apoi conținutul.
Cât timp pot descărca facturile din SPV?
60 de zile de la data mesajului, cu cel mult 10 descărcări pe mesaj pe zi. După aceea, fișierul nu mai este disponibil prin API sau în SPV și trebuie cerut punctual de la ANAF. Cel mai sigur este să descarci și să arhivezi facturile pe măsură ce apar.
Pot șterge o factură validată din greșeală?
Nu. O factură cu statusul ok nu mai poate fi ștearsă sau modificată. Se corectează prin stornare și, dacă este cazul, prin emiterea unei facturi corectate de tip 384, cu referință la cea inițială.
Ce amenzi se aplică în 2026?
Transmiterea cu întârziere se sancționează cu amenzi între 1.000 și 10.000 de lei, în funcție de categoria contribuabilului. Netransmiterea unei facturi B2B și înregistrarea unei facturi primite în afara sistemului se sancționează cu 15% din valoarea facturii. Perioadele de grație s-au încheiat.
Informațiile sunt valabile la data publicării, octombrie 2026.
Simplifică conformitatea fiscală cu Latitude App
Facturare, e-Factura, e-Transport, SAF-T, e-TVA, Declarații TVA, Verificare coduri TVA, Procure-to-Pay (P2P) și Raportare XML — toate într-o singură platformă cloud. Testează gratuit, fără obligații.
