# 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](/blog/ce-este-sistem-erp) 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): ```xml urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1 FACT-2026-00187 2026-06-19 RON 210.00 ``` ![Diagrama fluxului de emitere e-Factura din ERP, prin generare XML și API-ul ANAF, până la recipisa semnată și arhivare](https://pub-05fe7f6c08814b92acf8fd74d03a6c18.r2.dev/inline/Integrare%20ERP%20cu%20e-Factura%20%C8%99i%20ANAF/fluxul-emitere-efactura.svg "Fluxul de transmitere a unei facturi în RO e-Factura") ## 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 | Situație | Consecință | | ----------------------------------------------------------------------- | ------------------------------------ | | Întârziere peste termen — contribuabil mic / PFA | Amendă 1.000–2.500 lei | | Întârziere peste termen — contribuabil mijlociu | Amendă 2.500–5.000 lei | | Întârziere peste termen — contribuabil mare | Amendă 5.000–10.000 lei | | Factură B2B înregistrată în afara fluxului e-Factura (anumite situații) | Penalitate 15% din valoarea facturii | | Factură netransmisă prin e-Factura când legea o cere | TVA nedeductibil pe acea factură | 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/...`](https://api.anaf.ro/test/FCTEL/rest/...) pentru sandbox și [`https://api.anaf.ro/prod/FCTEL/rest/...`](https://api.anaf.ro/prod/FCTEL/rest/...) pentru producție. Autorizarea OAuth se face la [`https://logincert.anaf.ro/anaf-oauth2/v1/authorize`](https://logincert.anaf.ro/anaf-oauth2/v1/authorize) și `/token`. Fluxul minim de upload, în curl: ```bash # 1. Încarci XML-ul (B2B) curl -X POST "https://api.anaf.ro/prod/FCTEL/rest/upload?standard=UBL&cif=12345678" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type: text/plain" \ --data-binary @factura.xml # -> primești un index de încărcare # 2. Verifici starea curl "https://api.anaf.ro/prod/FCTEL/rest/stareMesaj?id_incarcare=3008662942" \ -H "Authorization: Bearer $ACCESS_TOKEN" # ->

``` 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. ![Comparație vizuală a trei arhitecturi de integrare e-Factura: modul ERP nativ, middleware terț și integrare custom prin API-ul ANAF](https://pub-05fe7f6c08814b92acf8fd74d03a6c18.r2.dev/inline/Integrare%20ERP%20cu%20e-Factura%20%C8%99i%20ANAF/trei-abordari-integrare.svg "Cele trei abordări de integrare cu e-Factura") ### 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](/blog/erp-custom-vs-standard) și o echipă care poate ține fluxul viu. | Criteriu | ERP nativ | Middleware | Custom | | ------------------------------- | ------------------- | ------------------------- | ------------------- | | Time-to-market | Rapid (dacă există) | Rapid | Lent | | Control asupra fluxului | Mic | Mediu | Total | | Mentenanță la schimbări de lege | Vendorul | Furnizorul | Tu | | Dependență externă | ERP | Middleware | Niciuna | | Potrivit pentru | ERP matur existent | Firme fără echipă tehnică | ERP custom + echipă | ## 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. * **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](/blog/semne-ca-ai-depasit-excel) 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. 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. Pentru imaginea de ansamblu, pornește de la [ce înseamnă un sistem ERP](/blog/ce-este-sistem-erp) și urcă spre integrările care contează pentru tine.

Toate articolele

e-Factura

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