BR-CO-14Document VAT total is missing from a tax total block
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-14.
What kind of value was found — empty, not_15_digits and the like — never the value itself.
Document VAT total is missing from a tax total block
Reported astotal_missingthe total is missing
What is wrong
A cac:TaxTotal block at the root of the document carries VAT breakdown entries (cac:TaxSubtotal) but no cbc:TaxAmount of its own, so the document states no invoice total VAT amount (BT-110) for those entries to add up to. EN 16931 rule BR-CO-14, which ZATCA runs before its own Saudi checks, requires that total to equal the sum of the VAT category tax amounts (BT-117); with no total written there is nothing for the sum to equal and the rule fails.
What to check in your ERP
A ZATCA invoice normally carries two cac:TaxTotal blocks at document level - one holding the VAT breakdown, one holding the total on its own - and the one with the breakdown must also carry its own cbc:TaxAmount. Check the export template in your e-invoicing module: this is usually a mapping that writes the breakdown loop and omits the header amount above it, not a missing figure in the ledger. The element is required by the UBL schema as well, so a document in this state is normally reported here and by the schema check together.
Document VAT total does not equal the sum of the VAT breakdown
Reported asnot_sum_of_subtotalsnot the sum of the VAT breakdown
What is wrong
The invoice total VAT amount (BT-110) written in a root cac:TaxTotal does not equal the sum of the VAT category tax amounts (BT-117) in that block's cac:TaxSubtotal entries. EN 16931 rule BR-CO-14, which ZATCA runs, compares them exactly: the breakdown amounts are added, that sum is rounded to two decimals, and the result must equal the declared total to the last hundredth. There is no tolerance - one halalah of difference is a rejection. The comparison is per tax total block, and it is the document-level blocks that are tested, not the ones on invoice lines.
What to check in your ERP
The two figures come from different places in most systems: the breakdown is computed per VAT category and the header total is often carried from the order or the ledger, so they drift when one is rounded and the other is not. Check where each is rounded. ZATCA adds the category amounts first and rounds the sum once, so a system that rounds each category to two decimals and then adds them can differ by a hundredth or two on an invoice with several categories. Fix the rounding point in the mapping, not by adjusting one of the figures to match the other - either side may be the wrong one.
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(child::cbc:TaxAmount)= round((sum(cac:TaxSubtotal/xs:decimal(cbc:TaxAmount)) * 10 * 10)) div 100) or not(cac:TaxSubtotal))
Reported test
(xs:decimal(child::cbc:TaxAmount)= round((sum(cac:TaxSubtotal/xs:decimal(cbc:TaxAmount)) * 10 * 10)) div 100) or not(cac:TaxSubtotal)
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.