BR-CO-10Sum of line amounts is missing from the document totals
Mutabiq checks Saudi ZATCA Phase 2 e-invoice XML before you submit it: pre-validation against published ZATCA requirements, not an approval by the authority. This page explains one rule, BR-CO-10.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
What Mutabiq reports
One entry for each way this rule can be reported.
Reported as
What kind of value was found — empty, not_15_digits and the like — never the value itself.
Sum of line amounts is missing from the document totals
Reported astotal_missingthe total is missing
What is wrong
The document totals block, cac:LegalMonetaryTotal, carries no cbc:LineExtensionAmount. That field is the sum of the invoice lines' own line amounts (BT-106), and EN 16931 rule BR-CO-10, which ZATCA runs, requires it to equal that sum. With no value written there is nothing to compare and the rule fails.
What to check in your ERP
The document totals block has to carry every total the rule set expects, not only the ones your customers read. Check the export template in your e-invoicing module: this is normally a mapping that writes the payable and tax totals and omits the line total above them. The element is required by the UBL schema as well, so a document in this state is usually reported here and by the schema check together.
Sum of line amounts does not match the invoice lines
Reported asnot_sum_of_linesnot the sum of the lines
What is wrong
The cbc:LineExtensionAmount in cac:LegalMonetaryTotal is not the sum of the individual lines' cbc:LineExtensionAmount values. EN 16931 rule BR-CO-10, which ZATCA runs, adds the line amounts, rounds that sum to two decimals, and requires the total to equal it exactly. There is no tolerance. Note also that an invoice with no lines at all is compared against zero rather than being passed over, so a totals block carrying a line total on a document with no lines fails here too.
What to check in your ERP
Check where each figure is rounded. ZATCA adds the line amounts first and rounds once at the end, so a system that rounds every line to two decimals and then adds them can differ by a hundredth or two on an invoice with many lines - the more lines, the likelier it is. Check too whether a discount or charge is being applied to the header total but not to the lines it came from: this field is the lines alone, before document-level allowances and charges, which belong in cbc:AllowanceTotalAmount and cbc:ChargeTotalAmount.
The clause that runs
Quoted from the validation-rule stylesheet ZATCA publishes, at the file and line named below. The executed guard is what the check runs; the reported test is what it prints when it fails, and the two are not always the same.
Executed guard
not((xs:decimal(cbc:LineExtensionAmount) = xs:decimal(round(sum(//(cac:InvoiceLine|cac:CreditNoteLine)/xs:decimal(cbc:LineExtensionAmount)) * 10 * 10) div 100)))
Reported test
(xs:decimal(cbc:LineExtensionAmount) = xs:decimal(round(sum(//(cac:InvoiceLine|cac:CreditNoteLine)/xs:decimal(cbc:LineExtensionAmount)) * 10 * 10) div 100))
Evaluated against
cac:LegalMonetaryTotal
Source
vendor/zatca/schematron/CEN-EN16931-UBL.xsl:431
As shipped in ZATCA SDK 3.4.8: the copy quoted here is, byte for byte, the file that release ships. The date in the file name is the name ZATCA gives the file; the rules in it are those of SDK 3.4.8.
A worked example
A synthetic document from the measured test corpus that trips this rule, shown where it differs from one that passed. Mutabiq's report names the class of the value, never the value itself.