Skip to content
  • Management Financiar

    Management financiar

    • Concept

      Ce înseamnă management financiar?

    • Raportare financiară

      Conceptul de raportare financiară pentru IMM-uri

    • SAF-T

      Cum depui declarația SAF-T în România

    • Documentație

      Baza de informații pentru antreprenori și contabili.

    Soluțiile Finlight

    • Raportare financiară

      Dashboard BIM® by Iancu Guda

    • Verificare declarație SAF-T

      Verificarea declației SAF-T conform comunicatului ANAF

    • Automatizări B2B

      Soluții de automatizare pentru portofolii de companii

  • SAF-T
    • Despre SAF-T

      8 pași simpli pentru asigurarea conformității fiscale SAF-T

    • Verificare declarație SAF-T

      Acum poți verifica, explora și compara datele pe care le depui la ANAF în declarația SAF-T 406

    • Ghidul SAF-T Finlight

      Resursă interactivă destinată tuturor celor ce doresc să utilizeze Raportarea financiară în activitatea profesională și/sau didactică.

  • Resurse
    • Ghidul Financiar Finlight

      Resursă interactivă destinată tuturor celor ce doresc să utilizeze Raportarea financiară în activitatea profesională și/sau didactică

    • Ghidul SAF-T Finlight

      Resursă interactivă destinată celor ce doresc să asigure conformitatea raportării SAF-T

    • Ghidul de utilizare Finlight

      Tot ce ai nevoie să știi despre utilizarea platformei Finlight

    • Blog

      Articole Finlight

  • Prețuri
  • Management Financiar
    • Concept
    • Raportare Financiara
    • SAF-T
    • Automatizare B2B
    • Documentație
  • SAF-T
    • SAF-T
    • Verificare declarație SAF-T
    • Ghidul SAF-T Finlight
  • Automatizare
  • Resurse
    • Ghidul Financiar Finlight
    • Ghidul SAF-T Finlight
    • Ghidul de utilizare Finlight
    • Blog
  • Business in Motion by Iancu Guda
  • Preturi si Servicii
Sign Up
Login
Login
Sign Up
Popular Search venituri

Raportarea SAF-T în Romania

  • Totul despre SAF-T

MasterFiles (Fișierele Master)

  • GeneralLedgerAccounts (Conturi contabile)
  • Customers (Clienti)
  • Suppliers (Furnizori)
  • Products (Produse)
  • TaxTable (Tabelă Taxe)
  • AnalysisTypeTable (Tabel tipuri analiză)
  • UOMTable (Tabela Unităților de Măsură – UOM)

GeneralLedgerEntries (Înregistrări Contabile - Registrul Jurnal)

  • GeneralLedgerEntries (Înregistrari contabile – Registrul Jurnal)

SourceDocuments (Documente sursă)

  • SalesInvoices (Facturi de Vânzare)
  • PurchaseInvoices (Facturi de Achiziție)
  • Payments (Plăți)
View Categories
  • Home
  • Documentație
  • Ghidul SAF-T Finlight
  • GeneralLedgerEntries (Înregistrări Contabile - Registrul Jurnal)
  • GeneralLedgerEntries (Înregistrari contabile – Registrul Jurnal)

GeneralLedgerEntries (Înregistrari contabile – Registrul Jurnal)

Descriere #

Secțiunea GeneralLedgerEntries (Înregistrări Contabile – Registrul Jurnal)  din fișierul SAF-T conține informații despre înregistrările contabile efectuate în perioada de raportare așa cum sunt înregistrate în sistemul contabil al contribuabilului în Registrul Jurnal.

Raportarea se realizează la nivel de tranzacție, incluzând conturile contabile analitice stabilite conform planului de conturi românesc aplicabil contribuabilului → AccountID.

Structură GeneralLedgerEntries #

Secțiunea GeneralLedgerEntries a fișierului SAF-T conține subsecțiuni de tip Jurnal (elemente → Journal), fiecare corespunzând unui jurnal (inclusiv jurnalele auxiliare ținute de contribuabilul raportor).

În fiecare jurnal sunt înregistrate tranzacții (elemente → Transaction), care sunt detaliate prin linii de tranzacție (elemente → TransactionLine).

Secțiunea GeneralLedgerEntries va include următoarele elemente:

  • NumberOfEntries – reprezentând numărul total de linii (TransactionLine) asociate tuturor jurnalelor.

  • TotalDebit – reprezentând suma tuturor sumelor debitoare din jurnale.

  • TotalCredit – reprezentând suma tuturor sumelor creditoare din jurnale.

  • Journal → iterații multiple – reprezentând fiecare jurnal ce va conține informații specifice. În cadrul unui jurnal, informațiile sunt organizate în tranzacții (Transaction), iar fiecare tranzacție poate conține una sau mai multe linii de tranzacție (TransactionLine).

Elemente GeneralLedgerEntries #

În continuare, vei găsi detaliile legate de secțiunea GeneralLedgerEntries, împreună cu subsecțiunile și elementele sale constitutive.

Elementele care necesită raportare obligatorie sunt evidențiate printr-o iconiță cu semnul exclamării pentru o identificare rapidă și clară.

Elemente GeneralLedgerEntries ⮧

  • Descriere : umărul total de linii (TransactionLine) asociate tuturor jurnalelor
  • Tip: nonNegativeInteger
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr întreg, mai mare decât zero (0)
  • Validare semantică: nu există
 
  • Descriere : totalul tuturor sumelor debitoare din valuta implicită a antetului
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal, maxim 2 (două) cifre după punctul zecimal. 
  • Validare semantică: nu există
Notă

Număr zecimal cu maxim 2 zecimale. Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor.

Atenție: Sumele raportate pentru Total Debit trebuie să fie consistente cu suma tuturor înregistrărilor listate pe Debit în structurile de tip Journal. Poți verifica gratuit consistența acestor elemente folosind Finlight → Detalii aici.

  • Descriere : totalul tuturor sumelor creditoare din valuta implicită a antetului
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal, maxim 2 (două) cifre după punctul zecimal. 
  • Validare semantică: nu există
Notă

Număr zecimal cu maxim 2 zecimale. Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor.

Atenție: Sumele raportate pentru Total Credit trebuie să fie consistente cu suma tuturor înregistrărilor listate pe Credit în structurile de tip Journal. Poți verifica gratuit consistența acestor elemente folosind Finlight → Detalii aici.

Elemente GeneralLedgerEntries/Journal ⮧

  • Descriere : identificator unic pentru jurnal
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal, maxim 2 (două) cifre după punctul zecimal. 
  • Validare semantică: nu există
Note

Pentru fiecare jurnal, trebuie să utilizezi un identificator unic. Acesta ar trebui să fie numele jurnalului exprimat ca text, cum ar fi: Jurnal de casă, Jurnalul de bancă, Jurnalul pentru achiziții de la furnizori locali, etc. Vei avea nevoie de un astfel de identificator pentru fiecare jurnal pe care îl folosești.

  • Descriere :descrierea jurnalului – text explicativ
  • Tip: SAFlongtextType
  • Mod de raportare: obligatoriu
  • Validare sintactică: nu există
  • Validare semantică: nu există
 
  • Descriere : mecanismul de grupare a jurnalelor – descrie modul de grupare a jurnalelor și o listă de tranzacții
  • Tip: SAFcodeType
  • Mod de raportare: obligatoriu
  • Validare sintactică: nu există
  • Validare semantică: nu există
Notă

Număr zecimal cu maxim 2 zecimale. Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor.

Atenție: Sumele raportate pentru Total Credit trebuie să fie consistente cu suma tuturor înregistrărilor listate pe Credit în structurile de tip Invoice. Poți verifica gratuit consistența acestor elemente folosind Finlight → Detalii aici.

Elemente GeneralLedgerEntries/Journal/Transaction⮧

  • Descriere: referință încrucișată la înregistrarea GL. Poate conține mai multe niveluri diferite pentru a identifica tranzacția. Acesta ar putea include centre de cost, cum ar fi societatea, divizia, regiunea, grupul și sucursala /departamentul.
  • Tip: SAFmiddle2textType
  • Mod de raportare: obligatoriu
  • Validare sintactică: nu există
  • Validare semantică: nu există
  • Descriere: data documentului
  • Tip: Date
  • Mod de raportare: obligatoriu
  • Validare sintactică: conform standardului ISO 8601
  • Validare semantică: nu există

Notă

Codificarea datei și a orei în fișierul standard de audit SAF-T se realizează pe baza standardului ISO 8601, care specifica următorul format : AAAA-LL-ZZ

Exemplificare

2023-02-23

Elemente …Transaction/TransactionLine ⮧

  • Descriere :numărul documentului sursă la care se referă linia
  • Mod de raportare: opțional
  • Validare sintactică: nu există
  • Validare semantică: nu există
Note
Deși acest câmp este opțional, vă recomandăm să îl folosiți pentru a putea face legătura dintre plăți și documentele justificative aferente.
    • Descriere : se raportează identificatorul (numărul) aferent liniei din Registrul jurnal
    • Tip: SAFshorttextType
    • Mod de raportare: obligatoriu
    • Validare sintactică: nu există
    • Validare semantică: nu există
    • Descriere : codul contului analitic
    • Tip: SAFmiddle2textType
    • Mod de raportare: obligatoriu
    • Validare sintactică: număr întreg, diferit de zero
    • Validare semantică: codul contului analitic care trebuie să corespundă planului de conturi contabile pentru România aplicabil tipului societății raportoare conform standardelor românești de contabilitate

Notă

AccountID reprezintă contul contabil analitic in care este înregistrată plata/încasarea (contul contabil pentru furnizor, client, comision bancar, dobânda, etc. relevant in funcție de natura plații sau a încasării)

Codificarea contului se bazează pe combinarea unui Prefix (corespunzător planului de conturi al societății) cu un Sufix format dintr-un set de cifre. Nu este important cum se determină Sufixul, dar este crucial ca AccountID, obținut din combinația Prefix+Sufix, să fie unic. În cazul în care nu există conturi analitice pentru un anumit cont, se poate raporta doar prefixul.

Exemplificare raportare cont cu sufix

Dacă, de exemplu, în sistemul contabil avem un cont analitic denumit “701.vanzariclientfavorit SRL“, AccountID-ul corespunzător rezultat va fi de forma:

Prefix = 701

Se adaugă un Sufix generat (de sistem sau manual), care conține cel puțin o cifră, fără alte caractere. Astfel, se pot genera (fara ca aceste variante sa fie limitative) următoarele variante de AccountID:

      • 7011
      • 7019999
      • 70112321
      • etc.

Atenție! →  AccountID, obținut din combinația Prefix+Sufix, trebuie să fie unic, pentru ca altfel veți raporta solduri diferite pentru același cont contabil.

Descriere : cod unic pentru client este format astfel: tip (două cifre zecimale) urmat de codul unic al clientului. Se construieste in felul urmator:

    • operatori economici înregistrați în România→ 00 urmat de CUI – unde tipul este 00, iar CUI este codul unic de identificare . Codul este un număr întreg zecimal, cu 1 până la 9 cifre, urmat de o cifră de control – Exemplu: 004221306 – pentru Ministerul Finantelor Publice. Atenție! Nu se trece și atributul fiscal ”RO” pentru plătitorii de TVA.
    • operatori economici din statele membre ale UE, mai puțin România → 01 urmat de codul de țară (conform ISO 3166-1 – 2 litere) și de Codul unic de identificare pentru TVA din statul membru respectiv –  verificate conform sistemului VIES (VAT Information Exchange System) – Exemplu: 01EL123456789 sau 01HU12345678
    • operatori economici din alte state care nu sunt România sau membre UE →02 urmat de codul de țară și de codul unic de identificare pentru TVA din statul respectiv, care nu este nici România, nici stat membru UE – Exemplu: 02TK123005284
    • persoane fizice cetățeni români → 03 urmat de CNP 
    • persoane fizice rezidente în România→ 03 urmat de codul unic personal  (același format cu CNP-ul, dar  la care prima cifra este 7 sau 8) 
    • persoane fizice nerezidente → 03 urmat de NIF
    • persoane fizice care nu își declară CNP-ul pe tranzacții → 04 urmat de cod client asociat în mod unic de către operatorul economic (exemplu: comerț online)
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele membre ale UE, mai puțin România → 05 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic – pentru 
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele non-UE→ 06 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic
    • stații de distribuție de carburanți-lubrefianți sau magazine cu vânzare în detaliu→08 urmat de 13 cifre zero (080000000000000) pentru clienții care NU SE IDENTIFICĂ cu cod fiscal în tranzacțiile de la punctele de vânzare.  Acest cod este utilizat NUMAI pentru astfel de tranzacții și nu este un înlocuitor universal în raportarea facturilor și plăților etc. Acest cod NU SE UTILIZEAZĂ pentru elementul SupplierID – deoarece identitatea furnizorului pe bază de cod fiscal este mereu cunoscută
    • persoane juridice nerezidente înregistrate în Romania→ 09 urmat de NIF
    • societăți bancare pentru clienții persoane juridice nerezidente care nu se regăsesc in categoria 01,02,05,06 si 09 → 10 urmat de codul de țară și de codul unic alocat 
    • societăți bancare pentru clienții persoane fizice nerezidente care nu se regăsesc în categoria 03 → 11 urmat de codul de tara si de codul unic alocat
  • Tip: SAFmiddle1textType
  • Mod de raportare: obligatoriu
  • Validare sintactică:
    • dacă elementul CustomerID este diferit de ”0” (zero), atunci valoarea se validează astfel:
      • Dacă primele două caractere din MF.C.3 CustomerID sunt:
        • 00 atunci se verifică ca lungimea maximă a valorii fără prefixul ”00”, să fie de 10 caractere doar de tip numeric. Nu se acceptă caracterele ”RO”. Validarea se realizează după regulile cunoscute pentru CUI .Formatul unui CUI este #########C – unde ######### este numărul de identificare, între 1 și 9 cifre, iar C este numărul de verificare, 1 cifră
        • 01 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”EL” pentru 01EL123456789 sau ”HU” pentru 01HU12345678
        • 02 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”TK” pentru 02TK123005284
        •  03 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”03”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0.
        • 04 atunci se verifică ca valoarea să nu conțină caractere speciale (de exemplu: ”.”, ”,”,”!”, ”-”, ”?” etc)
        • 05 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 06 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 08 atunci se verifică ca lungimea maximă a valorii fără prefixul ”08”, să fie de 13 caractere doar de tip numeric. Se verifică ca valoarea să fie egal cu ”080000000000000”

        • 09 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”09”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0
          1.10 “10” atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”10”, să fie de max 20 caractere alfanumerice – codul se folosește pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificările si completările ulterioare

        • 11 atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”11”, să fie de max 20 caractere alfanumerice – codul se foloseste pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificarile si completarile ulterioare
          1.12. În orice alt caz nu se validează valoarea, semnalându-se eroare la validarea sintactică.(Validation error – CustomerID incorrect value)

    •   dacă CustomerID este egal cu ”0” (zero) se semnalează eroare sintactică. CustomerID nu poate fi ”0”.

  • Validare semantică: idem validare sintactică
Note
În funcție de specificul tranzacției: 
  • dacă tranzacția reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → CustomerID aferent clientului, așa cum este definit în sectiunea MasterFiles/Clienți
  • dacă tranzacția NU reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → codul unic al contribuabilului raportor
 

Descriere : cod unic pentru client este format astfel: tip (două cifre zecimale) urmat de codul unic al clientului. Se construiește in felul următor:

    • operatori economici înregistrați în România→ 00 urmat de CUI – unde tipul este 00, iar CUI este codul unic de identificare . Codul este un număr întreg zecimal, cu 1 până la 9 cifre, urmat de o cifră de control – Exemplu: 004221306 – pentru Ministerul Finantelor Publice. Atenție! Nu se trece și atributul fiscal ”RO” pentru plătitorii de TVA.
    • operatori economici din statele membre ale UE, mai puțin România → 01 urmat de codul de țară (conform ISO 3166-1 – 2 litere) și de Codul unic de identificare pentru TVA din statul membru respectiv –  verificate conform sistemului VIES (VAT Information Exchange System) – Exemplu: 01EL123456789 sau 01HU12345678
    • operatori economici din alte state care nu sunt România sau membre UE →02 urmat de codul de țară și de codul unic de identificare pentru TVA din statul respectiv, care nu este nici România, nici stat membru UE – Exemplu: 02TK123005284
    • persoane fizice cetățeni români → 03 urmat de CNP 
    • persoane fizice rezidente în România→ 03 urmat de codul unic personal  (același format cu CNP-ul, dar  la care prima cifra este 7 sau 8) 
    • persoane fizice nerezidente → 03 urmat de NIF
    • persoane fizice care nu își declară CNP-ul pe tranzacții → 04 urmat de cod client asociat în mod unic de către operatorul economic (exemplu: comerț online)
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele membre ale UE, mai puțin România → 05 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic – pentru 
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele non-UE→ 06 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic
    • persoane juridice nerezidente înregistrate în Romania→ 09 urmat de NIF
    • societăți bancare pentru clienții persoane juridice nerezidente care nu se regăsesc in categoria 01,02,05,06 si 09 → 10 urmat de codul de țară și de codul unic alocat 
    • societăți bancare pentru clienții persoane fizice nerezidente care nu se regăsesc în categoria 03 → 11 urmat de codul de tara si de codul unic alocat
  • Tip: SAFmiddle1textType
  • Mod de raportare: obligatoriu
  • Validare sintactică:
    • dacă elementul CustomerID este diferit de ”0” (zero), atunci valoarea se validează astfel:
      • Dacă primele două caractere din MF.C.3 CustomerID sunt:
        • 00 atunci se verifică ca lungimea maximă a valorii fără prefixul ”00”, să fie de 10 caractere doar de tip numeric. Nu se acceptă caracterele ”RO”. Validarea se realizează după regulile cunoscute pentru CUI .Formatul unui CUI este #########C – unde ######### este numărul de identificare, între 1 și 9 cifre, iar C este numărul de verificare, 1 cifră
        • 01 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”EL” pentru 01EL123456789 sau ”HU” pentru 01HU12345678
        • 02 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”TK” pentru 02TK123005284
        •  03 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”03”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0.
        • 04 atunci se verifică ca valoarea să nu conțină caractere speciale (de exemplu: ”.”, ”,”,”!”, ”-”, ”?” etc)
        • 05 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 06 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 09 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”09”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0

        •  10 atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”10”, să fie de max 20 caractere alfanumerice – codul se folosește pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificările si completările ulterioare

        • 11 atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”11”, să fie de max 20 caractere alfanumerice – codul se folosește pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificările și completările ulterioare
          1.12. În orice alt caz nu se validează valoarea, semnalându-se eroare la validarea sintactică.(Validation error – CustomerID incorrect value)

    •   dacă CustomerID este egal cu ”0” (zero) se semnalează eroare sintactică. CustomerID nu poate fi ”0”.

  • Validare semantică: idem validare sintactică
Note
În funcție de specificul tranzacției: 
  • dacă tranzacția reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → SupplierID aferent furnizorului, așa cum este definit în secțiunea MasterFiles/Clienți
  • dacă tranzacția NU reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → codul unic al contribuabilului raportor

Elemente ..TransactionLine/TaxInformation ⮧  (Informații fiscale pentru linia contabilă)

  • Descriere : cod taxă conform nomenclator din schema xls
  • Tip: SAFcodeType
  • Mod de raportare: Obligatoriu
  • Validare sintactică: bazată pe sheet-ul TAX_IMP – Impozite din schema xls
  • Validare semantică: nu există
  • Descriere : codul numeric conform nomenclatoarelor de taxe (TVA) disponibile în documentația SAF-T 
  • Tip: SAFCodeType
  • Mod de raportare: Obligatoriu
  • Validare sintactică:  validare conform nomenclatoarelor TVA
  • Validare semantică: nu există

Notă

Codurile necesare pentru completarea TaxCode se regăsesc în nomenclatoarele specifice detaliate în foaia Legenda coduri tax din documentul schema xls : Livrari, Achizitii ded 100%, Achizitii ded 50%_baserate,  Achizitii ded 50%_not_know, Achizitii ded 50%, Achizitii neded, Achizitii base rate, Achizitii not known, WHT – nomenclator, TVA_NoteContabile, Achizitii neded 50% 

Elemente …TaxInformation/TaxAmount ⮧

  • Descriere :suma în moneda implicită a antetului, reprezentată ca un număr zecimal cu două cifre zecimale după separatorul punct zecimal („ . ”). Suma poate fi negativă sau pozitivă după caz. Sumele negative sunt prefixate cu semnul minus („-”) 
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal cu maxim 2 (două) cifre după punctul zecimal
  • Validare semantică: nu există

Note

Se completează cu valoarea în RON, pentru România. Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor.

  • Descriere: cod valutar din trei litere conform standardului ISO 4217. Exemplu: EUR pentru euro sau USD pentru dolari americani.
  • Tip: ISOCurrencyCode
  • Mod de raportare: obligatoriu
  • Validare sintactică: coduri alfabetice
  • Validare semantică: conform ISO4217CurrCodes

Notă

Se completează conform nomenclatorului ISO4217CurrCodes.

  • Descriere :suma în valută străină, reprezentată ca un număr zecimal cu două cifre zecimale după separatorul punct zecimal („ . ”). Suma poate fi negativă sau pozitivă după caz. Sumele negative sunt prefixate cu semnul minus („-”)
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal cu maxim 2 (două) cifre după punctul zecimal
  • Validare semantică: nu există

Notă

Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor. În cazul în care valuta transmisă este în RON, se va completa cu valoarea de la Amount.

  • Descriere : cursul de schimb utilizat. CurrencyAmount x ExchangeRate = Sumă
  • Tip: SAFexchangerateType
  • Mod de raportare: opțional
  • Validare sintactică: număr zecimal, delimitat prin PUNCT zecimal cu maxim 4 cifre după punctul zecimal
  • Validare semantică: nu există

Notă

Cursul de schimb utilizat pentru determinarea în RON a bazei impozabile a taxei este cursul din data exigibilității taxei, astfel cum este stabilit la art. 135 din Codul fiscal, indiferent de data la care sunt sau vor fi recepționate bunurile/ facturile/ serviciile/ alte documente financiare.

  • Descriere : procentul de impozitare (cota de TVA)
  • Tip: decimal
  • Mod de raportare: opțional
  • Validare sintactică:  validare număr zecimal
  • Validare semantică: dacă raportați utilizând TaxPercentage, nu raportați FlatTaxRate.

Notă

Este foarte important să te asiguri că ai completat corect cotele de TVA. Daca vrei să verifici, poți utiliza gratuit platforma Finlight pentru a identifica erorile legate de TVA.

  • Descriere: baza pe care se calculează impozitul. Aceasta poate fi o sumă.
  • Tip: zecimal
  • Mod de raportare: opțional
  • Validare sintactică:  validare număr zecimal
  • Validare semantică: nu există
  • Descriere : Descrierea valorii TaxBase
  • Tip: SAFmiddle2textType
  • Mod de raportare: opțional
  • Validare sintactică:  validare număr zecimal
  • Validare semantică: dacă raportați utilizând TaxPercentage, nu raportați FlatTaxRate.
  • Descriere : motivul sau raționamentul scutirii sau reducerii fiscale
  • Tip: SAFmiddle2textType
  • Mod de raportare: opțional
  • Validare sintactică:  nu există
  • Validare semantică: nu există
  • Descriere : identificarea declarației în care suma taxei este raportată organului fiscal
  • Tip: SAFmiddle2textType
  • Mod de raportare: opțional
  • Validare sintactică:  nu există
  • Validare semantică: nu există

Note

Pentru operațiunile de import, în această subsecțiune se va raporta factura de import, iar la TaxType se va completa 000 (3 de zero), TaxCode 0000000 (6 de zero).

Elemente ..TransactionLine/DebitAmount⮧  (Informații despre suma debitului pentru tranzacție)

  • Descriere :suma în moneda implicită a antetului, reprezentată ca un număr zecimal cu două cifre zecimale după separatorul punct zecimal („ . ”). Suma poate fi negativă sau pozitivă după caz. Sumele negative sunt prefixate cu semnul minus („-”) 
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal cu maxim 2 (două) cifre după punctul zecimal
  • Validare semantică: nu există

Note

Se completează cu valoarea în RON, pentru România. Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor.

  • Descriere: cod valutar din trei litere conform standardului ISO 4217. Exemplu: EUR pentru euro sau USD pentru dolari americani.
  • Tip: ISOCurrencyCode
  • Mod de raportare: obligatoriu
  • Validare sintactică: coduri alfabetice
  • Validare semantică: conform ISO4217CurrCodes

Notă

Se completează conform nomenclatorului ISO4217CurrCodes.

  • Descriere :suma în valută străină, reprezentată ca un număr zecimal cu două cifre zecimale după separatorul punct zecimal („ . ”). Suma poate fi negativă sau pozitivă după caz. Sumele negative sunt prefixate cu semnul minus („-”)
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal cu maxim 2 (două) cifre după punctul zecimal
  • Validare semantică: nu există

Notă

Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor. În cazul în care valuta transmisă este în RON, se va completa cu valoarea de la Amount.

  • Descriere : cursul de schimb utilizat. CurrencyAmount x ExchangeRate = Sumă
  • Tip: SAFexchangerateType
  • Mod de raportare: opțional
  • Validare sintactică: număr zecimal, delimitat prin PUNCT zecimal cu maxim 4 cifre după punctul zecimal
  • Validare semantică: nu există

Notă

Cursul de schimb utilizat pentru determinarea în RON a bazei impozabile a taxei este cursul din data exigibilității taxei, astfel cum este stabilit la art. 135 din Codul fiscal, indiferent de data la care sunt sau vor fi recepționate bunurile/ facturile/ serviciile/ alte documente financiare.

  • Suma debitoare poate fi pozitivă sau negativă, după caz putând fi reflectate stornările în negru. Suma negativă se reprezintă prefixată cu semnul „-”
  • Dacă linia de tranzacție este debit, utilizați DebitAmount și nu raportați CreditAmount

Elemente ..TransactionLine/CreditAmount⮧  (Informații despre suma creditului pentru tranzacție)

  • Descriere :suma în moneda implicită a antetului, reprezentată ca un număr zecimal cu două cifre zecimale după separatorul punct zecimal („ . ”). Suma poate fi negativă sau pozitivă după caz. Sumele negative sunt prefixate cu semnul minus („-”) 
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal cu maxim 2 (două) cifre după punctul zecimal
  • Validare semantică: nu există

Note

Se completează cu valoarea în RON, pentru România. Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor.

  • Descriere: cod valutar din trei litere conform standardului ISO 4217. Exemplu: EUR pentru euro sau USD pentru dolari americani.
  • Tip: ISOCurrencyCode
  • Mod de raportare: obligatoriu
  • Validare sintactică: coduri alfabetice
  • Validare semantică: conform ISO4217CurrCodes

Notă

Se completează conform nomenclatorului ISO4217CurrCodes.

  • Descriere :suma în valută străină, reprezentată ca un număr zecimal cu două cifre zecimale după separatorul punct zecimal („ . ”). Suma poate fi negativă sau pozitivă după caz. Sumele negative sunt prefixate cu semnul minus („-”)
  • Tip: SAFmonetaryType
  • Mod de raportare: obligatoriu
  • Validare sintactică: număr zecimal, delimitat prin punct zecimal cu maxim 2 (două) cifre după punctul zecimal
  • Validare semantică: nu există

Notă

Pentru aproximări se utilizează regulile de rotunjire, conform Ordinului nr. 978 din 8 Iulie 2005 al Ministerului Finanțelor. În cazul în care valuta transmisă este în RON, se va completa cu valoarea de la Amount.

  • Descriere : cursul de schimb utilizat. CurrencyAmount x ExchangeRate = Sumă
  • Tip: SAFexchangerateType
  • Mod de raportare: opțional
  • Validare sintactică: număr zecimal, delimitat prin PUNCT zecimal cu maxim 4 cifre după punctul zecimal
  • Validare semantică: nu există

Notă

Cursul de schimb utilizat pentru determinarea în RON a bazei impozabile a taxei este cursul din data exigibilității taxei, astfel cum este stabilit la art. 135 din Codul fiscal, indiferent de data la care sunt sau vor fi recepționate bunurile/ facturile/ serviciile/ alte documente financiare.

  • Suma debitoare poate fi pozitivă sau negativă, după caz putând fi reflectate stornările în negru. Suma negativă se reprezintă prefixată cu semnul „-”
  • Dacă linia de tranzacție este credit, utilizați CreditAmount și nu raportați DebitAmount
  • Descriere : descrierea liniei de jurnal
  • Tip: SAFlongtextType
  • Mod de raportare: opțional
  • Validare sintactică: nu există
  • Validare semantică: nu există
  • Descriere: data efectivă de la care dobânda este percepută. A se raporta atunci când această dată diferă de data tranzacției
  • Tip: Date
  • Mod de raportare: opțional
  • Validare sintactică: conform standardului ISO 8601
  • Validare semantică: conform standardului ISO 8601
Notă

Codificarea datei și a orei în fișierul standard de audit SAF-T se realizează pe baza standardului ISO 8601, care specifica următorul format : AAAA-LL-ZZ  → 2021-04-13

  • Descriere: perioada contabilă pentru care s-a făcut înregistrarea respectivă → numărul lunii sau trimestrului, după caz
  • Tip: SAFmiddle1textType
  • Mod de raportare: obligatoriu
  • Validare sintactică: nu există
  • Validare semantică: nu există
  • Descriere: anul perioadei contabile
  • Tip: nonnegativeInteger
  • Mod de raportare: obligatoriu
  • Validare sintactică: de la 2020 până la valoarea anului curent, inclusiv
  • Validare semantică: nu există

Note

Se completează cu anul contabil, exprimat numeric, complet → 2021, 2022 etc. Se validează mereu să fie mai mare sau egal cu 2020, nefiind posibil de depus D406 pentru ani din trecut.
  • Descriere: descrierea tranzacției în jurnal după cum a fost introdusă în evidența contabilă de către contribuabilul raportor
  • Tip: SAFlongtextType
  • Mod de raportare: obligatoriu
  • Validare sintactică: nu există
  • Validare semantică: nu există
  • Descriere: este data când a fost procesat lotul de înregistrări contabile în evidența contribuabilului raportor
  • Tip: Date
  • Mod de raportare: obligatoriu
  • Validare sintactică: validare conform standardului ISO 8601
  • Validare semantică: nu există
Exemplu
Data introducerii în evidența informatică a unor bonuri de consum sau note de intrare-recepție, din documentele primare, care sunt procesate grupat la sfârșitul săptămânii etc.
  • Descriere: data înregistrării în Registrul Jurnal
  • Tip: Date
  • Mod de raportare: obligatoriu
  • Validare sintactică: validare conform standardului ISO 8601
  • Validare semantică: nu există
Notă
Codificarea datei și a orei în fișierul standard de audit SAF-T se realizează pe baza standardului ISO 8601, care specifica următorul format : AAAA-LL-ZZ

Descriere : cod unic pentru client este format astfel: tip (două cifre zecimale) urmat de codul unic al clientului. Se construieste in felul urmator:

    • operatori economici înregistrați în România→ 00 urmat de CUI – unde tipul este 00, iar CUI este codul unic de identificare . Codul este un număr întreg zecimal, cu 1 până la 9 cifre, urmat de o cifră de control – Exemplu: 004221306 – pentru Ministerul Finantelor Publice. Atenție! Nu se trece și atributul fiscal ”RO” pentru plătitorii de TVA.
    • operatori economici din statele membre ale UE, mai puțin România → 01 urmat de codul de țară (conform ISO 3166-1 – 2 litere) și de Codul unic de identificare pentru TVA din statul membru respectiv –  verificate conform sistemului VIES (VAT Information Exchange System) – Exemplu: 01EL123456789 sau 01HU12345678
    • operatori economici din alte state care nu sunt România sau membre UE →02 urmat de codul de țară și de codul unic de identificare pentru TVA din statul respectiv, care nu este nici România, nici stat membru UE – Exemplu: 02TK123005284
    • persoane fizice cetățeni români → 03 urmat de CNP 
    • persoane fizice rezidente în România→ 03 urmat de codul unic personal  (același format cu CNP-ul, dar  la care prima cifra este 7 sau 8) 
    • persoane fizice nerezidente → 03 urmat de NIF
    • persoane fizice care nu își declară CNP-ul pe tranzacții → 04 urmat de cod client asociat în mod unic de către operatorul economic (exemplu: comerț online)
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele membre ale UE, mai puțin România → 05 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic – pentru 
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele non-UE→ 06 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic
    • stații de distribuție de carburanți-lubrefianți sau magazine cu vânzare în detaliu→08 urmat de 13 cifre zero (080000000000000) pentru clienții care NU SE IDENTIFICĂ cu cod fiscal în tranzacțiile de la punctele de vânzare.  Acest cod este utilizat NUMAI pentru astfel de tranzacții și nu este un înlocuitor universal în raportarea facturilor și plăților etc. Acest cod NU SE UTILIZEAZĂ pentru elementul SupplierID – deoarece identitatea furnizorului pe bază de cod fiscal este mereu cunoscută
    • persoane juridice nerezidente înregistrate în Romania→ 09 urmat de NIF
    • societăți bancare pentru clienții persoane juridice nerezidente care nu se regăsesc in categoria 01,02,05,06 si 09 → 10 urmat de codul de țară și de codul unic alocat 
    • societăți bancare pentru clienții persoane fizice nerezidente care nu se regăsesc în categoria 03 → 11 urmat de codul de tara si de codul unic alocat
  • Tip: SAFmiddle1textType
  • Mod de raportare: obligatoriu
  • Validare sintactică:
    • dacă elementul CustomerID este diferit de ”0” (zero), atunci valoarea se validează astfel:
      • Dacă primele două caractere din MF.C.3 CustomerID sunt:
        • 00 atunci se verifică ca lungimea maximă a valorii fără prefixul ”00”, să fie de 10 caractere doar de tip numeric. Nu se acceptă caracterele ”RO”. Validarea se realizează după regulile cunoscute pentru CUI .Formatul unui CUI este #########C – unde ######### este numărul de identificare, între 1 și 9 cifre, iar C este numărul de verificare, 1 cifră
        • 01 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”EL” pentru 01EL123456789 sau ”HU” pentru 01HU12345678
        • 02 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”TK” pentru 02TK123005284
        •  03 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”03”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0.
        • 04 atunci se verifică ca valoarea să nu conțină caractere speciale (de exemplu: ”.”, ”,”,”!”, ”-”, ”?” etc)
        • 05 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 06 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 08 atunci se verifică ca lungimea maximă a valorii fără prefixul ”08”, să fie de 13 caractere doar de tip numeric. Se verifică ca valoarea să fie egal cu ”080000000000000”

        • 09 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”09”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0
          1.10 “10” atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”10”, să fie de max 20 caractere alfanumerice – codul se folosește pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificările si completările ulterioare

        • 11 atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”11”, să fie de max 20 caractere alfanumerice – codul se foloseste pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificarile si completarile ulterioare
          1.12. În orice alt caz nu se validează valoarea, semnalându-se eroare la validarea sintactică.(Validation error – CustomerID incorrect value)

    •   dacă CustomerID este egal cu ”0” (zero) se semnalează eroare sintactică. CustomerID nu poate fi ”0”.

  • Validare semantică: idem validare sintactică
Note
În funcție de specificul tranzacției: 
  • dacă tranzacția reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → CustomerID aferent clientului, așa cum este definit în sectiunea MasterFiles/Clienți
  • dacă tranzacția NU reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → codul unic al contribuabilului raportor
 

Descriere : cod unic pentru client este format astfel: tip (două cifre zecimale) urmat de codul unic al clientului. Se construiește in felul următor:

    • operatori economici înregistrați în România→ 00 urmat de CUI – unde tipul este 00, iar CUI este codul unic de identificare . Codul este un număr întreg zecimal, cu 1 până la 9 cifre, urmat de o cifră de control – Exemplu: 004221306 – pentru Ministerul Finantelor Publice. Atenție! Nu se trece și atributul fiscal ”RO” pentru plătitorii de TVA.
    • operatori economici din statele membre ale UE, mai puțin România → 01 urmat de codul de țară (conform ISO 3166-1 – 2 litere) și de Codul unic de identificare pentru TVA din statul membru respectiv –  verificate conform sistemului VIES (VAT Information Exchange System) – Exemplu: 01EL123456789 sau 01HU12345678
    • operatori economici din alte state care nu sunt România sau membre UE →02 urmat de codul de țară și de codul unic de identificare pentru TVA din statul respectiv, care nu este nici România, nici stat membru UE – Exemplu: 02TK123005284
    • persoane fizice cetățeni români → 03 urmat de CNP 
    • persoane fizice rezidente în România→ 03 urmat de codul unic personal  (același format cu CNP-ul, dar  la care prima cifra este 7 sau 8) 
    • persoane fizice nerezidente → 03 urmat de NIF
    • persoane fizice care nu își declară CNP-ul pe tranzacții → 04 urmat de cod client asociat în mod unic de către operatorul economic (exemplu: comerț online)
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele membre ale UE, mai puțin România → 05 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic – pentru 
    • operatori economici care nu sunt înregistrați în scopuri de TVA din statele non-UE→ 06 urmat de codul de țară și de cod client asociat în mod unic de către operatorul economic
    • persoane juridice nerezidente înregistrate în Romania→ 09 urmat de NIF
    • societăți bancare pentru clienții persoane juridice nerezidente care nu se regăsesc in categoria 01,02,05,06 si 09 → 10 urmat de codul de țară și de codul unic alocat 
    • societăți bancare pentru clienții persoane fizice nerezidente care nu se regăsesc în categoria 03 → 11 urmat de codul de tara si de codul unic alocat
  • Tip: SAFmiddle1textType
  • Mod de raportare: obligatoriu
  • Validare sintactică:
    • dacă elementul CustomerID este diferit de ”0” (zero), atunci valoarea se validează astfel:
      • Dacă primele două caractere din MF.C.3 CustomerID sunt:
        • 00 atunci se verifică ca lungimea maximă a valorii fără prefixul ”00”, să fie de 10 caractere doar de tip numeric. Nu se acceptă caracterele ”RO”. Validarea se realizează după regulile cunoscute pentru CUI .Formatul unui CUI este #########C – unde ######### este numărul de identificare, între 1 și 9 cifre, iar C este numărul de verificare, 1 cifră
        • 01 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”EL” pentru 01EL123456789 sau ”HU” pentru 01HU12345678
        • 02 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere. – Exemplu: ”TK” pentru 02TK123005284
        •  03 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”03”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0.
        • 04 atunci se verifică ca valoarea să nu conțină caractere speciale (de exemplu: ”.”, ”,”,”!”, ”-”, ”?” etc)
        • 05 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 06 atunci se verifică codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere
        • 09 atunci se verifică ca lungimea maximă a înregistrării fără prefixul ”09”, să fie de 13 caractere de tip numeric. Se verifică ca prima cifră din grupul de 13 caractere să fie diferită de 0

        •  10 atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”10”, să fie de max 20 caractere alfanumerice – codul se folosește pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificările si completările ulterioare

        • 11 atunci se verifică ca societatea are TaxAccountingBasis (H2) = Bank si codul de țară (caracterele 3 și 4) care trebuie să fie un cod valid conform nomenclatorului ISO 3166-1 – 2 litere si se verifică ca lungimea maximă a valorii fără prefixul ”11”, să fie de max 20 caractere alfanumerice – codul se folosește pana la aplicarea prevederilor art 82, alin (6), lit e din legea nr. 207/2015 privind Codul de procedura fiscala cu modificările și completările ulterioare
          1.12. În orice alt caz nu se validează valoarea, semnalându-se eroare la validarea sintactică.(Validation error – CustomerID incorrect value)

    •   dacă CustomerID este egal cu ”0” (zero) se semnalează eroare sintactică. CustomerID nu poate fi ”0”.

  • Validare semantică: idem validare sintactică
Note
În funcție de specificul tranzacției: 
  • dacă tranzacția reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → SupplierID aferent furnizorului, așa cum este definit în secțiunea MasterFiles/Clienți
  • dacă tranzacția NU reprezintă înregistrări de datorii și creanțe pentru  care există obligația de contabilizare pe fiecare persoană fizică sau juridică → codul unic al contribuabilului raportor
  • Descriere: ID unic cod unic generat din sistemul informatic al contribuabilului raportor pentru lotul de înregistrări contabile introduse în evidență
  • Tip: SAFmiddle1textType
  • Mod de raportare: opțional
  • Validare sintactică: nu există
  • Validare semantică: nu există

Note

În mod obișnuit, se face fie cu:

  • înregistrări continue de-a lungul unei luni – când acest cod este identic la toate înregistrările
  • înregistrări pe loturi, folosind diferite fișiere de import cu note contabile (posting files), caz în care poate fi complet cu numele fișierului de posting etc.
  • orice altă organizare pe loturi de înregistrări înscrise în evidența contabilă de contribuabilul raportor

Acest element se raportează opțional – la latitudinea contribuabilului raportor, însă este foarte util pentru contribuabilii cu volume foarte mari de activitate pentru a determina modul în care au compus fișierul standard de control fiscal (SAF-T) din informațiile extrase din sistemul lor de evidență financiar – contabilă.

  • Descriere: detalii despre persoana sau aplicația care a introdus/generat tranzacția
  • Tip: SAFmiddle1textType
  • Mod de raportare: opțional
  • Validare sintactică: nu există
  • Validare semantică: nu există
Note
Sursa de unde provine înregistrarea contabilă (element opțional, de exemplu marca contabilului care a operat înregistrarea – MADA01 sau Theodor.Stanescu sau TS100101 sau GLMODUL, dacă este vorba de o aplicație anume de unde s-au importat notele contabile).
  • Descriere : Tipul tranzacției în jurnal
  • Tip: SAFcodeType
  • Mod de raportare: opțional
  • Validare sintactică: nu există
  • Validare semantică: Se validează cu nomenclatorul Nom_Tipuri_facturi
 

Notă

Pentru completarea câmpului se vor utiliza următoarele coduri: 
  • NORMALĂ
  • AUTOMATĂ
  • PERIODICĂ
  • Descriere: număr unic creat de sistem pentru document
  • Tip: SAFshorttextType
  • Mod de raportare: opțional
  • Validare sintactică: nu există
  • Validare semantică: nu există
Notă
Număr unic de înregistrare (în general este un număr în secvență crescătoare) din evidența contabilă a contribuabilului raportor. Este în general automat, ca un număr natural, dintr-o secvență strict crescătoare, care se reia de la 1 doar în următorul an financiar (sau poate și mai rar). Identifică în mod unic înregistrarea. 

Mențiuni importante din documentația ANAF #

Cum se raportează informațiile fiscale în GeneralLedgerEntries? #

Informații fiscale pentru linia contabilă.(TaxInformation) – se raportează pentru notele contabile relevante din punct de vedere al impozitelor astfel:

  • Informațiile referitoare la TVA (informațiile din TaxInformaționStructure) sunt obligatoriu a fi raportate în cazul înregistrărilor contabile cum ar fi cele aferente unor ajustări/autocolectări de TVA
  • Contribuabilii pot opta la raportarea TaxType si TaxCode pentru toate liniile de postare contabilă pentru care informația este disponibilă în sistem (inclusiv pentru linia de TVA din postarea contabilă a unei facturi), în timp ce informația din TaxAmount se va raporta doar pentru postarea contabilă aferente bazei impozabile (valoare netă/bază impozabilă din postarea unei facturi). Pentru restul liniilor de postare contabilă aferentă unei facturi (e.g. linie aferentă valorii brute, linia aferentă TVA), elementul TaxAmount va fi completat cu 0.Informațiile referitoare la impozitele cu reținere la sursă vor fi raportate la nivelul liniei relevante bazei impozabile (plați efectuate).
  • Pentru tranzacțiile raportate în secțiunea GeneralLedgerEntries care nu sunt relevante pentru raportarea de taxe și impozite se va raporta Tax Type= 000 și TaxCode=000000.

Ce este un Jurnal Auxiliar? #

Operațiunile de aceeași natură, realizate în același loc de activitate (atelier, secție etc.), pot fi recapitulate într-un centralizator, denumit jurnal auxiliar, care stă la baza înregistrării în Registrul jurnal.

Entitățile pot utiliza jurnale auxiliare pentru: operațiunile de casă și bancă, decontările cu furnizorii, situația încasării-achitării facturilor etc.

Cum se raportează postările aferente claselor 8 și 9? #

Contribuabilii care utilizează Planul de conturi pentru Societăți Comerciale Generale (OMFP 1802/2014), respectiv Planul de conturi pentru Societăți Comerciale Generala care aplică prevederile OMFP 2844/2016 nu vor raporta postările contabile aferente conturilor de clasă 8 și de clasă 9.

Sursa: ANAF →  Ghidul SAF-T, Document Q&A și schema xls

Acum îți poți verifica declarația SAF-T (406) cu Finlight​ #

Verificare SAF-T de la Finlight →încarcă fișierul tău .xml pe platforma Finlight și verifică-ți gratuit declarația SAF-T conform celor 22 de teste de consistență recomandate de ANAF, precum și alte teste specifice. Rezultate imediate!

Verifică SAF-T
Află mai multe

Mesaj Finlight #

Am construit Ghidul SAF-T Finlight și Ghidul financiar Finlight pentru a oferi soluții simple, gratuite și aplicabile celor ce au nevoie de ele.

  • folosește opțiunea de comment de la Facebook pentru a ne adresa întrebări și pentru a ne ajuta să ne îmbunătățim materialele
  • dacă materialele ți se par utile, apasă Recommend și Share.
SAF-T
What are your Feelings
Cuprins
  • Descriere
  • Structură GeneralLedgerEntries
  • Elemente GeneralLedgerEntries
  • Mențiuni importante din documentația ANAF
    • Cum se raportează informațiile fiscale în GeneralLedgerEntries?
    • Ce este un Jurnal Auxiliar?
    • Cum se raportează postările aferente claselor 8 și 9?
Contact

Email: office@finlight.ro

Tel: 0741 170 178

Facebook-f Youtube Linkedin
Link-uri utile

Automatizare B2B

Prețuri și servicii

Ghid financiar Finlight

Ghid SAF-T Finlight

Blog

Soluțiile Finlight

BIM by Iancu Guda

Verificare declarație SAF-T

Management Financiar

Raportare financiară

Aspecte legale

Condiții generale de utilizare a platformei Finlight

Politica de confidențialitate

Politica privind utilizarea cookie-urilor

© 2025 Finlight. All rights reserved.