De la 1 iulie 2024, România a trecut la facturare electronică generalizată în B2B prin e-Factura ANAF, după o perioadă de raportare între 1 ianuarie – 30 iunie 2024. Decizia a fost posibilă prin derogarea acordată de Consiliul UE prin Implementing Decision (EU) 2023/1553, iar specificațiile tehnice sunt bazate pe UBL 2.1 aliniat la EN 16931 (profilul local RO_CIUS). În acest context, echipele IT, furnizorii ERP și consultanții EDI trebuie să mapeze corect segmentele EDIFACT, în special EDI NAD (Name and Address), către structurile UBL cerute de e-Factura ANAF, pentru a asigura conformitatea și a evita respingerile în SPV.
Ce înseamnă EDI NAD și de ce contează în e-Factura ANAF
EDI NAD este segmentul EDIFACT pentru identificare și adrese ale părților implicate într-o tranzacție. El acoperă calități precum SU (Supplier), BY (Buyer), IV (Invoicee), DP (Delivery Party) sau PE (Tax Representative). În e-Factura ANAF, aceste informații trebuie mapate în UBL la entități precum AccountingSupplierParty, AccountingCustomerParty, PayeeParty, Delivery/DeliveryParty și TaxRepresentativeParty. O mapare greșită a EDI NAD duce la erori de validare RO_CIUS, întârzieri și potențiale penalități.
Câmpuri obligatorii pentru părți în e-Factura ANAF
- Furnizor (Supplier): denumire legală, identificator fiscal (CUI/VAT), adresă (stradă, localitate, cod poștal, țară), cel puțin un identificator fiscal într-un schemeID acceptat; opțional cont IBAN, e-mail.
- Client (Buyer): denumire legală, identificator fiscal (CUI/VAT) pentru B2B domestic, adresă, țară; pentru livrări intracomunitare se aplică regulile de TVA relevante.
- Invoicee/Payee (dacă diferă de Buyer/Supplier): identificator fiscal și denumire.
- Delivery Party/Delivery Location (opțional dar recomandat când livrarea e către alt punct): denumire, adresă, țară.
- Tax Representative (dacă există): identificator fiscal și adresă.
RO_CIUS cere utilizarea identificatorilor conform listelor EAS/EN 16931. Practic, pentru România, identificatorul fiscal trebuie să reprezinte CUI/VAT-ul, iar validarea e-Factura ANAF se face pe baza acestuia. În UBL, câmpurile relevante sunt PartyIdentification/ID (cu schemeID specific) și PartyTaxScheme/CompanyID.
Maparea EDI NAD către UBL (RO_CIUS) pentru e-Factura ANAF
- NAD+SU (Supplier)
- C082.3039 (Party ID) → AccountingSupplierParty/Party/PartyIdentification/ID; folosiți identificatorul fiscal (CUI/VAT). Recomandare: păstrați doar cifrele în CompanyID și setați schemeID pentru RO_CIUS (de ex. “RO:CIF”).
- C080/C058 (Nume) → PartyName/Name.
- C059/3164/3251/3207 (Adresă/Localitate/Cod poștal/Țară) → PostalAddress/StreetName, CityName, PostalZone, Country/IdentificationCode (“RO”).
- VAT → PartyTaxScheme/CompanyID (același CUI/VAT; formatarea fără “RO” în valoare, dacă schemeID acoperă originea).
- NAD+BY (Buyer)
- C082.3039 → AccountingCustomerParty/Party/PartyIdentification/ID.
- Nume și adresă → PartyName și PostalAddress ca mai sus.
- VAT → PartyTaxScheme/CompanyID.
- NAD+IV (Invoicee) și/sau NAD+PY (Payer/Payee)
- C082.3039 → PayeeParty/PartyIdentification/ID (dacă entitatea ce încasează diferă de Supplier) sau BuyerReference/Party când există un invoicee distinct.
- NAD+DP (Delivery Party)
- C080/C059/3164/3251/3207 → Delivery/DeliveryParty/PartyName și Delivery/DeliveryLocation/Address. La nevoie, folosiți endpoint intern (cod magazin, GLN) în PartyIdentification cu schemeID corespunzător (ex. GLN) – nu este obligatoriu pentru e-Factura ANAF, dar util operațional.
- NAD+PE (Tax Representative)
- C082.3039 → TaxRepresentativeParty/PartyIdentification/ID; adresa în PostalAddress.
Reguli de validare și capcane frecvente
- Consistența identificatorului: folosiți același CUI/VAT în PartyIdentification și PartyTaxScheme. Evitați dublarea cu “RO” în valoare dacă schema îl codifică deja.
- Diacritice și encodare: UBL trebuie să fie UTF-8; evitați caractere de control din EDI NAD ce pot perturba XML-ul.
- Adresarea: completați PostalZone (cod poștal) și țara în format ISO 3166-1 alpha-2 (“RO”). Pentru județ, folosiți AdministrativeArea unde este disponibil.
- Invoicee/Payee distinct: dacă în EDIFACT exista NAD+IV sau NAD+PY, reflectați diferența în UBL; altfel, e-Factura ANAF consideră Buyer și Payee/Supplier identici.
- Endpoint operațional vs. fiscal: e-Factura ANAF rutează pe baza CUI-ului din SPV. GLN/DUNS din EDI NAD pot fi păstrate ca PartyIdentification suplimentar, dar nu înlocuiesc identificatorul fiscal.
Integrare cu ERP/EDI: la ce să fiți atenți
Furnizori ca SAP (Document Compliance), Microsoft Dynamics 365, Oracle NetSuite, dar și rețele EDI precum Pagero, Sovos, Comarch și OpenText oferă conectori pentru e-Factura ANAF. Cheia este transformarea fiabilă EDI NAD → UBL RO_CIUS, cu mapping configurabil pe calități (SU/BY/IV/DP/PE) și validare înainte de transmiterea în SPV. Soluțiile mature includ validatoare RO_CIUS și jurnalizare a erorilor ANAF (HTTP 4xx/5xx, coduri de validare), plus retry cu backoff pentru ferestrele de indisponibilitate ANAF.
Date de piață și context european
Romania a aliniat e-Factura ANAF la EN 16931, în linie cu tendința europeană de digitalizare fiscală. La nivel global, piața EDI a fost estimată la circa 2,1 miliarde USD în 2022, cu o creștere anuală compusă de aproximativ 9–10% până în 2030, conform analizelor Grand View Research, pe fondul extinderii e-invoicing-ului și a cerințelor de conformitate digitală.
Resurse utile:
Implementing Decision (EU) 2023/1553,
Ministerul Finanțelor – e-Factura,
ANAF – SPV,
Grand View Research – EDI Market.
Concluzie
Pentru conformitate e-Factura ANAF, maparea corectă a EDI NAD către entitățile UBL RO_CIUS este esențială. Prioritizați identificatorii fiscali (CUI/VAT) cu schemeID adecvat, adrese complete și separarea corectă a rolurilor SU/BY/IV/DP/PE. Implementați validări automate și jurnalizare a erorilor, testați capabilitățile de retry și mențineți sincronia între ERP și gateway-ul de trimitere. Într-o piață EDI în creștere și cu reglementări în evoluție, robustețea mapping-ului NAD și disciplina datelor de master vor face diferența între un flux conform și unul blocat în erori ANAF.