„Trebuie să depunem D406.” Dacă fraza asta a apărut de curând în discuțiile cu contabilul tău, iar răspunsul tău a fost un „bine…” nesigur, articolul de față e pentru tine. Nu e un ghid de contabilitate — e explicația, pe limba administratorului de firmă, a ceea ce cere de fapt SAF-T de la sistemele tale informatice.
Pentru că asta se pierde adesea din discuție: D406 arată ca o obligație contabilă, dar reușita sau eșecul ei se joacă în softul de gestiune. Declarația nu se „completează” — se generează, automat, din datele pe care le are (sau nu le are) ERP-ul tău. Dacă datele sunt curate, depunerea e o rutină. Dacă nu, fiecare termen devine o operațiune de salvare.
Ce e SAF-T și ce e D406
SAF-T (Standard Audit File for Tax) e fișierul standard de audit fiscal: un format electronic prin care firmele transmit către ANAF, periodic, o radiografie detaliată a evidenței lor contabile și fiscale. În România, el ia forma declarației D406 — un fișier XML cu structură impusă, generat din datele contabile și depus electronic.
Frecvența urmează perioada ta fiscală de TVA: lunar pentru plătitorii cu TVA lunar, trimestrial pentru cei cu TVA trimestrial. Cu alte cuvinte, nu e o declarație anuală pe care o rezolvi într-o săptămână de efort concentrat — e un flux permanent, care presupune ca datele să fie în ordine tot timpul, nu doar la final de an.
De ce a ajuns obligația și la firmele mici
SAF-T a fost introdus etapizat: întâi marii contribuabili, apoi cei mijlocii, apoi cei mici. Etapizarea a fost gândită tocmai pentru că adaptarea sistemelor cere timp — iar acum procesul e complet: obligația acoperă toate categoriile de contribuabili. Firmele mici, care au avut cel mai mult timp la dispoziție, sunt și cele care au ajuns adesea cel mai puțin pregătite la termen — nu din rea-voință, ci pentru că nimeni din interior nu avea subiectul în fișa postului.
Dacă firma ta e la început de drum cu D406, vestea bună e că traseul e deja bătătorit: greșelile tipice sunt cunoscute, iar softurile românești de contabilitate și gestiune au avut ani să-și construiască exporturile. Rămâne partea ta: să verifici că lanțul funcționează cap-coadă la tine, nu doar în broșura furnizorului.
Ce date intră în D406
Fără să intrăm în structura tehnică a fișierului, declarația preia informații direct din evidența contabilă: date de identificare și nomenclatoare (clienți, furnizori, conturi, produse), jurnalele contabile, facturile de vânzare și de cumpărare, plățile și încasările. Anumite secțiuni — de exemplu cele legate de stocuri sau de active — au reguli și termene proprii; acolo lasă contabilul să conducă discuția și cere-i lista exactă a ceea ce se aplică firmei tale.
Punctul important pentru tine e altul: toate aceste date trebuie să existe în sistem, complete și consecvente. Fișierul XML e doar oglinda lor.
Partea care ține de IT: poate softul tău să genereze fișierul?
Aici se despart apele. Întrebarea nu e doar „are softul buton de export D406?” — majoritatea au. Întrebarea e dacă datele din spatele butonului sunt în starea cerută. Problemele care apar cel mai des:
- Parteneri cu date incomplete: clienți și furnizori fără cod fiscal valid, cu denumiri duplicate sau cu țara lipsă. Fiecare înregistrare șchioapă poate deveni o eroare de validare.
- Planul de conturi: structura cerută de declarație presupune o corespondență clară între conturile folosite de firmă și nomenclatorul impus — dacă firma folosește conturi analitice exotice, corespondența trebuie definită explicit.
- Nomenclatoarele de produse și cotele de TVA: articole create în grabă, cote atribuite manual, unități de măsură inconsecvente — toate ies la suprafață la export.
- Istoricul: datele vechi, migrate cândva dintr-un sistem anterior, pot avea găuri care nu au deranjat pe nimeni până acum.
Regula practică: generează fișierul de test devreme și trece-l prin validatorul pus la dispoziție de ANAF înainte de primul termen real. Lista de erori de la primul test e, de fapt, lista ta de lucru — și e mult mai plăcut s-o descoperi într-o zi liniștită decât în ziua depunerii. Dacă erorile se dovedesc structurale — date care trebuie curățate în masă, exporturi care trebuie construite sau completate — acolo devine util un proiect punctual de dezvoltare și automatizare, care să repare cauza, nu doar simptomul de la fiecare termen.
Întrebările pe care i le pui furnizorului de soft
- Exportul D406 acoperă toate secțiunile care se aplică firmei noastre, la frecvența noastră de raportare?
- Ce se întâmplă când structura cerută de ANAF se schimbă — actualizarea vine automat, la termen, și cu ce costuri?
- Există o validare înainte de export, care să ne arate erorile de date direct în program, nu abia la depunere?
- Cum se corectează o declarație deja depusă și cât de greu e de refăcut fișierul?
- Cine răspunde la întrebări în săptămâna termenului — și cât de repede?
Răspunsurile vagi la întrebările 2 și 5 sunt semnalul de alarmă clasic: obligația e periodică, deci și suportul trebuie să fie.
Cine depune: contabilul, softul sau amândoi
În practică, D406 e un sport de echipă: contabilul răspunde de corectitudinea datelor și de depunere, softul de generarea fișierului, iar firma — adică tu — de faptul că cei doi au ce le trebuie. Cele mai multe blocaje apar exact la granițe: contabilul extern nu are acces la ERP, ERP-ul exportă într-un format pe care programul contabilului nu-l citește, nimeni nu știe cine apasă butonul în săptămâna de concediu.
Merită o discuție de o oră, o dată, în care stabiliți: cine generează fișierul, cine îl validează, cine îl depune, cine păstrează dovezile și cum circulă datele între sisteme fără exporturi manuale repetate. Dacă nu știi cu cine să porți discuția asta din partea tehnică, întrebările frecvente despre consultanța IT arată cum se abordează de obicei astfel de clarificări.
Și încă ceva: D406 nu e singura obligație digitală cu termen din 2026 — regulile e-Factura s-au schimbat și ele de la 1 ianuarie, iar cele două se sprijină pe aceleași date și pe aceleași sisteme. O curățenie făcută o dată servește amândurora.
Pasul următor: cere contabilului data primului (sau următorului) termen D406 al firmei și programează un export de test cu cel puțin câteva săptămâni înainte. Neoxis, firmă de servicii IT fondată în 2015 la Pitești, lucrează cu IMM-uri din toată România la exact acest tip de pregătire a sistemelor.