Iar aceasta este o schimbare mult mai importantă pentru companii decât poate părea la prima vedere.
La finalul lunii august, ANAF a publicat două aplicații gratuite prin care contribuabilii își pot verifica declarația D406 înainte de depunere. Le-am testat și continuăm să le testăm, iar dincolo de utilitatea lor imediată, cred că ele transmit un semnal important despre direcția în care merge administrarea fiscală din România.
ANAF începe să privească dincolo de fișierul XML
Mult timp, discuția despre SAF-T s-a concentrat pe capacitatea companiilor de a genera și depune corect fișierul. Validatorul DUKIntegrator verifică însă în principal dacă fișierul respectă structura solicitată de ANAF: dacă există câmpurile necesare și dacă informațiile au formatul așteptat.
De aici apare una dintre cele mai importante distincții pe care companiile ar trebui să o facă astăzi: „Validat” nu înseamnă neapărat „corect”.
Un fișier poate trece de validarea tehnică și totuși să conțină coduri de taxă mapate greșit în ERP, tranzacții relevante pentru TVA fără codurile corespunzătoare sau informații care nu se corelează cu alte secțiuni ale raportării.
Până acum, asemenea probleme puteau rămâne relativ puțin vizibile. Pe măsură ce ANAF începe să folosească efectiv datele SAF-T, situația se schimbă.
De la colectarea datelor la reconcilierea lor
Cele două noi instrumente merg exact în această direcție. Primul permite contribuabilului să ruleze înainte de depunere testele de consistență stabilite de ANAF. Până acum, pentru unele dintre aceste verificări, problema putea fi identificată după depunere, când contribuabilul primea o notificare în SPV și trebuia să revină asupra declarației. Noul mecanism mută verificarea înainte de depunere.
Al doilea instrument mi se pare chiar mai interesant din perspectiva evoluției sistemului fiscal: ANAF poate genera un decont de TVA precompletat pe baza informațiilor din SAF-T. Cu alte cuvinte, contribuabilul poate vedea mai clar cum interpretează ANAF datele pe care compania însăși le-a raportat. Iar aici cred că se află adevărata schimbare.
Nu mai discutăm doar despre întrebarea „Am transmis D406?”, ci despre întrebări precum:
Datele din D406 spun aceeași poveste fiscală ca D300? Dar ca D394, D390, e-Factura sau celelalte informații aflate deja la dispoziția ANAF?
Pe termen lung, tocmai aceste comparații pot deveni extrem de relevante pentru analiza de risc fiscal.
Mai multă transparență, dar încă nu suficientă
Noile aplicații reprezintă, în opinia mea, un pas înainte. În primul rând, verificările sunt gratuite și disponibile oricărui contribuabil. Mai important, ele oferă companiilor o perspectivă pe care până acum nu o aveau suficient de clar: cum interpretează ANAF anumite informații SAF-T din perspectiva TVA. Dar testarea lor arată și limitele actualului proces.
În prezent, contribuabilul ajunge să lucreze cu trei instrumente distincte de verificare, dacă includem și DUKIntegrator. Rezultatele testelor de consistență sunt afișate prin coduri precum NOK-01 sau NOK-02, care nu sunt întotdeauna intuitive pentru utilizator. Iar decontul precompletat prezintă totalurile, fără să arate tranzacțiile care au construit fiecare sumă, ceea ce poate face reconcilierea cu D300 dificilă.
În testele noastre am identificat și erori punctuale în decontul precompletat, inclusiv situații în care anumite coduri de taxă sunt preluate pe mai multe rânduri sau totalurile nu sunt calculate corect. Odată cu publicarea celei mai recente versiuni a aplicației de către ANAF (D300 din SAF-T), o parte semnificativă din aceste neconcordanțe a fost deja remediată. Este firesc ca astfel de probleme să existe într-o etapă de testare, important este ca ajustările să continue în același ritm înainte ca instrumentele să devină parte dintr-un mecanism fiscal cu consecințe mai ample.
Companiile nu ar trebui să aștepte ca ANAF să găsească diferențele
Aceasta este, pentru mine, concluzia practică cea mai importantă. Aplicațiile sunt în testare până în noiembrie 2026, iar ANAF solicită contribuabililor feedback privind problemele identificate. Pilotul inițial a inclus doar 34 de contribuabili, potrivit declarațiilor reprezentanților ANAF, în timp ce aproximativ 870.000 de contribuabili depun SAF-T.
Este o diferență uriașă de scară. Niciun pilot de asemenea dimensiune nu poate reproduce toate particularitățile care apar în sute de mii de companii, industrii, sisteme ERP și tipuri de tranzacții.
De aceea, firmele ar trebui să folosească această perioadă nu doar pentru a testa noile aplicații, ci și pentru a-și testa propriile date.
Aș merge chiar mai departe: companiile ar trebui să ruleze verificările inclusiv pentru declarațiile deja depuse, nu doar pentru următoarea D406. Dacă există o diferență între ceea ce compania crede că a raportat și ceea ce ANAF poate deduce din acele date, este preferabil ca firma să descopere prima acea diferență.
Problema nu se termină atunci când găsești eroarea
Există însă o limită importantă a oricărui validator: poate semnala că există o problemă, dar nu elimină cauza ei. Dacă diferența provine dintr-o mapare greșită în ERP, dintr-o configurare a aplicației care generează SAF-T sau dintr-o înregistrare modificată ulterior, simpla identificare a erorii nu presupune si corecția ei în raportarea curentă sau în raportările viitoare.
Aici cred că trebuie să evolueze și modul în care companiile privesc tehnologia fiscală. Nu mai este suficient să avem un instrument care spune „există o eroare”. Avem nevoie de procese și soluții care să ne ajute să înțelegem unde este eroarea, ce tranzacții au generat-o, cum se reflectă în celelalte declarații și cum poate fi corectată.
Exact aceasta este și problema pe care încercăm să o rezolvăm prin Latitude App: reunirea verificărilor ANAF într-un singur flux, explicarea erorilor, reconcilierea la nivel de rând cu D300 și posibilitatea de a interveni asupra declarației atunci când corecția în sistemul-sursă nu mai poate fi făcută imediat, ca de exemplu:
- perioada contabilă/de raportare este deja închisă
- eroarea vine din configurarea ERP-ului
- configurare greșită a aplicației care generează SAF-T
- o înregistrare a fost modificată după exportul SAF-T
În astfel de situații, posibilitatea de a corecta declarația în afara sistemului contabil permite rezolvarea problemei pentru raportarea curentă, fără a aștepta modificarea sistemului-sursă.
SAF-T începe să devină infrastructură fiscală, nu doar o declarație
Astfel, se conturează una dintre cele mai importante direcții pentru următorii ani. România a construit într-un timp relativ scurt un ecosistem fiscal digital format din SAF-T, e-Factura, e-TVA și alte surse de date. Valoarea pentru administrația fiscală nu vine însă din existența fiecărui sistem separat, ci din capacitatea de a pune aceste informații una lângă alta și de a identifica automat neconcordanțele.
În acest context, este anticipată și posibilitatea ca informațiile din decontul precompletat SAF-T să ajungă să fie corelate prin e-TVA cu D300, D394, D390, e-Factura, declarațiile vamale și datele caselor de marcat.
Dacă aceasta este direcția, atunci și întrebarea pe care ar trebui să și-o pună directorii financiari se schimbă. Nu doar: „Am depus SAF-T la timp?”, ci: „Dacă ANAF ar pune astăzi toate datele noastre fiscale una lângă alta, ar spune ele aceeași poveste?”. Pentru mine, aceasta este adevărata miză a noilor aplicații.
SAF-T nu mai trebuie privit ca o obligație tehnică pe care compania o bifează lunar sau trimestrial. Devine treptat una dintre sursele prin care autoritatea fiscală poate înțelege activitatea financiară a unei companii, poate identifica diferențe și, în timp, poate fundamenta analiza de risc și controlul fiscal.
Iar într-un asemenea sistem, calitatea datelor înainte de depunere va conta cel puțin la fel de mult ca depunerea în sine.
