The short answer
BR-12 fails when cac:LegalMonetaryTotal has no cbc:LineExtensionAmount child. Add it as the first element of the monetary totals, holding the cbc:LineExtensionAmount of every line added together and rounded to two decimals.
The same element name appears on each line, which makes this total easy to overlook. The line amounts do not count towards it: the document-level sum has to be written as well, even when one line makes the two figures identical.
What the rule checks
The rule runs on cac:LegalMonetaryTotal and needs a cbc:LineExtensionAmount element directly inside it. Its value is not examined here; whether it equals the lines is for BR-CO-10 to decide.
An empty line total never gets this far. The schema requires every amount to be a decimal number, so when tried, an empty cbc:LineExtensionAmount in the totals failed the XSD layer and the EN 16931 layer was skipped.
Within the monetary totals the UBL schema requires only the amount due, which is why leaving out the line total passes the XSD layer. The monetary totals block itself is mandatory: when tried, a document without cac:LegalMonetaryTotal failed at the schema.
The line net amounts on cac:InvoiceLine or cac:CreditNoteLine are separate elements and do not satisfy the rule, however many there are.
| Term | Meaning | UBL element |
|---|---|---|
| BT-106 | Sum of Invoice line net amount | cac:LegalMonetaryTotal/cbc:LineExtensionAmount |
| BT-131 | Invoice line net amount | cac:InvoiceLine/cbc:LineExtensionAmount (cac:CreditNoteLine/cbc:LineExtensionAmount in a credit note) |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The totals block is built from a fixed list of fields that holds only the totals the source system stores, such as the net and gross totals, and the line total is not among them.
- The mapping treats the line total as redundant when there are no document-level allowances or charges, because it would equal the total without VAT.
- The line total is calculated after the totals block is written, so it is still null when the serialiser reaches it and gets skipped.
How to fix it
- Take the
cbc:LineExtensionAmountof every line exactly as written, and add them with decimal arithmetic, keeping the sign of negative lines. - Round the sum to two decimals and write it as
cbc:LineExtensionAmount, with the document currency incurrencyID, as the first child ofcac:LegalMonetaryTotal. When tried, the element placed aftercbc:TaxExclusiveAmountfailed the XSD layer. - Check that the total without VAT equals the new line total minus the allowance total plus the charge total, so that
BR-CO-13passes as well.
Validate your corrected invoice
Before and after
These are fragments, not complete documents. The complete synthetic documents they come from are linked below.
Fragment of the failing invoice: the monetary totals start at the total without VAT, while the line keeps its own net amount
<cac:LegalMonetaryTotal>
<cbc:TaxExclusiveAmount currencyID="GBP">25.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="GBP">30.00</cbc:TaxInclusiveAmount>
<cbc:AllowanceTotalAmount currencyID="GBP">0.00</cbc:AllowanceTotalAmount>
<cbc:ChargeTotalAmount currencyID="GBP">0.00</cbc:ChargeTotalAmount>
<!-- prepaid, rounding and payable amounts omitted from this fragment -->
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
<!-- item and price omitted from this fragment -->
</cac:InvoiceLine>Fragment of the corrected invoice: the line total of 25.00 opens the monetary totals
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="GBP">25.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="GBP">30.00</cbc:TaxInclusiveAmount>
<cbc:AllowanceTotalAmount currencyID="GBP">0.00</cbc:AllowanceTotalAmount>
<cbc:ChargeTotalAmount currencyID="GBP">0.00</cbc:ChargeTotalAmount>
<!-- prepaid, rounding and payable amounts omitted from this fragment -->
</cac:LegalMonetaryTotal>The corrected invoice has a cbc:LineExtensionAmount of 25.00 as the first child of cac:LegalMonetaryTotal; the failing one lacks it, and its single line is unchanged. Two more EN 16931 rules are reported at the same location. BR-CO-10 compares the line total with the sum of the lines, and an absent total cannot equal 25.00. BR-CO-13 works out the expected total without VAT from the line total, so with no line total it cannot confirm the 25.00 that was sent. Restoring the element clears all three.
What the validator reported
- The failing invoice reports BR-12, BR-CO-10 and BR-CO-13. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected XML
Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.
Where it applies
- Applies to UBL
InvoiceandCreditNote; the monetary totals are named the same in both. When tried, a credit note without the line total reported the same three rules. - Treat
BR-CO-10andBR-CO-13beside this rule as consequences of the one missing element, not as separate faults. When tried on the richer example with document allowances and charges, removing its line total of 66.00 reported the same three rules and nothing else. - The element on each line is a different matter. The schema requires it there, so when tried, a line without its own
cbc:LineExtensionAmountfailed the XSD layer and no business rule was reported for it.
Related rules
- BR-CO-10 checks that this line total, once present, equals the sum of the lines
- BR-CO-13 derives the total without VAT from this line total
- BR-13 is the matching presence rule for the total without VAT
- Browse every rule in the reference
- Background: Understanding EN 16931 validation errors
Scope and source
Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.
The official definition of BR-12 carries the normative wording and test. This page is our explanation of it, not a copy.
Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.
