Cinci ani de SAF-T în România: de la standardul OCDE la declarația D406

Pe 26 august 2026, ANAF a publicat un comunicat în care apar două cifre care merită reținute: aproximativ 870.000 de firme depun declarația D406, iar dintre acestea circa 580.000 depun și decont de TVA. Practic toată economia activă a României trimite lunar sau trimestrial un fișier pe care softul de contabilitate îl generează cu un singur buton.

Articolul acesta e o recapitulare ordonată a ce se află în spatele butonului, utilă atât pentru cine lucrează cu declarația și vrea să-și reia noțiunile, cât și pentru cine nu este familiarizat cu SAF-T și care nu a intrat vreodată în detaliile ei. De unde vine formatul, de ce arată așa cum arată, ce conține, cine intră când în obligație, până când se depune și ce se întâmplă dacă greșești.

Verificarea propriu-zisă a fișierului o tratăm separat. Uneltele gratuite publicate de ANAF le-am analizat deja în articolul despre cele două aplicații de verificare, iar cum se verifică datele din fișier, cu ce se poate cumpăra de pe piață și cu cât, e subiectul articolului următor. Aici ne oprim la ce este.

SAF-T nu e o invenție a ANAF

Acronimul vine de la Standard Audit File for Tax, iar standardul a fost dezvoltat de OCDE în 2005.

E o organizație mai des pomenită decât cunoscută, deci merită o lămurire scurtă. OCDE, Organizația pentru Cooperare și Dezvoltare Economică, este o organizație interguvernamentală care reunește majoritatea economiilor dezvoltate și care produce standarde, ghiduri și recomandări. Nu produce legislație obligatorie. Statele preiau ce le convine, cum le convine.

Detaliul care ne privește direct: România nu e încă membră, dar procesul de aderare, deschis oficial în ianuarie 2022, e aproape de final. Din cele 25 de avize tehnice cerute de comitetele de specialitate, 24 sunt deja obținute, iar finalizarea e așteptată chiar spre sfârșitul lui 2026. Alinierea la standardele OCDE se evaluează pe tot parcursul acestui proces, iar SAF-T e exact genul de standard care se bifează vizibil. E rezonabil de presupus că o parte din viteza cu care s-au mișcat autoritățile în ultimii ani, de la e-Factura la e-Transport și SAF-T, are și această motivație în spate, nu doar nevoia internă de colectare.

Consecința practică e mai importantă decât pare: OCDE nu impune o formă anume a fișierului. Definește principiul și un set de secțiuni, iar fiecare stat își construiește propria schemă. De aceea o firmă cu operațiuni în România, Polonia și Portugalia produce trei fișiere SAF-T care nu seamănă între ele decât conceptual, și de aceea un consultant care „a făcut SAF-T în altă țară” nu are automat răspunsul pentru varianta românească.

Formatul ales este XML, pentru că e standardizat internațional și poate fi citit de un program fără ambiguități.

Definiția OCDE, în forma preluată de ANAF, spune că fișierul a fost conceput „pentru a permite auditorilor accesul la date într-un format ușor de citit pentru testarea substanțială a controalelor și datelor sistemului, folosind software de audit proprietar”.

Merită citită de două ori, pentru că e ușor de înțeles greșit. „Ușor de citit” se referă la software-ul de audit, nu la om. Fișierul e proiectat ca să fie parcurs de un program, nu deschis și verificat prin lectură. E o distincție care nu deranjează pe nimeni până în ziua în care trebuie să răspunzi pentru ce ai depus.

La ce ar trebui să folosească raportarea

Ideea de la care pornește standardul e rezonabilă. Într-un control fiscal clasic, inspectorul cere extrase din contabilitate, iar fiecare firmă i le dă în alt format, din alt program, cu alte denumiri de coloane. SAF-T standardizează acest schimb: aceleași secțiuni, aceleași coduri, aceeași structură, indiferent de ERP.

Cât despre cum arată bilanțul după cinci ani de raportare în România, e cinstit spus că beneficiul pentru contribuabil rămâne greu de demonstrat. Efortul de mapare a fost real, iar controalele nu s-au scurtat vizibil. Partea de câștig pentru ANAF abia acum începe să se materializeze, prin proiectul pilot care testează precompletarea decontului de TVA direct din datele SAF-T. Merită știut de pe acum că declarația trece, în 2026, din faza „se colectează” în faza „se folosește”.

Cum a ajuns la noi: OG 11/2021

Obligația de a depune fișierul standard de control fiscal a fost introdusă prin Ordonanța Guvernului nr. 11/2021, publicată în Monitorul Oficial nr. 832 din 31 august 2021, cu aplicare de la 1 ianuarie 2022. Ordonanța a modificat Codul de procedură fiscală, adică Legea nr. 207/2015, și a adăugat în el două articole noi:

• art. 59¹, care instituie obligația propriu-zisă: cine depune fișierul standard de control fiscal, în ce condiții și la ce termene, urmând ca detaliile să fie stabilite prin ordin al președintelui ANAF;
• art. 337¹, care stabilește contravențiile și amenzile aferente, la care revenim la final.

Restul cadrului se construiește prin ordine ale președintelui ANAF:

La lista asta se adaugă ceva ce nu e act normativ, dar care în practică e mai constrângător decât oricare dintre ordinele de mai sus: documentația tehnică publicată pe portalul ANAF, adică schema în format xlsx, fișierul xsd și validatorul DUKIntegrator. Nu poți depune un fișier care nu trece de validator, indiferent ce scrie în ordin. Iar documentația se actualizează fără să apară un act normativ care să o anunțe.

Implementarea etapizată

România a introdus obligația pe categorii, eșalonat pe patru ani.

Pentru contribuabilii înregistrați după data de referință a categoriei lor, obligația începe de la data efectivă a înregistrării.

Cine e obligat, pe scurt: practic orice persoană juridică. Societăți comerciale de orice formă, regii autonome, companii naționale, cooperative, entități fără personalitate juridică ale unor persoane juridice străine, nerezidenți înregistrați în scopuri de TVA, asociații cu și fără scop patrimonial, fonduri de pensii. Există și excepții, clarificate prin OPANAF 407/2025, dar sunt marginale: entități publice, PFA, cabinete notariale, profesii liberale reglementate special, entități fără scop patrimonial în partidă simplă, firme cu activitatea suspendată. Dacă ai o societate activă cu contabilitate în partidă dublă, presupunerea de lucru corectă e că depui.

Perioadele de grație au expirat

Mesajul ANAF pe acest subiect e neobișnuit de tranșant: nicio categorie de contribuabili nu mai beneficiază de perioadă de grație, iar începând cu 1 iulie 2025 obligativitatea e deplină pentru toate categoriile.

Mecanismul original, prevăzut de OPANAF 1783/2021, era degresiv. Un mare contribuabil cu raportare lunară avea 6 luni pentru prima raportare, 5 pentru a doua, 4 pentru a treia, 3 pentru a patra și 2 pentru a cincea. Cei cu obligație trimestrială aveau 3 luni pentru prima raportare. Ultimele termene au expirat astfel:

Cum arată fișierul

Prima regulă de înțeles despre D406 e că nu se completează. Se generează.

Softul de contabilitate produce fișierul pe baza unor mapări făcute în prealabil, iar acolo se decide dacă declarația va fi corectă sau nu:

• planul de conturi se mapează pe codurile SAF-T;
• partenerii se mapează pe CustomerID și SupplierID, după un set de reguli care ține cont de rezidență, de calitatea de plătitor de TVA și de tipul de persoană;
• unitățile de măsură proprii se traduc în nomenclatorul internațional UN/ECE Recomandarea nr. 21;
• articolele primesc încadrarea tarifară, codul NC8;
• tipurile de tranzacții se mapează pe combinația TaxType plus TaxCode.

Calitatea fișierului se decide în aceste mapări, nu în momentul generării. Un fișier generat corect dintr-o mapare greșită e un fișier greșit care trece validarea.

Cele patru secțiuni cu date

Schema SAF-T pentru România are șase secțiuni de nivel unu, dar două dintre ele, Structures și SimpleTypes, sunt definiții tehnice ale schemei, nu informație pe care o raportezi. Rămân patru secțiuni cu date, iar despre ele e vorba mai departe.

Header

Header identifică declarația: cine o depune, pentru ce perioadă și de ce tip este. Tipul se codifică cu o literă sau două, L lunară, T trimestrială, A anuală, C la cerere, plus NL și NT pentru nerezidenți, și se pune în HeaderComment. Tot aici se declară tipul de organizare a contabilității, în TaxAccountingBasis, unde există unsprezece variante, de la planul de conturi general la cele pentru instituții de credit, asigurări, IFN, ONG-uri sau instituții de plată. Selectarea greșită a acestui tip invalidează tot fișierul.

Merită remarcate două lucruri. Perioada de raportare nu se dă ca lună și an, ci ca interval de date calendaristice, în SelectionCriteria. Iar SegmentIndex și TotalSegmentsInsequence sunt cei doi indici prin care o declarație împărțită în mai multe fișiere se recompune la destinație, mecanismul folosit de contribuabilii mari.

<Header>
  <AuditFileVersion>2.1</AuditFileVersion>
  <AuditFileCountry>RO</AuditFileCountry>
  <AuditFileDateCreated>2026-08-14</AuditFileDateCreated>
  <SoftwareCompanyName>Furnizor Software SRL</SoftwareCompanyName>
  <SoftwareID>Generator D406</SoftwareID>
  <SoftwareVersion>1</SoftwareVersion>
  <Company>
    <RegistrationNumber>RO12345678</RegistrationNumber>
    <Name>EXEMPLU COM SRL</Name>
    <Address>
      <City>Cluj-Napoca</City>
      <Country>RO</Country>
    </Address>
    <Contact>
      <ContactPerson>
        <FirstName>Ioana</FirstName>
        <LastName>Popescu</LastName>
      </ContactPerson>
      <Telephone>0264000000</Telephone>
    </Contact>
    <TaxRegistration>
      <TaxRegistrationNumber>RO12345678</TaxRegistrationNumber>
    </TaxRegistration>
    <BankAccount>
      <IBANNumber>RO49AAAA1B31007593840000</IBANNumber>
    </BankAccount>
  </Company>
  <DefaultCurrencyCode>RON</DefaultCurrencyCode>
  <SelectionCriteria>
    <SelectionStartDate>2026-07-01</SelectionStartDate>
    <SelectionEndDate>2026-07-31</SelectionEndDate>
  </SelectionCriteria>
  <HeaderComment>L</HeaderComment>
  <SegmentIndex>1</SegmentIndex>
  <TotalSegmentsInsequence>1</TotalSegmentsInsequence>
  <TaxAccountingBasis>A</TaxAccountingBasis>
</Header>

// Header, cu perioada de raportare, tipul declarației și indicii de segment

MasterFiles

MasterFiles e dicționarul fișierului și, cum se vede din schemă, partea cu cele mai multe componente. Nu conține tranzacții, ci nomenclatoarele la care trimit tranzacțiile din celelalte secțiuni. Cele douăsprezece subsecțiuni, pe scurt:

• GeneralLedgerAccounts, planul de conturi analitic din clasele 1 până la 8. Element repetitiv Account, cu AccountID, AccountDescription, AccountType și soldurile de deschidere și de închidere.
• Taxonomies, corespondența dintre conturi și o taxonomie externă de raportare, prin TaxonomyReference. Nu se folosește deocamdată în România.
• Customers, clienții: CustomerID, contul analitic din AccountID, datele de identificare din CompanyStructure și soldurile.
• Suppliers, simetric, cu SupplierID în locul lui CustomerID.
• TaxTable, nomenclatorul de taxe, în TaxTableEntry. Aici se definesc TaxType și, în TaxCodeDetails, codurile de taxă folosite pe fiecare linie de tranzacție.
• UOMTable, unitățile de măsură proprii puse în corespondență cu nomenclatorul UN/ECE Recomandarea nr. 21, prin UnitOfMeasure și descrierea lui.
• AnalysisTypeTable, dimensiunile analitice: centre de cost, proiecte, gestiuni. Ține perechile AnalysisType și AnalysisID, fiecare cu descrierea proprie.
• MovementTypeTable, tipurile de mișcare de stocuri, MovementType plus descriere. Contează la declarația de Stocuri.
• Products, articolele: ProductCode, descriere, încadrarea tarifară în ProductCommodityCode și unitățile de măsură de bază și standard.
• PhysicalStock, stocurile faptice, pe gestiune și pe articol: WarehouseID, ProductCode, OwnerID, cantități și valori de deschidere și de închidere.
• Owners, proprietarii stocurilor aflate în gestiunea firmei, pentru bunurile terților.
• Assets, imobilizările: AssetID, contul, descrierea, DateOfAcquisition, StartUpDate și blocul de evaluări Valuations. E secțiunea centrală a declarației anuale de Active.

Fragmentul de mai jos arată un singur cont și un singur client. Într-un fișier real, blocurile se repetă pentru fiecare poziție din nomenclator.

<MasterFiles>

  <GeneralLedgerAccounts>
    <Account>
      <AccountID>411101</AccountID>
      <AccountDescription>Clienti</AccountDescription>
      <AccountType>Activ</AccountType>
      <OpeningDebitBalance>5000</OpeningDebitBalance>
      <ClosingDebitBalance>2500</ClosingDebitBalance>
    </Account>
  </GeneralLedgerAccounts>

  <Customers>
    <Customer>
      <CompanyStructure>
        <RegistrationNumber>008765432</RegistrationNumber>
        <Name>ALFA DISTRIBUTIE SRL</Name>
        <Address>
          <City>Magurele, Ilfov</City>
          <Country>RO</Country>
        </Address>
      </CompanyStructure>
      <CustomerID>008765432</CustomerID>
      <AccountID>411101</AccountID>
      <OpeningDebitBalance>5000</OpeningDebitBalance>
      <ClosingDebitBalance>2500</ClosingDebitBalance>
    </Customer>
  </Customers>

</MasterFiles>

// Un cont din GeneralLedgerAccounts și un client din Customers

GeneralLedgerEntries

Este secțiunea care contează cel mai mult, deși în discuția publică se vorbește mai ales despre facturi. Aici se raportează toate tranzacțiile așa cum sunt înregistrate în contabilitate, iar fiecare notă contabilă generează câte un element TransactionLine pentru fiecare cont debitor și creditor. O factură de achiziție cu TVA deductibilă produce cel puțin trei linii: contul de furnizor, contul de cheltuială sau de stoc și contul de TVA. Poate produce mai multe, dacă factura atinge mai multe conturi de cheltuială sau de stoc, iar la taxare inversă intră două conturi de TVA, deductibilă și colectată.

Elementul esențial, care explică jumătate din problemele de mai târziu: informația de taxă se raportează pe linia bazei impozabile, nu pe linia de TVA și nu pe linia totalului. În fragmentul de mai jos se vede direct. Pe linia contului 628100, cea cu baza de 1.000 de lei, apar TaxType 300 și un cod de taxă, împreună cu suma TVA de 210 lei. Pe linia contului 442601, unde valoarea contabilă e chiar TVA-ul de 210 lei, și pe linia contului de furnizor, care poartă totalul de 1.210 lei, taxa e neutră: 000, 000000 și sumă zero.

Se vede și regula de partener: CustomerID e zero pe toate cele trei linii, iar SupplierID poartă codul furnizorului.

<GeneralLedgerEntries>
  <NumberOfEntries>1</NumberOfEntries>
  <TotalDebit>1210</TotalDebit>
  <TotalCredit>1210</TotalCredit>
  <Journal>
    <JournalID>1</JournalID>
    <Description>ACH</Description>
    <Type>1</Type>
    <Transaction>
      <TransactionID>1</TransactionID>
      <Period>7</Period>
      <PeriodYear>2026</PeriodYear>
      <TransactionDate>2026-07-22</TransactionDate>
      <Description>ACH servicii</Description>
      <SystemEntryDate>2026-07-23</SystemEntryDate>
      <GLPostingDate>2026-07-22</GLPostingDate>
      <CustomerID>0</CustomerID>
      <SupplierID>002233445</SupplierID>

      <TransactionLine>              <!-- contul de furnizor: taxa neutra -->
        <RecordID>1</RecordID>
        <AccountID>401111</AccountID>
        <CustomerID>0</CustomerID>
        <SupplierID>002233445</SupplierID>
        <Description>servicii</Description>
        <CreditAmount>
          <Amount>1210</Amount>
          <CurrencyCode>RON</CurrencyCode>
          <CurrencyAmount>1210</CurrencyAmount>
        </CreditAmount>
        <TaxInformation>
          <TaxType>000</TaxType>
          <TaxCode>000000</TaxCode>
          <TaxAmount>
            <Amount>0</Amount>
            <CurrencyCode>RON</CurrencyCode>
            <CurrencyAmount>0</CurrencyAmount>
          </TaxAmount>
        </TaxInformation>
      </TransactionLine>

      <TransactionLine>              <!-- linia bazei: aici sta informatia de taxa -->
        <RecordID>2</RecordID>
        <AccountID>628100</AccountID>
        <CustomerID>0</CustomerID>
        <SupplierID>002233445</SupplierID>
        <Description>servicii</Description>
        <DebitAmount>
          <Amount>1000</Amount>
          <CurrencyCode>RON</CurrencyCode>
          <CurrencyAmount>1000</CurrencyAmount>
        </DebitAmount>
        <TaxInformation>
          <TaxType>300</TaxType>
          <TaxCode>301104</TaxCode>
          <TaxAmount>
            <Amount>210</Amount>
            <CurrencyCode>RON</CurrencyCode>
            <CurrencyAmount>210</CurrencyAmount>
          </TaxAmount>
        </TaxInformation>
      </TransactionLine>

      <TransactionLine>              <!-- contul 4426: taxa neutra, suma zero -->
        <RecordID>3</RecordID>
        <AccountID>442601</AccountID>
        <CustomerID>0</CustomerID>
        <SupplierID>002233445</SupplierID>
        <Description>servicii</Description>
        <DebitAmount>
          <Amount>210</Amount>
          <CurrencyCode>RON</CurrencyCode>
          <CurrencyAmount>210</CurrencyAmount>
        </DebitAmount>
        <TaxInformation>
          <TaxType>000</TaxType>
          <TaxCode>000000</TaxCode>
          <TaxAmount>
            <Amount>0</Amount>
            <CurrencyCode>RON</CurrencyCode>
            <CurrencyAmount>0</CurrencyAmount>
          </TaxAmount>
        </TaxInformation>
      </TransactionLine>

    </Transaction>
  </Journal>
</GeneralLedgerEntries>

// O achiziție de servicii de 1.000 lei plus TVA 21%, în trei linii de tranzacție

ANAF nu citește TVA-ul din factură, îl citește din nota contabilă.

SourceDocuments

SourceDocuments ține documentele propriu-zise, la nivel de linie. Aici apar elementele pe care GeneralLedgerEntries nu le are: cantitatea, prețul unitar și data exigibilității taxei. Unitatea de măsură din nomenclatorul UN/ECE și codul de produs stau tot aici, dar nu apar în fragmentul de mai jos, fiindcă schema nu le cere obligatoriu pe fiecare linie.

Cele cinci subsecțiuni, cu elementul care se repetă și cel de linie:

• SalesInvoices, facturile emise. Element repetitiv Invoice, linia InvoiceLine, cu numărul și data facturii, clientul, contul, cantitatea, prețul unitar, InvoiceLineAmount și TaxInformation.
• PurchaseInvoices, aceeași structură pentru facturile primite, cu SupplierID în locul clientului.
• Payments, plățile și încasările. Payment cu linii PaymentLine: PaymentRefNo, data tranzacției, PaymentMethod, contul, partenerul și PaymentLineAmount.
• MovementOfGoods, mișcările de bunuri. StockMovement cu linii StockMovementLine: referința și data mișcării, MovementType, articolul, cantitatea, unitatea de măsură și valoarea contabilă.
• AssetTransactions, tranzacțiile cu imobilizări. AssetTransaction, cu AssetID, tipul și data tranzacției, plus evaluările din AssetTransactionValuations.

Un detaliu practic pe care merită să-l știe oricine lucrează cu retail: bonurile fiscale nu se raportează la facturi. Vânzările pe bon intră centralizat în registrul jurnal, pe baza rapoartelor Z, cu un cod de client rezervat pentru clienții neidentificați fiscal.

<SourceDocuments>
  <SalesInvoices>
    <NumberOfEntries>1</NumberOfEntries>
    <TotalDebit>0</TotalDebit>
    <TotalCredit>1500</TotalCredit>
    <Invoice>
      <InvoiceNo>2026_15</InvoiceNo>
      <CustomerInfo>
        <CustomerID>008765432</CustomerID>
        <BillingAddress>
          <City>Iasi</City>
          <Country>RO</Country>
        </BillingAddress>
      </CustomerInfo>
      <AccountID>411101</AccountID>
      <InvoiceDate>2026-07-02</InvoiceDate>
      <InvoiceType>380</InvoiceType>
      <SelfBillingIndicator>0</SelfBillingIndicator>

      <InvoiceLine>
        <AccountID>707101</AccountID>
        <Quantity>1</Quantity>
        <UnitPrice>1500</UnitPrice>
        <TaxPointDate>2026-07-02</TaxPointDate>
        <Description>produs1</Description>
        <InvoiceLineAmount>
          <Amount>1500</Amount>
          <CurrencyCode>RON</CurrencyCode>
          <CurrencyAmount>1500</CurrencyAmount>
        </InvoiceLineAmount>
        <DebitCreditIndicator>C</DebitCreditIndicator>
        <TaxInformation>
          <TaxType>300</TaxType>
          <TaxCode>310344</TaxCode>
          <TaxAmount>
            <Amount>315</Amount>
            <CurrencyCode>RON</CurrencyCode>
            <CurrencyAmount>315</CurrencyAmount>
          </TaxAmount>
        </TaxInformation>
      </InvoiceLine>

    </Invoice>
  </SalesInvoices>
</SourceDocuments>

// O factură de vânzare cu o linie, din secțiunea SalesInvoices

Cum se depune

Ce nu se depune este chiar fișierul XML generat de softul contabil. El e materia primă, iar declarația propriu-zisă o produce DUKIntegrator, aplicația pusă la dispoziție de ANAF: prelucrează XML-ul, îl validează față de schemă și generează un PDF care poartă fișierul ca atașament, în formă comprimată.

Aici sunt două cifre care se confundă des. Limita tehnică de 500 MB se referă la fișierul XML comprimat, așa cum ajunge atașat formularului electronic D406, nu la fișierul brut al unei secțiuni. Rata de compresie, spune ANAF, variază între 1:10 și 1:25, în funcție de conținut, adică de înregistrările contabile. Fișierele XML pregătite, cu una sau mai multe subsecțiuni, pot ajunge la circa 5 GB, sau chiar mai mult, după cât se extrage din sistemul informatic al contribuabilului. Practic, un fișier brut de câteva GB ajunge după comprimare la ordinul zecilor sau sutelor de MB, deci limita nu trebuie citită ca un plafon pe volumul contabilității.

PDF-ul rezultat se semnează electronic, cu certificatul calificat înrolat pentru depunere, și se încarcă pe eguvernare.ro. Validatorul poate fi rulat și din linie de comandă, ceea ce contează pentru cine vrea să automatizeze pasul acesta pe un portofoliu de clienți.

Cât despre corecții, mecanismul e simplu și des neînțeles: prima declarație validată depusă pentru o perioadă este declarația inițială, iar orice a doua declarație depusă pentru aceeași perioadă devine automat rectificativă. Nu există bifă, nu există formular separat. Diferența o face exclusiv momentul depunerii.

Cele trei tipuri de declarații

Mulți contabili folosesc „SAF-T” ca sinonim pentru declarația lunară. În realitate sunt trei declarații diferite, cu conținut, termen și logică proprii.

Declarația anuală de Active prinde pe picior greșit firmele care nu și-au pus la punct evidența mijloacelor fixe, pentru că cere toate imobilizările deținute în perioada de raportare, indiferent de data achiziției. Declarația de Stocuri e cea mai rar întâlnită, dar și cea mai incomodă, pentru că apare doar la cerere și presupune evidență cantitativă, inclusiv pentru stocurile terților aflate la dispoziția firmei.

Termenele

Dacă termenul cade într-o zi nelucrătoare, se mută în următoarea zi lucrătoare. Exemplu din acest an: D406 pentru aprilie 2026 a avut termen 2 iunie, pentru că 31 mai a fost duminică, iar 1 iunie zi liberă legală.

Unde stau informațiile oficiale

Pagina proiectului SAF-T de pe portalul ANAF e singura sursă care contează pentru documentația tehnică. E organizată acum în șapte secțiuni: programe de asistență, documente de asistență, documentație tehnică, teste de consistență, legislație și comunicate, plus câte una pentru fiecare dintre cele două aplicații de verificare publicate în august 2026.

Ce găsești acolo, la zi:

• schema în format xls, republicată la 19 februarie 2026;
• fișierul xsd cu structura formală a declarației;
• validatorul DUKIntegrator, actualizat în aceeași dată;
• cele două serii de teste de consistență, publicate în martie 2023 și august 2024;
• de la 26 august 2026, două aplicații gratuite de verificare, aflate în testare până în noiembrie 2026.

Aplicațiile acestea le-am testat și analizat separat, în articolul despre cele două tool-uri ANAF, așa că aici doar le semnalăm.

Contravenții și sancțiuni

Temeiul este art. 337¹ din Codul de procedură fiscală, introdus prin aceeași OG 11/2021.

Există și două situații în care fapta nu se sancționează contravențional, iar a doua e cea care ține în viață practica de zi cu zi:

• când contribuabilul corectează fișierul până la termenul legal de depunere a următoarei D406;
• când corectează ulterior acestui termen, ca urmare a unui fapt care nu îi este imputabil.

Sancțiunea e mică. Miza e în altă parte

Aici e capătul argumentului, și merită spus direct.

Amenda maximă pentru nedepunere este 5.000 de lei. Pentru o firmă mijlocie, e sub costul unei luni de consultanță fiscală. Cifra asta a produs, în discuția publică din ultimii ani, o concluzie liniștitoare și greșită: că SAF-T e o obligație ieftină și că un fișier aproximativ e un risc acceptabil.

Repercusiunea reală nu e amenda. Sunt două lucruri mai importante.

Primul este poziția firmei în analiza de risc. ANAF nu comunică public o regulă care să lege explicit calitatea fișierului D406 de clasa de risc fiscal, așa că nimeni nu poate cita un prag. Dar mecanismul de analiză de risc funcționează exact pe acest tip de date, iar o firmă care depune constant cu întârziere sau cu erori într-o raportare care conține integral contabilitatea nu are cum să treacă neobservată într-un sistem construit tocmai pentru a compara automat.

Al doilea, mai concret, e ce se întâmplă în 2026. Prin proiectul pilot derulat între decembrie 2025 și august 2026, ANAF a testat construirea decontului de TVA direct din datele SAF-T și compararea lui, rând cu rând, cu decontul depus de contribuabil. Declarația nu mai e un depozit de date pentru un eventual control viitor. Devine sursa din care se calculează ce ar fi trebuit să declari.

Într-un asemenea mecanism, o mapare greșită de cod de taxă nu mai produce o amendă de 1.500 de lei. Produce o diferență de TVA.

Ceea ce ne aduce la întrebarea practică: dacă fișierul contează atât de mult, cum verifici că e corect înainte să-l semnezi? Iar răspunsul „l-a validat DUKIntegrator” nu e suficient. Nici pe departe. Ce se poate face cu uneltele gratuite de la ANAF am scris deja. Ce verifică de fapt validatorul, ce oferă piața contra cost și dacă merită banii, în articolul următor.

Surse oficiale