Două aplicații ANAF pentru SAF-T: pași corecți, dar timizi
Pe 26 august, ANAF a pus la dispoziția contribuabililor două tool-uri pentru SAF-T: unul aplică testele de consistență pe fișierul D406, celălalt transpune datele din XML într-un format similar decontului de TVA. Le-am testat pe ambele și le-am analizat funcționalitățile.
// Cuprins
Ce a publicat ANAF
Pe 26 august 2026, ANAF a pus pe portal, în secțiunea dedicată SAF-T, două tool-uri destinate contribuabililor, numerotate ca instrumentele 6 și 7. Primul aplică testele de consistență a datelor din fișierul D406, teste publicate tot de ANAF, în două serii. Al doilea transpune datele din același fișier într-un format similar celui al decontului de TVA, D300.
Comunicatul de presă spune direct de ce: din aproximativ 870.000 de societăți cu obligație SAF-T, circa 580.000 depun și decont de TVA. Ideea e ca aceștia să poată compara cele două raportări înainte de depunere, nu după ce primesc notificarea de neconformitate.
Trei lucruri merită reținute din start. Prelucrarea rulează pe calculatorul tău, datele nu pleacă nicăieri. Tool-urile sunt declarate în testare pentru perioada septembrie ‑ noiembrie 2026. Iar ANAF cere explicit feedback, la adresa saft@anaf.ro.
Și o precizare care trebuie făcută înaintea oricărei alteia: niciunul dintre cele două nu înlocuiește DUKIntegrator. Validarea structurii fișierului, adică verificarea conformității cu schema publicată de ANAF, și generarea PDF-ului cu XML atașat pentru depunere rămân în continuare acolo. Tool-urile astea vin după, pe un fișier deja valid structural, și se uită la conținutul lui.
Le-am testat pe ambele și le-am analizat funcționalitățile. Ce urmează sunt observații de utilizare, nu impresii.
Primul tool: testele de consistență pe D406
Ce face, concret: aplică pe datele din fișier testele de consistență publicate de ANAF în cele două serii, comunicatele din 9 martie 2023 și 19 august 2024. Nu inventează verificări proprii și nu validează structura fișierului.
Sunt două fișiere, cu aceeași logică înăuntru. TestSaftW.jar se deschide cu dublu clic și are o fereastră cu trei butoane. TestSaftT.jar se lansează din linia de comandă și primește directorul ca parametru. Diferă doar felul în care pornesc, testele pe care le aplică sunt aceleași.
Alegi un director, tool-ul ia toate fișierele XML din el și le prelucrează pe rând. Nu contează câte sunt.
- Header: codul fiscal, denumirea, perioada de raportare, indicii de segment
- General Ledger Entries: numărul de înregistrări, totalul rulajelor declarate
- Linia de tranzacție: contul, clientul sau furnizorul, sumele de debit și credit
- Structura de taxă: tipul de taxă, codul de taxă, cota, baza și valoarea TVA
- Master Files: planul de conturi, clienții, furnizorii, produsele, soldurile
- Source Documents: facturile de vânzare și de achiziție, plățile, stocurile
- Schema XSD: nu face validare de structură, presupune că fișierul e deja valid
- Segmentarea: nu recompune o declarație împărțită în mai multe fișiere
La final primești, pentru fiecare declarație verificată, unul sau două fișiere CSV cu delimitatorul #:
- Header‑...csv, întotdeauna. Conține datele de identificare și, important, trei valori calculate de tool: câte linii de tranzacție a parcurs efectiv și cât însumează rulajele debitoare și creditoare.
- Err‑...csv, doar dacă are ce raporta. Fiecare linie problematică apare cu tranzacția, contul, codul de taxă, sumele și eticheta testului picat.
Cele 11 teste, ce semnalează fiecare
Toate se aplică la nivelul structurii de taxă din fiecare linie de tranzacție, cu excluderile de conturi și pragurile de mai jos:
| Nr. | Ce semnalează | Excluderi și praguri |
|---|---|---|
| 1 | TVA pe cod generic. Tip de taxă 300 și cod de taxă 000000, dar cu valoare TVA nenulă |
conturile 4426, 4427, 4428 |
| 2 | TVA care nu se potrivește cu cota. Baza înmulțită cu cota corespunzătoare codului de taxă nu dă valoarea TVA declarată | conturile 442, plus câteva coduri speciale. Semnalează numai dacă diferența trece simultan de 10 lei și de 10% din valoarea calculată |
| 3 | TVA pe operațiune fără taxă. Tip de taxă 000 și cod 000000, dar cu TVA peste 1 leu |
conturile 4426, 4427, 4428 |
| 4 | TVA în structura de taxă pe cont de TVA deductibilă (4426 și echivalentul 35326) | niciuna |
| 5 | Același lucru pe TVA colectată (4427 și 35327) | niciuna |
| 6 | Același lucru pe TVA neexigibilă (4428 și 35328) | niciuna |
| 7 | Tip de taxă care nu are ce căuta în note. Valorile 301, 302, 303, 304, 305, 307, 344, 390 | niciuna. Codul semnalează orice apariție, indiferent de codul de taxă asociat |
| 8 | TVA pe o operațiune scutită. Cod de taxă care duce la rândurile 1, 2, 3, 3.1, 4, 13, 14, 15, dar cu valoare TVA | conturile 442. Vezi observația de mai jos |
| 9 | Taxare inversă fără TVA. Cod de achiziție cu taxare inversă, rândurile 5/20 până la 12.5/27.5, dar cu valoare TVA zero | conturile 451, 40, 442, 3532, 3556, 3566. Ignoră liniile sub 2 lei |
| 10 | TVA pe achiziție scutită. Cod care duce la rândul 30, dar cu valoare TVA | conturile 442 |
| 11 | Note de autocolectare cu TVA. Codurile 380001 până la 380007, cu valoare TVA | conturile 4426, 4427, 4428 și echivalentele lor |
Un lucru care nu se vede din documentație: toate cele 11 teste se opresc la jurnal. Facturile din secțiunea Source Documents nu sunt atinse. O factură codificată greșit se prinde doar dacă și înregistrarea contabilă aferentă e greșită la fel.
33 de teste publicate, 11 implementate
Aici e prima limită vizibilă. Cele 33 de teste de consistență de care se vorbește sunt, de fapt, două comunicate diferite: 22 de teste publicate în martie 2023 și 11 teste publicate în august 2024. Aplicația acoperă seria a doua integral și nimic din prima.
Nu e o scăpare minoră. Seria din 2023 conține exact verificările pe care un contabil le-ar face manual și le-ar face greu:
- completarea datelor de identificare: adresă, contact, telefon, conturi bancare
- completarea nomenclatoarelor: conturi, clienți, furnizori, tabela de taxe, produse, unități de măsură
- egalitatea soldurilor inițiale debitoare cu cele creditoare, și la fel pentru cele finale
- continuitatea soldurilor: soldul final al lunii să fie soldul inițial al lunii următoare
- verificarea soldului final prin rulaje, pe tipuri de cont
- egalitatea rulajelor debitoare cu cele creditoare din jurnal
- coerența sumelor în valută față de cele în lei
- cota aplicată bazei, verificată pe facturile din Source Documents
Există totuși o compensație parțială. Fișierul Header‑...csv îți dă numărul de linii parcurse efectiv și totalul rulajelor calculate, alături de valorile declarate în fișier. Comparația dintre ele acoperă manual două dintre testele lipsă. Tool-ul le pune alături, dar nu le compară singur.
Pasul în sine merită apreciat. Până acum, testele existau doar ca text într-un comunicat, iar fiecare contribuabil trebuia să și le implementeze singur, cine avea cu ce. Acum există un instrument care le aplică. Rămâne întrebarea de ce doar o treime: dacă tot ai publicat 33 de teste și tot ai scris tool-ul, acoperirea integrală ar fi fost pasul firesc.
Al doilea tool: datele SAF-T în format D300
D300_2026.jar face lucrul mai vizibil: încarci fișierul XML corespunzător secțiunii General Ledger Entries, iar tool-ul transpune datele din el într-un format similar celui al decontului de TVA. Rezultatul se poate exporta în PDF, XML sau JSON. Cere Java 17, iar pentru cine nu vrea să instaleze Java există și o variantă cu instalator, pentru Windows.
Transpunerea pornește de la codul de taxă atașat fiecărei linii din jurnal. Codul determină și cota, și rândul de decont pe care ajunge suma. De aici vine și prima consecință practică: dacă un cod de taxă e pus greșit în contabilitate, suma ajunge pe alt rând, iar tool-ul nu are cum să știe. Nu corectează, doar transpune ce găsește.
Trei lucruri de reținut înainte de a compara rezultatul cu decontul tău:
Semnul urmează sensul înregistrării. Nu se adună pur și simplu bazele de impozitare. Stornările și notele de corecție scad, exact ca în decont.
Rezultatul nu este o declarație. Este o transpunere, adică un instrument de comparație. Nu se depune, nu înlocuiește decontul întocmit de tine și nu trece prin DUKIntegrator.
Sunt două machete, nu una. Pentru raportările din 2025, cea cu subrândurile de tranziție, pentru cotele de 19, 9 și 5 la sută. Pentru 2026, cea fără ele, cu numerotarea rândurilor schimbată începând de la rândul 26.
Limitările care contează în practică
Aici e partea pentru care merită citit articolul până la capăt. Nu sunt scăpări cosmetice, sunt lucruri care schimbă cifra afișată.
Vede un singur modul din declarație
Ghidul cere explicit încărcarea fișierului cu General Ledger Entries. Numai că ultimul rând al decontului, soldul TVA de plată din perioada precedentă, se calculează din soldul contului 4423 și din plățile efectuate. Ambele stau în alte secțiuni ale declarației, care la raportarea modală se află în alte fișiere. Concluzia: pentru contribuabilii mari, care raportează modal, acel rând va ieși zero. Nu pentru că nu ai sold, ci pentru că tool-ul nu are de unde să îl citească.
TVA la încasare rămâne o zonă gri
La exigibilitate amânată, TVA devine exigibilă la încasare, iar în contabilitate momentul acela apare ca o mutare între conturile de TVA, de regulă fără o factură nouă în spate. Tool-ul are un tratament pentru situația asta și reconstituie sumele, dar acoperirea nu este uniformă pe toate cotele și pe toate tipurile de operațiune.
Consecința practică: dacă firma aplică TVA la încasare, rândurile de bază din transpunere se verifică separat, nu se preiau ca atare. O diferență față de decontul tău nu înseamnă neapărat că ai greșit tu. Pentru o imagine completă a decontului de TVA, în forma actuală, tool-ul nu este suficient.
Exportul XML nu este declarația, iar DUKIntegrator rămâne obligatoriu
Butonul „Export XML" salvează reprezentarea internă a motorului de raportare, nu structura de depunere a decontului. Nu se încarcă în DUKIntegrator și nu are legătură cu schema oficială a D300. E util pentru arhivare sau pentru prelucrare proprie, atât. Ghidul de utilizare nu face distincția, iar confuzia e ușor de făcut.
Merită repetat, pentru că e punctul cel mai ușor de înțeles greșit: niciunul dintre cele două tool-uri nu înlocuiește DUKIntegrator. Validarea structurii fișierului SAF-T și generarea PDF-ului de depunere rămân acolo. Cele două vin în plus, pe zona de conținut al datelor.
Butonul care ar fi schimbat totul
Al doilea tool produce rândurile de decont din SAF-T. Contribuabilul are deja decontul depus, tot ca fișier XML. Pasul care lipsește e chiar cel din titlul comunicatului: comparația.
Un al doilea buton, „încarcă și XML-ul D300", și un tabel cu patru coloane, rândul, valoarea din SAF-T, valoarea declarată de contribuabil și diferența, ar transforma un instrument informativ într-unul de reconciliere. Așa cum e acum, comparația o faci ochiometric, rând cu rând, între un PDF și o declarație. Pentru un cabinet cu 30 de clienți, asta înseamnă 30 de comparații manuale pe lună.
În aceeași categorie de îmbunătățiri simple intră și:
- recompunerea declarațiilor segmentate, condiție minimă pentru contribuabilii mari
- o comparație automată între totalurile declarate în Header și cele calculate, cifre pe care tool-ul deja le are amândouă
Nu e o critică a intenției, ci a stadiului. Direcția e bună, dar pașii puteau fi duși până la capăt: 33 de teste publicate meritau 33 de teste implementate, iar un tool care scoate rândurile decontului din SAF-T merita să poată citi și decontul depus, ca să spună singur unde nu se potrivesc.
Cum le folosești luna asta
Cu limitele de mai sus asumate, tool-urile rămân utile. Concret:
Validează întâi fișierul cu DUKIntegrator. Cele două tool-uri presupun o declarație deja corectă structural. Ele se uită la conținut, nu la formă, iar ordinea contează.
Rulează apoi tool-ul de consistență, pe XML-urile lunii. Dacă apare fișierul de erori, ai ce corecta. Dacă nu apare, înseamnă doar că ai trecut de cele 11 teste, nu că declarația e completă.
Deschide și fișierul Header, chiar dacă nu ai erori. Compară numărul de linii și totalurile rulajelor cu cele declarate în fișier. Sunt două verificări pe care tool-ul ți le pregătește, dar nu ți le face.
Rulează al doilea tool și compară rândurile mari: livrările pe cote, achizițiile pe cote, taxarea inversă. Acolo corespondența e cea mai directă și potrivirea cea mai probabilă.
Nu te aștepta la potrivire pe rândurile de regularizare, pe soldul din perioada precedentă și, dacă aplici TVA la încasare, nici pe rândurile de bază. O diferență nu înseamnă automat că ai greșit tu.
Va deveni SAF-T sursa decontului precompletat?
Întrebarea vine natural, uitându-te la al doilea tool. Răspunsul scurt: formal, SAF-T este deja o sursă.
Decontul precompletat RO e-TVA, reglementat prin OUG 70/2024, își ia datele din RO e-Factura, RO e-Transport, RO e-Sigiliu, RO e-SAF-T, casele de marcat electronice și sistemul vamal. SAF-T e pe listă de la început. Ce a lipsit până acum a fost partea publică și verificabilă: maparea concretă a codurilor de taxă pe rândurile decontului.
Exact asta face acum instrumentul 7. Iar cine publică o mapare cod de taxă către rând de decont o face fiindcă are de gând să o folosească.
Există și un argument de fond, dincolo de intenție. E-Factura acoperă foarte bine facturile. Nu acoperă însă ce nu trece prin factură: autofacturarea, ajustările de taxă, pro-rata, taxarea inversă înregistrată prin note contabile, exigibilitatea amânată. Toate astea trăiesc în contabilitate, deci în SAF-T. Pentru un decont precompletat care să prindă și rândurile de regularizare, nu doar rândurile de vânzări și cumpărări, SAF-T e singura sursă disponibilă.
Ce ne face prudenți: perioada de testare declarată până în noiembrie 2026 și motivul pentru care tool-urile au apărut, spus chiar de ANAF, adică erorile și neconcordanțele găsite în etapa pilot. Nu se precompletează un decont din date despre care știi că au probleme. Întâi cureți datele, apoi le folosești. Tool-urile astea sunt, cel mai probabil, exact partea de curățare.
Ce înseamnă pentru tine, dacă direcția se confirmă: codurile de taxă din SAF-T încetează să mai fie o formalitate de export, bifată o dată la implementare și uitată. Ele ajung să alimenteze rândurile decontului precompletat, adică versiunea pe care ANAF o construiește din datele proprii și o pune alături de decontul tău.
Decontul de TVA îl întocmești în continuare tu, pe baza evidenței proprii. Ce se schimbă e sursa comparației. Un cod de taxă pus greșit în contabilitate nu mai rămâne o scăpare internă, fără efect vizibil: produce o diferență între cele două deconturi, iar diferența ajunge notificare de conformare, cu termen de răspuns.
Concluzie
Sunt pași corecți și merită spus clar. Tool-urile rulează local, nu trimit nimic nicăieri, răspund unei nevoi reale și vin cu un canal de feedback deschis. Până acum, singura verificare disponibilă venea sub formă de notificare, după depunere. Faptul că testele de consistență au încetat să mai fie doar text într-un comunicat și au devenit un instrument care le aplică este, în sine, o schimbare bună.
Sunt și pași timizi. Din 33 de teste publicate, 11 sunt implementate. Transpunerea în format D300 nu se compară singură cu decontul depus, deși exact asta e nevoia din spatele comunicatului. Fișierele modale sunt acoperite parțial, iar TVA la încasare rămâne o zonă în care rezultatul trebuie verificat separat.
Perioada de testare durează până în noiembrie. Merită folosită, chiar dacă rezultatele se citesc cu rezervele de mai sus, și merită trimis feedback. Așteptăm cu interes următorii pași.