Eroare BR-CO-10 e-Factura: cauze și rezolvare

Trimiți o factură către SPV, aștepți indexul de încărcare și, în loc de confirmare, primești un fișier de răspuns cu un mesaj tehnic, în engleză, care nu spune nimic clar la prima citire: „[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)." Tradus simplu, ANAF îți spune că suma valorilor nete de pe liniile facturii nu coincide cu totalul net calculat la nivel de document — iar factura este respinsă înainte să apuce să fie validată.

Eroarea BR-CO-10 este una dintre cele mai frecvente respingeri la validarea XML în RO e-Factura, mai ales pentru firmele care își generează singure fișierul, prin soft propriu sau integrare API. Acest ghid explică exact ce înseamnă regula din spatele codului, care este cauza tehnică reală întâlnită cel mai des în XML — inversarea câmpurilor LineExtensionAmount și PriceAmount — și cum o corectezi pas cu pas, cu exemplu concret de cod.

Materialul este util dezvoltatorilor care integrează RO e-Factura în aplicații sau ERP-uri proprii, precum și contabililor și administratorilor de firmă care primesc acest mesaj de la softul de facturare și vor să înțeleagă ce anume trebuie corectat.

Ce este eroarea BR-CO-10 și ce mesaj exact returnează ANAF

BR-CO-10 este o regulă de validare din specificația tehnică RO_CIUS, varianta românească a standardului european EN 16931 pentru facturarea electronică, pe care se bazează validatorul ANAF din Spațiul Privat Virtual (SPV). Regula verifică o singură condiție matematică simplă: totalul net al facturii, calculat la nivel de document (BT-106), trebuie să fie identic cu suma valorilor nete individuale ale fiecărei linii de factură (BT-131).

În XML, BT-106 corespunde elementului cac:LegalMonetaryTotal/cbc:LineExtensionAmount, iar BT-131 corespunde elementului cac:InvoiceLine/cbc:LineExtensionAmount, repetat pentru fiecare linie de factură. Dacă suma celor din urmă nu se potrivește exact cu valoarea din primul, ANAF respinge factura înainte de validare, iar fișierul de răspuns conține exact mesajul de eroare citat mai sus, identificat prin codul BR-CO-10.

O propoziție utilă de reținut: eroarea BR-CO-10 nu este un avertisment, ci o respingere fermă — factura nu primește index de încărcare și nu este considerată transmisă, până nu este corectată și retrimisă.

De ce apare eroarea BR-CO-10: regula de validare din spatele mesajului

Practic, există două categorii mari de cauze pentru această eroare. Prima este o nepotrivire de rotunjire: la facturi cu multe linii sau cu valori în valută, rotunjirea individuală a fiecărei linii și calculul separat al totalului pot produce diferențe de ordinul bănuților, suficiente cât să încalce regula de egalitate exactă cerută de BR-CO-10.

A doua categorie, mai frecventă la integrările proprii generate prin cod, este o eroare de mapare a câmpurilor în structura XML: valoarea pusă în LineExtensionAmount nu este, de fapt, subtotalul liniei (cantitate × preț unitar), ci altă valoare — de exemplu, prețul unitar al produsului. Această a doua cauză este exact situația documentată mai jos, întâlnită direct într-o integrare reală de facturare.

Cauza tehnică reală: câmpurile LineExtensionAmount și PriceAmount inversate

Într-o implementare proprie de generare a XML-ului pentru e-Factura, scrisă în PHP, fiecare linie de factură era construită corect din punct de vedere al structurii XML, dar cu două valori inversate între ele. Tabelul de mai jos arată exact diferența dintre varianta greșită și cea corectă.

Element XML	Ce trebuie să conțină	Greșit (cauza erorii)	Corect
`cbc:LineExtensionAmount` (BT-131)	Subtotalul liniei: cantitate × preț unitar	Prețul unitar al produsului	Subtotalul liniei (`$item->subtotal`)
`cbc:PriceAmount` din `cac:Price`	Prețul unitar net al produsului	Subtotalul liniei	Prețul unitar (`$item->price`)
`cbc:BaseQuantity` din `cac:Price`	Cantitatea de referință pentru preț, obligatorie	Lipsea complet din linie	`1.00`, cu `unitCode="H87"`

Practic, codul greșit punea prețul unitar acolo unde trebuia subtotalul liniei și subtotalul acolo unde trebuia prețul unitar — iar suma valorilor din LineExtensionAmount ale tuturor liniilor (BT-131) nu mai corespundea cu totalul real al facturii, calculat corect în altă parte a documentului (BT-106). De aici, exact regula BR-CO-10 încălcată.

Mai jos este structura greșită a unei linii de factură, generată dintr-un buclu PHP:

$xml .= '<cac:InvoiceLine> <cbc:ID>'.$c.'</cbc:ID> <cbc:InvoicedQuantity unitCode="H87">'.$item->qty.'</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="RON">'.$item->price.'</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>'.$item->title.'</cbc:Name> <cac:ClassifiedTaxCategory> <cbc:ID>O</cbc:ID> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:ClassifiedTaxCategory> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="RON">'.$item->subtotal.'</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>';

Și structura corectă, după inversarea celor două valori și adăugarea BaseQuantity:

$xml .= '<cac:InvoiceLine> <cbc:ID>'.$c.'</cbc:ID> <cbc:InvoicedQuantity unitCode="H87">'.$item->qty.'</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="RON">'.$item->subtotal.'</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>'.$item->title.'</cbc:Name> <cac:ClassifiedTaxCategory> <cbc:ID>O</cbc:ID> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:ClassifiedTaxCategory> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="RON">'.$item->price.'</cbc:PriceAmount> <cbc:BaseQuantity unitCode="H87">1.00</cbc:BaseQuantity> </cac:Price> </cac:InvoiceLine>';

Cum rezolvi eroarea BR-CO-10 pas cu pas

Deschide fișierul de răspuns primit de la ANAF (descărcabil din SPV, la factura respinsă) și citește exact codurile de eroare returnate — pot apărea mai multe reguli încălcate simultan, nu doar BR-CO-10.
Localizează în codul tău sursă bucla care generează elementele cac:InvoiceLine și verifică, linie cu linie, ce valoare este atribuită efectiv lui LineExtensionAmount și lui PriceAmount.
Confirmă semnificația fiecărui câmp: LineExtensionAmount este întotdeauna subtotalul liniei (cantitate × preț unitar, fără TVA), iar PriceAmount este prețul unitar net al produsului sau serviciului.
Adaugă BaseQuantity în cac:Price, cu valoarea 1.00 și unitCode identic cu cel din InvoicedQuantity, dacă lipsește din XML-ul generat.
Regenerează fișierul XML pentru factura respinsă și validează-l, dacă ai acces, cu un instrument de validare RO_CIUS înainte de retrimitere, ca să confirmi că eroarea nu mai apare.
Retrimite factura corectată în SPV ca document nou — o factură respinsă la validare nu a primit niciodată index de încărcare, deci nu necesită stornare, ci doar retransmitere.

De ce apare mai des la vânzătorii neplătitori de TVA

În exemplul real de mai sus, eroarea a apărut la facturi emise de un vânzător neplătitor de TVA, cu categoria de TVA marcată în XML prin codul cac:ClassifiedTaxCategory/cbc:ID = O („Not subject to VAT"). Pentru acest tip de contribuabil, fișierul de răspuns de la ANAF a conținut, în paralel cu BR-CO-10, și regula BR-O-08, care verifică suma valorilor din categoria de TVA „neimpozabil" la nivel de document.

Combinația celor două reguli apare frecvent la neplătitorii de TVA pentru că structura facturii lor are mai puține elemente de validare încrucișată pentru TVA — practic, orice diferență la nivel de valoare netă a liniei „trece" direct în calculul total, fără un al doilea nivel de verificare prin cote de TVA distincte, așa cum se întâmplă la facturile cu TVA calculat normal.

Dacă firma ta este plătitoare de TVA și primești totuși BR-CO-10, cauza cea mai probabilă rămâne tot inversarea de câmpuri sau rotunjirea, nu codul de categorie TVA în sine — verifică întâi LineExtensionAmount și PriceAmount, indiferent de regimul de TVA al firmei.

Alte cauze posibile ale erorii BR-CO-10 și cum le previi

Pe lângă inversarea de câmpuri, există și alte situații, mai puțin legate de o greșeală de cod, care pot declanșa aceeași regulă de validare:

Rotunjire inconsistentă. Dacă softul rotunjește fiecare linie la 2 zecimale, dar calculează totalul facturii dintr-o sumă nerotunjită (sau invers), diferența de câțiva bani poate declanșa BR-CO-10. Soluția: rotunjește fiecare linie la 2 zecimale, apoi adună valorile deja rotunjite pentru a obține totalul.
Discounturi sau taxe la nivel de linie, omise din calcul. Dacă o linie are reducere sau cost suplimentar, LineExtensionAmount trebuie să reflecte subtotalul net rezultat după aplicarea acestora, nu prețul de listă înmulțit simplu cu cantitatea.
Editare manuală a totalului din factură, după ce softul a generat deja liniile. Orice ajustare manuală a totalului, fără recalcularea liniilor, rupe egalitatea cerută de BR-CO-10.
Generare XML din mai multe surse de date (de exemplu, linii calculate dintr-un modul de comenzi și total calculat separat, dintr-un modul de facturare), care pot ajunge să nu mai fie sincronizate la momentul exportului.

O regulă practică simplă pentru orice integrare proprie: totalul facturii trebuie să rezulte întotdeauna din suma liniilor, niciodată invers. Dacă totalul este calculat separat de linii, riști exact tipul de eroare descris în acest articol.

Plan practic: checklist înainte de retrimiterea facturii în SPV

Înainte să retrimiți o factură respinsă cu eroarea BR-CO-10, parcurge rapid această listă de verificare:

Ai verificat că LineExtensionAmount conține subtotalul liniei (cantitate × preț unitar), nu prețul unitar?
Ai verificat că PriceAmount din cac:Price conține prețul unitar net, nu subtotalul?
Are fiecare linie elementul BaseQuantity, cu valoarea 1.00 și unitCode identic cu cel din InvoicedQuantity?
Suma valorilor LineExtensionAmount de pe toate liniile este egală, la bănuț, cu valoarea din cac:LegalMonetaryTotal/cbc:LineExtensionAmount?
Ai aplicat aceeași regulă de rotunjire (2 zecimale) atât la nivel de linie, cât și la nivel de total?
Dacă apar și alte coduri de eroare în fișierul de răspuns (de exemplu BR-O-08), le-ai citit pe toate, nu doar pe primul din listă?

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): eInvoicing-EN16931 - reguli de validare oficiale

Data ultimei verificări a surselor: 30.06.2026. Acest material este informativ și tehnic, bazat pe un caz real de integrare; 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 eroarea BR-CO-10

1. Ce înseamnă mai exact eroarea BR-CO-10 în e-Factura?

Înseamnă că suma valorilor nete declarate pe liniile facturii (BT-131) nu este egală cu totalul net al facturii, calculat la nivel de document (BT-106). Este o regulă de consistență matematică din specificația RO_CIUS, aplicată automat de validatorul ANAF la încărcarea facturii în SPV.

2. De ce apare eroarea BR-CO-10 mai ales la facturile emise de vânzători neplătitori de TVA?

Pentru neplătitorii de TVA, factura folosește categoria „Not subject to VAT" (cod O), care are mai puține verificări încrucișate legate de TVA. Orice diferență de valoare la nivel de linie ajunge direct să afecteze egalitatea cerută de BR-CO-10, fără un al doilea nivel de validare prin cote de TVA distincte, ca la facturile cu TVA normal.

3. Ce este BaseQuantity și de ce lipsa lui poate cauza erori de validare?

BaseQuantity este cantitatea de referință pentru prețul unitar declarat în PriceAmount și este, de regulă, obligatorie cu valoarea 1.00. Lipsa ei nu generează mereu, de una singură, eroarea BR-CO-10, dar este frecvent omisă în aceleași integrări unde apare și inversarea de câmpuri descrisă în acest articol, motiv pentru care merită verificată în paralel.

4. Eroarea BR-CO-10 poate apărea și fără nicio greșeală de cod, doar din rotunjire?

Da. La facturi cu multe linii sau cu calcule în valută, o diferență de rotunjire de câțiva bani între suma liniilor și totalul facturii este suficientă pentru a încălca regula. Soluția standard este să rotunjești fiecare linie la 2 zecimale înainte de a aduna valorile pentru total, nu să rotunjești doar rezultatul final.

5. Ce faci dacă ai trimis deja o factură greșită din cauza acestei erori?

O factură respinsă cu BR-CO-10 nu primește niciodată index de încărcare în SPV, deci nu este considerată transmisă și validată. Nu este nevoie de stornare sau factură de corecție — corectezi XML-ul, regenerezi fișierul și retrimiți factura ca document nou, cu aceleași date.

Concluzie

Eroarea BR-CO-10 în e-Factura indică, aproape întotdeauna, fie o diferență de rotunjire între suma liniilor și totalul facturii, fie o eroare de mapare a câmpurilor din XML — cel mai frecvent, inversarea dintre LineExtensionAmount (subtotalul liniei) și PriceAmount (prețul unitar). Verificarea acestor două câmpuri, plus prezența elementului BaseQuantity, rezolvă majoritatea cazurilor, fără să fie nevoie de stornare, pentru că o factură respinsă la validare nu ajunge niciodată un document fiscal definitiv.

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. Scrie-ne sau vezi serviciile noastre de dezvoltare software custom. Dacă te confrunți și cu alte erori tehnice la transmitere, citește și articolul despre eroarea 401 la trimiterea facturii, iar pentru context despre obligativitatea transmiterii corecte în relațiile B2B, vezi articolul despre transmiterea exclusivă prin SPV.

Imagine generată cu AI, folosită în scop ilustrativ.

Eroarea BR-CO-10 la validarea facturii e-Factura: cauze și pași de remediere