The Document level allowance VAT rate (BT-96), Document level Charge VAT rate (BT-103), VAT category rate(BT-119), Invoiced item VAT rate (BT-152), Prepayment VAT rate(KSA-34) must be limited to one of the following values (5 or 15) when the relevant Document level allowance VAT category code (BT-95), Document level Charge VAT category code(BT-102), VAT category code(BT-118), Invoiced item VAT category code(BT-151), Prepayment VAT Category Code (KSA-33) is "S"- "Standard rated". In other words, for Standard Rate VAT Category the rate can either be 15% or 5%.
What does this mean?
The rule reads two fields together in each place: the category letter and the number beside it. The invoiced item VAT rate (BT-152) is cbc:Percent inside cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory, with its letter BT-151 in the cbc:ID next to it; the VAT category rate (BT-119) sits in cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory with its letter BT-118; the document-level allowance rate (BT-96) and charge rate (BT-103) sit in cac:AllowanceCharge/cac:TaxCategory at document level with their letters BT-95 and BT-102; and the prepayment rate (KSA-34) sits in the prepayment line's tax subtotal with its letter KSA-33. The rule speaks only when the letter is S, and then the number can only be 15 or 5.
The two values themselves: 15 is the rate in force since July 2020, and 5 is the rate before it, which the rule still accepts. Which one your supply attracts is a tax question for zatca.gov.sa, not for this page. And 15 and 15.00 are the same value; trailing zeros do no harm.
And here is the form that brings most readers to this page: 0.15. It is inside the window of BR-KSA-DEC-02 and has two decimals, so it passes that rule, and then fails here because it is neither 15 nor 5. Nor is it merely a formatting error; it is an error of meaning: the Authority reads a VAT amount as the base times the rate divided by one hundred, so a base of 100.00 at a rate of 15 carries 15.00 of VAT, and at a rate of 0.15 it carries 0.15 — which brings a second rejection from the amount-matching rules in the same response.
Zero on a standard-rated line is the second form, and it is read as a number error when it is a letter error. A line that carries no VAT has its own letter: Z for zero-rated, E for exempt and O for out of scope, each with an exemption reason written beside it. Writing S with a rate of 0 stays under this rule, and the remedy is to change the letter, not the number — the four letters are in BR-KSA-18.
It is an error: the invoice is rejected, and nothing is recorded with the Authority until it is corrected and sent again. The message names no document family, so it applies to the tax invoice, the simplified invoice and their notes alike. And the response does not say which of the five fields failed, so all five have to be checked.
Why does it happen?
Ordered from the most common to the least — your cause is most likely the first or the second.
-
The rate stored as a fraction (
0.15) and passed through to the XML unchanged. - A rate recovered by dividing the VAT amount by the base after both were rounded: 14.99 from rounded figures, or 14.999999999999998 from floating-point arithmetic — the latter fails BR-KSA-DEC-02 as well, so the two codes arrive together.
-
A line that carries no VAT written with the letter
Sand a rate of 0 instead of its proper letter and reason. -
A document-level allowance carrying category
Swith a rate other than the lines' — zero, usually — because the mapping filled the allowance category from a default rather than from the category of what was discounted. -
A free rate field in an ERP or a price list where
1.5,150or15.5was typed. - A rate multiplied by a hundred twice — once in the source system and once in the mapping — giving 1500.
How to fix it
3 steps, then send the invoice again.
-
1
Derive the number from the letter, in all five fields, from one table
A fixed table:
Sis 15 (or 5 where that applies), andZ,EandOare 0. One function, read in every place a rate is written: the line, the tax subtotal, any document-level allowance or charge, and the prepayment. Then there is no path anywhere on the route to a rate the table does not know, and BR-KSA-DEC-02 and BR-KSA-11 are closed in the same pass. -
2
Write the percentage, not the fraction
15means fifteen per cent. If your system stores the fraction for a library that expects it, convert it once at the moment the XML is written, and compute the VAT amounts from the rate you wrote — base times rate over one hundred — never from the fraction, or the rate will be right and the amounts will contradict it. -
3
If the line carries no VAT, change the letter, not the number
Zero has its three letters and their reasons, and it is not allowed on
S. Pick the letter that describes the supply and the published exemption reason that goes with it, and write the rate 0 from the same table, on the line and on its tax subtotal together. How to read the whole response when more than one code arrives 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, by construction. The rate is never accepted from anyone: the values are four constants in TaxCategories — 15.0 for S and zero for Z, E and O — and TaxCategories::rate() is the only source of every rate written into the XML, with a letter the table does not know coerced to S. It is read in exactly three places: the line's category, each tax subtotal, and the category on the document-level allowance. The remaining two of the five fields do not exist in our documents at all: a document carries no charge at its level — the only block that leaves is an allowance — and no prepayment, so there is no charge rate and no prepayment rate to check. The library writes the rate on the line with two decimals, 15.00, and on the subtotal and the allowance with none, 15, and both are inside the rule. One limit stated plainly: there is no rate of 5 in ZATCA Tools; a standard-rated line here is 15 and nothing else.
Related codes
Frequently asked questions
I sent 0.15 and it was rejected here, not by BR-KSA-DEC-02. Why? +
0.15 is inside it. This rule is the fence on value: a standard-rated item takes 15 or 5 and nothing else. The fraction passes the first and fails the second, and the right value is 15.My line is exempt and I wrote S with a rate of 0. Is zero not accepted? +
S. Zero is accepted on Z, E and O with an exemption reason, and this rule allows a standard-rated item only 15 or 5. The mistake is in the letter, and the letters are covered in BR-KSA-18.The message lists five fields. How do I know which one failed? +
Is a rate of 5 allowed? +
Does it apply to simplified invoices? +
Does 15.00 with the zeros fail? +
ZATCA Tools builds the signature, the PIH, the counter and the encoding for you, and validates your data before it is sent. Start free, with no credit card.
Start for free