BR-KSA-53Tax invoice line has no line amount with VAT
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-53.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-53]-The line amount with VAT (KSA-12) is mandatory for tax invoice and associated credit notes and debit notes (KSA-2, position 1 and 2 = 01).
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.
Tax invoice line has no line amount with VAT
Reported asline_amount_with_vat_missingthe line amount with VAT is missing
What is wrong
An invoice line on a tax invoice (the name attribute of cbc:InvoiceTypeCode starting 01) has no cac:TaxTotal/cbc:RoundingAmount - the line amount including VAT (KSA-12). ZATCA rejects the document under BR-KSA-53, which requires it on every line of a tax invoice and of its credit and debit notes.
What to check in your ERP
Write the line's net amount plus its VAT into cbc:RoundingAmount inside the line's cac:TaxTotal, beside cbc:TaxAmount. UBL's element name is misleading - it is not a rounding difference - and exports built to the plain EN 16931 profile often leave it out.
Tax invoice line's amount with VAT is empty
Reported asline_amount_with_vat_emptythe line amount with VAT is present but empty
What is wrong
An invoice line on a tax invoice carries cac:TaxTotal/cbc:RoundingAmount - the line amount including VAT (KSA-12) - with no value. ZATCA rejects the document under BR-KSA-53, which requires a non-empty value on every line of a tax invoice and of its credit and debit notes.
What to check in your ERP
Write the line's net amount plus its VAT into cbc:RoundingAmount. An empty element usually comes from a template that writes the tag for every line but fills it only when a value was calculated.
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(every $line in //cac:InvoiceLine satisfies exists($line/cac:TaxTotal/cbc:RoundingAmount) and ($line/cac:TaxTotal/cbc:RoundingAmount) != '')
Reported test
every $line in //cac:InvoiceLine satisfies exists($line/cac:TaxTotal/cbc:RoundingAmount) and ($line/cac:TaxTotal/cbc:RoundingAmount) != ''
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.
Where it differs from a document that passed
− This example
+ A document that passed
<cbc:IssueDate>2026-09-01</cbc:IssueDate><cbc:IssueTime>10:00:00</cbc:IssueTime>−This example: <cbc:InvoiceTypeCode name="020100000">388</cbc:InvoiceTypeCode>+A document that passed: <cbc:InvoiceTypeCode name="0200000">388</cbc:InvoiceTypeCode><cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode><cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>⋯<cac:TaxTotal> <cbc:TaxAmount currencyID="SAR">15.00</cbc:TaxAmount>+A document that passed: <cbc:RoundingAmount currencyID="SAR">116.00</cbc:RoundingAmount></cac:TaxTotal><cac:Item>