Erori e-Factura

EN16931

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 înseamnă

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

Așa pică

<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>

Așa 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>

Greșeala asta strică și alte verificări, deci în același răspuns vei găsi și: BR-CO-10, BR-CO-13, BR-DEC-RO-09, UBL-DT-01. Le repari pe toate odată cu asta.

Verificat. Am pus fiecare din cele două fragmente într-o factură completă și le-am trecut prin validatorul oficial ANAF, versiunea ro16931-ubl-1.0.9. Factura cu fragmentul din stânga a fost respinsă cu exact mesajul de mai sus; cea cu fragmentul din dreapta a trecut fără nicio eroare. Verificarea s-a făcut pe 14.09.2026.
Regula așa cum e scrisă în schematronul oficial

Textul oficial, în engleză

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

Unde se aplică

$Document_totals

Condiția care trebuie să fie adevărată

$BR-DEC-09
Ce nu rezultă 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.