SAF-T si datele din CRM: cum pregatiti Zoho CRM si Zoho Books pentru D406

SAF-T si datele din CRM sunt legate direct. Fisierul D406 se genereaza din contabilitate, dar clientii, CUI-urile si produsele de pe facturi vin adesea din CRM. CUI-urile lipsa, firmele duplicate sau codurile de produs nealiniate din Zoho CRM trec in Zoho Books si apoi in declaratie. De aceea curatati aceste campuri inainte de raportare, nu dupa validare.

SAF-T este fisierul standard prin care o companie raporteaza periodic un set de informatii. Aceste informatii permit autoritatilor fiscale sa revizuiasca operatiunile companiei. In Romania, fisierul SAF-T se depune prin declaratia D406.

Rolul principal al SAF-T este standardizarea transferului de informatii intre autoritatile fiscale si contribuabili. Asa il descrie documentatia D406 din aplicatia EBS-RO a BIT Software. Pentru o firma, standardizarea are o consecinta practica. Fiecare factura trebuie sa poarte aceleasi date de identificare, in acelasi format, luna de luna.

Ghidul de fata urmeaza datele in ordinea in care circula. Incepe cu ce cere D406 si cu modul in care este validat fisierul. Continua cu campurile din CRM care alimenteaza facturile si cu un exemplu lucrat. Se incheie cu o lista de verificare pe care o puteti folosi inainte de fiecare declaratie.

Declaratia D406 lunara sau trimestriala contine inregistrarile contabile, facturile emise, facturile de furnizor si platile. Obligatia de depunere a declaratiei D406 a fost introdusa etapizat. S-a aplicat din 1 ianuarie 2022 marilor contribuabili si din 1 ianuarie 2023 contribuabililor mijlocii. Din 1 ianuarie 2025 se aplica si contribuabililor mici si nerezidentilor inregistrati in scopuri de TVA. Perioada de raportare este lunara sau trimestriala, in functie de perioada fiscala de TVA.

Continutul declaratiei este descris in documentatia Odoo pentru localizarea Romania. Exista si alte tipuri de D406, cu continut diferit. Declaratia anuala include mijloacele fixe. Declaratia la cerere include stocurile. Pentru declaratia trimestriala, documentatia EBS-RO indica tipul T, iar luna aleasa este ultima luna a trimestrului.

Pentru datele din CRM conteaza mai ales facturile. Fiecare factura are un tip de document SAF-T, exprimat printr-un cod. Documentatia EBS-RO enumera urmatoarele coduri:

• 380 pentru factura initiala;
• 381 pentru factura storno;
• 384 pentru factura finala re-emisa;
• 389 pentru autofactura;
• 751 pentru informatii in scopuri contabile.

Autofactura este factura emisa de firma dumneavoastra in locul furnizorului sau pentru propriile operatiuni, in cazurile prevazute de Codul fiscal. Contabilul stabileste cand se aplica. Pe fiecare factura apar clientul sau furnizorul, identificat prin CUI, si liniile de produse. Exact aceste doua elemente vin, in multe companii, din CRM.

Fisierul XML al declaratiei D406 se valideaza si se semneaza cu DUKIntegrator, programul de validare al ANAF. Daca DUKIntegrator gaseste erori, le corectati in date inainte de depunere. Documentatia EBS-RO descrie fluxul complet. Fisierele .xml sunt verificate in DUKIntegrator si, daca nu au erori, sunt convertite in PDF, semnate si depuse.

ANAF a publicat doua seturi de teste de consistenta pentru SAF-T, in 2023 si in 2024. Primul set contine 22 de teste. Al doilea, publicat in august 2024, adauga 11 teste axate pe TVA. Testele sunt verificari pe care contribuabilul le poate aplica singur inainte de depunere, iar ANAF anunta ca notifica firmele ale caror declaratii le identifica drept incorecte sau incomplete. Un exemplu din primul set: testul 12 verifica egalitatea dintre totalul soldurilor initiale debitoare si totalul soldurilor initiale creditoare, fara conturile din clasele 8 si 9.

Ce nu vede validatorul

Un validator verifica structura fisierului si regulile publicate. El nu stie ca doua fise de client diferite apartin aceleiasi firme. Nu stie nici ca un produs a primit alt cod in CRM decat in contabilitate. Aceste neconcordante raman in sarcina companiei, iar sursa lor este de obicei introducerea datelor, nu contabilitatea.

CUI-ul si codul de TVA sunt campurile din Zoho CRM care conteaza cel mai mult pentru D406. CUI este Codul Unic de Inregistrare al unei companii. Documentatia Odoo pentru Romania arata un format clar. CUI-ul se scrie fara prefixul RO, de exemplu 18547290. Codul de TVA, pentru o firma inregistrata in scopuri de TVA, se scrie cu prefixul RO.

In CRM, cele doua valori ajung adesea amestecate intr-un singur camp. Unele fise au "RO18547290", altele "18547290", altele nimic. Cand fisa trece in Zoho Books, formatul inconsecvent trece odata cu ea. Recomandarea noastra este sa pastrati doua campuri separate:

• CUI, doar cifre, fara prefix, obligatoriu pentru orice client persoana juridica;
• cod de TVA, cu prefixul RO, completat doar pentru platitorii de TVA.

Faceti campul CUI obligatoriu inainte ca o oportunitate sa ajunga la factura. Un camp gol descoperit la emiterea facturii costa mai mult decat unul cerut la crearea fisei.

Pentru a nu copia manual datele din registru, puteti folosi o extensie de verificare CUI la ANAF pentru Zoho CRM. Ea verifica CUI-ul si preia datele financiare ale firmei. Astfel, denumirea si codul vin din aceeasi sursa pentru toti clientii.

Firmele duplicate din CRM produc facturi emise catre acelasi client sub denumiri diferite. Duplicatele apar firesc in timp. Un agent scrie "SRL", altul scrie "S.R.L.", iar un al treilea creeaza o fisa noua din telefon, fara CUI. Cautarea dupa nume nu le prinde, pentru ca denumirile difera prin detalii.

Cheia corecta pentru gasirea duplicatelor este CUI-ul, nu denumirea. Exportati fisele de companii, normalizati CUI-ul eliminand prefixul RO si spatiile, apoi sortati dupa el. Orice CUI care apare de doua ori indica un duplicat. Fisele fara CUI le verificati separat, dupa denumire si adresa.

La Svennis, inainte de a porni sincronizarea clientilor din Zoho CRM catre Zoho Books, exportam fisele de companii, le sortam dupa CUI si unificam duplicatele impreuna cu cineva din contabilitate, nu doar cu echipa de vanzari. Altfel, aceeasi firma ajunge pe facturi sub doua denumiri, iar corectura se face apoi document cu document.

Regula pentru fisa principala

Alegeti ca fisa principala pe cea cu cel mai mult istoric de oportunitati si activitati. Scrieti denumirea legala exact ca in registru. Mutati pe ea contactele si oportunitatile din fisele secundare, apoi stergeti-le pe acestea. Faceti unificarea inainte de sincronizare, ca Zoho Books sa primeasca o singura fisa.

Catalogul de produse din Zoho CRM trebuie sa foloseasca aceleasi coduri ca nomenclatorul din Zoho Books. Cand un produs are un cod in CRM si altul in contabilitate, liniile de factura nu mai pot fi urmarite de la oferta la declaratie. Problema apare des cand produsele intra in CRM din mai multe surse. Un exemplu este integrarea WooCommerce cu Zoho CRM, unde magazinul vine cu propriile coduri.

Pentru D406 conteaza si codul NC al produsului. Documentatia Odoo pentru Romania arata ca, la unele tranzactii cu marfuri, legea cere configurarea codului Intrastat (cod NC) pe produs. In Odoo, de exemplu, un produs care nu este serviciu si nu are cod NC este exportat cu codul implicit "0". Verificati cu contabilul cum trateaza Zoho Books sau programul dumneavoastra de raportare un cod NC lipsa. Pentru tranzactiile la care legea cere codul NC, un produs fizic fara acest cod este raportat incomplet.

Taxele cu coduri SAF-T

Fiecare taxa folosita trebuie sa aiba Tipul fiscal SAF-T, din 3 cifre, si Codul fiscal SAF-T, din 6 cifre. Ambele coduri sunt definite de ANAF pentru D406. Aceste coduri se seteaza in contabilitate, nu in CRM. Totusi, cotele de TVA alese pe produsele din CRM trebuie sa corespunda unor taxe care au deja codurile completate.

Concret, pe fiecare produs din CRM verificati codul unic, tipul (bun sau serviciu), codul NC pentru bunuri si cota de TVA. Mai multe despre configurarea contabila gasiti pe pagina despre Zoho Books in Romania.

Exemplul urmator arata cum corectati in CRM doua erori tipice inainte de D406. Un distribuitor are in Zoho CRM firma "Alfa Distributie SRL", cu CUI-ul scris "RO18547290". Tot acolo exista "ALFA DISTRIBUTIE S.R.L.", fara CUI, creata de alt agent. Pe facturi se vinde si un termostat, inregistrat ca bun, dar fara cod NC.

Corectura se face in ordinea de mai jos:

1. Cautati CUI-ul in ambele forme, 18547290 si RO18547290. Gasiti prima fisa. A doua apare doar la cautarea dupa denumire.
2. Alegeti prima fisa ca principala, pentru ca are istoricul de oportunitati. Scrieti CUI-ul 18547290 fara prefix.
3. Daca firma este platitoare de TVA, completati codul de TVA RO18547290 in campul separat.
4. Mutati contactele si oportunitatile de pe a doua fisa pe cea principala, apoi stergeti fisa secundara.
5. Pe produs, completati codul NC confirmat de contabil. Fara el, produsul poate ajunge in D406 fara cod NC sau cu un cod implicit, in functie de programul care genereaza fisierul. Raportarea este atunci incompleta acolo unde codul NC este cerut.
6. Sincronizati din nou cu Zoho Books. Generati fisierul D406 si validati-l in DUKIntegrator.

Facturile deja emise nu se repara din CRM. Corectura lor o decide contabilul, de exemplu printr-o factura storno, raportata cu tipul de document 381. CRM-ul curat previne doar erorile din facturile urmatoare.

Lista de verificare de mai jos acopera principalele campuri din CRM si contabilitate care ajung in D406. Ea include orasul si tara clientului, pe care ANAF le verifica explicit. Pentru clientii din alte state, identificatorul este codul de TVA de pe factura, nu un CUI. Folositi lista inainte de fiecare perioada de raportare, lunara sau trimestriala.

Coloana "Cine raspunde" conteaza la fel de mult ca restul. Fara un responsabil numit, corectura ramane intre vanzari si contabilitate.

Camp	Unde se corecteaza	Regula de verificat	Cine raspunde
CUI client	Zoho CRM, fisa companiei	Doar cifre, fara prefixul RO, obligatoriu la persoanele juridice din Romania	Vanzari
Cod de TVA	Zoho CRM, camp separat	Cu prefixul RO pentru platitorii romani; pentru clientii straini, codul de TVA de pe factura	Vanzari
Oras si tara client	Zoho CRM, adresa companiei	Completate pe fiecare fisa de client	Vanzari
Denumire legala	Zoho CRM, fisa principala	Scrisa ca in registru, o singura fisa per CUI	Vanzari si contabilitate
Cod produs	Catalogul din CRM si Zoho Books	Acelasi cod unic in ambele sisteme	Responsabilul de catalog
Cod NC	Fisa produsului	Completat pentru bunuri acolo unde este cerut, cu valoarea confirmata de contabil	Contabilitate
Taxe	Zoho Books	Tip fiscal SAF-T din 3 cifre si cod fiscal din 6 cifre	Contabilitate
Tip document	Contabilitate	380, 381, 384, 389 sau 751, dupa caz	Contabilitate

Primele cinci randuri se corecteaza in CRM. Ultimele trei tin de contabilitate, dar depind de date corecte venite din CRM.

Pentru o companie din Romania, D406 transforma calitatea datelor din CRM intr-o obligatie recurenta. Din 2025, declaratia se depune lunar sau trimestrial si de contribuabilii mici. Obligatia acopera acum marii contribuabili, contribuabilii mijlocii si pe cei mici. Ordinul ANAF prevede exceptii, de exemplu PFA, II si IF.

O fisa de client gresita nu produce o singura eroare, ci aceeasi eroare in fiecare perioada. Corectura facuta o data in CRM le opreste pe toate cele urmatoare.

Verificarea datelor din SAF-T a devenit si mai stricta in timp. ANAF a adaugat in 2024 al doilea set de teste, cu 11 verificari axate pe TVA. ANAF anunta ca notifica firmele ale caror declaratii SAF-T le identifica drept incorecte sau incomplete. Neconcordantele de TVA nu mai raman deci doar in fisierul intern al contabilului.

Multe companii emit facturile direct din CRM, printr-un program de facturare conectat. Un exemplu este integrarea SmartBill cu Zoho CRM pentru e-facturare ANAF. In acest caz, fisa clientului din CRM alimenteaza direct factura. CUI-ul gresit ajunge atunci pe factura si de acolo in raportare.

Concluzia practica este simpla. Vanzarile si contabilitatea lucreaza pe aceleasi date, chiar daca in sisteme diferite. Stabiliti cine detine fiecare camp si cand se verifica, inainte de urmatoarea declaratie, nu dupa notificare.

Incepeti cu un export si o discutie de o ora intre vanzari si contabilitate. Nu aveti nevoie de un proiect mare pentru primul pas. Aveti nevoie de lista campurilor si de un responsabil pentru fiecare. Ordinea de mai jos functioneaza pentru majoritatea companiilor care sincronizeaza Zoho CRM cu Zoho Books:

1. Exportati fisele de companii si sortati-le dupa CUI normalizat, fara prefixul RO.
2. Unificati duplicatele si completati CUI-urile lipsa la clientii persoane juridice.
3. Separati CUI-ul de codul de TVA si faceti CUI-ul obligatoriu.
4. Comparati catalogul de produse din CRM cu nomenclatorul din Zoho Books, cod cu cod.
5. Cereti contabilului codurile NC pentru bunuri si verificarea codurilor SAF-T pe taxe.
6. Generati un fisier D406 de proba si validati-l in DUKIntegrator inainte de termen.

Repetati pasii 1 si 4 inainte de fiecare perioada de raportare, pana cand nu mai gasiti diferente. Daca doriti ca regulile de validare sa fie construite direct in CRM, pagina despre implementarea Zoho CRM in Romania descrie cum se configureaza sistemul pentru firmele locale.

• Odoo 17.0, localizarea fiscala Romania (D406, CUI, cod NC, DUKIntegrator)
• BIT Software, EBS-RO: D406 - SAF-T