BR-KSA-05: Invoice type code is not allowed

Official text

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.

Error · Source: ZATCA E-Invoicing SDK 238-R3.3.8 · Electronic Invoice XML Implementation Standard v1.2, 19 May 2023, §13.3.1, p. 48 · Checked: 26 October 2026

What it means

The document type code must come from the Saudi subset: 388 invoice, 386 prepayment invoice, 383 debit note, 381 credit note. Any other code is rejected.

When it happens

• The system uses 380 (the European commercial invoice code) instead of 388.
• A credit note was sent with the invoice code, or the reverse.
• The code contains a space or an extra character.

How to fix it

1. Use 388 for tax and simplified invoices.
2. Use 381 for a credit note, 383 for a debit note and 386 for a prepayment.
3. Tell tax and simplified invoices apart with the name attribute (first two digits 01 or 02), not with a different code.

Example

<cbc:InvoiceTypeCode name="0200000">380</cbc:InvoiceTypeCode>

<cbc:InvoiceTypeCode name="0200000">388</cbc:InvoiceTypeCode>

We ran the wrong example through ZATCA's SDK 238-R3.3.8 on 26 October 2026 and it raised BR-KSA-05. The example is an excerpt of ZATCA's sample Simplified/Invoice/Simplified_Invoice.xml with one change; the sample without it does not raise the code.

Related codes

• BR-KSA-06 Transaction code (KSA-2) is incomplete
• BR-CL-01 The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001.
• BR-KSA-03 Invoice unique identifier (UUID) is missing

Terms on this page

Last updated: 26 October 2026 · What we don't do · Methodology · Correct us · Changelog

First published 2026-10-26 · Archived copy