Erori e-FacturaBR-DEC-09

Prea multe zecimale la suma liniilor facturii (BT-106)

Codul regulii este BR-DEC-09.

Mesajul exact din validatorul ANAF

textEroare=[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
textEroare=[BR-CO-13]-Invoice total amount without VAT (BT-109) = Σ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108).
textEroare=[BR-DEC-09]-The allowed maximum number of decimals for the Sum of Invoice line net amount (BT-106) is 2.
textEroare=[UBL-DT-01]-Amounts shall be decimal up to two fraction digits
textEroare= [BR-RO-Z2]-Numarul maxim permis de zecimale pentru Suma valorilor nete ale liniilor facturii (BT-106) este 2. #The allowed maximum number of decimals for the Sum of Invoice line net amount (BT-106) is 2.

Ce inseamna

EN 16931 limitează numărul de zecimale al sumelor din factură la numărul de zecimale al monedei facturii; pentru RON sunt 2. Regula se aplică pe totalul BG-22 (BT-106), deci nu ajunge să rotunjești liniile: dacă totalul iese cu 3 sau 4 zecimale din însumare ori din conversie valutară, factura este respinsă. În exemplul de referință suma este deja rotundă (10 x 100,00 = 1.000,00), deci regula e respectată.

Cum repari

Rotunjește la 2 zecimale valoarea pe care o scrii în LineExtensionAmount din LegalMonetaryTotal, imediat înainte de generarea XML-ului, după ce ai însumat liniile. Dacă lucrezi cu prețuri unitare cu multe zecimale sau cu conversii valutare, aplică rotunjirea atât pe linie (BT-131), cât și pe total, ca să nu apară diferențe.

Exemplu

Asa pica

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
             xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="RON">1000.001</cbc:LineExtensionAmount>
  </cac:LegalMonetaryTotal>
</ubl:Invoice>

Asa trece

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
             xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="RON">1000.00</cbc:LineExtensionAmount>
  </cac:LegalMonetaryTotal>
</ubl:Invoice>

Greseala asta strica si alte verificari, deci in acelasi raspuns vei gasi si: BR-CO-10, BR-CO-13, BR-DEC-RO-09, UBL-DT-01. Le repari pe toate odata cu asta.

Verificat. Am pus fiecare din cele doua fragmente intr-o factura completa si le-am trecut prin validatorul oficial ANAF, versiunea ro16931-ubl-1.0.9. Factura cu fragmentul din stanga a fost respinsa cu exact mesajul de mai sus; cea cu fragmentul din dreapta a trecut fara nicio eroare. Verificarea s-a facut pe 14.09.2026.
Regula asa cum e scrisa in schematronul oficial

Textul oficial, in engleza

The allowed maximum number of decimals for the Sum of Invoice line net amount (BT-106) is 2.

Unde se aplica

$Document_totals

Conditia care trebuie sa fie adevarata

$BR-DEC-09
Ce nu rezulta din textul oficial al regulii

Nu am putut confirma din datele primite cum se produce practic valoarea cu 3 zecimale (împărțire, conversie valutară sau preț unitar cu multe zecimale) și nici dacă validatorul aplică numărul de zecimale în funcție de monedă sau îl fixează la 2. De asemenea, modificarea doar a lui BT-106, fără ajustarea celorlalte totaluri, poate declanșa în validator și erori de coerență între totaluri, nu doar BR-DEC-09.