UBL 2.1 (CIUS-RO): formatul XML pentru e-Factura ANAF

Universal Business Language (UBL) versiunea 2.1 este standardul internațional XML pentru documente de afaceri, dezvoltat de OASIS și adoptat ca normă europeană prin EN 16931¹. UBL definește o gramatică XML comună pentru facturi, comenzi, avize de expediție, recipise și alte documente comerciale, astfel încât un sistem care emite o factură UBL să fie citit fără ambiguitate de orice sistem care o consumă, indiferent de țară sau de furnizorul de software.

În România, e-Factura ANAF nu acceptă orice fișier UBL 2.1. Acceptă un profil restrâns numit CIUS-RO (Core Invoice Usage Specification, profilul pentru România), definit prin OMFP 1366/2021. CIUS-RO este un strat suplimentar de reguli peste UBL 2.1 care precizează ce câmpuri trebuie să existe obligatoriu, ce coduri sunt acceptate pentru categorii de TVA, cum se exprimă CUI-ul cu prefixul „RO", formatul datelor (RRRR-LL-ZZ ISO 8601), și valorile permise pentru tipul de document². Un fișier UBL 2.1 perfect valid contra schemei OASIS poate fi respins de e-Factura dacă încalcă CIUS-RO.

Ce este Universal Business Language?

UBL face parte din familia de standarde OASIS, cu origini în 2003 și o serie de versiuni succesive (1.0 în 2004, 2.0 în 2006, 2.1 în 2013, 2.4 în 2020). Versiunea 2.1 este cea adoptată majoritar de jurisdicțiile europene pentru e-Factura, fiind referința pe care se sprijină norma EN 16931 publicată de CEN pentru a face e-Factura interoperabilă în Uniunea Europeană.

Conceptual, UBL livrează trei lucruri:

• O schemă XML (XSD) care definește structura permisă: ce tag-uri, în ce ordine, cu ce tipuri de date.
• Un vocabular comun: nume canonice pentru entități recurente (Party, Address, TaxScheme, InvoiceLine, PaymentTerms), astfel încât „client" sau „furnizor" să însemne același lucru peste tot.
• Profiluri opționale: subseturi predefinite pentru cazuri de utilizare specifice (facturare europeană B2G, facturare națională, ordin de cumpărare). Fiecare profil restrânge sau extinde UBL 2.1 pentru un context.

Profilurile sunt mecanismul prin care fiecare țară își ajustează UBL la realitatea locală fără să fragmenteze standardul. CIUS-RO este unul dintre aceste profiluri; PEPPOL BIS Billing 3.0 este altul, folosit pe scară largă în spațiul Nordic și pentru achiziții publice. Un sistem care poate citi UBL 2.1 generic poate fi învățat să producă orice profil specific schimbând doar layer-ul de validare și câteva mapări de câmp.

Ce adaugă CIUS-RO peste UBL 2.1 standard?

CIUS-RO restrânge UBL 2.1 prin trei tipuri de reguli:

1. Câmpuri obligatorii adiționale: CUI cu prefix „RO" pe părțile B2B, codul de țară ISO 3166 pe adrese, codul valutei ISO 4217 pe orice sumă. UBL standard le permite, CIUS-RO le impune.
2. Coduri restrânse: categoriile de TVA acceptate sunt S (taxă standard), AE (taxare inversă), Z (cotă zero) și E (scutit); tipurile de document sunt 380 (factură fiscală), 381 (notă de credit), 384 (factură corectivă); unitățile de măsură urmează UN/ECE Recommendation 20. Un cod în afara listei produce respingere.
3. Reguli de calcul: relațiile aritmetice între linii, subtotaluri, TVA și total trebuie să fie consistente la nivel de bani (rotunjire la 2 zecimale). O diferență de 0,01 lei între suma liniilor și totalul declarat respinge documentul.

Regulile sunt exprimate parțial în XSD (validare sintactică) și parțial în Schematron (validare semantică). Schematron este un standard separat pentru reguli de validare bazate pe expresii XPath; ANAF publică un set Schematron CIUS-RO pe care poți rula local înainte de a trimite la e-Factura, exact ca un linter.

Cum se validează un fișier UBL pentru ANAF?

Trei treceri, în ordine:

• Validare XSD UBL 2.1: schema OASIS oficială. Prinde greșeli de structură (tag necunoscut, tip de date greșit, ordine invalidă). Orice parser XML cu suport pentru XSD face asta.
• Validare Schematron CIUS-RO: regulile specifice României. Cere un procesor Schematron (saxon-HE plus o foaie de stil XSLT generată din regulile Schematron este cea mai folosită combinație în ecosistemul Java).
• Validare aplicată de e-Factura la încărcare: ANAF re-rulează propriile reguli pe server. Mesajele de eroare returnate folosesc coduri numerice (de exemplu, BR-04, BR-12) care corespund regulilor din specificația EN 16931 + CIUS-RO. Documentația publică listează codurile și sensul lor.

Mecanismul de retransmitere pentru documente respinse la validare cere atenție la idempotență: dacă schimbi un câmp și retrimiți, fișierul are deja un identificator nou (UUID intern), dar ANAF îl asociază cu factura comercială prin numărul de factură. Un al doilea upload cu același număr de factură și conținut diferit poate fi tratat ca o reraportare a aceleiași facturi sau ca document complet nou, în funcție de regulile interne ANAF. Citește răspunsul de validare înainte să decizi cum continui.

Care sunt erorile cele mai frecvente la validare?

Patru tipare apar repetat în implementări reale:

• Codificare. Fișierul trebuie să fie UTF-8 cu sau fără BOM, declarat explicit în prologul XML. ISO-8859-2 (latin-2) este o capcană clasică pentru cei care exportă din software vechi de contabilitate.
• Namespace-uri inversate. UBL 2.1 are namespace-uri stricte (urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 pentru rădăcina Invoice, plus declarații pentru cac și cbc). Schimbarea ordinii sau lipsa unei declarații rupe parserul ANAF chiar dacă conținutul este corect.
• Formatul CUI. „123456" și „RO123456" nu sunt echivalente pentru CIUS-RO. Plătitorul de TVA înregistrat în România declară CUI cu prefix „RO"; neînregistrat, fără prefix. O confuzie aici respinge documentul cu un cod de eroare neclar.
• Suma rotunjită inconsistent. Rotunjire la 2 zecimale pe linii, dar pe total folosești 4. Diferența de centime apare la validare ca discrepanță aritmetică. Practică sigură: rotunjire la fiecare etapă cu același număr de zecimale.

De ce contează UBL 2.1 pentru un dezvoltator?

Două motive practice: primul, dacă atingi e-Factura (direct prin API sau prin intermediar), UBL 2.1 este formatul peste care lucrezi. Înțelegerea diferenței dintre UBL standard și CIUS-RO te scutește de o categorie întreagă de bug-uri „de ce ANAF îmi respinge documentul când XML-ul meu pare valid?".

Al doilea: structurile UBL sunt reutilizabile dincolo de e-Factura românească. PEPPOL pentru facturare cross-border în UE, facturarea B2G în țări nordice și o parte din integrările Stripe (export factură UBL pentru abonamenți europeni) folosesc același vocabular. La crawlerra construim generatoare UBL ca biblioteci modulare, cu un strat de validare comutabil pe profil (CIUS-RO, PEPPOL BIS, EN 16931 generic), pentru că aceeași logică de generare deservește mai multe destinații cu efort minimal. Pentru cadrul mai larg al sistemului, vezi entry-ul despre e-Factura și diferența față de exportul contabil periodic prin SAF-T. Pentru un model mental despre date structurate citite de mașini fără ambiguitate, paralela cu JSON-LD ajută: ambele aleg standardizare lexicală peste flexibilitate, în schimbul interoperabilității.

1. Standard internațional UBL: OASIS Universal Business Language 2.1, publicată în noiembrie 2013. Adoptată ca normă europeană prin EN 16931 (CEN/TC 434), care definește semantica facturii electronice interoperabile la nivelul UE. Directiva 2014/55/UE a impus utilizarea EN 16931 în achizițiile publice. Documentația publică: docs.oasis-open.org/ubl, cen.eu (EN 16931). [seo.ubl_oasis_standard]
2. Profilul CIUS-RO este definit prin OMFP 1366/2021 și anexele tehnice publicate de ANAF. Schema XSD restrânsă, regulile Schematron și lista codurilor de eroare sunt publicate la efactura.anaf.ro (secțiunea „Specificații tehnice"). [seo.ubl_cius_ro_profile]