SAF-T (D406): ce raportează firmele la ANAF și de când

SAF-T (Standard Audit File for Tax) este un format internațional XML standardizat de OECD prin care contribuabilul exportă întreaga contabilitate către autoritatea fiscală pentru audit automatizat. În România, fișierul SAF-T se depune la ANAF prin formularul D406, cu profilul specific definit prin OMFP 1783/2021¹. „Generez SAF-T" și „depun D406" descriu același act tehnic: produci un XML SAF-T conform schemei impuse de România și îl trimiți prin Spațiul Privat Virtual.

Pe scurt: o dată pe lună sau pe trimestru (în funcție de perioada de TVA), firma ta trebuie să exporte tot ce a circulat contabil (vânzări, achiziții, jurnal contabil, stocuri, plăți) într-un fișier XML cu structură standardizată. ANAF îl folosește pentru audit automat: încrucișează datele între contribuabili, detectează neconcordanțe față de e-Factura și ridică steaguri roșii fără să trimită un inspector pe teren.

Cui i se aplică SAF-T și de când?

SAF-T a intrat în vigoare etapizat, pe mărimea contribuabilului: întâi marii contribuabili, apoi cei mijlocii, apoi cei mici și sectoarele specifice²:

• Mari contribuabili: obligatoriu din 1 ianuarie 2022. Categoria este definită de ANAF anual, pe baza cifrei de afaceri și a sectorului de activitate.
• Contribuabili mijlocii: obligatoriu din 1 ianuarie 2023.
• Contribuabili mici și sectoare specifice: obligatoriu din 1 ianuarie 2025, cu termene de grație inițiale pentru sancțiuni.

Încadrarea pe categorii este recalibrată anual de ANAF; firmele care își schimbă încadrarea (creștere de cifră de afaceri sau scădere) au, de regulă, o perioadă de tranziție. Practic, dacă firma ta este înregistrată în România și are activitate economică, undeva între 2022 și 2025 a intrat în obligație. Verifică spațiul fiscal în SPV pentru clasificarea curentă.

Care este formatul tehnic al SAF-T?

Baza este standardul OECD SAF-T 2.0, un schema XML conceput pentru audit fiscal cross-jurisdictional. Profilul românesc, definit prin OMFP 1783/2021, restrânge și extinde schema standard pentru contextul fiscal local: forma codurilor CUI, structura conturilor analitice, codurile CPV pentru produse, regulile pentru TVA și pentru taxarea inversă.

Un fișier SAF-T are patru zone mari:

1. Header: identitatea contribuabilului (CUI, denumire), perioada raportată, software-ul care a generat fișierul, versiunea schemei.
2. MasterFiles: dicționarele de bază (planul de conturi, clienții, furnizorii, produsele, mijloacele fixe, codurile fiscale). Master data trebuie să fie consistentă peste timp: dacă un cod CPV s-a schimbat la mijlocul perioadei, ambele variante trebuie să apară corect.
3. GeneralLedgerEntries: jurnalul contabil complet, înregistrare cu înregistrare, cu debit, credit, document sursă și data efectuării.
4. SourceDocuments: facturile de vânzare, facturile de achiziție, plățile și încasările, fiecare cu linie de detaliu, TVA defalcat și legătura către înregistrarea contabilă corespunzătoare.

Pentru o firmă mijlocie cu câteva mii de facturi pe lună, fișierul SAF-T ajunge ușor la zeci de MB; pentru contribuabili mari, peste 100 MB pe lună³. Generarea, validarea contra schemei XSD și depunerea trebuie să suporte fișiere mari fără să încarce întreaga structură în memorie.

Care sunt cele trei căi de generare a SAF-T?

Cele trei căi sunt modulul SAF-T al unui ERP integrat (SAP, Oracle, Microsoft Dynamics), software-ul de contabilitate românesc (SAGA, Charisma) sau un pipeline propriu de generare XML:

• ERP integrat (SAP, Oracle, Microsoft Dynamics, IFS): pachetul de localizare RO include export SAF-T conform OMFP 1783/2021. Costul este licență ERP + pachet de localizare, dar tot ce pleacă în SAF-T provine deja din sistemul tău de evidență. Cel mai sigur, cel mai scump.
• Software de contabilitate românesc (SAGA, ContaPro, NavExpert, Charisma): generează SAF-T din datele contabile pe care le ții deja în ele. Funcționează când contabilitatea trăiește integral în acel software. Devine problematic când o parte din date stă în altă platformă (POS retail, magazin online, ERP pentru producție).
• Pipeline propriu: pentru companii cu sisteme proprii sau cu date împrăștiate, extrage și consolidează din sursele tale, validează master data, generează XML conform OMFP 1783/2021, validează contra XSD, trimite prin API-ul ANAF. Aici intervine ingineria reală: pipeline cu validare strictă, idempotență pentru reraportări, retransmiteri controlate pentru erori temporare ANAF, și un data warehouse care să țină istoricul versiunilor de fișiere depuse.

De ce se sparge SAF-T mai des decât e-Factura?

Cele trei moduri clasice de eșec văzute în practică sunt master data inconsistentă, datele împrăștiate pe mai multe surse și storno-urile din perioade deja raportate:

• Master data inconsistentă. Clienți fără CUI complet, produse cu cod CPV greșit, conturi analitice schimbate la mijlocul perioadei. SAF-T cere consistență cross-tabelă: dacă MasterFiles declară clientul X cu CUI Y, toate facturile către X din SourceDocuments trebuie să folosească exact același CUI. O singură diferență de spațiu sau de prefix RO produce respingere.
• Date împrăștiate pe surse. Vânzările vin din ERP, încasările din POS retail, achiziții scanate din OCR. Înainte de export, trebuie reconciliate într-un singur model coerent, fără pierderi sau duplicări. Asta seamănă mai mult cu un proces de ETL/ELT contabil decât cu un raport bancar.
• Storno-uri și corecții întârziate. O factură stornată în luna următoare cere reraportarea perioadei închise. Pipeline-ul trebuie să știe să republice o perioadă veche fără să strice cea curentă, cu trasabilitate clară pe versiunile depuse.

În plus, validarea ANAF este strictă pe ratele de schimb BNR: tranzacțiile în valută trebuie convertite la cursul oficial al zilei tranzacției, nu la unul estimat. O conversie greșită la o singură factură produce o discrepanță care nu se rezolvă fără reraportare.

De ce contează SAF-T pentru un dezvoltator?

Două motive practice: primul, dacă lucrezi pentru o firmă românească mid-market sau mai mare, vei atinge SAF-T mai devreme sau mai târziu. Fie pe partea de extragere a datelor pentru ERP integrator, fie pe partea de validare și depunere pentru un pipeline propriu, fie pe partea de monitoring (cine a depus, cine nu, ce a eșuat la validare).

Al doilea: SAF-T este exact tipul de problemă pe care un studio o poate rezolva curat. Cere disciplină de pipeline, schemă strictă, control bun pe erori, istoric reproductibil al versiunilor depuse. La crawlerra tratăm acest tip de raportare ca o integrare ETL contabilă, nu ca o funcție de export pe lângă alta, pentru că fișierele mari și corecțiile întârziate cer arhitectură, nu un export ad-hoc. Pentru contextul mai larg al raportărilor ANAF, vezi entry-ul despre e-Factura și nuanțele de rate limiting când integrezi prin SaaS de contabilitate. Pentru fluxul concret cu cod și gestiunea fișierelor mari fără să consumi toată memoria, urmează ghidul nostru de pipeline SAF-T (în pregătire).

1. Cadrul legal al SAF-T în România: OMFP 1783/2021 (definirea profilului SAF-T RO și a formularului D406), modificat prin acte succesive. Schema XSD oficială și documentația tehnică sunt publicate de ANAF la anaf.ro (secțiunea D406). Standardul internațional de bază: OECD SAF-T versiunea 2.0. [seo.saft_legal_framework]
2. Calendarul intrării în obligație pe categorii de contribuabili (mari 1 ianuarie 2022, mijlocii 1 ianuarie 2023, mici 1 ianuarie 2025) reflectă etapizarea prevăzută în OMFP 1783/2021 și actele subsecvente. Categoria de încadrare a fiecărui contribuabil este publicată anual de ANAF și vizibilă în spațiul fiscal SPV. [seo.saft_calendar]
3. Mărimile tipice de fișier observate în implementări de producție: zeci de MB pe lună pentru o firmă mijlocie cu câteva mii de facturi, peste 100 MB pe lună pentru contribuabili mari. Generarea trebuie să folosească streaming XML, nu construire în memorie a întregului DOM, pentru a evita OOM-uri pe procesele de raportare lunară. [seo.saft_filesize_orders]