e-Factura: ce este, cui i se aplică și cum se trimite la ANAF

E-Factura este sistemul ANAF de facturare electronică prin care emitentul unei facturi B2B (între operatori economici stabiliți în România) este obligat să trimită documentul, în format XML standardizat, către o platformă centralizată administrată de Agenția Națională de Administrare Fiscală. Sistemul a fost introdus prin OUG 120/2021, generalizat pentru toate tranzacțiile B2B prin OUG 115/2023, și operează la efactura.anaf.ro¹.

Pe scurt: dacă firma ta emite factură către o altă firmă din România, copia XML a acelei facturi trebuie trimisă la ANAF în câteva zile lucrătoare de la emitere. Trimiterea se face prin Spațiul Privat Virtual al ANAF, prin clientul desktop oficial (DUK Integrator) sau prin API. Pentru sisteme cu volum sau cu nevoie de automatizare, opțiunea practică este API-ul, fie direct, fie prin intermediari (SmartBill, Oblio, FGO).

Cui i se aplică e-Factura și de când?

e-Factura se aplică tranzacțiilor B2B dintre operatori stabiliți în România (obligatorie din 1 ianuarie 2024), achizițiilor publice, tranzacțiilor B2C și, în anumite cazuri, operatorilor neînregistrați în România. Domeniul de aplicare este mai larg decât pare la prima vedere:

• B2B intern: orice tranzacție între doi operatori economici stabiliți în România. De la 1 ianuarie 2024 este obligatorie trimiterea facturii în e-Factura, indiferent de tipul produsului sau serviciului. Cazurile speciale și excepțiile inițiale au fost restrânse treptat².
• B2C: extinderea către consumatorul final s-a făcut etapizat, cu termene amânate de mai multe ori. Pentru calendarul curent aplicabil cazului tău, verifică efactura.anaf.ro.
• Achiziții publice: în relație cu autoritățile contractante, e-Factura era deja obligatorie încă din 2022, prin transpunerea Directivei 2014/55/UE.
• Operatori neînregistrați în România: dacă vinzi din străinătate către clienți B2B din România, obligația de trimitere îi revine cumpărătorului român (mecanismul de „taxare inversă"), nu ție.

Excluderile clare sunt persoanele fizice fără activitate economică, tranzacțiile interne (consum propriu, neînsoțite de factură comercială) și câteva cazuri tehnice menționate în normele de aplicare.

Care este formatul tehnic al e-Facturii?

Standardul de bază este Universal Business Language (UBL) versiunea 2.1, în profilul CIUS-RO definit de ANAF, o restrângere a schemei UBL standard la câmpurile acceptate de sistemul românesc, cu reguli adiționale (validarea CUI, forma codurilor de TVA, formatul datelor). Un XML UBL 2.1 generic, perfect valid contra schemei internaționale, poate fi respins de e-Factura dacă încalcă CIUS-RO.

Mecanismul de transport, în cinci pași:

1. Generare: emitentul produce XML-ul UBL 2.1 conform CIUS-RO.
2. Semnătură: documentul este semnat cu un certificat digital calificat (eIDAS), folosind XAdES. Fără semnătură validă, XML-ul este respins la încărcare.
3. Încărcare: trimitere prin SPV, DUK Integrator sau API-ul ANAF, cu autentificare prin certificat sau token OAuth.
4. Validare: ANAF returnează un identificator de încărcare și, după validare asincronă (de la câteva secunde la câteva minute), un mesaj de acceptare sau respingere cu codurile de eroare.
5. Răspuns către destinatar: facturile acceptate apar destinatarului în SPV-ul lui, de unde le poate descărca tot prin API.

Faptul că validarea este asincronă transformă integrarea într-o problemă de cozi: trimiți, primești ID, apoi tragi periodic statusul. Tratamentul corect al retransmiterilor și al idempotenței este partea care diferențiază o integrare bine făcută de una care blochează tot fluxul de facturare la prima eroare.

Care sunt cele trei căi de trimitere a e-Facturii?

Cele trei căi sunt portalul SPV (plus DUK Integrator), un SaaS de facturare precum SmartBill, Oblio sau FGO, și integrarea directă prin API-ul ANAF:

• Portal SPV plus DUK Integrator: opțiunea oficială fără cod, potrivită pentru volum mic sau pentru testare. DUK Integrator este un client desktop care încarcă manual XML-uri. Limitarea evidentă: nu se scalează, semnătura este per-utilizator, fără audit trail în sistemul tău.
• SaaS de facturare (SmartBill, Oblio, FGO): emiți factura prin SaaS, iar acesta o trimite automat în e-Factura. Integrarea ta e cu API-ul SaaS-ului, nu cu ANAF direct. Cost mai mare pe lună, dar zero efort de UBL, XAdES sau cozi de retransmitere. La SmartBill, atenție la rate limit-ul de aproximativ 3 cereri pe secundă: depășirea returnează 403 (nu 429) pentru până la zece minute³, deci clientul tău trebuie să facă rate limiting defensiv.
• API direct la ANAF: control total, costuri operaționale zero, dar implementare laborioasă: generarea UBL conform CIUS-RO, gestiunea certificatului eIDAS, cozile de retransmitere, monitorizarea răspunsurilor asincrone. Justificat când volumul depășește câteva mii de facturi pe lună sau când vrei să servești mai mulți clienți cu un singur sistem.

Care sunt riscurile dacă nu trimiți e-Factura la timp?

Riscul direct este amenda: cadrul sancțiunilor a fost introdus prin OUG 115/2023, cu o perioadă inițială de toleranță, urmată de aplicare efectivă. Amenzile se calculează în funcție de tipul contribuabilului (mare, mijlociu sau mic) și de gravitatea omiterii (factură netrimisă, trimisă cu întârziere, trimisă în format invalid). Pentru sumele exacte valabile la data verificării tale, consultă ANAF; ordinul de mărime este de mii de lei pe document neraportat, suficient să justifice automatizarea integrării chiar și pentru volume mici.

Mai puțin discutat, dar la fel de relevant: dezactivarea posibilității de deducere a TVA-ului pentru destinatarul facturii, dacă aceasta nu a fost trimisă corect în e-Factura. Asta înseamnă că orice eroare a emitentului devine o problemă comercială cu clientul, nu doar o problemă fiscală cu ANAF.

De ce contează e-Factura pentru un dezvoltator?

Două motive practice: primul, dacă lucrezi pe orice produs care emite facturi în România (SaaS cu plată recurentă, magazin online, platformă de rezervări, aplicație de servicii), integrarea cu e-Factura nu este opțională. Lipsa ei nu este un risc pe care îl poți amâna; este un cost recurent (amendă pe document) plus un cost reputațional (clientul nu poate deduce TVA pe ceea ce vinzi).

Al doilea: spațiul este suficient de tehnic încât majoritatea departamentelor de contabilitate ale clienților nu îl pot acoperi singure. Integrarea curată (Stripe, SaaS de facturare, e-Factura, cu webhook-uri, retransmiteri și monitoring) este un proiect între două și patru săptămâni pentru un dezvoltator care a mai parcurs acest proces. Pentru contextul UBL 2.1 specific și diferența față de SAF-T (D406), citește entry-urile dedicate. Pentru fluxul concret cu cod (Spring Boot și Node.js), vezi ghidul nostru de integrare a SmartBill cu Stripe. Dacă vrei un model mental mai general pentru autentificarea pe API-uri publice românești, entry-ul despre JWT acoperă semantica token-urilor pe care ANAF, SmartBill și Oblio le folosesc în mod similar.

1. Cadrul legal al sistemului RO e-Factura: OUG 120/2021 (introducere), OUG 115/2023 (generalizare B2B), OMFP 1366/2021 (formatul UBL CIUS-RO). Documentația tehnică curentă, schema XSD CIUS-RO și API-ul de încărcare sunt publicate la efactura.anaf.ro. [seo.efactura_legal_framework]
2. Calendarul aplicării B2B și al sancțiunilor a suferit modificări succesive după publicarea OUG 115/2023. Pentru data curentă valabilă, ANAF publică o pagină de FAQ și un sumar al actelor normative la efactura.anaf.ro/intrebari-frecvente. [seo.efactura_b2b_calendar]
3. Caracteristicile rate limit-ului SmartBill API, observate în clientul nostru de producție: aproximativ 3 cereri pe secundă, depășirea returnează 403 (nu 429) timp de până la zece minute, fără antete care să declare limita. Implementarea noastră tratează 403 ca semnal de rate limit și aplică un backoff de 60 secunde înainte de o singură retransmitere. [crawlerra.smartbill_backoff]