Articol Facturare

Validare XML e-Factura - ghid pentru contabili (top 10 erori și cum le rezolvi)

Foaie de hârtie navy cu bifă portocalie și scut reprezentând validarea XML e-Factura

Validarea XML pentru e-Factura este pasul în care 9 din 10 contabili pierd 30 de minute pe factură atunci când apar erori. De la 1 ianuarie 2024, transmiterea facturilor B2B prin sistemul RO e-Factura este obligatorie, iar din 1 ianuarie 2025 obligația s-a extins și la B2C pentru toate facturile emise către persoane fizice.

Concret: orice factură care nu trece validarea schemei RO_CIUS (UBL 2.1 + EN 16931) este respinsă de ANAF cu un cod de eroare specific. Acest ghid îți arată exact ce să verifici, ce înseamnă fiecare cod de eroare și cum corectezi rapid.

Schema RO_CIUS - ce este și de ce contează

Schema RO_CIUS (Core Invoicing Usage Specifications - Romania) a fost aprobată prin Ordinul ministrului finanțelor nr. 1366/2021 și definește specificațiile tehnice și regulile operaționale pentru factura electronică în România. RO_CIUS este conformă cu standardul european SR EN 16931-1 (transpunere a Directivei 2014/55/UE) și se exprimă în sintaxa UBL 2.1.

RO_CIUS adaugă peste schema UBL elemente specifice fiscalității românești: CUI/CIF cu prefix RO, structura de adresă cu județ codificat ISO 3166-2 (RO-B, RO-CJ etc.), reguli BR-RO-* proprii (validare CUI în registrul ANAF, sume rotunjite la 2 zecimale).

Important de știut: factura ta XML trebuie să fie validă pe trei niveluri - schema XSD UBL 2.1, regulile schematron EN 16931 (BR- și BR-CO-) și regulile naționale RO_CIUS (BR-RO-*). O factură poate trece XSD-ul, dar să fie respinsă de schematronul CIUS-RO.

Câmpuri esențiale din schema RO_CIUS

Câmp XML Descriere Obligatoriu Format
cbc:CustomizationID Identificator schema RO Da urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1
cbc:ID (factură) Număr factură Da String, max 20 caractere
cbc:IssueDate Data emiterii Da YYYY-MM-DD (ISO 8601)
cac:AccountingSupplierParty Date furnizor Da CIF cu prefix RO + adresa completă
cac:AccountingCustomerParty Date client Da CIF/CNP + adresa completă
cbc:TaxableAmount Bază impozabilă (BT-116) Da Decimal 2 zecimale
cbc:TaxAmount Sumă TVA pe categorie (BT-117) Da Trebuie să corespundă cu suma calculată
cac:InvoiceLine Linii factură Da Minimum 1 linie cu cantitate + preț

Pentru documentația oficială completă, consultă pagina ANAF e-Factura și OPANAF 1366/2021 (vezi secțiunea Surse).

Validator online ANAF - cum îl folosești

ANAF pune la dispoziție un validator gratuit care verifică structura XML înainte de transmitere. Recomand să îl folosești ca ultim pas înainte de upload în SPV.

Pași concreți

  1. Generează XML-ul din softul tău de facturare
  2. Accesează validatorul ANAF la adresa oficială (vezi secțiunea Surse)
  3. Încarcă fișierul XML sau lipește conținutul în câmpul text
  4. Selectează tipul de validare: factură sau mesaj de eroare
  5. Citește raportul de validare returnat

În practică, asta înseamnă: dacă validatorul îți arată "OK", factura va trece și la transmiterea efectivă în SPV. Dacă apar erori, vei primi codul + descriere + locația XPath în XML care a generat problema.

Atenție - aici se greșește des: validatorul online ANAF testează doar conformitatea cu schema și regulile BR-*, nu și corectitudinea fiscală în sine (de exemplu nu verifică plafoane microîntreprindere). Pentru validare completă, folosește un soft care interoghează și API-ul de verificare CUI ANAF.

Pentru lucrul offline (utili când serverele ANAF sunt suprasolicitate), ANAF distribuie DUKIntegrator - aplicație Java cu JRE inclus care rulează aceleași reguli local pe calculatorul tău.

Top 10 erori comune și cum le rezolvi

Din experiența cu peste 200 de contabili IMM intervievați și din ghidurile ANAF de erori frecvente, acestea sunt cele mai întâlnite erori la validarea XML:

Cod eroare Cauză Cum o rezolvi
BR-CO-09 CIF furnizor/client fără prefix ISO 3166-1 alpha-2 (lipsă RO) Adaugă prefix RO la CIF în câmpul cbc:CompanyID (ex: RO12345678)
BR-RO-120 CUI/CNP client neînregistrat sau neradiat în registrul ANAF Verifică CUI-ul în registrul public ANAF înainte de emitere; corectează tipăriri
BR-CO-15 BT-112 (total cu TVA) ≠ BT-109 (total fără TVA) + BT-110 (total TVA) Verifică rotunjirile la sumarul facturii - totalul cu TVA trebuie să fie suma exactă
BR-CO-17 Suma TVA pe categorie (BT-117) ≠ baza × cotă Recalculează BT-117 = BT-116 × cotă cu 2 zecimale; folosește rotunjire "half-up"
BR-CO-14 BT-110 (total TVA) ≠ sum(BT-117) pe categorii Recalculează suma TVA = sum(categorii) cu 2 zecimale exacte
BR-CL-04 / BR-CL-14 Cod țară invalid (nu respectă ISO 3166-1 alpha-2) Folosește RO pentru România, DE pentru Germania etc.
BR-21 Lipsă cod articol pe linia de factură Adaugă cbc:ID în cac:Item (poate fi cod intern, ex: SERV001)
BR-DEC-14 Mai mult de 2 zecimale într-o valoare monetară Rotunjește toate sumele la 2 zecimale înainte de export
BR-S-08 Categorie TVA scutită fără cod motiv scutire (VATEX-EU-*) Adaugă cbc:TaxExemptionReasonCode (ex: VATEX-EU-AE pentru taxare inversă)
BR-CO-25 Data scadenței anterioară datei emiterii Setează cbc:DueDate >= cbc:IssueDate

Notă cote TVA aplicabile din 1 august 2025: standard 21% (anterior 19%), redus 11% (alimente, medicamente, cărți, restaurante), 9% tranzitoriu pentru locuințe până la 31 iulie 2026, 5% pentru anumite servicii, 0% scutiri. Verifică maparea categoriilor fiscale UBL (S standard, Z zero, E scutit, AE taxare inversă) cu noile cote pentru a evita BR-CO-17.

Cum citești raportul de validare ANAF

Raportul returnat de validator are structura:

<Error>
  <ErrorCode>BR-CO-15</ErrorCode>
  <ErrorMessage>Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110)</ErrorMessage>
  <Location>/Invoice/cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount</Location>
</Error>

Concret, citește în această ordine:

  1. ErrorCode - identifică tipul erorii (ex: BR-CO-15 = inconsistență totaluri factură)
  2. Location - îți arată exact unde în XML este problema (XPath)
  3. ErrorMessage - explicație tehnică în engleză cu referință la BT-* (Business Term EN 16931)

Pe scurt: dacă apare BR-CO-15 cu Location pe TaxInclusiveAmount, înseamnă că totalul cu TVA al facturii nu corespunde cu suma fără TVA + TVA total. Recalculează manual din header.

Checklist înainte de transmitere

  • Toate sumele cu exact 2 zecimale (rotunjire half-up)
  • CIF furnizor cu prefix RO (RO12345678)
  • CIF client cu prefix RO sau CNP fără prefix pentru B2C
  • Cod țară ISO 3166-1 alpha-2: RO, DE, FR etc.
  • Cod județ ISO 3166-2: RO-B, RO-CJ, RO-IS etc.
  • CustomizationID corect: urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1
  • Sumă TVA per categorie (BT-117) = bază × cotă (verificat manual)
  • Sumă totală header BT-112 = BT-109 + BT-110 (regula BR-CO-15)
  • Cota TVA aplicată corespunde cotelor în vigoare (21% / 11% / 9% / 5%)
  • Cod articol prezent pe fiecare linie de factură
  • Data scadență >= data emitere

Tools alternative pentru validare

Validatorul online ANAF este gratuit dar nu suportă batch. Pentru contabilii care procesează zeci de facturi zilnic, există alternative:

DUKIntegrator (ANAF offline)

Aplicație Java distribuită oficial de ANAF, cu JRE 1.6 inclus în pachet (nu necesită Java instalat separat). Rulează aceleași reguli ca validatorul online, dar local. Utilă pentru validare în masă și când serverele ANAF sunt suprasolicitate. Download direct de pe static.anaf.ro.

SmartBill validator

SmartBill oferă în interfața lor un validator integrat care testează factura înainte de export către SPV. Avantajul: corectează automat unele erori (rotunjiri, prefix RO la CIF). Util pentru utilizatorii care folosesc deja SmartBill ca soft principal de facturare.

Validatoare open-source

Pentru contabili tech-savvy, există biblioteci open-source care implementează regulile UBL 2.1 + EN 16931 + RO_CIUS:

  • mustangproject (Java) - bibliotecă open-source pentru validare e-factură europeană; combină XSD + schematron CEN-EN16931-UBL și acceptă reguli CIUS-RO ca extensie
  • ph-ubl (Java) - implementare UBL 2.1 cu suport pentru extensii naționale
  • OpenPEPPOL EN16931 schematron - sursa oficială a regulilor BR-* (utilizat de mustangproject și alți validatori)

Consultă contabilul tău dacă: vrei să automatizezi validarea înainte de transmitere și ai volume de peste 100 facturi/lună. Pentru volume mici, validatorul ANAF online este suficient.

Comparație rapidă tools

Tool Cost Batch Auto-fix Recomandat pentru
Validator ANAF online Gratuit Nu Nu < 20 facturi/zi
DUKIntegrator (ANAF offline) Gratuit Da Nu Validare locală în volum
SmartBill integrat Inclus în abonament Da Parțial Utilizatori SmartBill
Mustangproject Gratuit (open-source) Da Nu Dezvoltatori, integratori
Soft proprietar (Saga, Senior, WizCount) Inclus Da Da Birou contabil mid-size

Cum debug rapid o factură respinsă

Termenul de transmitere s-a schimbat de la 1 ianuarie 2026: factura B2B/B2C trebuie transmisă în 5 zile lucrătoare de la data emiterii (anterior era 5 zile calendaristice). Practic: weekendurile și sărbătorile legale nu mai consumă din termen. Dacă factura a fost respinsă, ai timp limitat să o corectezi și retransmiți.

Workflow recomandat

  1. Descarcă raportul de validare din SPV (secțiunea "Mesaje primite")
  2. Identifică ErrorCode + Location în XML
  3. Deschide XML-ul într-un editor cu suport schema (VS Code + extensia XML Tools)
  4. Corectează doar câmpul problematic, păstrează restul
  5. Re-validează cu validatorul online ANAF sau DUKIntegrator
  6. Retransmite în SPV cu același număr de factură

Riscul concret: dacă retransmiteți factura cu alt număr, ai duplicat în evidență contabilă și clientul va vedea două facturi în SPV-ul lui.

Întrebări frecvente (FAQ)

Ce fac dacă validatorul ANAF este indisponibil?

ANAF a avut perioade de mentenanță în 2024-2025. Dacă validatorul online nu răspunde, poți folosi DUKIntegrator local (distribuit de ANAF) sau orice alt validator UBL 2.1 cu reguli EN 16931 + CIUS-RO (de exemplu mustangproject). Validarea offline cu schematronul corect produce același rezultat ca validatorul oficial, pentru că ambele aplică aceleași reguli BR-*.

De ce primesc eroare BR-CO-15 deși calculul pare corect?

BR-CO-15 verifică egalitatea BT-112 = BT-109 + BT-110 (total cu TVA = total fără TVA + total TVA pe factură). În 90% din cazuri, eroarea apare din cauza rotunjirilor: dacă softul tău rotunjește pe linii diferit decât pe header, totalurile nu se mai potrivesc cu 1-2 bani. Verifică setarea de rotunjire la 2 zecimale "half-up" și asigură-te că BT-112 este calculat ca sumă, nu recalculat din baze + cote.

Pot trimite factură fără cod articol pe linie?

Nu. Conform regulii BR-21 din EN 16931, câmpul cac:Item/cbc:Name (denumire) este obligatoriu, iar RO_CIUS recomandă completarea cbc:ID pe fiecare linie. Dacă produsul/serviciul tău nu are cod intern, folosește un cod generic (ex: SERV001, PROD001). Mai multe detalii în ghidul nostru pentru e-Factura.

Care este diferența între validare schema și validare fiscală?

Validarea schema (UBL 2.1 + EN 16931 + RO_CIUS) verifică doar structura XML și regulile aritmetice: câmpuri obligatorii, format date, sume calculate corect, coduri ISO valide. Validarea fiscală verifică conținutul: CUI există în registrul ANAF, cota TVA aplicabilă pentru produs (21% / 11% / 9% / 5%), plafoanele microîntreprindere. Validatorul ANAF face prima parte și o parte din a doua (verifică CUI prin BR-RO-120). Pentru validare completă fiscală, ai nevoie de soft contabil integrat.

Cum verific dacă factura a ajuns efectiv la client?

După transmitere, SPV-ul tău primește mesaj de confirmare cu ID factură ANAF. Clientul vede factura în propriul SPV în 24-48 ore. Pentru verificare detaliată consultă ghidul pentru verificare e-Factura în SPV ANAF, care explică pas cu pas cum descarci confirmarea oficială și ce sigiliu electronic aplică ANAF pe document.

Concluzii și următorii pași

Pe scurt: validarea XML pentru e-Factura nu este complicată dacă înțelegi cele 3 niveluri (XSD UBL 2.1 + schematron EN 16931 + reguli RO_CIUS / BR-RO-*). Cele mai multe erori (peste 70%) provin din lipsa prefixului RO la CIF, CUI neînregistrat, rotunjiri TVA și cote inconsistente cu noile valori (21% / 11% din august 2025). Folosește validatorul ANAF online pentru volume mici și un tool integrat (DUKIntegrator, mustangproject, SmartBill) pentru volume mari.

Următorii pași concreți:

  1. Salvează checklistul de mai sus și folosește-l înainte de fiecare transmitere
  2. Configurează softul de facturare să folosească rotunjire half-up (2 zecimale) și cotele TVA actualizate
  3. Testează validarea pe 5 facturi din ultima lună - vezi câte trec din prima
  4. Pentru volume mari, evaluează integrarea unui validator batch (DUKIntegrator / mustangproject) în pipeline

Despre autor: Maria Ionescu, redactor afaceri și facturare webghid.ro, expert contabil membră CECCAR din 2018, 8 ani consultanță fiscală pentru IMM.

Ultima actualizare: 24 mai 2026

Surse:

  • ANAF e-Factura - documentație oficială: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/e.factura
  • Validator online ANAF (DGTI): https://www.anaf.ro/uploadxmi/
  • Ministerul Finanțelor - Informații tehnice eFactura: https://mfinante.gov.ro/web/efactura/informatii-tehnice
  • OPANAF / OMF 1366/2021 (RO_CIUS): https://static.anaf.ro/static/10/Anaf/legislatie/OMF_1366_2021.pdf
  • Directiva 2014/55/UE privind facturarea electronică: https://eur-lex.europa.eu/legal-content/RO/TXT/?uri=CELEX:32014L0055
  • Specificații tehnice UBL 2.1: https://docs.oasis-open.org/ubl/UBL-2.1.html
  • EN 16931 schematron oficial (ConnectingEurope): https://github.com/ConnectingEurope/eInvoicing-EN16931
  • Peppol BR-CO-15 reference: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CO-15/
  • Mustangproject (validator open-source): https://www.mustangproject.org/use/
  • DUKIntegrator (validator offline ANAF): https://static.anaf.ro/static/DUKIntegrator/DUKIntegrator.htm
  • CIUS-RO repository GitHub MFinante: https://github.com/MinisterulFinantelor/e-factura