Automatizare e-Factura pentru magazine online și volume mari

Un magazin online cu 400 de comenzi pe zi nu are o problemă de conformitate. Are o problemă de debit.

Fiecare comandă înseamnă o factură. Fiecare factură înseamnă un XML valid, trimis în SPV în maximum 5 zile lucrătoare, la care ANAF răspunde asincron. La 20 de facturi pe lună, un om le încarcă manual și e în regulă. La 12.000 pe lună, exact aceleași reguli produc un sistem distribuit — cu cozi, retry-uri, idempotență și limite de rată. Pe ăsta ori îl construiești intenționat, ori îl descoperi în producție, prin amenzi.

Articolul ăsta e despre partea a doua. Dacă îți lipsesc bazele — formatul RO_CIUS, autentificarea, cele trei arhitecturi posibile — ghidul de integrare ERP cu e-Factura și ANAF le acoperă pe toate. Aici pornim de la premisa că fluxul există deja și trebuie să reziste la volum.

Ce se schimbă, de fapt, când crește volumul

La zeci de facturi pe lună, tot ce contează e să nu uiți. La mii, se schimbă natura problemei. Trei lucruri, concret: Termenul devine statistic, nu individual. Nu mai întrebi „am trimis factura asta?", ci „câte din facturile de ieri au recipisă validă azi?". Diferența pare mică, dar schimbă complet ce trebuie să construiești: ai nevoie de o stare per factură, interogabilă, nu de un folder cu XML-uri.

Erorile devin o categorie, nu un incident. La 12.000 de facturi pe lună, un rând de client cu CUI prost formatat nu mai e o excepție de rezolvat manual — e o clasă de eroare care va apărea de câteva sute de ori. Are nevoie de tratament automat și de un raport, nu de cineva care se uită în SPV.

API-ul ANAF are limite pe care le atingi. Asta e partea pe care mulți o descoperă târziu, și e cea mai scumpă.

Limitele reale ale API-ului ANAF

Ministerul Finanțelor publică limitele de apel într-un fișier text pe care aproape nimeni nu-l citește înainte să scrie primul cron. Merită citit. Valorile publicate:

Citește a doua coloană cu atenție, pentru că două dintre limite nu sunt globale, ci per mesaj. Un retry naiv — „interoghează starea la fiecare 30 de secunde până primești ok" — arde cele 100 de interogări zilnice pentru acea factură în mai puțin de o oră. Dacă ANAF întârzie prelucrarea peste fereastra aia, nu mai afli rezultatul în ziua respectivă. Nu pentru că sistemul e picat, ci pentru că l-ai epuizat singur.

Depășirea limitei îți întoarce 429 Too Many Requests. Și aici vine partea pe care documentația o spune fără menajamente: 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ști throttled temporar. Poți fi scos.

Concluzia de arhitectură e simplă: nu face polling per factură. Fă polling pe listă.

Fluxul care rezistă: de la comandă la recipisă

Arhitectura care ține la volum arată cam la fel indiferent de platformă. Cinci etaje, fiecare cu propria stare persistată.

1. Comanda produce un eveniment, nu o factură

Când comanda se finalizează, nu genera XML pe loc, în request-ul clientului. Scrie un eveniment într-o coadă. Motivul e banal: ANAF poate fi indisponibil, iar clientul tău nu are de ce să aștepte după el ca să vadă pagina de mulțumire. Facturarea e asincronă prin natura ei; tratează-o așa din primul pas.

2. Generare XML + validare locală

Generezi RO_CIUS din datele comenzii și îl validezi înainte să-l trimiți. ANAF expune un endpoint de validare (/validare/FACT1) care nu cere autentificare — îl poți folosi ca plasă de siguranță, dar validarea locală, cu artefactele Schematron publicate de Minister, e mai rapidă și nu consumă cotă.

Regula: o factură care n-a trecut validarea nu intră niciodată în coada de upload. Altfel îți umpli cota de apeluri cu documente despre care știai deja că vor fi respinse.

3. Upload cu idempotență

Aici e capcana clasică. Dacă job-ul de upload cade după ce ANAF a primit fișierul, dar înainte să apuci să salvezi id_incarcare, retry-ul trimite factura a doua oară. Rezultatul e o factură duplicată în sistemul național, pe care nu o poți șterge — o corectezi doar prin stornare.

Soluția e o cheie de idempotență pe numărul facturii, verificată înainte de fiecare trimitere, plus persistarea id_incarcare în aceeași tranzacție cu marcarea stării. Nu „aproape în aceeași". În aceeași.

4. Reconciliere pe listă, nu pe factură

În loc să întrebi de fiecare factură în parte, ceri periodic lista de mesaje disponibile pentru CUI-ul tău și potrivești răspunsurile cu ce ai în baza ta, după id_solicitare. Un singur apel îți aduce zeci sau sute de răspunsuri.

Două detalii care contează la volum:

• listaMesajeFactura acceptă un parametru zile cu valori între 1 și 60. Dacă job-ul tău de reconciliere e oprit mai mult de 60 de zile, mesajele mai vechi de fereastra asta nu mai apar în listă. Monitorizarea job-ului nu e opțională.
• Pentru volume mari există varianta cu paginație, care primește un interval startTime/endTime în unix timestamp cu milisecunde și un număr de pagină. Cota ei zilnică e de aproape 70 de ori mai mare decât a listei simple. La mii de facturi pe lună, ea e apelul corect.

Poți filtra lista după tipul mesajului: erori de factură, factură trimisă, factură primită sau mesaj de la cumpărător. Filtrarea nu e cosmetică — reduce volumul de descărcări, iar /descarcare are propria limită per mesaj.

5. Descărcare, arhivare, raport

Descarci arhiva (conține factura sau erorile, plus semnătura electronică a Ministerului Finanțelor), o stochezi la tine pentru zece ani și actualizezi starea. SPV nu e arhiva ta. Dacă singura copie a recipiselor semnate stă la ANAF, nu ai arhivă — ai o dependență.

Partea B2C, care surprinde magazinele online

Dacă vinzi către persoane fizice, ai un al doilea flux, nu o variantă a primului.

Raportarea B2C are un endpoint separat, /uploadb2c, obligatoriu de la 31 martie 2025. Nu e o opțiune de configurare pe apelul normal — e alt URL. Un integrator care trimite facturile B2C pe /upload obișnuit are o problemă care nu se vede până la prima verificare.

Al doilea detaliu, cel care blochează efectiv vânzări dacă nu e tratat: ce faci când cumpărătorul nu-ți dă niciun cod de identificare. Legislația prevede explicit situația, iar soluția tehnică e un identificator format din 13 cifre de zero în locul codului fiscal al beneficiarului, disponibil în producție din 16 decembrie 2024.

Pentru un magazin online, asta înseamnă că formularul de checkout nu are voie să ceară CNP-ul ca să emită factura. Dacă îl ceri obligatoriu, pierzi conversii pentru o cerință care nu există. Dacă nu-l ceri, dar nici nu tratezi cazul, factura se blochează. Ambele variante costă — prima în vânzări, a doua în conformitate.

Gestionarea erorilor: ce automatizezi și ce escaladezi

La volum, împarte erorile în trei găleți și tratează-le diferit.

Distincția contează pentru că răspunsul greșit e scump în ambele direcții. Un retry pe o eroare de date consumă cotă la infinit pentru un document care nu va trece niciodată. Iar lipsa unui retry pe o eroare tranzitorie transformă o indisponibilitate de zece minute într-o factură cu termen depășit.

Tiparele de eroare care se repetă cel mai des, cu cauza reală și soluția fiecăreia, sunt strânse în articolul despre greșelile frecvente la e-Factura.

Pentru erorile de flux, un caz merită menționat separat: token-ul de acces expiră la 90 de zile, iar cel de refresh la 365. O integrare fără reînnoire automată nu dă niciun semn până în dimineața în care se oprește complet. Alertă pe expirare, nu doar pe eroare.

Cât economisești, concret

Nu am date de la clienți pe care să le public aici, așa că nu-ți vând un procent. Îți dau aritmetica, cu ipotezele la vedere — pune-ți tu numerele.

Ipoteze: 2.000 de facturi pe lună, 90 de secunde de om per factură procesată manual (generare, încărcare în SPV, verificare status, arhivare), 60 lei/oră cost intern încărcat.

• 2.000 × 90 s = 50 de ore/lună
• 50 × 60 lei = 3.000 lei/lună, adică 36.000 lei/an, doar în timp de operare

La asta se adaugă partea greu de cuantificat, dar reală: riscul de amendă. Termenul depășit se sancționează cu 5.000–10.000 lei pentru contribuabilii mari, 2.500–5.000 lei pentru cei mijlocii și 1.000–2.500 lei pentru restul persoanelor juridice și pentru persoanele fizice. Iar netransmiterea propriu-zisă a unei facturi prin sistem — sau primirea și înregistrarea unei facturi B2B în afara lui — se sancționează cu o amendă egală cu 15% din valoarea totală a facturii.

Cele două nu sunt același lucru și sunt confundate des. Prima e pentru întârziere. A doua e pentru absență. La un volum mare, a doua e cea care te doare.

Dacă vrei să vezi cum arată bugetul unei implementări în care fluxul ăsta e inclus, estimarea de cost pentru un sistem ERP pornește de la module și volume reale, nu de la o listă de prețuri fixe.

Când merită automatizarea și când nu

Câteva praguri practice, în locul unei concluzii generale:

• Sub ~100 de facturi/lună: un program de facturare cu conector inclus e aproape sigur suficient. Automatizarea custom e efort prost investit.
• 100–1.000/lună: contează mai mult ce facturezi decât cât. Dacă ai particularități — abonamente, storno frecvent, mai multe CUI-uri, marketplace-uri — automatizarea începe să se plătească.
• Peste ~1.000/lună: manualul nu mai e o opțiune, iar limitele API-ului devin o constrângere reală de proiectare, nu o notă de subsol.
• Oricând ai mai multe surse de facturi (magazin online plus ERP plus abonamente), problema nu mai e volumul, ci consistența. Aici automatizarea nu e despre economie de timp, ci despre a avea o singură stare adevărată.

Automatizarea e-Facturii nu e un proiect de bifat. E o bucată de infrastructură care trebuie monitorizată ca oricare alta: alertă pe job-ul de reconciliere, alertă pe expirarea token-ului, raport zilnic pe facturile fără recipisă. Fără partea asta, ai automatizat doar trimiterea — nu și certitudinea.

Construim fluxul ăsta ca parte din sistemele ERP la comandă, integrat cu procesele tale de facturare existente, fără vendor lock-in și fără să-ți mutăm datele într-o platformă din care nu mai poți ieși. Ce intră concret într-o implementare — componente, faze, ce ne dai tu — e detaliat în pagina despre integrarea cu API-ul ANAF.

Întrebări frecvente

Pot automatiza e-Factura fără să-mi schimb magazinul online?

Da. Integrarea se face pe evenimentele pe care platforma le expune deja (comandă finalizată, plată confirmată). Magazinul rămâne cum e; fluxul de facturare stă alături de el, nu în el.

Ce se întâmplă dacă ANAF e indisponibil în ziua în care expiră termenul?

De asta se trimite factura la 1–2 zile după emitere, nu în ultima zi. Fereastra de 5 zile lucrătoare e o marjă de siguranță, nu o țintă. O coadă cu retry consumă indisponibilitățile fără să atingă termenul.

Am nevoie de certificat digital separat pentru automatizare?

Ai nevoie de un certificat digital calificat, cu care înregistrezi aplicația în portalul ANAF și obții token-urile OAuth2. Același certificat acoperă și accesul manual în SPV.

Cum tratez stornările la volum?

O factură transmisă nu se mai modifică. Corecția se face prin notă de creditare, transmisă ca document separat (standard=CN). Fluxul tău trebuie să lege storno-ul de factura originală în propria bază, pentru că ANAF nu face legătura asta pentru tine.

Pot testa fără efecte fiscale?

Da. Mediul de test are endpoint-uri distincte, sub /test/, iar tot ce încarci acolo nu are efect fiscal. Testează mai ales mapările de TVA și cazul B2C fără CNP — acolo apar surprizele.