Cum verifici fișierul SAF-T D406 înainte de depunere

În articolul precedent am descris obiectul: de unde vine SAF-T, cum a ajuns la noi prin OG 11/2021, ce conține fișierul, cine depune, până când și ce riscă cine greșește. Cine a sărit peste el poate să se întoarcă oricând, pentru că aici nu reluăm nimic din acea parte.

Articolul acesta continuă exact de unde se oprea celălalt, cu întrebarea practică: cum verifici datele din XML înainte să depui. Nu „cum generezi fișierul”, ci ce faci cu el între momentul în care softul de contabilitate îl produce și momentul în care apeși butonul de transmitere.

E o întrebare care pare rezolvată și nu e.

In DUK we trust

Bancnota americană de un dolar poartă tipărită formula „In God we trust”. Pentru ce facem noi în fiecare lună cu D406, formularea corectă ar fi „In DUK we trust”.

Nu e neapărat o glumă care circulă, e felul nostru de a descrie o practică reală: generăm fișierul, îl trecem prin DUKIntegrator și citim în caseta de rezultat trei rânduri, „Validare fara erori fisier”, „Fisierul PDF a fost creat cu succes” și, dacă am bifat și semnarea la lansarea validării, „Fisierul PDF a fost semnat cu succes”. Depunem și considerăm subiectul închis până luna următoare. Încrederea nu vine dintr-o verificare făcută de noi, vine din trei rânduri de text scrise de altcineva.

Problema e că rândurile acelea nu spun ce credem noi că spun. „Validare fără erori fișier” înseamnă exact ce scrie: validare. Iar cuvântul acesta are, în DUKIntegrator, un sens mult mai îngust decât cel din vorbirea curentă.

Ce face, de fapt, DUKIntegrator

DUKIntegrator verifică dacă fișierul XML respectă schema XSD publicată de ANAF. Atât.

Întrebarea pe care merită să ne-o punem, înainte de orice discuție despre unelte, e simplă.

Este un fișier SAF-T validat de DUKIntegrator complet și corect din perspectivă contabilă și fiscală?

Nu neapărat. Validarea confirmă că fișierul e construit după schemă, nu că datele din el sunt cele corecte. Sunt două întrebări diferite, iar validatorul răspunde doar la prima.

Pentru cine nu lucrează cu scheme XML, comparația cea mai apropiată e din propria noastră meserie: e diferența dintre a verifica dacă o balanță are toate coloanele la locul lor și a verifica dacă balanța este echilibrată.

Mai e un nivel pe care îl uită aproape toată lumea. Validarea nu se termină la DUK. După transmitere apar erorile de validare globală returnate prin recipisă, iar acolo pot să iasă la iveală lucruri pe care validatorul local nu le-a atins. În regimul de depunere modală, fiecare dintre cele trei module are propria recipisă, iar un modul respins oprește lanțul: modulul 2 nu se transmite până când recipisa 1 nu e în regulă, iar modulul 3 până când recipisa 2 nu e în regulă.

Un fișier „validat” poate să fie, așadar, un fișier respins. Și un fișier acceptat poate să fie un fișier greșit.

De ce contează acum mai mult decât acum doi ani

Până în 2025, subiectul a fost mai amortit decât pare azi. ANAF a marșat, pe bună dreptate, pe extinderea sistemului: aducerea în obligație a categoriilor de contribuabili, una după alta, cu calendare, amânări și perioade de grație. Prioritatea a fost ca declarațiile să ajungă, nu ca ele să fie corecte până la ultima linie. Amenzile spun același lucru: 5.000 de lei maximum pentru nedepunere, între 500 și 1.500 de lei pentru depunere incorectă sau incompletă.

Nu înseamnă că verificarea nu se justifica. Înseamnă că nimeni nu ți-o cerea. Fișierul intra în bazele de date ANAF și rămânea acolo, ca depozit pentru un eventual control viitor.

În 2026 se schimbă natura problemei, iar schimbarea are un nume: proiectul pilot.

Prin comunicatul nr. 1010 din 7 octombrie 2025, ANAF a anunțat un program pilot cu obiectiv declarat explicit: „implementarea unui mecanism de verificare a consistenței datelor declarate prin declarația D406 prin comparare cu informațiile furnizate prin D300, respectiv D301”. Perioada anunțată, septembrie 2025 până în august 2026. Participanții, maximum 50 de companii, selectate voluntar din categorii diferite, mari, mijlocii și mici, active în domenii variate: construcții, bănci, energie, asigurări sau comerț.

La eșantion contează diversitatea, nu numărul. Un pilot care ia și o firmă mică, și o bancă, înseamnă și planuri de conturi diferite, și programe de contabilitate diferite, și moduri diferite de a mapa aceleași operațiuni. Nu e un test de laborator pe un singur ERP.

Cât de bine a mers se citește, indirect, chiar din comunicatul din august 2026: aplicațiile „au fost dezvoltate după ce, în etapa pilot, au fost identificate situații în care datele transmise conțineau erori sau neconcordanțe”. Uneltele gratuite nu sunt un cadou, sunt o consecință.

Detaliul care contează e metodologia: analiza diferențelor se face pe fiecare rând al decontului de TVA, nu la nivelul sumei finale de plată.

Aici e util spus limpede ce nu se schimbă, ca să se vadă ce se schimbă. Comparația pe rând de decont există deja: notificarea de conformare RO e-TVA se declanșează la diferențe semnificative între valorile din rândurile decontului depus și valorile corespunzătoare din decontul precompletat, unde „semnificativ” înseamnă cumulativ minimum 20% și minimum 5.000 de lei în valoare absolută, pe fiecare rând. Nu pe total.

Ce se schimbă e sursa comparației, nu granularitatea ei. Astăzi, rândul precompletat se construiește din facturi și din alte declarații. Mâine, dacă pilotul se confirmă, se construiește din registrul jurnal.

Iar contextul de acum face schimbarea mai ușor de ratat. Din 1 ianuarie 2026, prin OUG 89/2025, obligația de a răspunde la notificarea de conformare a fost eliminată, împreună cu amenzile aferente, iar motivul invocat public a fost chiar incapacitatea ANAF de a procesa volumul de răspunsuri. Notificarea a devenit informativă. Un mecanism care se odihnește nu e însă un mecanism desființat, iar pilotul construiește exact partea care îi lipsea: o sursă de date mai bună decât mozaicul actual.

Merită observată și o distincție care se pierde ușor. Formal, SAF-T e sursă a decontului precompletat încă de la început: OUG 70/2024 îl enumeră alături de RO e-Factura, RO e-Transport, RO e-Sigiliu, casele de marcat electronice și sistemul vamal. Practic însă, lista surselor din care se construiește azi decontul precompletat P300 arată altfel: D394, D390, RO e-Case de marcat, RO e-Factura, registrul achizițiilor de locuințe cu cotă redusă, RO e-Transport și sistemul vamal. Adică un mozaic de declarații și sisteme, în care registrul jurnal din D406 nu intră încă efectiv. Pilotul testează exact schimbarea aceasta: de la șase surse indirecte, la contabilitatea propriu-zisă.

Consecința practică e cea mai importantă frază din tot articolul acesta, și era deja în cel precedent: ANAF nu extrage TVA-ul din factură, îl extrage din nota contabilă. O factură perfectă în e-Factura, dar contabilizată pe un cod de taxă greșit, produce o diferență. Nu o eroare de formă, o diferență de TVA.

Iar cine urmărește documentația ANAF de mai multă vreme știe că nu e o surpriză. Ultimul dintre testele de consistență publicate în august 2024 spunea, negru pe alb, că sumele din TaxAmount pe fiecare TaxCode trebuie să corespundă cu decontul de TVA. ANAF a anunțat în 2024 ce face în 2026.

Ce a pus ANAF la dispoziție pe 26 august 2026

Aici trebuie spus limpede, înainte de orice nuanță: ANAF a făcut un pas real și util.

Prin comunicatul nr. 782 din 26 august 2026, au fost publicate două aplicații gratuite, la instrumentele 6 și 7 de pe pagina SAF-T a portalului. Le-am testat pe amândouă și le-am analizat pe larg în articolul dedicat, așa că aici le luăm doar ca piesă din tabloul general.

Câteva detalii care contează în practică:

• sunt în testare, în perioada septembrie - noiembrie 2026, iar ANAF cere explicit feedback;
• rulează local, pe calculatorul utilizatorului, fără transmiterea datelor către ANAF în această fază. E un punct pe care merită să insistăm, pentru că răspunde din start celei mai serioase obiecții pe care o are oricine lucrează cu fișiere care conțin toată contabilitatea firmei;
• rezultatul primei aplicații e un set de fișiere CSV cu delimitatorul „#”: un fișier de tip Header cu informații generale, plus un fișier de erori, generat doar dacă există erori;
• niciuna nu înlocuiește DUKIntegrator. Vin după el, pe un fișier deja valid structural, și se uită la conținut;
• adresabilitatea, din același comunicat: circa 870.000 de firme depun D406, dintre care circa 580.000 depun și decont de TVA.

A doua aplicație e, de fapt, cel mai bun indiciu despre direcția în care merge lucrul. Îți arată ce decont va construi ANAF din datele tale. Nu îți spune că datele sunt corecte, îți spune ce va vedea administrația fiscală când se va uita la ele.

De ce nu e suficient

Recunoașterea de mai sus rămâne în picioare. Dar cele două aplicații nu acoperă decât o parte din problemă, și e cinstit să spunem care.

Rulează un set fix de teste, definit de ANAF, și nici măcar pe tot. Testele de consistență sunt 33, publicate în două serii: 22 în martie 2023 și 11 în august 2024. Aplicația acoperă integral seria a doua și nimic din prima, adică exact verificările pe care un contabil le-ar face greu de mână: completarea nomenclatoarelor, egalitatea și continuitatea soldurilor, egalitatea rulajelor din jurnal, coerența sumelor în valută.

Nu verifică maparea, care e partea cea mai specifică din tot fișierul. Corespondența dintre planul tău de conturi și conturile standardizate din schemă, dintre tipurile tale de documente și nomenclatorul de documente, dintre operațiunile tale și codurile de taxă, s-a stabilit o singură dată, la implementare, în firma ta. De atunci se aplică automat, lună de lună. Un test generic vede că un cod de taxă e completat și că se potrivește cu cota. Nu are cum să vadă că e codul greșit pentru operațiunea aceea, pentru că nu știe ce operațiune a fost.

Tot de aici vin și verificările pe care doar tu le poți formula. Că toate analiticele tale de clienți se regăsesc pe același cont standardizat din schemă, nu împrăștiate pe două, fiindcă cineva a adăugat un analitic nou după implementare și nu l-a mapat. Că partenerii din grup, pe care doar tu îi știi, apar consecvent cu codul de taxare inversă și se regăsesc și în recapitulativul D390. Că fiecare factură din secțiunea de documente-sursă are corespondent în registrul jurnal, pentru fluxurile în care cele două se despart: autofacturare, stornări, note de credit. Niciun instrument construit pentru 870.000 de firme nu poate cunoaște maparea uneia singure.

Îți dau erori, nu date. Un CSV cu linii care au picat testul nu e același lucru cu a putea privi conținutul fișierului. Problema de fond, aceea că nu poți citi ce depui, rămâne întreagă.

Nu acoperă reconcilierea cu propria contabilitate. SAF-T față de balanța lunară, față de situația analitică a clienților și a furnizorilor, față de registrele de casă și bancă, față de situația imobilizărilor. Nimeni din afara firmei nu poate face verificarea asta, nici ANAF. Nu pentru că nu ar vrea, ci pentru că nu are datele.

Sunt în testare. Cu un orizont declarat până în noiembrie 2026. Procedura lunară a unui cabinet nu se construiește pe un instrument aflat în testare.

Aplicațiile ANAF acoperă un nivel dintr-o problemă care are cinci.

Grila de citire: cele cinci niveluri de verificare

Ca să nu ne pierdem în enumerări, merită fixat un cadru. Orice soluție discutată mai jos se așază pe unul dintre nivelurile acestea.

Nivelul zero merită dezvoltat aici, pentru că e gratuit, e cel mai eficient și îl sare aproape toată lumea. Lista nu trebuie inventată: prima serie de teste de consistență publicată de ANAF, cea din martie 2023, e ea însăși un checklist de reconciliere internă, iar documentațiile publice ale furnizorilor de software repetă aceleași corelații.

Se rezumă la a compara fișierul cu ceea ce știi deja că e corect. Rulajul lunar din balanță trebuie să dea același lucru cu registrul jurnal, iar soldurile de deschidere ale lunii trebuie să fie exact soldurile de închidere ale lunii precedente. Restul sunt corelații pe care le faci oricum la închidere: balanța partenerilor și cea a stocurilor față de balanța contabilă, verificate pe solduri, nu pe rulaje, stocurile pe conturi față de stocurile la moment, registrele de casă și bancă față de balanță, iar la imobilizări amortizările curente față de rulajul conturilor 28x și valoarea rămasă față de diferența soldurilor finale.

Noi lucrăm în tabele, fișierul e un arbore

Aici ajungem la partea care ne privește direct, ca profesie.

Contabilul lucrează tabelar. Balanța e un tabel. Jurnalul e un tabel. Fișa de cont e un tabel. Pivotul e tot un tabel. Instrumentul pe care îl stăpânim, în care ne mișcăm repede și în care avem intuiție pentru ce e greșit, e foaia de calcul.

XML-ul e un arbore. Elemente imbricate pe mai multe niveluri, fiecare cu propriii copii, repetate de zeci de mii de ori. Nu e un defect al formatului, e chiar destinația lui: a fost proiectat ca să fie parcurs de un program, nu citit de un om.

Între fișierul pe care îl depui și instrumentul cu care știi să lucrezi există, deci, o traducere obligatorie. Iar întrebarea reală nu e „cum verific SAF-T”, ci „cum transform un XML arborescent într-un tabel”.

Întâi Notepad, apoi Excel

Toți am avut curiozitatea să vedem cum arată datele din XML. Iar unealta la îndemână a fost editorul de text deja instalat pe calculator, în cele mai multe cazuri clasicul Notepad. Se deschide, într-adevăr. Fișierul e text simplu, nu are nevoie de niciun program special.

Numai că, la prima înșiruire de etichete, gândul e același pentru toată lumea: cum transform totul într-un tabel, ca să pot citi. Notepad îți arată fișierul, nu datele. Vezi că informația e acolo, undeva între paranteze unghiulare, dar nu poți nici să o filtrezi, nici să o sortezi, nici să o aduni.

De acolo, pasul următor pentru mare parte dintre noi a fost de a încerca să găsim o soluție în Excel.

Fila Developer, XML Source și maparea XML. Importi schema, mapezi elementele pe coloane, aduci datele. Funcționează frumos pe structuri plate. Se comportă prost pe scheme cu liste imbricate repetitive, unde Excel fie refuză maparea, fie denormalizează în feluri pe care nu le controlezi. Schema SAF-T e exact genul de structură care produce probleme.

Data, Get Data, From XML. Mai comod ca punct de plecare, dar te lasă cu tabele imbricate pe care tot trebuie să le expandezi manual, nivel cu nivel.

Power Query. Cea mai robustă dintre cele trei, și singura care merită investiție. Expandezi controlat, filtrezi, agregi, iar luna următoare reîmprospătezi fără să refaci munca. E și cea mai lentă pe fișiere mari, iar pașii de expandare pe o structură cu multe niveluri devin repede greu de întreținut de altcineva decât cel care i-a scris.

Unde cedează

Limita unei foi de calcul e de 1.048.576 de rânduri. E o cifră pe care o știe orice contabil și care, în discuția asta, nu e problema.

Problema e mai devreme. Peste 400.000 - 500.000 de linii, cu un număr rezonabil de coloane, Excel lucrează deja la limită. Recalculări de zeci de secunde, fișiere de sute de megabiți, blocaje la sortare și la filtrare, pivot tables care nu se mai reîmprospătează.

Iar volumele sunt exact acolo. Pentru o firmă medie, un D406 lunar ajunge fără efort la zeci sau sute de mii de linii, dacă desfaci registrul jurnal la nivel de linie. Pentru companiile mari, cifrele sunt deja de ordinul milioanelor. Nu vorbim despre un caz extrem, vorbim despre luna obișnuită a unui client obișnuit.

O nuanță, ca să nu spunem o inexactitate: Power Query poate încărca datele în Data Model, adică în Power Pivot, peste limita foii de calcul. Deci limita de 1.048.576 nu e absolută. Dar în momentul acela lucrezi cu un model tabelar și cu DAX, ai ieșit din zona de confort a foii de calcul și ai făcut, oricum, jumătate din drumul către un instrument dedicat.

Concluzia onestă e că traducerea se poate face, dar costă. Trei zile de construit și încă o zi pe lună de întreținut, pentru fiecare client, cu riscul ca la o schimbare de schemă să reiei o parte din muncă.

Ceea ce ne duce firesc la întrebarea următoare.

Direcția următoare: ce oferă piața

Dacă traducerea din XML în tabel și verificările de peste ea sunt o muncă repetitivă, deterministă și lunară, întrebarea rezonabilă e dacă nu cumva a construit-o deja cineva. Adică dacă există pe piață aplicații care rulează automat verificările, produc rapoarte detaliate cu elementele inventariate și cu neconcordanțele găsite, și fac reconcilieri între datele din SAF-T și informațiile contabile: balanțe lunare, situații analitice de clienți și furnizori, declarații.

Răspunsul scurt: da, există, mai multe decât se știe în general, și cu prețuri publice mult mai mici decât percepția din piață.

Ce fac programele de contabilitate și ERP-urile

Practic toate programele de contabilitate au un strat de validare proprie înainte de DUK: coduri fiscale invalide, parteneri fără date complete, unități de măsură fără corespondent, coduri de taxă necompletate.

Ce diferă de la un furnizor la altul e cât din mecanica asta se poate citi din afară. O parte dintre ei o publică. WinMENTOR ține documentația D406 pe serverul propriu de descărcare, deschis oricui, fără cont și fără cerere de ofertă. RVX ERP are manualul online, cu rapoartele de verificare enumerate pe secțiuni: vânzări și cumpărări fără cod SAF-T, articole cu unități de măsură invalide, conturi fără analitice, parteneri cu țară sau tip fiscal invalid, note contabile pe conturi de terți fără partener asociat. SmartBill Conta livrează, odată cu declarația, un fișier CSV de sinteză cu indicatori extrași din D406 și cu sugestii despre cum se corelează fiecare cu datele din contabilitate. Nexus ERP publică lista erorilor de validare și cauzele lor.

Merită oprit puțin la SAGA, probabil cel mai răspândit program de contabilitate din România, tocmai pentru că nu e un ERP și totuși documentează public procedura. Pagina lor de sfaturi practice pentru SAF-T trimite la o verificare care se rulează înainte de generare, din Administrare, Întreținere BD, fila Verificare date, butonul Verificare plan conturi. Compară planul de conturi din baza ta cu cel reglementat, semnalează analiticele de clienți și furnizori folosite în note dar inexistente în plan și le propune spre adăugare, iar la final scoate un raport cu ce s-a adăugat, ce s-a eliminat și ce ar trebui eliminat dar nu se poate, fiindcă are rulaj în spate.

Tot înainte de generare, programul verifică și lucrurile care par formalități până când opresc depunerea: datele de identificare ale firmei, telefon și email, existența măcar a unui cont bancar, încadrarea corectă la tipul de contabilitate și la categoria de TVA. Iar lista de erori scoate raportul cu ce trebuie corectat: denumiri de conturi incomplete, parteneri fără județ sau localitate, coduri fiscale greșite, coduri de nomenclator lipsă la articole.

Alții, printre care Charisma, Wizrom, Senior Software cu SeniorERP și SeniorXRP, Transart cu ERP-ul propriu, prezintă funcționalitatea la nivel de produs și lasă detaliul pentru clientul care are deja soluția implementată. E o alegere legitimă, nu o ascundere: SAF-T e un modul dintr-un ERP integral, nu un produs vândut separat, deci nu există niciun preț distinct de publicat. Manualul ajunge la client prin implementare, nu prin site.

Pentru cine alege un furnizor, distincția rămâne totuși utilă. Documentația publică îți permite să compari mecanica înainte de a intra în discuții comerciale. Cea livrată la implementare îți spune ce primești abia după ce ai semnat.

O observație transversală merită însă reținută, indiferent de furnizor: niciun program dintre cele de mai sus nu declară public reconcilierea SAF-T către decontul de TVA. Toate reconcilierile documentate sunt interne, SAF-T față de propria contabilitate. Exact golul pe care îl atacă pilotul ANAF.

Soluțiile dedicate românești

Segmentul cel mai interesant și cel mai puțin cunoscut. Aici sunt și singurele prețuri publice din toată piața.

Câteva note de precizie, pentru că cifrele de mai sus au vârste diferite. Prețul Tigris și grila Latitude au fost reconfirmate direct pe paginile furnizorilor la 29 august 2026. La Smart Validator, grila e publicată pe pagina de comandă a producătorului și e construită modular: licența de bază, plus un cod de validare pentru fiecare firmă, plus modulele pe care le alegi. La SAF-T Interpret, pagina publică nu afișează suma și pare neactualizată din noiembrie 2025.

Iar acum cifra care merită scoasă în evidență: pentru un cabinet cu 30 - 50 de clienți, 990 de lei pe an înseamnă între 20 și 33 de lei per client, pe an. Nu pe lună.

Big Four și restul, sau de ce nu vedem prețuri

O precizare despre ce urmează, fiindcă delimitează ce am reușit să documentăm. Aproape tot ce se poate citi public despre soluțiile de verificare venite din consultanță aparține celor patru firme mari, plus Crowe, prin Digital Mind. Dincolo de ele, nu am găsit firme de consultanță fiscală din eșalonul următor care să documenteze public un instrument dedicat de verificare SAF-T. Ce există în afara lor sunt furnizori de software și de servicii de raportare, adică exact categoria din tabelul de mai sus.

Iar despre ele există o constatare care se poate scrie fără nicio nuanță: niciuna dintre ele nu publică prețuri pentru soluțiile SAF-T. Fără excepție. Toate paginile de produs se termină cu un formular de contact.

Ce oferă, pe scurt: PwC are SAF-T cross-check, cu vizualizare pe secțiuni, validări de consistență între secțiuni și reconciliere între decont și SAF-T. KPMG are SAF-T Verifier și e-VAT Verifier, al doilea comparând decontul precompletat cu evidențele contabile. Deloitte are taxCube, instalabil inclusiv pe serverul clientului. EY prezintă în cadrul propriilor evenimente instrumente de verificare SAF-T care promit inclusiv reconcilierea datelor cu decontul de TVA. Direcția e aceeași pe care o descriu și public, în presă: controalele ANAF se mută pe corelarea automată a datelor raportate digital. În afara celor patru, Crowe, prin Digital Mind, are modulul SAF-T din ContaX, cu conectori direcți către ERP-uri românești.

Sunt, așadar, cei mai „secretoși” din toată piața când vine vorba de costul aplicațiilor de validare. Merită însă spusă și explicația rezonabilă, nu doar constatarea. O soluție de consultanță nu e un produs de raft, e o implementare: se adaptează la planul de conturi al clientului, la particularitățile lui de mapare, la ERP-ul lui, uneori la mai multe entități dintr-un grup, cu perioade fiscale diferite. În momentul în care livrezi ceva croit pe măsură, un preț fix afișat pe site devine, dacă nu imposibil, cel puțin înșelător pentru amândouă părțile.

Observația cea mai utilă din tot capitolul acesta e însă alta, și se poate verifica oricine. În martie 2023, doi consultanți PwC descriau public, într-un articol de specialitate, exact metoda pe care o vedem azi în aplicațiile gratuite ale ANAF: reconciliere între declarația SAF-T și datele-sursă din ERP, reconciliere între D406 și celelalte declarații periodice, în special D300 și D390, plus un set de teste de consistență rulate ca rutină lunară automatizată.

Cu alte cuvinte, modelul „îmi construiesc singur comparația, ca să știu ce va vedea ANAF” exista pe piață cu trei ani înainte ca ANAF să publice instrumentul care îl face gratuit. Ceea ce administrația tocmai a democratizat, consultanța vindea deja.

Cât costă, în context

Percepția din piață e că verificarea SAF-T e scumpă. Cifrele care circulă vin însă, aproape toate, din altă discuție: costul implementării, adică al ajustării programului de contabilitate ca să poată genera fișierul. Aia chiar a costat, și chiar a fost o dată. Nu are legătură cu ce discutăm aici, adică verificarea lunară a unui fișier deja generat.

Așezate una lângă alta, cifrele de mai sus arată altfel. Trei niveluri din cinci se acoperă gratuit: verificările din programul de contabilitate la N0, DUKIntegrator la N1, aplicația ANAF la N3. Ce lipsește, adică reconcilierea între secțiuni și cea cu celelalte declarații, se acoperă cu aproximativ 990 de lei pe an.

Ecartul dintre percepția de cost și oferta reală de piață e, în sine, un subiect.

Iar dacă 990 de lei pe an rezolvă ce ție ți-ar lua trei zile de construit în Power Query și încă o zi pe lună de întreținut, atunci cumperi. E o concluzie rațională, nu o capitulare.

Când soluțiile de piață nu sunt disponibile

Există însă situații, deloc rare, în care direcția de mai sus e închisă. Patru dintre ele, fără dramatizare.

Nu poți trimite fișierul în afara firmei. D406 conține datele fiscale complete ale firmei și ale tuturor partenerilor: solduri, facturi la nivel de linie, plăți, marje care se deduc din prețuri. Multe soluții sunt web, iar întrebarea „pe ce server ajunge fișierul și în ce jurisdicție” nu are întotdeauna un răspuns pe care să-l accepte departamentul juridic sau grupul din care faci parte. E corect spus că o parte dintre soluții rulează local, exact ca aplicațiile ANAF: SAF-T Interpret, Smart Validator, taxCube în varianta on-premise. Nu toate presupun trimiterea datelor afară. Dar disponibilitatea trebuie verificată de la caz la caz, nu presupusă.

Nu poți instala nimic local. În companiile cu politici de securitate stricte, instalarea unui executabil neaprobat e imposibilă, iar procedura de aprobare durează luni. Ironia e că asta blochează inclusiv aplicațiile gratuite ale ANAF, care sunt fișiere .jar și cer un mediu Java instalat.

Cine a lucrat într-o multinațională recunoaște imediat scena, pentru că problema apare deja la DUKIntegrator. Are nevoie de Java, de driverul token-ului USB și de acces la magazia de certificate din Windows, iar toate trei sunt exact lucrurile pe care o politică IT de grup le închide: fără runtime neaprobat, fără dispozitive USB, fără intervenții în magazia de certificate. Consecința practică e că, în multe firme, validarea și semnarea declarațiilor se fac de pe o stație scoasă din rețeaua corporativă, în afara domeniului și a VPN-ului, uneori pe o conexiune separată. Un instrument propriu de verificare, oricât de util, intră în aceeași fundătură.

Nu există buget. Nu pentru că 990 de lei ar fi mult, ci pentru că, în unele organizații, orice achiziție nouă declanșează un proces de aprobare complet disproporționat față de sumă.

Ai nevoie de verificări pe care nu ți le vinde nimeni. Maparea ta, analiticele tale, fluxurile tale. Un instrument generic nu are cum să știe pe ce cont standardizat ar trebui să cadă analiticul pe care l-ai deschis luna trecută, nici care dintre partenerii tăi sunt din grup și trebuie să apară consecvent cu taxare inversă.

În oricare dintre situațiile astea, rămâne o singură direcție. Și s-a deschis abia recent.

Aici intră vibe coding

SAF-T e cazul aproape ideal de problemă pe care AI-ul chiar o rezolvă: regulă deterministă, volum mare, format structurat, zero creativitate necesară. Nu e o problemă de judecată profesională, e o problemă de aplicat mecanic o regulă cunoscută pe foarte multe linii. Exact genul de muncă la care computerul e imbatabil și la care atenția unui om se epuizează după câteva sute de linii.

Constatarea care face argumentul credibil e că nu există alternativă gata făcută. Ecosistemul open-source pentru D406 e cvasi-inexistent. Căutările pe GitHub nu identifică niciun proiect activ dedicat parsării sau validării D406. Ce există pentru ANAF e aproape exclusiv pentru e-Factura, iar proiectele SAF-T mature aparțin altor jurisdicții, Norvegia și Portugalia, și nu se aplică României. Nu există un depozit de cod de la care să pornești.

Dar există materia primă, și e publică toată: schema XSD oficială, fișierul XLS cu definiții și note explicative, cele 33 de teste de consistență enunțate public de ANAF în cele două serii, nomenclatorul care mapează codurile de taxă pe rândurile decontului. Adică exact ce îi trebuie unui model ca să genereze cod determinist.

Întrebarea de la care pornim mai departe e aceasta: cum ar fi să-ți poți construi propria aplicație, care rulează pe calculatorul tău, care nu trimite nimic nicăieri, care costă zero și care face exact verificările specifice firmei tale?

Înainte de asta, trei precauții care nu se negociază:

• fișierul nu se încarcă în instrumente AI publice. Ce generezi cu AI e codul, nu prelucrarea datelor. Prelucrarea rămâne locală, pe calculatorul tău;
• AI-ul e bun la scris codul care aplică o regulă cunoscută, nu la a decide care e regula corectă. Enunțul testelor se ia din documentul ANAF, nu din memoria modelului;
• orice instrument propriu se calibrează pe o lună deja depusă și acceptată, ca să știi că dă aceleași cifre ca fișierul real.

Cu asta se încheie partea de diagnostic. Am parcurs ce face DUKIntegrator, ce a adăugat ANAF în august, unde cedează Excel-ul și ce se poate cumpăra de pe piață. Ce urmează nu mai e o analiză, e o construcție.

În articolele următoare ne apucăm efectiv de treabă: pornim de la schema publicată, scriem împreună aplicația care citește D406, o facem să scoată rapoartele de care avem nevoie și adăugăm pe rând verificările pe care nu ni le vinde nimeni. Pas cu pas, cu prompturile la vedere, așa cum ne-o dorim să fie.