La câteva facturi pe lună, o respingere în SPV se rezolvă în cinci minute: contabilul citește mesajul, corectează și retrimite. La câteva mii de facturi pe lună, aceeași respingere devine un proces paralel, cu o persoană care descarcă mesaje, le traduce pentru colegi și urmărește termenul fiecărei facturi.
Diferența nu ține de numărul de erori, ci de locul în care sunt reparate. O eroare reparată în fișierul XML revine la următoarea factură. O eroare reparată în ERP, acolo unde s-a născut, dispare definitiv.
Cum citiți un răspuns de la ANAF
Când ANAF respinge o factură, emitentul primește în SPV o arhivă cu un fișier XML care conține erorile identificate, semnat de Ministerul Finanțelor. Fiecare eroare are un cod, iar prefixul codului spune de unde vine regula:
- Erori de structură. Fișierul nu respectă schema: lipsește un element obligatoriu sau un nume de element este greșit. Mesajul arată de obicei calea până la element, de exemplu
AccountingCustomerParty → Party → PostalAddress → Country, urmată de elementul ‘IdentificationCode’ ar fi trebuit să apară de minimum 1 ori, dar apare efectiv de 0 ori. Aici, clientul nu are codul de țară completat. - BR-xx și BR-CO-xx. Reguli din standardul european EN 16931, comune tuturor țărilor. BR-CO sunt regulile de calcul: totaluri, sume de linii, TVA.
- BR-S-xx, BR-O-xx, BR-E-xx. Reguli pentru câte o categorie de TVA: cota standard, operațiuni neimpozabile, scutiri.
- BR-CL-xx. Liste de coduri: țări, monede, unități de măsură.
- BR-RO-xxx. Regulile specifice României, din specificația CIUS-RO: adrese, coduri de județ, lungimi maxime de câmp, formatul datelor.
Fiecare regulă face referire la un câmp din standard, notat BT (de exemplu BT-116, baza de calcul a TVA). Codul BT vă spune exact ce câmp să căutați în ERP.
Erorile care apar cel mai des și unde se repară
Mesajele de mai jos sunt redate așa cum apar în răspunsurile ANAF și în documentația furnizorilor de ERP. Coloana care contează este ultima: locul în care eroarea se oprește definitiv.
| Eroare | Ce înseamnă | Unde se repară |
|---|---|---|
| BR-CO-10 Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131) | Totalul net al facturii nu este egal cu suma liniilor. | În modul de calcul al totalului: din linii deja rotunjite, nu dintr-un subtotal separat. |
| BR-CO-17, BR-S-09 Valoarea TVA pentru fiecare categorie (BT-117) trebuie să fie egală cu baza (BT-116) multiplicată prin cotă (BT-119) | TVA-ul a fost calculat pe fiecare linie și apoi adunat, iar suma diferă cu câțiva bani de calculul pe categorie. | În regula de calcul a TVA din ERP. Este cea mai frecventă eroare la facturile cu multe linii. |
| BR-O-09 | La o operațiune neimpozabilă, valoarea TVA trebuie să fie zero. | În maparea cotelor și a categoriilor de TVA. |
| BR-61 | Plata prin transfer bancar fără IBAN-ul beneficiarului. | În fișa firmei sau în constantele de facturare: un cont bancar implicit. |
| BR-RO-100, BR-RO-101 | Pentru București, localitatea trebuie să fie SECTOR1 până la SECTOR6, nu „București” sau „Sector 1”. |
În nomenclatorul de parteneri, o singură dată pentru toți clienții din București. |
| BR-RO-110, BR-RO-111 | Județul trebuie scris cu codul ISO, de exemplu RO-CJ, nu „Cluj”. |
În nomenclatorul de parteneri, cu o listă de selecție în locul câmpului text. |
| BR-RO-210a | Adresa de livrare trebuie să includă județul (BT-79). | În adresele de livrare ale clienților, adesea completate separat de sediu. |
| BR-RO-081, BR-RO-082 | Lipsește strada din adresa vânzătorului sau a cumpărătorului. | În fișa partenerului. |
| BR-CL-15 | Codul de țară nu este în lista ISO 3166-1. | În nomenclatorul de țări, uneori la nivel de articol (țara de origine). |
| BR-RO-001 | Identificatorul specificației (BT-24) nu corespunde versiunii CIUS-RO în vigoare. | În generatorul XML, care trebuie actualizat odată cu specificația. |
| BR-RO-010 | Numărul facturii nu conține nicio cifră. | În seria de numerotare. |
| Unitate de măsură invalidă | Unitatea este scrisă liber („buc”, „kg.”) în loc de cod standard (H87, KGM). |
În nomenclatorul de unități, cu corespondența către codurile standard. |
Pe lângă acestea, CIUS-RO impune lungimi maxime pentru aproape fiecare câmp text: 100 de caractere pentru numele articolului, 200 pentru descriere, 300 pentru comentariul facturii. Un ERP care permite texte mai lungi va produce respingeri ocazionale, greu de anticipat, de fiecare dată când cineva scrie o descriere detaliată.
Respinsă sau validată: două situații, două proceduri
Confuzia dintre cele două stări produce cele mai multe facturi duble în SPV.
Factura respinsă nu a ajuns la client. Conform OUG 120/2021, ea nu se consideră transmisă în sistem. Se corectează și se transmite din nou, fără stornare, pentru că nu există nimic de stornat. În practică, se retrimite cu același număr și aceeași serie, iar ANAF îi atribuie un index de încărcare nou.
Factura validată a ajuns la client și nu mai poate fi modificată sau ștearsă. O greșeală descoperită după validare se corectează conform art. 330 din Codul fiscal: o factură de stornare, apoi factura corectă. În răspunsurile date la webinarul ANAF din 2024, stornarea se face pe codul 380, cu valori negative, iar reemiterea corectă pe codul 384. Retrimiterea aceleiași facturi „corectate”, fără stornare, nu este o corecție: produce un duplicat.
Termenul nu se oprește. Din 1 ianuarie 2026, facturile se transmit în cel mult 5 zile lucrătoare de la emitere. Cât timp o factură stă respinsă, ea nu este transmisă, iar zilele curg. O respingere descoperită în a patra zi lasă o singură zi pentru corectură, iar una descoperită după termen nu mai are ce salva.
De ce reparatul în XML nu funcționează la volum mare
Când respingerile se repară de mână, se întâmplă trei lucruri:
- Eroarea revine. Clientul din București are în continuare „București” în fișă. Următoarea factură către el va fi respinsă la fel.
- XML-ul și ERP-ul nu mai spun același lucru. Factura din SPV are o adresă, cea din ERP alta. La un control sau la declarația SAF-T, diferența trebuie explicată.
- Nimeni nu vede ansamblul. O persoană care repară douăzeci de facturi pe zi nu are timp să observe că paisprezece au aceeași cauză.
Fiecare dintre aceste probleme are aceeași rezolvare: eroarea se repară o singură dată, în locul din care provine.
Cum arată un flux care nu produce respingeri
La companiile care emit mii de facturi pe lună, respingerile se reduc spre zero prin patru mecanisme, niciunul complicat.
Validare înainte de trimitere
ANAF publică regulile de validare și pune la dispoziție un validator. Fiecare factură poate fi verificată automat înainte de a pleca, iar cele cu erori rămân în ERP, cu mesajul afișat utilizatorului care a emis-o. Eroarea este reparată de cine a introdus datele, în minutul în care le-a introdus, nu de contabil, a doua zi.
Date de bază curate
Majoritatea erorilor BR-RO sunt de fapt erori de nomenclator. O curățare unică a fișelor de parteneri, cu județe pe cod ISO, sectoare pentru București, străzi completate și țări pe cod standard, elimină o mare parte din respingeri. Pentru ca nomenclatorul să rămână curat, câmpurile text libere trebuie înlocuite cu liste de selecție, iar partenerii noi trebuie verificați la creare, inclusiv CUI-ul, în registrul ANAF.
Urmărirea automată a stării
După încărcare, ANAF întoarce un index. Starea facturii (în prelucrare, validată sau respinsă) se interoghează separat, iar API-ul are limite: conform documentului publicat de Ministerul Finanțelor, cel mult 100 de interogări de stare pe zi pentru același mesaj și cel mult 10 descărcări pe zi ale aceluiași răspuns. Ignorarea repetată a limitelor poate duce la blocarea accesului la API. Un sistem bine construit interoghează rar și eficient, nu în buclă, și marchează fiecare factură în ERP cu starea ei reală.
Reconciliere zilnică
În fiecare dimineață, lista facturilor emise în ERP se compară cu ce există validat în SPV. Rezultatul are trei categorii: validate, respinse și netransmise. Ultimele două primesc o alertă cu numărul de zile rămase până la termen. Așa, o respingere nu mai poate trece neobservată până la închiderea lunii.
Ce să faceți luna aceasta
Dacă respingerile sunt deja o problemă, nu începeți cu un proiect mare. Începeți cu datele pe care le aveți:
- Descărcați mesajele de eroare din ultimele trei luni și numărați-le după cod. De obicei, trei sau patru coduri acoperă cea mai mare parte a respingerilor.
- Reparați cauza celor mai frecvente în ERP: nomenclatorul de parteneri, regula de calcul a TVA, contul bancar implicit.
- Stabiliți cine vede respingerile și în cât timp. Dacă răspunsul este „contabilul, când are timp”, aici este riscul real, nu în codurile de eroare.
Dacă după acești pași respingerile continuă sau volumul face imposibilă urmărirea manuală, problema nu mai este de date, ci de integrare. Pe această parte lucrăm în proiectele de conformitate ANAF: e-Factura integrată direct în ERP-ul existent, cu validare înainte de trimitere, starea fiecărei facturi vizibilă în sistem și reconciliere zilnică.
Întrebări frecvente
O factură respinsă trebuie stornată?
Nu. O factură respinsă nu se consideră transmisă în sistem, deci nu există nimic de stornat. Se corectează și se retrimite.
Pot retrimite o factură validată după ce am corectat-o?
Nu. Factura validată nu se mai poate modifica. Corecția se face prin stornare și emiterea unei facturi noi, corecte. Retrimiterea produce un duplicat în SPV, nu o corecție.
Se oprește termenul de 5 zile cât timp factura este respinsă?
Nu. Factura respinsă nu este transmisă, iar obligația de a o transmite în termen rămâne. De aceea contează cât de repede este observată respingerea.
Cine trebuie să repare erorile, contabilitatea sau IT-ul?
Depinde de cauză. Erorile de date de bază, cum ar fi adresele, județele sau conturile, se repară de cei care întrețin nomenclatoarele. Erorile de calcul și de structură, cum ar fi BR-CO-10, BR-CO-17 sau BR-RO-001, se repară în ERP sau în generatorul XML, de către furnizorul sistemului sau de echipa IT. Contabilitatea ar trebui să vadă respingerile, nu să le repare una câte una.
ERP-ul nostru are deja modul de e-Factura. De ce mai avem respingeri?
Modulul transmite ce primește. Dacă datele de bază sunt incomplete sau calculul TVA nu respectă regula pe categorie, modulul va trimite corect o factură greșită. Respingerile persistente indică de obicei datele sau regulile de calcul, nu conexiunea cu ANAF.
Surse
- OUG 120/2021 privind administrarea, funcționarea și implementarea sistemului național privind factura electronică RO e-Factura, art. 4. Prezentare în Fiscalitatea.ro, 25 februarie 2025.
- ANAF, OUG 89/2025, care stabilește termenul de 5 zile lucrătoare de la 1 ianuarie 2026. Prezentare în Contabilul.ro.
- HotNews, ANAF: corecția unei facturi se face doar prin stornare, 21 august 2024.
- WinMentor, Erori posibile și cauze la e-Factura, rev. 1.3, 21 octombrie 2025.
- SPVGo, Erori validare XML e-Factura.
- Ministerul Finanțelor, Limite apeluri API e-Factura.