Tax currency code (BT-6) must exist in an invoice.
What does this mean?
Two separate fields. The invoice currency (BT-5) is what the amounts are expressed in — what you priced and what the customer pays. The tax currency (BT-6) is the currency the VAT is accounted in, which on a Saudi invoice is SAR. This code checks one thing: that BT-6 is on the document at all.
It is not conditional. There is no shape of Saudi e-invoice that leaves the tax currency out, and an invoice entirely in SAR is not an exception — it says SAR explicitly, in an element of its own.
Three rules sit on this field and it helps to keep them apart. This one, an error, says BT-6 must exist. BR-KSA-EN16931-02, also an error, says its value must be SAR. BR-KSA-EN16931-09, a warning, governs what declaring BT-6 then obliges the document to carry: exactly one tax total block with no breakdown inside it, holding the VAT amount in SAR.
The element is cbc:TaxCurrencyCode at invoice level, beside cbc:DocumentCurrencyCode. A currencyID attribute on an amount is not this field and does not stand in for it.
Why does it happen?
Ordered from the most common to the least — your cause is most likely the first or the second.
- XML generated from a generic EN 16931 template, where BT-6 is optional. Under the KSA rules it is not, so the template passes European validation and fails here.
- A system that drops the field when the two currencies are identical, on the reasoning that repeating SAR adds nothing.
- The element emitted empty, or holding whitespace, from a mapping whose source value was null.
-
Setting the currency only through the
currencyIDattribute on the amounts and never emitting the standalone element.
How to fix it
3 steps, then send the invoice again.
-
1
Emit the element, always
cbc:TaxCurrencyCodewith the valueSAR, besidecbc:DocumentCurrencyCode, on every document — invoice, credit note and debit note. Write it as a constant rather than deriving it from your establishment settings: on a Saudi invoice there is nothing to derive. -
2
Then carry what it obliges
Once BT-6 is declared the tax structure has to match it: a first tax total with the breakdown in the invoice currency, and a second holding the VAT amount in SAR with no breakdown inside it. That second block is BR-KSA-EN16931-09, a warning rather than a rejection, which is why it is often the next thing you see after fixing this one.
-
3
If you bill in a foreign currency
BT-5 stays the currency you invoiced in and BT-6 stays SAR, with the VAT converted for the SAR block at the rate your business uses. Two more rules watch that combination:
BR-KSA-97expects the two VAT totals to differ once the invoice currency is not SAR, andBR-KSA-88andBR-KSA-89expect the exchange-rate fields, where present, to name those same two currencies.
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, though not by validation so much as by the shape of the product: ZATCA Tools issues in SAR only. The builder sets the invoice currency and the tax currency to SAR on every document, so BT-6 is always present and always right. Invoicing in a foreign currency is not supported at all, which is the honest version of the same sentence: the field cannot be wrong here because the case that makes it interesting does not arise.
Related codes
BR-KSA-EN16931-02
BR-KSA-EN16931-09
Warning
BR-KSA-CL-02
Frequently asked questions
Everything on my invoice is in SAR. Why does it want a tax currency at all? +
I added BT-6 and now I am getting BR-KSA-EN16931-09. Did I make things worse? +
Can BT-6 be something other than SAR? +
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