Integrare ERP cu e-Factura și ANAF: ce trebuie să știi

Fiecare factură pe care o emite ERP-ul tău trebuie acum să ajungă în SPV, validată de ANAF, în maximum 5 zile lucrătoare de la emitere. Nu mai e o opțiune și nu mai e doar pentru facturile către instituții publice: e-Factura acoperă B2B din iulie 2024 și B2C din 2025. Dacă sistemul tău încă scoate doar un PDF și un email, ești în afara legii la fiecare tranzacție.

Integrarea cu e-Factura nu e „un buton în plus". Înseamnă un flux întreg: generezi un XML structurat într-un format anume, te autentifici la API-ul ANAF cu certificat digital, încarci factura, aștepți validarea, descarci confirmarea semnată și o arhivezi zece ani. Plus partea pe care mulți o uită: primești și facturile furnizorilor prin același sistem.

Articolul ăsta îți arată ce trebuie să acopere integrarea, ce e obligatoriu acum în 2026, cele trei moduri de a o construi și capcanele care te costă amenzi sau TVA nedeductibil.

Ce înseamnă, concret, „e-Factura" pentru un ERP

e-Factura nu e un PDF trimis prin email. E un fișier XML structurat, citibil de mașină, în format RO_CIUS — adaptarea românească a standardului european EN 16931, peste sintaxa UBL 2.1. ANAF îl validează automat: ori trece, ori primești o listă de erori.

Pentru ERP-ul tău, asta mută granița responsabilității. Nu mai e destul să calculezi corect totalurile și să randezi un document. Trebuie să mapezi modelul tău intern — parteneri, produse, cote de TVA, unități de măsură — în câmpurile exacte pe care le cere schema RO_CIUS. Un CUI într-un format greșit, o categorie de TVA care nu există în nomenclator, o dată de emitere în viitor: toate se întorc ca respingere.

Dacă te întrebi de la ce nivel de complexitate ai nevoie de un sistem ERP propriu-zis ca să gestionezi asta, răspunsul scurt e: din momentul în care volumul de facturi depășește ce poți trimite manual în SPV fără să ratezi termenul.

Un fragment minimal de RO_CIUS arată cam așa (simplificat):

1<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
2  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1</cbc:CustomizationID>
3  <cbc:ID>FACT-2026-00187</cbc:ID>
4  <cbc:IssueDate>2026-06-19</cbc:IssueDate>
5  <cbc:DocumentCurrencyCode>RON</cbc:DocumentCurrencyCode>
6  <cac:AccountingSupplierParty><!-- CUI furnizor --></cac:AccountingSupplierParty>
7  <cac:AccountingCustomerParty><!-- CUI client --></cac:AccountingCustomerParty>
8  <cac:TaxTotal>
9    <cbc:TaxAmount currencyID="RON">210.00</cbc:TaxAmount>
10  </cac:TaxTotal>
11  <!-- linii, categorii TVA, totaluri -->
12</Invoice>

1<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
2  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1</cbc:CustomizationID>
3  <cbc:ID>FACT-2026-00187</cbc:ID>
4  <cbc:IssueDate>2026-06-19</cbc:IssueDate>
5  <cbc:DocumentCurrencyCode>RON</cbc:DocumentCurrencyCode>
6  <cac:AccountingSupplierParty><!-- CUI furnizor --></cac:AccountingSupplierParty>
7  <cac:AccountingCustomerParty><!-- CUI client --></cac:AccountingCustomerParty>
8  <cac:TaxTotal>
9    <cbc:TaxAmount currencyID="RON">210.00</cbc:TaxAmount>
10  </cac:TaxTotal>
11  <!-- linii, categorii TVA, totaluri -->
12</Invoice>

Dacă vrei să înțelegi fiecare câmp din acest XML — de ce arată exact așa, ce e CustomizationID-ul și ce verifică Schematron pas cu pas — ghidul dedicat structurii RO_CIUS intră în profunzime pe format, dincolo de mandat și integrare.

Ce e obligatoriu acum (2026) — și pentru cine

Regulile s-au mișcat mult, așa că hai să fixăm starea curentă.

• B2B: obligatoriu din 1 iulie 2024. Orice factură între firme, pentru operațiuni cu locul în România, merge prin SPV.
• B2C: obligatoriu din 2025; perioada de grație s-a încheiat la 1 iulie 2025. Facturile către persoane fizice se raportează și ele.
• Termenul de transmitere: din 1 ianuarie 2026 e de 5 zile lucrătoare de la emitere (înainte erau 5 zile calendaristice). Modificarea a venit prin OUG 89/2025.
• Nerezidenți cu cod RO de TVA: din 1 ianuarie 2026 trimiți prin e-Factura și facturile către persoane impozabile nestabilite în România, dar înregistrate aici în scopuri de TVA.
• Persoane fizice cu CNP: după o extindere la început de 2026, o lege promulgată în mai 2026 a făcut sistemul opțional pentru persoanele fizice care se identifică prin CNP, începând cu 1 iunie 2026. Pentru firme (SRL, PFA și alte forme organizate profesional) rămâne obligatoriu.

Ce nu intră: bonurile fiscale care îndeplinesc condițiile de factură simplificată și facturile pentru livrări intracomunitare de bunuri unde clientul comunică un cod de TVA din alt stat membru UE. Atenție însă: facturile simplificate propriu-zise (sub 100 EUR) se transmit oricum, nu mai sunt o excepție.

Un detaliu de implementare ușor de ratat: pentru clienți B2C care nu dau CNP-ul, factura folosește un cod generic format din 13 cifre de zero în loc de identificator. ERP-ul tău trebuie să suporte cazul ăsta, altfel blochezi vânzarea.

Termene și sancțiuni

Sancțiunile se aplică per factură. La un volum de câteva sute de facturi pe lună, o automatizare prost configurată nu mai e o problemă de conformitate — e o problemă de cont bancar.

Ce trebuie să acopere integrarea — checklist tehnic

Indiferent cum o construiești, o integrare completă acoperă opt lucruri:

1. Generare XML RO_CIUS valid — mapping din modelul ERP în schema UBL 2.1, cu validare locală înainte de trimitere (prinzi erorile la tine, nu la ANAF).
2. Autentificare OAuth2 — Authorization Code flow, pe baza unui certificat digital calificat înregistrat ca aplicație în portalul ANAF.
3. Upload — POST pe /upload (B2B) sau /uploadb2c (B2C); primești un id_incarcare.
4. Polling status — GET /stareMesaj?id_incarcare=... până la stare="ok" (sau erori), de unde iei id_descarcare.
5. Descărcare recipisă — GET /descarcare?id=... îți dă factura semnată electronic.
6. Recepție facturi inbound — listaMesaje îți aduce facturile emise de furnizorii tăi; nu doar emiți, ci și consumi.
7. Tratare erori și stornare — o factură trimisă nu se mai modifică; corecția se face prin stornare și reemitere.
8. Arhivare 10 ani — SPV nu garantează stocarea pe termen lung; XML-urile semnate sunt responsabilitatea ta.

Endpoint-urile trăiesc sub două medii: https://api.anaf.ro/test/FCTEL/rest/... pentru sandbox și https://api.anaf.ro/prod/FCTEL/rest/... pentru producție. Autorizarea OAuth se face la https://logincert.anaf.ro/anaf-oauth2/v1/authorize și /token.

Fluxul minim de upload, în curl:

1# 1. Încarci XML-ul (B2B)
2curl -X POST "https://api.anaf.ro/prod/FCTEL/rest/upload?standard=UBL&cif=12345678" 
3  -H "Authorization: Bearer $ACCESS_TOKEN" 
4  -H "Content-Type: text/plain" 
5  --data-binary @factura.xml
6# -> primești un index de încărcare
7
8# 2. Verifici starea
9curl "https://api.anaf.ro/prod/FCTEL/rest/stareMesaj?id_incarcare=3008662942" 
10  -H "Authorization: Bearer $ACCESS_TOKEN"
11# -> <header stare="ok" id_descarcare="..."/>

1# 1. Încarci XML-ul (B2B)
2curl -X POST "https://api.anaf.ro/prod/FCTEL/rest/upload?standard=UBL&cif=12345678" 
3  -H "Authorization: Bearer $ACCESS_TOKEN" 
4  -H "Content-Type: text/plain" 
5  --data-binary @factura.xml
6# -> primești un index de încărcare
7
8# 2. Verifici starea
9curl "https://api.anaf.ro/prod/FCTEL/rest/stareMesaj?id_incarcare=3008662942" 
10  -H "Authorization: Bearer $ACCESS_TOKEN"
11# -> <header stare="ok" id_descarcare="..."/>

Tokenul de acces expiră la 90 de zile, iar cel de refresh la 365. Reînnoirea trebuie automatizată — altfel integrarea se oprește tăcut într-o dimineață și afli din amenzi.

Trei moduri de a face integrarea

Logica de mai sus trebuie să stea undeva. Ai trei opțiuni, fiecare cu un alt compromis între control și efort.

1. Modul ERP nativ

ERP-ul are deja un conector e-Factura inclus. Configurezi certificatul, mapezi câmpurile o dată, gata.

Merge bine dacă ERP-ul tău e o platformă matură, care a ținut pasul cu legislația. Riscul: rămâi la ritmul în care vendorul își actualizează conectorul. Când ANAF schimbă schema sau termenul (cum s-a întâmplat în ianuarie 2026), aștepți update-ul lor.

2. Middleware / conector terț

Un serviciu intermediar (de obicei SaaS) primește XML-ul sau datele de la ERP, vorbește el cu ANAF și îți returnează statusul. ERP-ul tău trimite spre middleware, nu spre ANAF direct.

Câștigi viteză și scapi de mentenanța pe OAuth, retry și validări. Plătești un abonament și introduci o dependență externă în lanțul tău fiscal. Pentru multe firme e cel mai bun raport efort/risc, mai ales fără echipă tehnică internă.

3. Integrare custom prin API-ul ANAF

Codul tău vorbește direct cu endpoint-urile ANAF. Tu deții generarea XML, OAuth, polling-ul, arhivarea.

Control total și zero dependențe terțe. În schimb, tu porți și mentenanța: când se schimbă ceva, tu rescrii. Are sens când ai deja un ERP custom și o echipă care poate ține fluxul viu. Dacă vrei să externalizezi exact partea asta, integrarea e-Factura prin API-ul ANAF se poate construi și separat de restul ERP-ului.

Capcane reale

Lucrurile care chiar dau bătăi de cap, din practică:

• Cele 5 zile lucrătoare prind sărbătorile. Pare relaxant, dar dacă lași trimiterea pe manual, un weekend prelungit plus o factură uitată înseamnă termen depășit. Setează trimiterea automată la 1–2 zile după emitere.
• Cotele de TVA s-au schimbat în 2025. Cota standard e 21% din 1 august 2025 (era 19%), iar cea redusă s-a consolidat la 11%. ERP-ul trebuie să mapeze corect categoriile de TVA în RO_CIUS; o cotă veche pe o factură nouă înseamnă respingere. Dacă vinzi și SaaS sau servicii digitale, tratamentul TVA e mai nuanțat — reverse charge UE, OSS, praguri — și l-am detaliat separat în ghidul de TVA și e-Factura pentru SaaS.
• Nu poți edita o factură trimisă. Orice corecție trece prin stornare și reemitere. Dacă fluxul tău nu suportă stornarea curat, vei avea probleme de reconciliere.
• Token-urile expiră. 90 de zile pentru acces, 365 pentru refresh. Fără reînnoire automată, integrarea cade fără zgomot.
• Limită de 10 MB per fișier și cote zilnice de apeluri. Nu trimite tot la final de lună într-un singur val; eșalonează.
• Arhivarea e a ta. SPV nu e arhiva ta pe 10 ani. Stochezi XML-urile semnate la tine.
• Recepția inbound contează la fel de mult. Dacă o factură de la furnizor nu vine prin e-Factura când legea o cere, riști TVA nedeductibil. Verifici periodic SPV-ul, nu doar emiți.
• Testează în sandbox. Mediul /test există ca să nu descoperi în producție că mapping-ul tău de TVA e greșit.

Dacă încă ții facturarea în foi de calcul și te gândești la pasul ăsta, semnele că ai depășit Excelul sunt aceleași semne care îți spun că ai nevoie de o integrare reală, nu de un export manual în SPV.

Cum alegi abordarea

Câteva întrebări care taie decizia repede:

• Ai deja un ERP care scoate e-Factura? Dacă da și vendorul e prompt cu legislația, modulul nativ e suficient.
• Ai echipă tehnică internă? Fără ea, custom devine o datorie, nu un avantaj. Middleware-ul preia greul.
• Cât de mult control îți trebuie? Dacă fluxul fiscal e diferențiator sau ai volume mari cu particularități, custom îți dă mâna liberă.
• Care e volumul lunar? La zeci de facturi, orice merge. La mii, automatizarea și retry-urile robuste nu sunt opționale — vezi automatizarea e-Factura pentru volume mari.

Nu există un răspuns universal corect. Există potrivirea între volumul tău, echipa ta și cât risc extern accepți în lanțul fiscal.

Întrebări frecvente

Pot folosi e-Factura fără un ERP?

Da. Poți încărca manual în SPV sau printr-un program de facturare. Dar la volum, manual înseamnă termene ratate. Un ERP cu integrare automatizează exact pasul ăsta.

Ce certificat îmi trebuie?

Un certificat digital calificat, de la un furnizor acreditat, cu care înregistrezi o aplicație OAuth în portalul ANAF. Pe baza lui obții token-urile de acces și refresh.

Ce se întâmplă dacă ANAF respinge factura?

Primești o listă de erori la stareMesaj. Corectezi XML-ul și reîncarci. Factura nu e validă fiscal până nu trece validarea și nu primești recipisa semnată.

Trebuie să arhivez eu facturile?

Da. SPV nu garantează stocarea pe 10 ani. Răspunderea pentru arhivarea XML-urilor semnate e a emitentului.

Cât de des trebuie să verific facturile primite?

Periodic, în funcție de volum — săptămânal e un minim rezonabil pentru multe firme. Facturi de la furnizori netransmise corect îți pot afecta deducerea de TVA.

Mediul de test e separat de producție?

Da. /test și /prod sunt endpoint-uri distincte. Tot ce încarci în sandbox nu are efect fiscal.

În loc de concluzie

e-Factura nu e un task de bifat o dată. E un flux viu, care trebuie să reziste la schimbări de lege, de cote și de scheme. Înainte să alegi între modul nativ, middleware și custom, fixează-ți volumul, echipa și cât control îți trebuie asupra propriului lanț fiscal. Restul e implementare. Iar ca să nu calci în gropile deja bătătorite de alții, am strâns greșelile frecvente la e-Factura într-un articol separat.

Pentru imaginea de ansamblu, pornește de la ce înseamnă un sistem ERP și urcă spre integrările care contează pentru tine. Dacă firma ta transportă și fizic bunuri cu risc fiscal ridicat, mai ai o obligație separată de urmărit — RO e-Transport, cu praguri și termene proprii, diferite de e-Factura.