Conformitate fiscală, fără surprize în control ANAF.

Codul Fiscal art. 319 al. (20) cere numerotare secvențială bazată pe una sau mai multe serii, care să identifice unic fiecare factură. Legea contabilității 82/1991 art. 14 precizează că documentele justificative se numerotează cronologic și fără întreruperi. Două formulări, aceeași regulă: niciun gol în secvență, fără excepție.

Implementarea uzuală tratează numerotarea în doi pași separați: întâi creșterea contorului, apoi salvarea numărului pe documentul nou. Dacă procesul se întrerupe între cei doi pași — o repornire de server, o actualizare a aplicației, o problemă punctuală de conexiune — contorul a avansat, dar niciun document nu mai poartă numărul respectiv. La inspecție, apare un gol care trebuie justificat în scris.

Cele două operații rulează într-o singură tranzacție. Dacă a doua eșuează, prima se anulează automat și contorul revine la valoarea inițială. Numărul fie ajunge pe factură, fie nu se consumă. Pentru job-urile care eșuează ulterior — de pildă, la generarea XML-ului, după ce numărul a fost deja persistat — reluarea se face cu același număr, niciodată cu unul nou. Sequența rămâne intactă inclusiv după un crash între pași.

Două documente fiscale cu același număr de identificare reprezintă, în interpretarea Cod Penal art. 321 (fals material în înscrisuri oficiale), o expunere penală a comerciantului — chiar dacă duplicarea a fost provocată de un defect al aplicației. Răspunderea rămâne la firma care a emis.

Cazul cel mai frecvent: o factură respinsă de ANAF a primit deja un număr din secvență și a fost livrată în SPV. Dacă aplicația permite regenerarea ei cu corecții păstrând același număr, fie ANAF respinge re-trimiterea ca duplicat, fie acceptă două înregistrări sub același număr — ambele scenarii cu rezolvare doar prin storno și document nou.

Pentru o factură cu status respins, regenerarea cu același număr este blocată din interfață, iar mesajul trimite explicit către procedura corectă: notă de creditare emisă pentru factura respinsă, urmată de o factură nouă cu numărul următor. Re-trimiterea aceluiași XML, neschimbat, rămâne posibilă — pentru cazurile în care respingerea a fost tranzitorie (eroare punctuală a validatorului ANAF) și documentul nu se modifică.

Cod Fiscal art. 319 al. (16) stabilește că factura se emite în momentul livrării sau prestării, dar nu mai târziu de a 15-a zi a lunii următoare faptului generator. Pentru comerțul online cu plata în avans, faptul generator este momentul plății capturate — deci data facturii ar trebui să fie data efectivă a tranzacției, nu momentul în care un proces de pe server o procesează.

Implementarea naivă scrie pe factură data la care aplicația a procesat-o. În majoritatea cazurilor cele două coincid. Două situații însă rup această potrivire:

Granița de an fiscal. O comandă plătită la 23:59 pe 31 decembrie, procesată la 00:00:05 pe 1 ianuarie, primește data 1 ianuarie. Venitul alunecă în anul fiscal următor, iar pe deconturile lunare D300 și anuale D101 cifrele nu se mai reconciliază cu rapoartele platformei de vânzare.

Întârzieri de procesare. O conexiune ANAF picată pentru două zile aduce o factură cu data la doi bani după plata efectivă a clientului.

Data emiterii este ancorată pe timestamp-ul de plată al comenzii Shopify (processed_at), nu pe ceasul serverului. Indiferent cât durează procesarea, data documentului rămâne data faptului generator. Data scadenței urmează aceeași logică — se calculează pornind de la data facturii plus termenul de plată configurat, nu pornind de la momentul procesării.

Cod Fiscal art. 290 reglementează regularizarea bazei de impozitare în caz de retur sau anulare. Operațiunea de storno trebuie să respecte componența TVA originală: dacă factura inițială avea linii la 21%, 9% și transport la 21%, nota de creditare trebuie să poarte aceleași cote, în aceleași proporții.

Implementarea neglijentă tratează rambursarea ca o sumă unică și aplică cota implicită a comerciantului (de obicei 21%) pe întreg. Pentru un retur pe o factură cu cote mixte, suma totală a TVA storno este corectă în raport cu suma rambursată, însă breakdown-ul pe cote nu mai corespunde facturii originale. La reconciliere D300, jurnalul de vânzări și jurnalul de cumpărări nu se mai potrivesc per cotă; apare o discrepanță sistematică pentru comercianții cu sortimente pe mai multe categorii (mărfuri + alimente + cărți).

Nota de creditare moștenește cotele TVA ale fiecărei linii din factura originală, pornind de la articolele rambursate cu cantitățile lor exacte. Breakdown-ul rezultat este: o linie la 21%, alta la 9%, alta la transport, fiecare cu cota proprie. La reconciliere, sumele se potrivesc cu factura inițială până la ultimul ban.

Regula contabilă este half-up: jumătatea de ban se rotunjește în sus. Pe o factură singulară, regula nu se observă. Pe câteva mii de facturi într-un an, diferențele de 1 ban acumulate ajung la sume vizibile pe decontul lunar D300 — în speță, cazurile de „TVA declarat diferit față de TVA calculabil din facturi", care apar frecvent în notele de control.

Sursa erorii este reprezentarea internă a numerelor în majoritatea limbajelor de programare. Pentru sume cu jumătate-de-ban — 0,115 RON, 0,125 RON, 0,225 RON — micile erori invizibile pot determina o aplicație să rotunjească în jos ceea ce regula contabilă cere în sus. Eroarea este sistematică, nu aleatoare.

Rotunjim half-up la fiecare nivel — pe fiecare linie, pe fiecare cotă TVA, pe subtotal, pe TVA total, pe totalul cu TVA — folosind o procedură care compensează erorile de reprezentare numerică. Sumele declarate de eFacturio sunt exact sumele așteptate de ANAF la validare. Diferențele de 1 ban sistematice nu apar.

Un client plătește o comandă, apoi solicită anularea în câteva minute. Comerciantul anulează comanda în Shopify. Dacă aplicația de e-Factura nu reacționează imediat la anulare, factura — generată între timp și aflată în coadă pentru ANAF — pleacă în SPV ca document fiscal pentru o tranzacție care nu a avut loc. Singurul remediu legal devine storno-ul.

Aplicațiile tratează adesea anularea doar pentru documentele abia primite. Cele aflate în faza intermediară — XML deja generat, în coadă pentru ANAF, în reîncercare automată, sau marcate pentru verificare manuală — „scapă" anulării și ajung trimise în secundele următoare, ignorând complet starea comenzii în Shopify.

La primirea webhook-ului de anulare, aplicația marchează drept anulate toate stările pre-ANAF, fără excepție. Niciun venit fictiv pe deconturile lunare; nicio factură fără tranzacție reală în spate. Pentru documentele care au ajuns deja la ANAF, anularea automată nu mai este posibilă — calea legală este storno-ul, iar aplicația oferă butonul respectiv pe pagina facturii, cu referința corectă către documentul inițial.

BT-44 din RO_CIUS — numele cumpărătorului — este câmp obligatoriu în EN 16931 și păstrat ca atare în varianta ANAF. Pentru B2B, numele este al companiei; pentru B2C, al persoanei fizice. În niciun caz un placeholder generic.

Unele comenzi ajung însă cu câmpurile de nume goale: comenzi cadou fără adresă completată, comenzi create manual de comerciant, checkout-uri rapide cu doar adresă de email. Aplicația neglijentă trimite mai departe, cu un nume de tipul „Client" sau „Customer", pentru a satisface formal câmpul obligatoriu. Validatorul ANAF în mod strict respinge; în mod permisiv acceptă — iar factura ajunge în SPV cu un nume care nu se reconciliază cu jurnalul de vânzări al merchantului.

Dacă toate sursele de nume (prenume, nume, denumire pe adresă, denumire companie) sunt goale, factura nu pleacă spre ANAF. Trece în starea „necesită verificare" cu mesaj explicit pe pagina facturii: „Adaugă numele clientului înainte de trimitere." După completarea câmpului, procesarea reia automat. Nu trimitem un placeholder pe care contabilul cumpărătorului apoi nu poate să-l reconcilieze cu nimic.

Clientul primește factura în format PDF — documentul vizibil pe care contabilul lui îl înregistrează în jurnalul de cumpărări. XML-ul este forma fiscală pe care ANAF o reține în SPV. Cele două trebuie să corespundă byte-for-byte. Orice divergență de format, rotunjire sau afișare deschide riscul unui control încrucișat în care D300 al cumpărătorului nu se potrivește cu D300 al vânzătorului pentru aceeași factură.

Aplicațiile generează adesea PDF-ul local, pe baza unei copii a datelor folosite la XML. Mici diferențe se strecoară: o regulă de rotunjire diferită, o formatare cu locale alterat (virgula pe zecimale vs punct), o linie de transport tratată alternativ. Suma pe PDF e corectă; reconcilierea analitică nu mai e.

PDF-ul este generat de serverul ANAF pe baza XML-ului submis, prin endpoint-ul lor public de transformare. Practic, ANAF însuși produce documentul vizual din versiunea fiscală reținută în SPV. Documentul primit de client este, prin construcție, identic cu cel reținut de ANAF. Nu generăm nimic local pentru clientul final.

Autentificarea la ANAF se face prin certificat digital calificat și emite un token de acces cu valabilitate limitată. Token-ul expiră — uneori chiar în mijlocul transmisiei unui lot. Implementarea naivă oprește întregul lot la prima respingere 401 și marchează toate facturile rămase pentru reîncercare manuală — care va eșua identic, pentru că tokenul rămas tot e expirat.

La detecția unei respingeri 401, aplicația cere automat un token nou folosind refresh-token-ul, îl persistă, și reia uploadul lotului de la documentul curent. Toate facturile ajung la ANAF; întreruperea durează câteva secunde și este invizibilă pentru comerciant. Aceeași logică se aplică și în timpul verificării ulterioare a statusului ANAF — niciun document nu rămâne blocat fiindcă un token a expirat în timp.

ANAF intră în mentenanță programată. Token-ul comerciantului expiră și nu se reînnoiește (certificat fără utilizator activ). Conexiunea internet a serverului cade pentru câteva ore. Toate aceste scenarii produc facturi care așteaptă conexiune. Aplicațiile care nu reiau procesarea automat lasă zeci de documente blocate, fără nicio notificare către comerciant — observate uneori la rezumarea lunară, alteori la primul control.

Termenul legal pentru transmisia B2B prin e-Factura este de 5 zile lucrătoare de la emiterea facturii (OUG 120/2021). Depășirea atrage sancțiuni pe raportare tardivă.

Facturile generate în timpul indisponibilității ANAF sunt parcate cu mesaj clar către comerciant. La revenirea conexiunii, aplicația le trimite automat — nu este nevoie să apese cineva un buton de retry, pe fiecare document. Aceeași logică se aplică simetric și pentru notele de creditare: dacă cineva returnează ceva în timpul indisponibilității, storno-ul intră în aceeași coadă și pleacă la reconectare.

La acceptarea unei facturi, ANAF generează un fișier ZIP care conține XML-ul original împreună cu semnătura digitală ANAF — dovada electronică a transmisiei, validă juridic conform Regulamentului eIDAS. ANAF păstrează acest fișier disponibil pentru descărcare doar 60 de zile de la acceptare. După fereastra respectivă, nu se mai poate recupera.

O aplicație care ratează arhivarea în momentul acceptării — storage temporar indisponibil, bug punctual, cădere de rețea — pierde definitiv dovada. Comerciantul rămâne fără proba legală a transmisiei pentru factura respectivă; la un eventual control, lipsa este observabilă.

Descărcăm arhiva sigilată în momentul acceptării și o păstrăm fără limită de timp. Pentru cazurile rare în care încărcarea inițială eșuează, un proces secundar reia descărcarea o dată pe oră, pe toată fereastra de 60 de zile. În practică, arhiva este salvată în 1-2 ore chiar și după un incident punctual. Pe pagina fiecărei facturi acceptate apare butonul „Descarcă arhivă sigilată ANAF" — disponibil oricând, pentru control fiscal, audit sau dosar contencios.

La un control fiscal sau o dispută cu un client („susțin că n-am primit factura"), comerciantul trebuie să răspundă cu precizie: când exact a fost generată factura, când a plecat spre ANAF, când a fost acceptată, sub ce identificator în SPV. Răspunsul nu poate veni din memorie — trebuie să vină din evidența scrisă a aplicației.

Pentru fiecare factură înregistrăm cronologic toate momentele semnificative: primirea comenzii Shopify, generarea documentului, trimiterea la ANAF, acceptarea, respingerea, anularea. Fiecare moment are marcaj orar precis, identificator ANAF (dacă există), și contextul comenzii originale.

Istoricul complet este vizibil pe pagina fiecărei facturi: „primit la 14:32, generat la 14:32, trimis la 14:32, acceptat la 14:51, index ANAF 4870…". Pentru un eventual control, evidența este exportabilă la cerere. Documentele fiscale și istoricul aferent se păstrează conform termenului legal de 5 ani (Cod Fiscal art. 109); operațiunile administrative (logări, retry-uri, încercări intermediare) se anonimizează după perioada GDPR de retenție.