ANAF a lansat două aplicații pentru verificarea SAF-T. Ce rezolvă și ce rămâne în firmă

Pe 26 august, ANAF a anunțat două aplicații gratuite pentru verificarea datelor raportate prin declarația D406 SAF-T.

Prima verifică dacă informațiile din fișierul SAF-T sunt complete și coerente.

A doua folosește datele din SAF-T pentru a genera o structură similară decontului de TVA D300, astfel încât diferențele dintre cele două raportări să poată fi observate mai ușor.

Este o veste bună.

ANAF estimează că aproximativ 870.000 de societăți au obligația de a depune SAF-T. Dintre acestea, aproape 580.000 depun și D300 și pot beneficia direct de verificarea suplimentară.

Dar este important să înțelegem exact ce fac aceste aplicații și, mai ales, unde se opresc.

Ce face prima aplicație

Prima aplicație verifică declarațiile D406 deja generate în format XML.

Utilizatorul selectează directorul în care se află fișierele SAF-T, iar aplicația rulează o serie de teste de consistență. La final, produce fișiere CSV cu informații despre declarația verificată și, dacă este cazul, cu erorile identificate.

Verificările pot semnala probleme precum:

• informații lipsă despre companie;
• date incomplete despre clienți sau furnizori;
• coduri fiscale ori coduri de taxă necompletate;
• diferențe între soldurile inițiale sau finale;
• unități de măsură și coduri de produs lipsă;
• valori TVA care nu corespund regulilor aplicabile;
• informații inconsistente între secțiunile fișierului SAF-T.

Avantajul este clar: problema poate fi observată înainte ca declarația să fie transmisă.

Este mai ieftin să corectați o informație înainte de depunere decât după o notificare de neconformitate.

Ce face a doua aplicație

A doua aplicație pornește tot de la fișierul XML SAF-T.

Pe baza informațiilor din acesta, generează o reprezentare a declarației D300, care poate fi exportată în PDF, XML sau JSON.

Scopul este să facă mai ușoară comparația dintre TVA-ul rezultat din datele SAF-T și cel declarat prin D300.

Dacă, de exemplu, anumite operațiuni au fost încadrate diferit, dacă lipsesc tranzacții sau dacă unele coduri fiscale nu au fost asociate corect, diferențele pot deveni vizibile înainte de depunere.

Aplicația nu înlocuiește D300 și nu decide care dintre valori este corectă.

Dar oferă un punct de control suplimentar.

Datele rămân pe calculatorul utilizatorului

Un detaliu important este că verificările se fac local, pe calculatorul utilizatorului.

Potrivit ANAF, în această etapă datele analizate de cele două aplicații nu sunt transmise instituției.

Aplicațiile sunt în testare în perioada septembrie–noiembrie 2026, iar ANAF solicită feedback din partea utilizatorilor.

Instrumentele și documentația pot fi descărcate din secțiunea SAF-T a portalului ANAF, la punctele 6 și 7.

Ce rezolvă, concret

Pentru firme și contabili, cele două aplicații pot reduce o parte importantă din incertitudinea de dinaintea depunerii.

Ele pot ajuta la:

• identificarea informațiilor lipsă;
• verificarea consistenței interne a fișierului;
• descoperirea unor codificări fiscale incorecte;
• compararea mai ușoară a datelor SAF-T cu D300;
• reducerea numărului de declarații incomplete sau incorecte;
• documentarea mai clară a erorilor care trebuie remediate.

Pentru o firmă care folosește deja un program contabil bine configurat și generează SAF-T dintr-o singură sursă, acestea pot fi exact instrumentele de verificare care lipseau.

Nu orice problemă necesită un nou produs sau o dezvoltare personalizată.

Uneori, un instrument gratuit și o configurare mai bună a programului existent sunt suficiente.

Dar aplicațiile verifică fișierul, nu întregul proces

Ambele instrumente pornesc de la un fișier SAF-T deja generat.

Aceasta este și limita lor principală.

Ele pot semnala că un cod de taxă lipsește, că un sold nu se potrivește sau că valoarea rezultată pentru D300 este diferită.

Dar nu pot întotdeauna să spună de ce s-a întâmplat.

Cauza poate fi:

• o informație lipsă din nomenclatorul ERP-ului;
• o factură care nu a fost importată în contabilitate;
• un document înregistrat de două ori;
• o tranzacție introdusă într-o perioadă greșită;
• un produs configurat diferit în două sisteme;
• o regulă de mapare incorectă;
• o modificare făcută într-un sistem, dar nu și în celălalt;
• un export incomplet dintr-o aplicație veche.

Aplicația vede rezultatul acestor probleme în fișierul SAF-T.

Nu vede neapărat traseul prin care informația a ajuns acolo.

A găsi eroarea nu este același lucru cu a o corecta

Să presupunem că aplicația arată o diferență între SAF-T și D300.

Următoarea întrebare este:

Unde trebuie făcută corecția?

În programul contabil?

În ERP?

În nomenclatorul de produse?

În înregistrarea unei facturi?

În regula prin care datele sunt transferate între sisteme?

Dacă diferența apare o singură dată, poate fi o excepție ușor de rezolvat.

Dacă apare lunar, atunci problema nu mai este doar declarația.

Este procesul care produce declarația.

În acest caz, corectarea manuală a fișierului final poate rezolva raportarea curentă, dar nu elimină cauza. Luna următoare, aceeași muncă va trebui făcută din nou.

Unde rămâne loc pentru automatizare

Aplicațiile ANAF pot deveni o etapă foarte bună de control înainte de depunere.

Dar într-un flux mai larg pot exista în continuare operațiuni precum:

• exportarea datelor din mai multe sisteme;
• asocierea clienților și furnizorilor între aplicații;
• verificarea facturilor care există în e-Factura, dar nu și în contabilitate;
• compararea totalurilor dintre facturare, ERP și contabilitate;
• identificarea documentelor duplicate sau lipsă;
• trimiterea fiecărei diferențe către persoana care o poate rezolva;
• urmărirea corecției până la închiderea excepției;
• rularea din nou a verificărilor după remediere.

O parte dintre acestea poate fi automatizată.

Nu prin înlocuirea validatorului ANAF, ci prin conectarea lui la un proces mai bine organizat.

De exemplu:

sisteme interne → generare SAF-T → verificare ANAF → listă de erori → identificarea sursei → corecție → reverificare

Într-un proces manual, un om urmărește acest traseu prin fișiere, e-mailuri și mai multe aplicații.

Într-un proces bine conectat, sistemul poate identifica automat sursa probabilă a diferenței, poate atașa informațiile relevante și poate trimite excepția către persoana potrivită.

Decizia contabilă rămâne la om.

Munca de căutare și transfer poate fi redusă.

Ce am face înainte să cumpărăm ceva

Am începe prin a folosi instrumentele gratuite.

Apoi am urmări:

• câte erori sunt identificate;
• ce tipuri de erori se repetă;
• în ce sistem apare cauza;
• cât timp durează investigarea;
• cine trebuie să intervină;
• dacă aceeași corecție este făcută în fiecare lună;
• dacă problema poate fi eliminată prin configurarea programului existent.

Dacă verificarea trece fără probleme și procesul consumă puțin timp, probabil nu este nevoie de altceva.

Dacă apar aceleași diferențe lună de lună, dacă datele vin din mai multe sisteme sau dacă investigația durează ore ori zile, merită analizat fluxul din spatele fișierului.

Pentru că un validator bun vă spune că există o problemă.

Un proces bun face ca problema să nu mai apară.

Un pas util, dar nu ultimul

Cele două aplicații ANAF completează un gol important: permit firmelor să verifice mai bine datele înainte de depunerea SAF-T.

Pentru multe companii, acestea pot fi suficiente împreună cu programul contabil pe care îl folosesc deja.

Pentru altele, vor face vizibilă o problemă care exista de mai mult timp: aceleași informații sunt păstrate diferit în mai multe sisteme, iar cineva trebuie să le împace manual la finalul lunii.

În acest caz, problema nu este validatorul și nici fișierul SAF-T.

Este munca rămasă între sistemele care au produs fișierul.