BR-KSA-52 — Line VAT amount (KSA-11) missing

The message text as the Authority sends it in English, unedited

The line VAT amount (KSA-11) is mandatory for tax invoice and associated credit notes and debit notes (KSA-2, position 1 and 2 = 01).

What does this mean?

The place is cac:InvoiceLine/cac:TaxTotal/cbc:TaxAmount — inside the line itself, not at document level. It is not the invoice total VAT (BT-110) and not the VAT amount on each category breakdown (BT-117): three fields in three places, and having two of them does not cover the absence of the third.

The message scopes the requirement to one family — the tax invoice and its associated credit and debit notes, meaning KSA-2 with 01 in positions 1 and 2; the simplified family carries 02. The compiled schematron we read from holds no equivalent rule for the simplified family, but other rules speak about KSA-11 with no family attached: BR-KSA-51 on its arithmetic and BR-KSA-DEC-03 on its decimals. Writing it on every document is the safe practice.

This is where the commonest misreading of this code sits. A printed invoice that states the VAT once beneath the total does not mean the lines carry no VAT: the sheet and the XML are two different surfaces. What a reader sees on the printed document is a presentation choice; what gets signed carries KSA-11 on every line regardless of how the page looks. Deleting the field from the file because the column is not on the paper is exactly what produces this rejection.

Presence alone is not enough either: BR-KSA-51, a warning, requires the line amount with VAT (KSA-12) to equal the invoice line net amount (BT-131) plus this figure — so the value is read, not merely counted.

Why does it happen?

Ordered from the most common to the least — your cause is most likely the first or the second.

Hand-built XML that fills the document totals and leaves the lines with no tax block at all — by far the commonest shape of this code.
A template built on the European specification, EN 16931, where a line carries the VAT category (BT-151) and its rate (BT-152) but no amount: the line VAT amount is a Saudi addition. The template passes European validation and fails here.
A zero-rated or exempt line where the element is dropped instead of written as 0.00. Zero is a value; absence is not.
The field in the wrong place: on the item, or as a second document-level tax total, rather than inside cac:InvoiceLine.
A mapping that emits the element empty when its source value is null, so the file looks as though it carries the field while the validator finds nothing.

How to fix it

3 steps, then send the invoice again.

1

Emit the block inside every line

A cac:TaxTotal inside each cac:InvoiceLine, holding cbc:TaxAmount with the attribute currencyID="SAR". On every line without exception: standard-rated, zero-rated, exempt and out of scope — the last three carrying 0.00.
2

Compute it from the line rate, not the document rate

The line net multiplied by the rate of its own category. A mixed basket — zero-rated medicine beside standard-rated shampoo — gives one line at zero and one at 15% on the same document, and multiplying everything by a single rate passes this code and then fails on the totals. The four category letters are covered in BR-KSA-18.
3

Fix the twin in the same pass

The line amount with VAT (KSA-12) comes out of the same block and has its own code, BR-KSA-53. A file that dropped one of them usually dropped the other, so fixing both now saves you a second round of rejection. How to read the whole response is in ZATCA error codes explained.

Once corrected, send the invoice again. A rejected invoice was never recorded with the Authority, so it needs no credit note — send the corrected invoice itself.

Does ZATCA Tools prevent it?

Yes. Every line in ZATCA Tools goes through the payload builder, which writes a tax block for each line every time, with its amount computed from the line net at the rate of that line's own category. No door in the product accepts a VAT amount from outside — neither the invoice form nor the API: a line is read as its name, quantity, price and tax category, and the amount is derived here rather than at the sender. Our position on the printed document does not touch any of this: the sheet states the VAT once beneath the total, and the signed XML carries KSA-11 on every line exactly as it always did.

Related codes

BR-KSA-53 Rejects the invoice

Line amount with VAT (KSA-12) missing

BR-KSA-51

The official message text is in the Full reference.

BR-KSA-18 Rejects the invoice

Tax category code not accepted

Frequently asked questions

My printed invoice states the VAT once at the bottom. Is that why it was rejected? +

No. The Authority validates the XML, not the paper, and the two are independent surfaces: a printed document may state the VAT once beneath the total while the file carries KSA-11 on every line. The rejection means the file itself does not carry it — so look for the tax block inside the line element, not for a column in your page design.

The line is zero-rated, so its VAT is zero. Do I write the field at all? +

Yes, as 0.00. The rule requires the field to be present, not its value to be positive. What it rejects is the omission.

Does the requirement cover simplified invoices? +

The message scopes it to the family with 01 in the first two positions of KSA-2, which is the tax invoice and its notes. We see no equivalent rule for the simplified family in the extract — but what we read is the text of each rule and its severity, not the test that fires it, and other rules discuss KSA-11 with no family attached. Write it on every document, and if you want a definitive answer about simplified invoices, that is a question for zatca.gov.sa.

You fixed this one — now avoid the next

ZATCA Tools builds the signature, the PIH, the counter and the encoding for you, and validates your data before it is sent. Completely free for now, and no credit card.

Start for free

← All ZATCA error codes