BR-CO-11Allowance total is missing while the invoice carries allowances
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-11.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-CO-11]-Sum of allowances on document level (BT-107) = Σ Document level allowance amount (BT-92).
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.
Allowance total is missing while the invoice carries allowances
Reported astotal_missingthe total is missing
What is wrong
The document carries one or more document-level allowances - cac:AllowanceCharge entries whose cbc:ChargeIndicator is false - but cac:LegalMonetaryTotal has no cbc:AllowanceTotalAmount summing them. EN 16931 rule BR-CO-11, which ZATCA runs, allows the total to be absent only when there are no allowances at all; with allowances present it must be there.
What to check in your ERP
Either write the total or drop the allowances - both are valid documents, and a half-written one is not. If the discounts are real, the export must emit cbc:AllowanceTotalAmount holding their sum. This is usually a mapping that writes the allowance lines from one part of the document and the totals block from another, with nobody connecting the two.
Allowance total does not match the document allowances
Reported asnot_sum_of_allowancesnot the sum of the allowances
What is wrong
The cbc:AllowanceTotalAmount in cac:LegalMonetaryTotal is not the sum of the document-level allowances - the cac:AllowanceCharge entries whose cbc:ChargeIndicator is false. EN 16931 rule BR-CO-11, which ZATCA runs, adds those amounts, rounds the sum to two decimals, and requires an exact match. Only document-level allowances count: a discount recorded on an invoice line is deliberately outside this sum.
What to check in your ERP
The commonest cause is line-level discounts being added into the document allowance total. A discount attached to a line belongs in that line's own cac:AllowanceCharge and is already reflected in the line amount; only a discount applied to the invoice as a whole belongs here. Check as well where rounding happens - ZATCA sums first and rounds once - and that a charge has not been written with cbc:ChargeIndicator false, which would make it count as an allowance.
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:AllowanceTotalAmount) = (round(sum(../cac:AllowanceCharge[cbc:ChargeIndicator=false()]/xs:decimal(cbc:Amount)) * 10 * 10) div 100) or (not(cbc:AllowanceTotalAmount) and not(../cac:AllowanceCharge[cbc:ChargeIndicator=false()])))
Reported test
xs:decimal(cbc:AllowanceTotalAmount) = (round(sum(../cac:AllowanceCharge[cbc:ChargeIndicator=false()]/xs:decimal(cbc:Amount)) * 10 * 10) div 100) or (not(cbc:AllowanceTotalAmount) and not(../cac:AllowanceCharge[cbc:ChargeIndicator=false()]))
Evaluated against
cac:LegalMonetaryTotal
Source
vendor/zatca/schematron/CEN-EN16931-UBL.xsl:439
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.