BR-KSA-05 Rejects the invoice

Invoice type (BT-3) holds a value that is not accepted

Four values are accepted: 388 invoice, 386 prepayment invoice, 381 credit note, 383 debit note. And why Phase 2 has no cancel-invoice type.

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

The invoice type code (BT-3) must be equal to one of value from the subset of UN/CEFACT code list 1001, D.16B agreed for KSA electronic invoices. Please refer paragraph 11.2.1 of XML implementation Standards.

What does this mean?

Field BT-3 takes a value from the UN/CEFACT 1001 list, and the set adopted in Saudi Arabia — paragraph 11.2.1 of the XML Implementation Standard — is four values: 388 tax invoice, 386 prepayment (advance payment) invoice, 381 credit note, 383 debit note. Each carries its subtype, standard or simplified, in the name attribute.

386 is not an ordinary invoice under another number. It is issued when an advance payment is received, and the 388 invoice that later bills the supply deducts it, with the prepayment reference fields and the prepaid amount inclusive of VAT, as ZATCA's detailed e-invoicing guideline sets out in its section on advance payments. A worked example for a contractor is in e-invoicing for contractors.

What is not on the list: there is no cancelled-invoice type and no amended-invoice type. A correction in Phase 2 happens through a credit note or a debit note that references the original invoice, not by editing it and not by deleting it.

Why does it happen?

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

  • Sending a code from the full UN/CEFACT list that is not adopted in Saudi Arabia.
  • Trying to represent a cancellation with a special code instead of a credit note.
  • Confusing BT-3 (document type) with KSA-2 (transaction code) and sending the value of one in the field of the other.

How to fix it

2 steps, then send the invoice again.

  1. 1
    Use the four values and nothing else

    388 for an invoice, 386 for a prepayment invoice, 381 to reduce an amount or cancel it, 383 to increase an amount.

  2. 2
    To cancel: a credit note for the full amount

    Issue a credit note (381) for the full value of the invoice and reference the original invoice number in field BT-25, which is mandatory — see BR-KSA-56.

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, for what we issue: the type is set by the kind of document you create in ZATCA Tools — an invoice, a prepayment invoice, a credit note or a debit note — and a cancellation goes through a credit note linked to the invoice automatically. An advance is issued as 386 with its subtype, and the invoice that later deducts it stays 388.

Related codes

BR-KSA-06 Rejects the invoice
Transaction type code (KSA-2) invalid — the NNPNESB structure
BR-KSA-56 Warning
Credit or debit note with no reference to the original invoice

Frequently asked questions

I made a mistake on an invoice that was issued and reported — what now? +
Do not delete it and do not edit it. Issue a credit note that cancels it, then a new, correct invoice. The wrong invoice stays in the chain together with the document that corrects it, and that is exactly what the regulation asks for.
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. Start free, with no credit card.

Start for free

← All ZATCA error codes