EDI: Cum gestionezi listele de coduri pentru RO e‑Factura și SAF‑T D406

În 2024, odată cu generalizarea transmiterii prin RO e‑Factura și maturizarea raportărilor SAF‑T D406, organizarea listelor de coduri nu mai este o problemă “de back office”, ci o responsabilitate critică pentru proiectele EDI din orice companie. Fără o guvernanță clară a codelistelor, fluxurile EDI riscă respingeri de la ANAF, întârzieri operaționale și costuri de remediere. Mai jos este un ghid practic pentru IT manageri, consultanți, furnizori ERP și dezvoltatori care implementează EDI în România.

Ce liste de coduri contează pentru RO e‑Factura

RO e‑Factura implementează standardul european EN 16931, pe sintaxa UBL 2.1, conform cadrului legal stabilit prin OUG 120/2021 și actualizărilor ulterioare. Din iulie 2024, transmiterea facturilor B2B prin sistemul ANAF a devenit obligatorie. În practică, proiectele EDI trebuie să controleze și să verifice cel puțin următoarele liste de coduri:

• Valută: ISO 4217 (ex. RON, EUR, USD) – codul este obligatoriu pe document; EDI trebuie să valideze existența cursurilor și a simbolurilor corecte.
• Țară: ISO 3166‑1 alfa‑2 (ex. RO, DE, FR) – utilizat pentru adrese, identificări fiscale și livrare.
• Unități de măsură: UN/CEFACT Rec. 20/21 (ex. C62 = bucată, KGM = kilogram, LTR = litru) – lista are peste 1.000 de coduri; maparea în ERP este adesea incompletă.
• Categorii de TVA: codurile EN 16931 (S, Z, E, AE, K, G, O) – EDI trebuie să aplice regulile de consistență între categorie, cotă și baza legală.
• Mijloace de plată: UNCL 4461 (ex. 31 = Credit transfer, 48 = Card) – opțional, dar util pentru armonizare multi‑ERP.
• Scheme de identificare: ISO 6523/PEPPOL pentru identificatori de părți (acolo unde este cazul), plus CUI/RO conform practicilor locale.

ANAF publică documentație de conformitate pentru RO_CIUS; proiectele EDI trebuie să o urmărească la fiecare actualizare. În prima jumătate a lui 2024, multe echipe au constatat că respingerile ANAF vin frecvent din nealinierea codurilor UoM și a categoriilor de TVA cu regulile EN 16931.

Liste de coduri în SAF‑T D406

SAF‑T D406 (introdus prin OPANAF 1783/2021) urmează modelul OCDE SAF‑T v2, dar cu particularități locale. Și aici, EDI depinde de o taxonomie coerentă:

• TaxType și TaxCode: în practică, compania își definește codurile interne de TVA/impozite, care trebuie mapate consecvent la raportare (ex. cotele standard/reduse/zero, scutiri) și sincronizate cu RO e‑Factura.
• Chart of Accounts: tipuri de conturi și atribute (Active, Pasive, Venituri, Cheltuieli) – orice schimbare în planul de conturi afectează EDI și regulile de agregare.
• ProductType: Goods/Services – trebuie să fie consecvent cu natura liniei din factură și cu raportarea stocurilor.
• Unități de măsură: aceleași coduri UN/CEFACT ca în e‑Factura, pentru coerență între documente și stocuri.

Un risc tipic în EDI este dublarea logicii: o mapare pentru e‑Factura și alta pentru SAF‑T. Recomandarea este să aveți un “single source of truth” pentru codelist în tot peisajul EDI.

De ce se strică lucrurile în producție

• ERP folosește coduri interne scurte (ex. “BUC”) care nu sunt recunoscute de UN/CEFACT; EDI trebuie să traducă în “C62”.
• Schimbări legislative: chiar dacă nu sunt frecvente, mici ajustări în RO_CIUS sau D406 afectează validările EDI.
• Inconsecvențe între filiale: aceeași unitate de măsură mapată diferit în două instanțe ERP rupe raportarea consolidată EDI.

Arhitectura recomandată pentru gestionarea codelistelor

În proiectele mari EDI, tratati codelist ca un produs:

• Master Data pentru coduri: un registru central (MDM sau chiar un microserviciu) cu scheme: code, denumire, sursă, valid_from, valid_to, mapping_ERP, mapping_eFactura, mapping_SAF‑T.
• Versionare Git și pachete: mențineți codurile în repository (JSON/CSV), cu release‑uri semantice; CI/CD publică în medii non‑prod/prod pentru EDI.
• Sync automat din surse oficiale: ISO 4217, ISO 3166‑1, UN/CEFACT; validatori care blochează valori expirate.
• Validatori pre‑emisiei: rulează reguli EN 16931 și controale ANAF înainte de trimitere; în EDI, prevenția este mai ieftină decât resubmisiile.
• Observabilitate: dashboard cu rate de respingere pe motiv, top 10 coduri problematice, timp de remediere; SLO‑uri pentru latența EDI.

Tehnologii și exemple din piață

Furnizori mari precum SAP (Document and Reporting Compliance), Microsoft Dynamics 365 (e‑Invoicing add‑ons) și Oracle NetSuite oferă conectori sau acceleratoare, dar mapările de codelist rămân responsabilitatea clientului și a integratorului. Provideri specializați precum Sovos și Pagero oferă servicii de conformitate pentru România, cu actualizări rapide la schimbările legislative. În România, multe echipe EDI au standardizat unitățile de măsură pe UN/CEFACT și au centralizat categoriile de TVA pentru a reduce erorile cross‑modul (MM, SD, FI). La nivel global, rapoartele anuale Sovos indică peste 80 de jurisdicții care adoptă modele de raportare electronică tip CTC, ceea ce face disciplina de codelist o capabilitate strategică EDI, nu doar locală.

Exemplu practic: într‑un rollout multi‑ERP, o companie a stabilit că doar codurile UN/CEFACT pot exista în master data; orice altă valoare este respinsă la sursă printr‑un webhook EDI. Rezultatul: rata de respingere ANAF a scăzut sub 0,5% în prima lună, iar timpul de reconciliere pe facturi a scăzut cu peste 60%.

Procese operaționale care fac diferența

• Change Advisory Board pentru codelist: orice nou cod sau mapare trece prin review comun IT‑Tax‑Contabilitate.
• Calendar de actualizare: ferestre lunare pentru EDI, cu cut‑off înainte de închideri contabile/SAF‑T.
• Backtesting: rulați pe eșantioane istorice validările EDI de fiecare dată când se schimbă o mapare.

Concluzie

RO e‑Factura și SAF‑T D406 au mutat accentul din “integrare la nivel de fișier” spre “guvernanță de date și codelist” în EDI. Investiția într‑un registru central de coduri, versionare și validări automate scade riscul operațional, accelerează go‑live‑urile și pregătește organizația pentru următoarele cerințe CTC. Standardele (EN 16931, ISO 4217, ISO 3166‑1, UN/CEFACT) nu sunt opționale; ele sunt limbajul comun pe care EDI trebuie să‑l vorbească zi de zi. Dacă vă aflați la început, începeți cu unitățile de măsură, categoriile de TVA și monedele – apoi extindeți. EDI scalabil înseamnă codelist scalabil, iar în 2024 România a demonstrat că acesta este noul normal.