EN
RO
BR-CO-10 și BR-CO-26 sunt două reguli de validare complet diferite din specificația tehnică RO_CIUS, care apar frecvent în același fișier de răspuns de la ANAF, dar au cauze și soluții separate. BR-CO-10 semnalează o nepotrivire matematică între totalul facturii și suma valorilor de pe liniile ei, în timp ce BR-CO-26 semnalează faptul că factura nu conține niciun identificator valid al vânzătorului — de exemplu CUI-ul lipsă din câmpul tehnic corect din XML.
Confuzia dintre cele două vine din faptul că ambele apar sub eticheta generică „eroare de business rule" în fișierul de răspuns și amândouă blochează definitiv încărcarea facturii în Spațiul Privat Virtual (SPV), până la corectare și retransmitere. Acest ghid explică punctual ce verifică fiecare regulă, unde apare cel mai des fiecare eroare în XML-ul generat de un soft propriu sau de un ERP, și ce pași concreți rezolvă fiecare dintre ele. Ultima actualizare: 19.07.2026.
Materialul este util dezvoltatorilor care generează sau validează XML pentru RO e-Factura, precum și contabililor care primesc mesajul de eroare de la softul de facturare și vor să înțeleagă rapid dacă problema ține de totaluri sau de datele de identificare ale firmei.
Diferența pe scurt între BR-CO-10 și BR-CO-26
Cele două reguli verifică zone complet diferite ale facturii electronice și, în consecință, se corectează în locuri diferite din XML. Tabelul de mai jos rezumă diferența esențială.
| Aspect | BR-CO-10 | BR-CO-26 |
|---|---|---|
| Ce verifică | Totalul net al facturii (BT-106) trebuie să fie egal cu suma valorilor nete de pe liniile facturii (BT-131) | Factura trebuie să conțină cel puțin un identificator valid al vânzătorului (BT-29, BT-30, BT-31 sau BT-34) |
| Zona din XML afectată | cac:InvoiceLine și cac:LegalMonetaryTotal | cac:AccountingSupplierParty / cac:Party |
| Cauză tipică | Câmpuri inversate (LineExtensionAmount vs PriceAmount) sau rotunjire inconsistentă | CUI/CIF lipsă sau plasat în alt câmp XML decât cel validat, ori format incorect al identificatorului |
| Cine e afectat mai des | Integrări proprii care calculează totalul separat de liniile facturii | Integrări care preiau datele firmei dintr-un singur câmp generic, fără mapare corectă pe cele patru elemente RO_CIUS |
Practic, dacă mesajul de eroare vorbește despre sume și valori numerice, este BR-CO-10. Dacă vorbește despre identificarea vânzătorului (seller identification), este BR-CO-26 — și cele două rareori au aceeași cauză tehnică, chiar dacă apar în același răspuns.
Eroarea BR-CO-10: ce înseamnă și când apare
BR-CO-10 verifică o singură condiție matematică: totalul net al facturii, calculat la nivel de document (BT-106, elementul cac:LegalMonetaryTotal/cbc:LineExtensionAmount), trebuie să fie identic cu suma valorilor nete individuale ale fiecărei linii de factură (BT-131, elementul cac:InvoiceLine/cbc:LineExtensionAmount, repetat pe fiecare linie). Dacă suma liniilor nu se potrivește exact cu totalul declarat, ANAF respinge factura înainte de a-i acorda index de încărcare.
Cele mai frecvente cauze întâlnite în integrări reale sunt inversarea câmpurilor LineExtensionAmount (subtotalul liniei) cu PriceAmount (prețul unitar) și rotunjirea inconsistentă între suma liniilor și totalul facturii. Pentru o analiză tehnică detaliată, cu exemplu de cod XML greșit și corect, consultă ghidul dedicat erorii BR-CO-10 — articolul de față tratează BR-CO-10 doar în context comparativ cu BR-CO-26, nu detaliază din nou fiecare pas de corectare.
Eroarea BR-CO-26: ce înseamnă și când apare
BR-CO-26 provine direct din regula europeană EN 16931: „pentru ca un cumpărător să poată identifica automat un furnizor, factura trebuie să conțină cel puțin unul dintre următoarele elemente: identificatorul vânzătorului (BT-29), identificatorul de înregistrare legală al vânzătorului (BT-30), identificatorul de TVA al vânzătorului (BT-31) sau adresa electronică a vânzătorului (BT-34)". În RO_CIUS, varianta românească a standardului, regula rămâne aceeași, dar în practică validatorul ANAF cere aproape întotdeauna prezența CUI-ului/CIF-ului în cel puțin unul dintre câmpurile tehnice corespunzătoare.
Cele patru elemente corespund în XML următoarelor locații, toate în interiorul cac:AccountingSupplierParty/cac:Party:
- BT-29 —
cac:PartyIdentification/cbc:ID, un identificator general al vânzătorului - BT-30 —
cac:PartyLegalEntity/cbc:CompanyID, identificatorul de înregistrare legală (de regulă CUI-ul, cu prefixul de țară „RO") - BT-31 —
cac:PartyTaxScheme/cbc:CompanyID, codul de TVA al vânzătorului, dacă este plătitor de TVA - BT-34 —
cac:Party/cac:PartyLegalEntity/../cbc:EndpointIDsau elementul de adresă electronică echivalentă a vânzătorului
Eroarea apare aproape întotdeauna dintr-un singur motiv practic: niciunul dintre aceste patru câmpuri nu este completat corect în XML-ul generat, deși firma are, evident, un CUI valid în baza de date a softului de facturare. Cauza tehnică este o problemă de mapare — datele există, dar nu ajung în elementul XML pe care îl citește regula de validare.
Cauze tehnice frecvente ale erorii BR-CO-26
În integrările proprii, BR-CO-26 apare de regulă din una dintre următoarele situații:
- CompanyID complet lipsă din
PartyLegalEntity. Bucla care generează bloculcac:AccountingSupplierPartypopulează denumirea și adresa firmei, dar omite elementulcbc:CompanyID, pentru că șablonul XML a fost copiat dintr-un exemplu incomplet sau dintr-o versiune mai veche a specificației. - CUI scris fără prefixul de țară. Validatorul RO_CIUS acceptă
CompanyIDscris ca „RO12345678", nu doar „12345678"; formatul fără prefix poate fi respins sau tratat ca lipsă de identificator valid, în funcție de versiunea validatorului. - Datele firmei populate doar în
PartyIdentification(BT-29) generic, fără completarea în paralel aPartyLegalEntity/CompanyID(BT-30), atunci când softul de facturare a fost configurat inițial pentru alt tip de document decât e-Factura. - Element
cac:Partydublat sau plasat greșit în structura XML — de exemplu, un bloc de identificare a vânzătorului plasat subcac:AccountingCustomerParty(cumpărător) în loc decac:AccountingSupplierParty(vânzător), din cauza unei confuzii de variabile în cod.
O verificare rapidă utilă: dacă deschizi XML-ul generat și cauți manual șirul CUI-ului firmei tale, trebuie să îl găsești cel puțin o dată în interiorul blocului cac:AccountingSupplierParty — nu doar în denumirea firmei sau în adresă, ci într-un element cbc:CompanyID sau cbc:ID dedicat.
Cum rezolvi eroarea BR-CO-26 pas cu pas
- Deschide fișierul de răspuns de la ANAF și confirmă exact codul de eroare BR-CO-26, separat de orice alt cod prezent în același răspuns (de exemplu BR-CO-10).
- Localizează în XML blocul
cac:AccountingSupplierParty— nucac:AccountingCustomerParty, care corespunde cumpărătorului — și verifică ce elemente conține efectiv. - Verifică dacă există
cac:PartyLegalEntity/cbc:CompanyIDcu CUI-ul vânzătorului, scris cu prefixul de țară („RO" pentru România, urmat de cifrele CUI-ului, fără spații). - Dacă lipsește, adaugă elementul în codul care generează XML-ul, populat din același câmp din baza de date pe care softul îl folosește deja pentru afișarea CUI-ului pe facturile clasice.
- Verifică în paralel
cac:PartyTaxScheme/cbc:CompanyID(codul de TVA, pentru firmele plătitoare) — completarea și a acestui element reduce riscul altor erori conexe de validare a datelor fiscale ale vânzătorului. - Regenerează XML-ul și retrimite factura ca document nou în SPV — o factură respinsă la validarea BR-CO-26 nu a primit index de încărcare, deci nu necesită stornare.
Riscuri și greșeli frecvente la corectarea celor două erori
Cea mai frecventă greșeală, când ambele coduri apar în același răspuns, este corectarea unei singure erori și retransmiterea facturii fără să verifici dacă cealaltă regulă mai este încă încălcată — ceea ce duce la o a doua respingere, cu întârziere suplimentară. Verifică întotdeauna lista completă de coduri din fișierul de răspuns înainte de retrimitere, nu doar primul cod afișat.
O a doua greșeală tipică este să corectezi manual un singur XML respins, direct în fișier, fără să modifici și codul sursă care generează facturile viitoare — problema revine la următoarea factură emisă către alt client sau cu altă structură de linii.
A treia situație de risc apare la integrările care folosesc același șablon XML pentru mai multe firme (de exemplu, un soft multi-tenant sau o platformă folosită de mai mulți clienți): dacă identificatorul vânzătorului este populat static, în loc să fie preluat dinamic din datele fiecărei firme, eroarea BR-CO-26 poate apărea doar pentru unele firme din platformă, nu pentru toate — ceea ce face problema mai greu de reprodus și de depanat.
Plan practic: checklist de verificare pentru ambele erori
Înainte de a retrimite o factură respinsă cu BR-CO-10, BR-CO-26 sau ambele, parcurge lista de mai jos:
- Ai citit toate codurile de eroare din fișierul de răspuns, nu doar primul afișat?
- Pentru BR-CO-10: suma valorilor
LineExtensionAmountde pe toate liniile este egală, la bănuț, cu totalul dincac:LegalMonetaryTotal? - Pentru BR-CO-26: blocul
cac:AccountingSupplierPartyconține uncbc:CompanyIDvalid, cu prefixul de țară „RO"? - Ai verificat că datele vânzătorului nu au fost plasate din greșeală sub
cac:AccountingCustomerParty? - Dacă platforma ta emite facturi pentru mai multe firme, identificatorul vânzătorului este preluat dinamic din datele firmei curente, nu dintr-o valoare fixă?
- Ai regenerat și retrimis XML-ul ca document nou, nu ca modificare a facturii respinse?
Surse
- ANAF - pagina dedicată Spațiului Privat Virtual (SPV) și RO e-Factura: anaf.ro - SPV
- ANAF - documentația tehnică RO e-Factura: anaf.ro - spv-efactura
- Ministerul Finanțelor - pagina tehnică e-Factura: mfinante.gov.ro - informații tehnice e-Factura
- Comisia Europeană - implementarea de referință a standardului EN 16931, care stă la baza regulilor de validare RO_CIUS (inclusiv BR-CO-10 și BR-CO-26): eInvoicing-EN16931 - reguli de validare oficiale
Data ultimei verificări a surselor: 19.07.2026. Acest material este informativ și tehnic; nu înlocuiește verificarea formatului XML cu un validator RO_CIUS actualizat înainte de transmiterea în producție. Regulile de validare se pot completa sau modifica prin actualizări tehnice ulterioare ale ANAF — confirmă întotdeauna versiunea curentă a specificației pe anaf.ro.
FAQ - Întrebări frecvente despre erorile BR-CO-10 și BR-CO-26
1. Pot apărea BR-CO-10 și BR-CO-26 în același fișier de răspuns de la ANAF?
Da. Cele două reguli verifică zone diferite ale facturii, iar un XML generat dintr-o integrare incompletă poate încălca simultan ambele reguli — de exemplu, totaluri greșite pe linii și, separat, lipsa identificatorului vânzătorului. Citește lista completă de coduri din răspuns înainte de a retrimite factura.
2. Care este diferența principală dintre cele două erori?
BR-CO-10 verifică dacă suma valorilor de pe liniile facturii se potrivește cu totalul declarat la nivel de document. BR-CO-26 verifică dacă factura conține cel puțin un identificator valid al vânzătorului (CUI, cod de TVA sau echivalent), indiferent de valorile numerice ale facturii.
3. Ce fac dacă am completat CUI-ul, dar tot primesc eroarea BR-CO-26?
Verifică în ce element XML exact a ajuns CUI-ul. Regula caută specific cac:PartyLegalEntity/cbc:CompanyID, cac:PartyTaxScheme/cbc:CompanyID, cac:PartyIdentification/cbc:ID sau adresa electronică (EndpointID) din blocul vânzătorului. Dacă CUI-ul apare doar în denumirea sau adresa firmei, ca text simplu, regula nu îl recunoaște ca identificator valid.
4. Trebuie completate toate cele patru câmpuri (BT-29, BT-30, BT-31, BT-34) pentru a evita BR-CO-26?
Nu, regula cere ca cel puțin unul dintre cele patru să fie prezent. În practică, pentru firmele românești, cel mai sigur este să completezi întotdeauna PartyLegalEntity/CompanyID cu CUI-ul cu prefix „RO", și suplimentar PartyTaxScheme/CompanyID dacă firma este plătitoare de TVA.
5. O factură respinsă cu aceste erori necesită stornare?
Nu. O factură respinsă la validarea XML, indiferent dacă din cauza BR-CO-10, BR-CO-26 sau a altui cod, nu primește niciodată index de încărcare în SPV și nu este considerată transmisă. Corectezi XML-ul și retrimiți factura ca document nou, cu aceleași date.
Concluzie
BR-CO-10 și BR-CO-26 sunt două erori de validare distincte în e-Factura, care se rezolvă în zone diferite ale XML-ului: BR-CO-10 la nivelul liniilor și totalului facturii, BR-CO-26 la nivelul identificării vânzătorului. Când apar împreună, corectează-le separat și verifică ambele înainte de retrimitere — o factură care mai încalcă măcar o regulă este respinsă din nou, indiferent câte alte corecții ai făcut.
Te confrunți cu erori de validare la integrarea proprie cu RO e-Factura? Lucrăm soluții software compatibile cu SPV și e-Factura, cu generare corectă a XML-ului direct din sistemul tău de facturare sau ERP. Contactează-ne sau vezi serviciile noastre de dezvoltare software custom. Pentru detalii tehnice suplimentare despre BR-CO-10, cu exemplu complet de cod XML, citește ghidul dedicat erorii BR-CO-10.
Imagine generată cu AI, folosită în scop ilustrativ.
Write a comment