Erorile de validare SAF-T apar atunci când fișierul D406 generat din programul de contabilitate nu respectă structura sau regulile de coerență cerute de ANAF. Aproape întotdeauna, cauza nu este fișierul în sine, ci datele din contabilitate: un client fără cod fiscal valid, un cont analitic fără corespondent în structura SAF-T, un cod de taxă lipsă sau un sold inițial care nu se leagă de perioada anterioară.
Vestea bună este că erorile se repetă, iar o pregătire sistematică a datelor le elimină pe cele mai multe înainte de prima generare. Articolul descrie pregătirea pe etape, erorile frecvente și ordinea corectă de corectare. Este un material general: soluția pentru o eroare concretă depinde de programul folosit și de documentația tehnică ANAF în vigoare, iar deciziile contabile le ia contabilul. Ce este fișierul și ce conține afli din SAF-T (D406): ce este fișierul standard de control fiscal.
De ce apar erorile de validare
Validarea verifică două lucruri: dacă fișierul respectă schema tehnică și dacă datele din el sunt coerente între ele. Un fișier poate fi perfect structurat și totuși respins pentru că soldurile nu se leagă.
| Nivel de verificare | Ce se controlează | Unde e cauza de obicei |
|---|---|---|
| Schema XML | structura, formatul câmpurilor, câmpurile obligatorii | programul de contabilitate sau versiunea exportului |
| Nomenclatoare | codurile de taxe, de mișcări, de analiză, de țări, de monede | configurarea programului |
| Coerență internă | sumele, soldurile, legăturile dintre secțiuni | înregistrările contabile |
| Identificare | parteneri, conturi, documente cu identificatori unici | datele de bază |
Instrumentele ANAF de validare, inclusiv aplicația DUKIntegrator cu pachetul specific declarației D406, afișează erorile și, uneori, avertismentele. O eroare blochează depunerea; un avertisment semnalează o situație care merită verificată, dar nu blochează neapărat. Citește atent ambele categorii.
Sfat: Folosește întotdeauna cea mai nouă versiune a instrumentelor de validare și a schemei publicate de ANAF. O versiune veche poate respinge fișiere corecte sau, mai rău, poate accepta fișiere pe care sistemul le va respinge la depunere.
Pregătirea datelor de bază
Datele de bază (parteneri, conturi, produse, coduri) se pregătesc o dată, foarte atent, și apoi se întrețin. Ele produc cele mai multe erori la primele depuneri.
Partenerii
Fiecare client și furnizor trebuie să aibă un identificator unic și datele de identificare corecte:
- pentru firmele românești, codul fiscal valid, cu sau fără prefix, conform regulilor din documentația ANAF;
- pentru partenerii din alte state, codul de țară și identificatorul fiscal din țara lor;
- pentru persoanele fizice, regulile de identificare prevăzute în documentația D406;
- fără dubluri: același partener introdus de două ori, cu nume ușor diferite, produce neconcordanțe.
Conturile
Planul de conturi al firmei folosește, de regulă, conturi analitice proprii. Fiecare cont trebuie pus în corespondență cu un cont din structura cerută de SAF-T. Conturile nou create în timpul anului sunt sursa clasică de erori: au fost adăugate în program, dar nu și în mapare.
Codurile de taxe și celelalte nomenclatoare
Fiecare înregistrare sau linie de factură care implică o taxă trebuie să aibă tipul și codul de taxă din nomenclatorul ANAF. Regulile de TVA aplicate firmei (taxare normală, scutiri, taxare inversă, operațiuni intracomunitare) trebuie să aibă fiecare un cod corespunzător.
| Element de bază | Eroare tipică | Prevenție |
|---|---|---|
| Partener nou | cod fiscal lipsă sau cu format greșit | verificare la crearea fișei |
| Partener străin | țară sau cod fiscal străin lipsă | câmpuri obligatorii în program |
| Cont analitic nou | nemapat în structura SAF-T | procedură internă: niciun cont nou fără mapare |
| Regim de TVA nou | fără cod de taxă asociat | revizuirea tabelului de taxe la fiecare operațiune nouă |
| Produs sau serviciu nou | fără unitate de măsură sau cod | completarea fișei de produs |
Erorile frecvente de coerență
Erorile de coerență apar când datele din fișier nu se leagă între ele. Validatorul verifică, de exemplu, ca fiecare notă contabilă să fie echilibrată și ca soldurile să urmeze logica contabilă.
Cele mai frecvente:
- note contabile neechilibrate: totalul debitelor diferă de totalul creditelor într-o tranzacție, de obicei din cauza unei rotunjiri sau a unui import defectuos;
- solduri care nu se leagă: soldul final al unui cont nu este egal cu soldul inițial plus rulajele perioadei;
- solduri inițiale diferite de soldurile finale ale perioadei anterioare raportate, după corecturi făcute în urmă fără rectificativă;
- documente datate în afara perioadei raportate;
- facturi fără legătură cu înregistrările din registrul jurnal sau cu partenerul declarat;
- valori negative în câmpuri care acceptă doar valori pozitive, când stornările sunt tratate greșit de program.
Atenție: Nu corecta niciodată un sold „din fișier”. Dacă soldul este greșit în SAF-T, este greșit și în contabilitate. Corectura se face în evidență, iar fișierul se generează din nou.
Ordinea corectă de corectare
Când primești o listă de erori, nu le lua la rând, de sus în jos. Unele erori sunt consecințe ale altora, iar rezolvarea cauzei elimină dintr-odată zeci de mesaje.
O ordine care funcționează:
- erorile de schemă, pentru că pot ascunde alte probleme; de obicei le rezolvă furnizorul programului sau actualizarea exportului;
- datele de bază: parteneri, conturi, coduri de taxe; o singură fișă greșită poate genera erori pe sute de linii;
- soldurile inițiale, mai ales dacă perioada anterioară a fost corectată;
- notele contabile neechilibrate sau datate greșit;
- legăturile dintre secțiuni: facturi, plăți, parteneri.
După fiecare grup de corecturi, generezi din nou fișierul și îl validezi. Numărul de erori ar trebui să scadă semnificativ după primele două etape.
Un control lunar înainte de generare
Cea mai eficientă metodă de a evita erorile de validare este o verificare scurtă, făcută lunar, înainte de generarea fișierului. Se potrivește firesc cu închiderea de lună.
Lista de control:
- conturile noi create în perioadă au fost mapate;
- partenerii noi au cod fiscal și țară corecte;
- nu există parteneri dublați;
- operațiunile noi de TVA au cod de taxă;
- balanța de verificare este echilibrată, iar soldurile se leagă de perioada anterioară;
- facturile emise corespund celor acceptate în e-Factura;
- facturile primite din SPV au fost toate înregistrate.
Operațiunile de închidere în care se integrează această listă sunt descrise în Închiderea de lună: ce operațiuni face contabilul. Corelarea cu facturile electronice se face pornind de la Facturile primite în SPV: cum le descarci și le verifici și de la ghidul general e-Factura: ghid complet pentru firme, de la SPV la arhivare.
Situațiile speciale
Unele situații produc erori specifice, care nu țin de datele obișnuite. Merită cunoscute dinainte, ca să nu pierzi timp căutând cauze în altă parte.
- Fișiere foarte mari: la firmele cu volum mare de tranzacții, fișierul poate depăși limitele de dimensiune; documentația ANAF prevede reguli pentru transmiterea pe părți.
- Schimbarea programului de contabilitate în cursul anului: soldurile preluate trebuie să fie identice cu cele din vechiul program, iar maparea se verifică și se reface complet.
- Corecturi în perioade deja raportate: modifică soldurile inițiale ale perioadelor următoare și pot cere rectificative în lanț.
- Raportarea activelor: necesită un registru al mijloacelor fixe complet, cu date de intrare, amortizare și ieșiri; vezi Amortizarea mijloacelor fixe: metode și efectul fiscal.
- Raportarea stocurilor la cerere: presupune o gestiune corectă a stocurilor, cu mișcări codificate.
Cum lucrezi cu furnizorul programului
O parte dintre erori nu pot fi rezolvate nici de tine, nici de contabil, pentru că țin de felul în care programul construiește fișierul. Colaborarea cu furnizorul programului de contabilitate este, de aceea, parte din procesul de pregătire.
Ca să primești ajutor rapid:
- trimite raportul complet al validatorului, nu doar o captură cu primele rânduri;
- precizează versiunea programului și versiunea instrumentelor de validare folosite;
- spune dacă eroarea a apărut după o actualizare, după o operațiune nouă sau după o corectură în perioade anterioare;
- păstrează fișierul generat care a produs eroarea, ca să poată fi comparat cu cel corectat.
Merită întrebat furnizorul și ce controale interne oferă programul înainte de generare: multe programe au rapoarte care semnalează conturi nemapate, parteneri incompleți sau note neechilibrate. Folosite lunar, aceste rapoarte reduc dependența de validatorul ANAF.
Pentru o firmă mică, alegerea unui program care tratează SAF-T ca pe o funcție de bază, nu ca pe un modul adăugat, contează mai mult decât pare. Criteriile generale după care organizezi evidența sunt în Contabilitatea firmei: ghid complet pentru antreprenori.
Rectificativa D406
Dacă eroarea este descoperită după ce fișierul a fost depus și acceptat, corectura se face prin declarație rectificativă, după procedura stabilită pentru D406. Rectificativa cuprinde datele corecte ale perioadei, nu doar diferențele.
Înainte de depunere, verifică împreună cu contabilul:
- dacă eroarea afectează și alte declarații (decontul de TVA, declarațiile informative);
- dacă perioadele ulterioare trebuie la rândul lor corectate, din cauza soldurilor inițiale;
- dacă există un termen sau o limită pentru depunerea rectificativei.
Principiile generale ale corectării declarațiilor sunt în Declarațiile rectificative: când și cum corectezi o eroare.
Pe scurt, un SAF-T fără respingeri
Erorile de validare SAF-T sunt aproape întotdeauna simptome ale unor date de bază incomplete sau ale unor înregistrări neconsecvente. Corectura durabilă se face în contabilitate și în configurarea programului, nu în fișier, iar un control lunar înainte de generare previne majoritatea problemelor.
De reținut:
- folosește întotdeauna ultima versiune a schemei și a instrumentelor de validare ANAF;
- curăță partenerii, conturile și codurile de taxe înainte de prima depunere;
- niciun cont nou și niciun regim de TVA nou fără mapare și cod de taxă;
- rezolvă erorile în ordine: schemă, date de bază, solduri, note, legături;
- nu modifica manual fișierul XML;
- corectează perioadele deja depuse prin rectificativă, după corectarea contabilității.
Întrebări frecvente
Pot corecta direct fișierul XML ca să treacă validarea?
Nu este o practică sigură. Fișierul trebuie să reflecte contabilitatea; dacă îl modifici manual, creezi o diferență între declarație și evidență, care poate ieși la iveală la control.
Ce diferență este între o eroare și un avertisment la validare?
Eroarea blochează depunerea fișierului, iar avertismentul semnalează o situație care merită verificată, dar nu oprește neapărat depunerea. Ambele se analizează împreună cu contabilul.
De ce apar erori de sold inițial, deși luna curentă este corectă?
Pentru că soldurile inițiale trebuie să fie egale cu soldurile finale ale perioadei anterioare. O corectură făcută în urmă fără rectificativă rupe această legătură.
Cine rezolvă erorile de schemă?
De regulă, furnizorul programului de contabilitate, pentru că ele țin de felul în care este construit exportul. Asigură-te că programul este actualizat la ultima versiune a schemei.
Partenerii dublați produc erori?
Pot produce erori sau neconcordanțe, mai ales când același cod fiscal apare cu identificatori diferiți. Unifică fișele de parteneri înainte de generarea fișierului.
