BR-KSA-06 Rejects the invoice

Transaction type code (KSA-2) invalid — the NNPNESB structure

Seven digits that state the invoice type and the properties of the transaction. What each digit means, and the values actually used on a tax invoice and on a simplified one.

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

The invoice transaction code (KSA-2) must exist and respect the following structure: NNPNESB where NN (positions 1 and 2) = invoice subtype: - 01 for tax invoice - 02 for simplified tax invoice P (position 3) = 3rd Party invoice transaction, 0 for false, 1 for true N (position 4) = Nominal invoice transaction, 0 for false, 1 for true E (position 5) = Exports invoice transaction, 0 for false, 1 for true S (position 6) = Summary invoice transaction, 0 for false, 1 for true B (position 7) = Self billed invoice

What does this mean?

Field KSA-2 is seven digits, and each digit carries a specific meaning, in the order NNPNESB:

The first and second digits (NN): the invoice subtype — 01 tax invoice, 02 simplified tax invoice. The third (P): third-party transaction. The fourth (N): nominal transaction. The fifth (E): export. The sixth (S): summary invoice. The seventh (B): self-billed invoice. Each of the last five digits takes 0 when it does not apply and 1 when it does.

So an ordinary tax invoice between two local businesses is coded 0100000, and a simplified tax invoice to a consumer is 0200000.

Why does it happen?

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

  • A length other than seven digits — the most common cause.
  • Using 01 for a simplified invoice or 02 for a tax invoice, so the code contradicts the document type in BT-3.
  • Setting the export digit to 1 for a customer outside Saudi Arabia but inside the GCC states that have implemented VAT.
  • Setting the self-billed digit to 1 on an export invoice, which BR-KSA-07 forbids explicitly.
  • Leaving the field empty altogether because the system relies on BT-3 alone.

How to fix it

2 steps, then send the invoice again.

  1. 1
    Build the seven digits from the invoice type, not the other way round

    Decide first: tax invoice or simplified? Then set the first two digits. Then answer 0 or 1 to five questions: third party? nominal? export? summary? self-billed? For the overwhelming majority of invoices the answer is five zeros.

  2. 2
    Keep KSA-2 consistent with BT-3

    BT-3 cannot say tax invoice (388) while KSA-2 says simplified (02…). The contradiction is rejected even when each field is correct on its own. See BR-KSA-05.

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. ZATCA Tools builds the code from the invoice type you choose and from the customer data, so you never write the seven digits by hand.

Related codes

BR-KSA-05 Rejects the invoice
Invoice type (BT-3) holds a value that is not accepted
BR-KSA-31
The official message text is in the Full reference.

Frequently asked questions

What is a nominal invoice? +
A supply with no monetary consideration — a gift, a sample, or personal use of goods from stock. It is still subject to VAT, and it is flagged by setting the fourth digit to 1.
When do I set the summary digit? +
When you issue a single invoice covering several supplies to the same customer over a period. The Authority then requires additional data — see BR-KSA-71 and BR-KSA-72.
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