BR-CO-16Payable amount 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-16.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-CO-16]-Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Pre-Paid amount (BT-113) + Rounding amount (BT-114).
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.
Payable amount is missing from the document totals
Reported astotal_missingthe total is missing
What is wrong
The document carries a prepaid amount but cac:LegalMonetaryTotal has no cbc:PayableAmount, or no cbc:TaxInclusiveAmount to compute it from. EN 16931 rule BR-CO-16, which ZATCA runs, requires the payable amount to equal the total including VAT less the amount already paid, and it cannot be satisfied when one side is absent. This rule is only checked on a document that states a prepaid amount at all.
What to check in your ERP
Check the export template in your e-invoicing module: the totals block must carry cbc:PayableAmount, which is the figure the customer actually owes. Both elements are required by the UBL schema as well, so a document in this state is usually reported here and by the schema check together.
Payable amount does not equal the total including VAT less the prepaid amount
Reported asnot_inclusive_less_prepaidnot the total with VAT less the prepaid amount
What is wrong
The cbc:PayableAmount in cac:LegalMonetaryTotal is not the cbc:TaxInclusiveAmount less the cbc:PrepaidAmount. EN 16931 rule BR-CO-16, which ZATCA runs, requires that exactly, rounded to two decimals. Where the document also carries a cbc:PayableRoundingAmount, that amount is allowed to account for the difference. This rule only runs on a document that states a prepaid amount, so it will not appear on an invoice with nothing paid in advance.
What to check in your ERP
Check what is in cbc:PrepaidAmount: it is the amount already received against this invoice, and a deposit, an advance payment or a credit applied at billing all belong there. The commonest cause is the payable amount being carried straight from the total including VAT while the prepayment is recorded only in the ledger, so the two never meet in the export. If your system rounds the payable figure to a whole riyal for cash settlement, that difference belongs in cbc:PayableRoundingAmount rather than being absorbed silently.
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(( not(exists(cbc:PayableRoundingAmount)) and (xs:decimal(cbc:PayableAmount) = (round((xs:decimal(cbc:TaxInclusiveAmount) - xs:decimal(cbc:PrepaidAmount)) * 10 * 10) div 100))) or (not(exists(cbc:PrepaidAmount)) and not(exists(cbc:PayableRoundingAmount)) and xs:decimal(cbc:PayableAmount) = xs:decimal(cbc:TaxInclusiveAmount)) or (exists(cbc:PrepaidAmount) and exists(cbc:PayableRoundingAmount) and ((round((xs:decimal(cbc:PayableAmount) - xs:decimal(cbc:PayableRoundingAmount)) * 10 * 10) div 100) = (round((xs:decimal(cbc:TaxInclusiveAmount) - xs:decimal(cbc:PrepaidAmount)) * 10 * 10) div 100))) or (not(exists(cbc:PrepaidAmount)) and exists(cbc:PayableRoundingAmount) and ((round((xs:decimal(cbc:PayableAmount) - xs:decimal(cbc:PayableRoundingAmount)) * 10 * 10) div 100) = xs:decimal(cbc:TaxInclusiveAmount))))
Reported test
(exists(cbc:PrepaidAmount) and not(exists(cbc:PayableRoundingAmount)) and (xs:decimal(cbc:PayableAmount) = (round((xs:decimal(cbc:TaxInclusiveAmount) - xs:decimal(cbc:PrepaidAmount)) * 10 * 10) div 100))) or (not(exists(cbc:PrepaidAmount)) and not(exists(cbc:PayableRoundingAmount)) and xs:decimal(cbc:PayableAmount) = xs:decimal(cbc:TaxInclusiveAmount)) or (exists(cbc:PrepaidAmount) and exists(cbc:PayableRoundingAmount) and ((round((xs:decimal(cbc:PayableAmount) - xs:decimal(cbc:PayableRoundingAmount)) * 10 * 10) div 100) = (round((xs:decimal(cbc:TaxInclusiveAmount) - xs:decimal(cbc:PrepaidAmount)) * 10 * 10) div 100))) or (not(exists(cbc:PrepaidAmount)) and exists(cbc:PayableRoundingAmount) and ((round((xs:decimal(cbc:PayableAmount) - xs:decimal(cbc:PayableRoundingAmount)) * 10 * 10) div 100) = xs:decimal(cbc:TaxInclusiveAmount)))
Evaluated against
cac:LegalMonetaryTotal
Source
vendor/zatca/schematron/CEN-EN16931-UBL.xsl:490
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.
Document
bad-33-payable-amount-mismatch.xml
Mutabiq's verdict
Passed
Reported as
not_inclusive_less_prepaidnot the total with VAT less the prepaid amount