BR-KSA-51Line amount with VAT is missing from an invoice line on this simplified invoice
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-KSA-51.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-51]-The line amount with VAT (KSA-12) must be Invoice line net amount (BT-131) + Line VAT amount (KSA-11).
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.
Line amount with VAT is missing from an invoice line on this simplified invoice
Reported asline_amount_with_vat_missingthe line amount with VAT is missing
What is wrong
A cac:TaxTotal inside a cac:InvoiceLine carries no cbc:RoundingAmount, which is the element the line amount with VAT (KSA-12) is written in. ZATCA's rule BR-KSA-51 requires that value to equal the line net amount (BT-131) plus the line VAT amount (KSA-11); with nothing written there the comparison is made against an absent value, which is false, and the rule fails. Two things about it are worth knowing. It is the only rule in this pack that requires the line amount with VAT to exist at all - the assertion that asks for KSA-12 by name cannot be reached on any document - so this is where a missing line total is actually caught. And the element is optional in the UBL schema, so a system that never writes it produces a well-formed document that fails here on every simplified invoice it issues. The rule is gated to simplified invoices: a standard invoice is never judged by it, so silence on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
The element name is the usual trap: cbc:RoundingAmount at line level carries the line amount with VAT, not a rounding correction, so an export that writes it only when there is something to round leaves it off every ordinary line. Write it on every line of a simplified invoice, as that line's net amount plus that line's VAT amount. Check the line-level tax total in your export template rather than the document totals - the document's own rounding amount is a different element in a different block, and filling it in does nothing here.
Line net amount is missing where the line amount with VAT is checked
Reported asline_net_missingthe line net amount is missing
What is wrong
An invoice line carries no cbc:LineExtensionAmount. ZATCA's rule BR-KSA-51 requires the line amount with VAT (KSA-12) to equal the line net amount (BT-131) plus the line VAT amount (KSA-11), so with the net amount absent there is nothing to add, the comparison against an absent value is false, and the rule fails. The element is required by the UBL schema, so the schema check normally reports the same line. The net amount is read from the line itself while the other two values are read from the tax total inside it, which is why a line can fail this rule while its tax total looks complete. The rule is gated to simplified invoices: a standard invoice is never judged by it, so silence on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
Check that the invoice line template writes cbc:LineExtensionAmount on every line, including zero-value and free-of-charge lines, where some templates suppress an element whose value is nought. Expect a second note about the same line: the rule that multiplies the net amount by the rate reads the same element and fails for the same reason, so the two are one defect and not two. The line total in the document totals block is a different field and filling it in does not write the line's own.
Line VAT amount is missing where the line amount with VAT is checked
Reported asline_vat_amount_missingthe line VAT amount is missing
What is wrong
A cac:TaxTotal inside a cac:InvoiceLine carries a cbc:RoundingAmount but no cbc:TaxAmount. ZATCA's rule BR-KSA-51 adds the line VAT amount (KSA-11) to the line net amount (BT-131) and requires the sum to equal the line amount with VAT (KSA-12), so with the VAT amount absent there is nothing to add and the rule fails. The element is required by the UBL schema, so a document in this state is normally reported here and by the schema check together. Both values are read from the same tax total, so on a line carrying more than one of them each tax total is judged on its own. The rule is gated to simplified invoices: a standard invoice is never judged by it, so silence on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
A line tax total that carries the total but not the tax is normally an export template writing the two values from different sources - the total from the priced line, the tax from a tax engine result that was empty. Confirm that cbc:TaxAmount is written on every line, at 0.00 on zero-rated, exempt and out-of-scope lines rather than left out. Expect the rule that multiplies the net amount by the rate to report the same line, since it reads the same element.
Line amount with VAT is not the line net amount plus the line VAT amount
Reported asnot_net_plus_vatnot the net amount plus the VAT amount
What is wrong
The line amount with VAT (KSA-12), written in cbc:RoundingAmount inside the line's cac:TaxTotal, does not equal the line net amount (BT-131) plus the line VAT amount (KSA-11). ZATCA's rule BR-KSA-51 requires that identity on a simplified invoice with no tolerance at all, and SDK 3.4.8 flags a mismatch as a warning, which does not by itself reject the document. One thing has to be said plainly, because it decides what you can usefully do next: the comparison ZATCA runs is not a decimal one. The expression carries no decimal conversion, so both sides are turned into binary floating-point numbers before they are compared, and a line whose arithmetic is exactly right to the halalah can still be flagged. Measured on ZATCA's own tool: a line net of 100.00 at a rate of 8.04, a VAT amount of 8.04 and a line amount with VAT of 108.04 - correct in decimal to the last halalah - is flagged, because added as binary numbers those two values come to 108.03999999999999. On that line net, roughly one two-decimal rate in eight behaves this way. Recomputing the sum more precisely does not clear it, because the value the comparison wants is not a two-decimal amount at all. This is a defect in how the rule is written rather than anything wrong with your invoice, and the only thing that clears it is a different line net amount or a different rate. The rule is gated to simplified invoices: a standard invoice is never judged by it, so silence on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
Check the ordinary causes first, because they are commoner than the one above. The net amount is read from the line and the VAT amount from the tax total inside it, so a line carrying two tax totals can pair a total with the wrong tax; a line-level discount applied after the total was computed leaves the two out of step; and a system that writes the line amount with VAT from its own stored value rather than adding the two elements it has just written will drift by a halalah on lines that were rounded separately. If your figures do agree to the halalah, you are in the case described above: no setting in your system clears it, and the only route is different priced amounts on the line.
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.
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-78-simplified-line-total.xml
Mutabiq's verdict
Passed
Reported as
not_net_plus_vatnot the net amount plus the VAT amount