oneapiValidezi și citești fișierul SAF-T, printr-un apel.
Verifici un fișier SAF-T (D406) cu XSD-ul oficial ANAF (v2.4.9) plus propriile verificări, îl citești ca JSON cu sinteză pe secțiuni și îl randezi PDF — totul printr-un API, fără să stochezi nimic.
Nu construim declarația de la zero — fișierul îl produce ERP-ul sau programul tău de contabilitate. Noi îl validăm, îl despachetăm și îți dăm verdictul plus sinteza. Procesarea e în memorie; conținutul nu atinge un disc de-al nostru.
// multipart: fisier=D406.xml
// → { valid: true, standard: "D406", xsd_checked: "v2.4.9",
// errors: [], warnings: [] }
POST /saft/v1/parse // același fișier, despachetat
{
"header": { "firma": "RO12345678", "perioada": "2026-07", "versiune": "2.4.9" },
"rezumat": {
"master_files": { "conturi": 412, "clienti": 1380, "furnizori": 210 },
"jurnal": { "nr_jurnale": 8, "total_debit": 4820140.55, "total_credit": 4820140.55 }
}
}
- Standard
- D406 SAF-T
- Namespace
- mfp:anaf:dgti:d406t
- XSD oficial
- ANAF v2.4.9
- Operațiuni
- validate · parse · render (fără build)
- Retenție
- niciuna
Un fișier SAF-T valid e greu de verificat. Și nu e produsul tău.
Între fișierul pe care-l scoate ERP-ul și un D406 pe care ANAF îl acceptă la depunere se află un strat de reguli — schemă, structură, echilibru contabil — pe care cineva trebuie să-l verifice înainte.
Fișier imens
SAF-T nu e un formular, ci un XML cu rădăcina AuditFile și namespace-ul mfp:anaf:dgti:d406t:declaratie:v1 — master data, tot jurnalul de contabilitate și documentele sursă. Zeci de mii de linii, cu structură și ordine stricte.
Schema oficială v2.4.9
Structura se verifică împotriva XSD-ului oficial ANAF, versiunea 2.4.9. Un element lipsă, un tip greșit, o ordine încurcată, și fișierul e respins la validare.
Master files
Planul de conturi, clienții, furnizorii, tabela de taxe, produsele, stocurile, mijloacele fixe. Fiecare secțiune are propriile câmpuri obligatorii și coduri din nomenclatoare.
Jurnal contabil
Registrul-jurnal complet, cu toate înregistrările contabile. Echilibrul debit=credit trebuie să se închidă — o diferență, oricât de mică, și declarația e greșită.
Documente sursă
Facturile de vânzare și de cumpărare, plățile, mișcările de stoc. Legate de master files și de jurnal, cu coerență între totaluri și înregistrări.
Reguli care se schimbă
Schema se revizuiește, versiunile se succed (v2.4.9 azi), structura se ajustează. Ce trecea anul trecut poate pica azi, iar tu afli din refuz, nu din anunț.
Trei operațiuni și un nomenclator. Fără generare.
Fiecare e un apel POST independent. Nu construim fișierul — îl validăm, îl citim și îl randăm. Folosești pe cea de care ai nevoie.
/validate
Validează
Trimiți un fișier SAF-T existent, primești verdictul. Îl verificăm cu XSD-ul oficial ANAF v2.4.9 plus propriile verificări — rădăcina AuditFile, antetul, echilibrul debit=credit din jurnal. Primești ce s-a verificat, erorile și avertismentele.
/parse
Citește
Un fișier SAF-T devine JSON curat: antetul (firmă, perioadă, monedă, program, versiune) și o sinteză pe secțiuni — câte conturi, clienți, furnizori, produse, câte jurnale cu total debit și credit, câte documente. Îl citești fără să atingi XML-ul.
/render
Randează
Din fișier iese un PDF de sinteză lizibil pentru om, generat local. Antetul și totalurile pe secțiuni, pentru dosar sau verificare, fără un serviciu extern de randare.
/codes
Nomenclatoare
Listele oficiale pe care le folosește D406 — coduri de taxe, tipuri de conturi, unități de măsură — servite ca referință, ca să verifici din formular înainte de generare.
Contabilitatea ta nu ajunge nicăieri. Nici la noi, nici la ANAF.
Ăsta e răspunsul la „de ce aș trimite tot registrul meu contabil la un terț”. Pentru că, practic, nu-l trimiți nicăieri — procesăm și uităm.
Procesare în memorie
Fișierul nu se scrie niciodată pe disc. Intră în request, e validat și citit în memorie și dispare când răspunsul pleacă. Nu există un fișier SAF-T al tău la noi.
Validare locală
XSD-ul oficial v2.4.9 și verificările proprii rulează la noi, pe serverul care ține răspunsul tău. Nu trimitem fișierul la ANAF ca să aflăm dacă e valid — regulile sunt aici, verdictul e local.
Loguri fără conținut
Ce reținem e un cod de rezultat și o durată — atât. CUI-ul, conturile, partenerii, sumele nu intră în niciun log, nici la noi, nici la un serviciu de observabilitate.
Doar verdictul
Un header opțional îți spune să întoarcem doar verdictul și sinteza, fără nimic din conținutul liniilor. Pentru integrări unde vrei validarea, dar preferi ca datele să nu treacă prin răspuns.
Nu-ți spunem doar „invalid”. Îți spunem exact ce și unde.
Rulăm XSD-ul oficial v2.4.9 complet, local, plus propriile verificări, și îți dăm diagnosticul pe care validatorul DUK Integrator nu ți-l dă atât de clar înainte de depunere.
Schema XSD oficială v2.4.9
Verificăm structura împotriva XSD-ului oficial ANAF, versiunea 2.4.9: elemente, tipuri, ordine, cardinalități. Dacă lipsește un câmp obligatoriu sau un tip nu se potrivește, îl prindem înainte să ajungă vreodată la SPV.
Verificări proprii
Peste XSD rulăm propriile verificări: rădăcina AuditFile și namespace-ul corect, antetul complet și coerent, echilibrul debit=credit al jurnalului contabil. Lucrurile care trec de schemă, dar tot fac fișierul greșit.
Diagnostic, nu doar verdict
Răspunsul îți spune ce s-a verificat, dacă fișierul e valid, plus lista de erori și de avertismente cu regula și locul implicat. Diferența dintre a ști că e o problemă și a ști unde e.
Fără depunere în SPV
Validarea e complet locală: implicit, nimic nu pleacă de la noi către ANAF. Depunerea D406 prin SPV rămâne la tine, cu credențialele tale — noi îți dăm verdictul și sinteza înainte de acel pas.
De la planul de conturi la documentele sursă.
Secțiunile reale ale unui fișier D406, nu doar antetul. Fiecare validată și citită, cu totalurile numărate.
Acoperim fișierul D406 complet, cu master files, jurnal contabil și documente sursă. Dacă întâlnești o secțiune pe care nu o tratăm corect, scrie-ne — cazurile reale au prioritate în ce construim.
Un fișier SAF-T intră. Verdictul și sinteza ies.
Trimiți fișierul, primești verdictul de validare sau JSON-ul cu antet și sinteză. Fără SDK obligatoriu — clientul HTTP pe care îl ai deja.
# validate: un fișier D406 → verdict față de XSD-ul oficial v2.4.9 + verificări proprii
curl "https://oneapi.ro/api/anaf/v1/saft/validate" \
-H "Authorization: Bearer $ONEAPI_TOKEN" \
-F "fisier=@d406_2026_07.xml"
# → 200 OK
{
"valid": true,
"standard": "D406",
"xsd_checked": "v2.4.9",
"errors": [],
"warnings": []
}
Ce s-a verificat, regula și locul
Un răspuns de validare nu-ți dă doar „invalid”. Îți spune ce s-a verificat — XSD v2.4.9 și verificările proprii —, dacă e valid, plus erorile și avertismentele cu regula implicată. Suficient ca să corectezi din prima, nu să ghicești.
HTTP/1.1 422 Unprocessable Content
{ "valid": false,
"standard": "D406",
"xsd_checked": "v2.4.9",
"errors": [ {
"regula": "SAFT-BAL-01",
"mesaj": "Jurnal: debit ≠ credit (Δ 0.02).",
"camp": "GeneralLedgerEntries"
} ], "warnings": [] }
Înainte să depui primul D406.
Restul, în întrebări frecvente și în documentație.