Greșelile frecvente la e-Factura și cum le previi

Cele mai scumpe greșeli la e-Factura nu sunt cele care dau eroare. Sunt cele care trec.

O factură respinsă de ANAF îți spune imediat că ai o problemă. O factură pe care n-ai trimis-o niciodată, un token expirat săptămâna trecută sau un job de reconciliere oprit de două luni nu spun nimic — până la control.

Mai jos sunt greșelile pe care le vedem cel mai des, grupate după ce le declanșează. Fiecare are cauza reală și ce faci ca să n-o mai ai.

1. Confuzia dintre cele două amenzi

Cea mai răspândită neînțelegere din tot subiectul, și cea cu cel mai mare cost.

În OUG nr. 120/2021 sunt două contravenții distincte, cu sancțiuni complet diferite:

Diferența practică: întârzierea e o amendă fixă, plafonată. Absența e proporțională cu valoarea facturii și nu are plafon. La o factură de 300.000 lei, cele două nu sunt în aceeași categorie de risc.

A doua parte a primului rând e cea ignorată aproape universal: sancțiunea îl vizează și pe destinatar. Dacă înregistrezi în contabilitate o factură B2B primită prin email, în afara sistemului, fapta e a ta, nu doar a furnizorului.

Cum previi: blochează în sistemul propriu înregistrarea unei facturi B2B care nu are corespondent în e-Factura. Nu e o verificare pe care o faci lunar — e o regulă la intrare.

2. Termenul calculat după regula veche

Din ianuarie 2026, termenul-limită de transmitere e de 5 zile lucrătoare de la data emiterii facturii, dar nu mai târziu de 5 zile lucrătoare de la data-limită legală pentru emitere. Înainte erau 5 zile calendaristice.

Schimbarea pare în favoarea ta, și e — dar produce două greșeli:

• Proceduri interne rămase la calculul vechi, care acum trimit mai devreme decât e necesar. Inofensiv.
• Proceduri „actualizate" care numără greșit zilele lucrătoare, ignorând sărbătorile legale. Aici se pierde termenul.

Cum previi: nu calcula termenul deloc. Trimite la 1–2 zile de la emitere, automat. Fereastra legală e o marjă de siguranță pentru cazurile în care ceva se strică, nu o țintă de atins.

3. Cote de TVA rămase la valorile vechi

De la 1 august 2025, cota standard e 21% (era 19%), iar cotele reduse de 5% și 9% au fost înlocuite cu o singură cotă redusă de 11%, prin Legea nr. 141/2025.

O cotă veche într-o factură nouă nu e o eroare de rotunjire. Categoriile de TVA din RO_CIUS sunt validate, iar o combinație inconsistentă între cotă, categorie și totaluri produce respingere.

Cum previi: cotele se țin în nomenclator, cu valabilitate în timp, nu hardcodate în șabloane sau în cod. Dacă ai facturi de corectat din perioade cu cote diferite, storno-ul trebuie să folosească cota de la data facturii originale, nu cea curentă.

4. XML generat cu artefacte de validare depășite

Specificațiile RO_CIUS sunt versionate. Ministerul Finanțelor publică arhive de validare Schematron cu numere de versiune și date de la care devin aplicabile — versiunea 1.0.9, de exemplu, e valabilă începând cu 5 iunie 2024, iar modificările față de precedenta sunt documentate separat.

Greșeala tipică nu e să folosești o versiune veche la generare. E să validezi local cu o versiune veche și să te miri de ce ANAF respinge un fișier care „trece la tine".

Cum previi: artefactele de validare sunt o dependență cu versiune, tratată ca oricare alta. Când apare o versiune nouă, o actualizezi și rulezi setul de facturi de test înainte s-o pui în producție. Structura fișierului și ce verifică fiecare regulă sunt explicate pe larg în ghidul RO_CIUS și UBL 2.1.

5. Facturile B2C trimise pe endpoint-ul greșit

Raportarea B2C are un URL separat — /uploadb2c, nu /upload — obligatoriu de la 31 martie 2025.

Nu e un parametru pe apelul normal. E alt endpoint. O integrare scrisă înainte de martie 2025 și nemodificată de atunci trimite facturile către persoane fizice pe ruta greșită.

Cum previi: ruta se alege din tipul relației, în cod, nu din configurare. Și verifici în raportul zilnic că numărul de facturi B2C trimise se potrivește cu numărul de facturi B2C emise.

6. Blocarea vânzării când clientul nu dă CNP-ul

Situația e prevăzută explicit în legislație: dacă beneficiarul persoană fizică nu se identifică prin niciun cod de identificare fiscală, se folosește un identificator format din 13 cifre de zero în locul codului beneficiarului. Soluția e disponibilă în producție din 16 decembrie 2024.

Două greșeli simetrice, ambele scumpe:

• Faci CNP-ul obligatoriu la checkout „ca să poți emite factura". Pierzi conversii pentru o cerință care nu există legal.
• Nu-l ceri, dar nici nu tratezi cazul. Factura rămâne blocată în coadă.

Cum previi: CNP opțional în formular, cod de 13 zerouri ca valoare implicită în generator. Un caz de test dedicat, rulat la fiecare release.

7. Polling naiv, care îți epuizează cota

Aici greșeala nu e de conformitate, ci de arhitectură — dar consecința e tot o factură fără recipisă.

Limitele de apel publicate de Ministerul Finanțelor nu sunt toate globale. Două sunt per mesaj: maximum 100 de interogări de stare pentru un anumit mesaj pe zi și maximum 10 descărcări pentru un anumit mesaj pe zi. Limita generală e de 1.000 de apeluri pe minut, iar depășirea returnează 429 Too Many Requests.

Un retry care întreabă starea la fiecare 30 de secunde consumă cele 100 de interogări zilnice pentru acea factură în mai puțin de o oră.

Partea serioasă vine din nota oficială: ignorarea repetată a mesajelor de depășire poate duce la blocarea accesului la API pentru utilizator și, în cazurile grave, la blocarea aplicației. Nu e o încetinire temporară.

Cum previi: nu interoga per factură. Cere periodic lista de mesaje și potrivește răspunsurile după identificatorul de încărcare. Detaliile despre cum arată fluxul ăsta la mii de facturi pe lună sunt în articolul despre automatizarea e-Facturii la volum.

8. Retrimiterea unei facturi deja acceptate

Job-ul de upload cade după ce ANAF a primit fișierul, dar înainte să apuci să salvezi indexul de încărcare. Retry-ul trimite factura a doua oară.

Rezultatul e o factură duplicată în sistemul național. Nu se șterge. Se corectează prin stornare — cu tot ce înseamnă asta în contabilitate și în relația cu clientul.

Cum previi: cheie de idempotență pe numărul facturii, verificată înainte de fiecare trimitere, și persistarea indexului de încărcare în aceeași tranzacție cu marcarea stării. Nu în două operațiuni consecutive.

9. „Corectarea" unei facturi transmise

O factură ajunsă în sistem nu se mai modifică. Nici în SPV, nici prin retrimitere cu aceleași date.

Corecția se face prin notă de creditare, transmisă ca document separat, urmată de reemitere. Sistemele care permit editarea unei facturi deja transmise creează o divergență între ce ai tu în bază și ce are ANAF — care se descoperă la prima reconciliere serioasă, de obicei într-un control.

Cum previi: blochează editarea în interfață după ce factura a primit recipisă. Nu prin convenție internă — prin cod.

10. Emiți, dar nu citești

Jumătate din integrări tratează e-Factura ca pe un canal de ieșire. Este bidirecțional.

Facturile emise de furnizorii tăi ajung la tine prin același sistem. Dacă nu le descarci și nu le reconciliezi, două lucruri se strică: nu știi ce ai de plătit și, mai grav, poți înregistra o factură primită prin alt canal — exact fapta sancționată cu 15% din valoare, de la punctul 1.

Un detaliu tehnic care mușcă: interogarea listei de mesaje acceptă o fereastră de maximum 60 de zile. Dacă job-ul de reconciliere e oprit mai mult, mesajele mai vechi ies din fereastră.

Cum previi: reconcilierea e un job monitorizat, cu alertă dacă nu rulează. Nu un cron pe care îl vezi când te uiți.

11. Token-ul care expiră tăcut

Token-ul de acces OAuth2 e valabil 90 de zile, cel de refresh 365. O integrare fără reînnoire automată funcționează perfect trei luni și apoi se oprește complet, fără să dea eroare vizibilă cuiva.

Tiparul e mereu același: integrarea intră în producție, merge impecabil, echipa uită de ea, iar la trei luni nimeni nu se mai uită la log-uri.

Cum previi: refresh programat înainte de expirare, plus alertă separată pe „refresh eșuat". Și o alertă pe „zero facturi trimise azi", care prinde orice mod de oprire, nu doar ăsta.

12. SPV tratat ca arhivă

Ai obligația de arhivare a facturilor. SPV nu ți-o îndeplinește.

Fișierele XML semnate, cu semnătura electronică a Ministerului Finanțelor, trebuie păstrate de tine. Dacă singura copie stă în SPV, nu ai o arhivă — ai o dependență de disponibilitatea unui sistem pe care nu-l controlezi.

Cum previi: descarci arhiva imediat după ce factura primește starea ok, o stochezi cu index interogabil și testezi restaurarea. O arhivă din care n-ai scos niciodată nimic e o presupunere, nu o arhivă.

Tiparul din spatele tuturor

Uită-te la lista de mai sus și vei observa că foarte puține sunt greșeli de conformitate. Sunt greșeli de sistem.

Termenul, cotele, endpoint-urile, cazul fără CNP — toate sunt reguli scrise undeva, pe care le poți citi o dată. Ce se strică e infrastructura din jur: retry-uri fără idempotență, job-uri nemonitorizate, token-uri fără reînnoire, arhive care există doar pe hârtie.

De asta „am rezolvat cu e-Factura" e o afirmație care expiră. Fluxul e viu: legislația se mișcă, artefactele de validare se versionează, token-urile expiră. Un sistem care nu are monitorizare nu e conform — e doar netestat.

Dacă vrei imaginea completă a ce presupune fluxul, de la format până la arhitectură, ghidul de integrare ERP cu e-Factura și ANAF acoperă partea de fundație, iar pagina despre integrarea directă cu API-ul ANAF arată ce intră concret într-o implementare. Pentru pașii manuali în SPV, când încă nu ai automatizare, e ghidul de înregistrare și transmitere.

Noi construim fluxul ăsta ca parte din sistemele ERP la comandă — cu validare locală, reconciliere monitorizată și arhivare la tine. Dacă vrei să vezi cum se așază într-un buget, estimarea de cost pentru un ERP pornește de la module și volume, nu de la o listă fixă.

Întrebări frecvente

Dacă am întârziat o factură, mai are rost s-o trimit?

Da. Amenda pentru întârziere e fixă și plafonată; cea pentru netransmitere e 15% din valoarea facturii, fără plafon. Diferența dintre ele e, de regulă, mult mai mare decât diferența dintre a trimite târziu și a nu trimite deloc.

Cum aflu dacă o factură primită a trecut prin sistem?

O verifici în lista de mesaje pentru CUI-ul tău, filtrată pe facturi primite. Dacă o factură B2B din contabilitate nu are corespondent acolo, ai o problemă de rezolvat înainte de următorul control.

Cine răspunde dacă integratorul a greșit maparea?

Răspunderea fiscală rămâne a contribuabilului. Un contract de mentenanță poate acoperi corectarea, dar amenda se aplică firmei. De asta merită ca datele de test să includă cazurile urâte din istoricul tău real, nu exemple curate.

Cât de des ar trebui să verific reconcilierea?

Automat, zilnic, cu alertă la abatere. Manual, cu ocazia închiderii lunare. Un raport cu facturile fără recipisă mai vechi de 48 de ore prinde aproape tot ce se poate strica.

Erorile de validare sunt aceleași pentru toată lumea?

Regulile sunt comune, dar erorile pe care le vezi tu depind de nomenclatoarele tale. Cele mai frecvente vin din unități de măsură nemapate, categorii de TVA inconsistente cu cota și date de identificare ale partenerilor incomplete.