BR-KSA-F-06-C19 Warning — the invoice is accepted

Item name (BT-153) shorter than three characters, or longer than a thousand

The item name on an invoice line has two limits: a floor of three characters and a ceiling of a thousand. The floor is the surprise — a line named A, or 1, or m2 comes back with a warning from the Authority, and the invoice is accepted with it. This code is not in the extract published with the Authority SDK; we added it from a live API response to a real invoice.

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

Field character limits for Item name field (BT-153) have not been met. The minimum limit is 3 character and the maximum limit is 1000 characters.

What does this mean?

Every line on an invoice carries the item name (BT-153) in cac:InvoiceLine/cac:Item/cbc:Name — the name the buyer reads on the document and the validator reads in the file. This rule puts two limits on it in one sentence: not fewer than three characters, and not more than a thousand.

The floor is what earns this code a page. Of the 136 rules we index, only ten state a minimum in their text — and every one of those says one character. This is the only field whose minimum is three. So a name that satisfies every other condition in the file — not empty, not truncated, no forbidden characters — is still under the limit if it is one letter or two.

It is a warning: the Authority clears the invoice and returns the code alongside that acceptance in warningMessages, not in errorMessages. Nothing is rejected here. What remains is a line on a tax document that does not say what was sold.

Where it sits in the list is worth knowing. The BR-KSA-F-06 family is the field-length rules, and in the published extract it runs from C3 to C39 with gaps: C8, C10, C17 through C20, C27, C30 and C31 are absent. C19 is one of those gaps — and the live API returns it anyway. We added it to our list from a response we captured on 2026-08-29, exactly as we did before with BR-KSA-F-13.

Why does it happen?

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

  • A line carrying its code rather than its name: S for a small size, A4 for a paper size, m2 for a square metre — one character or two in the name field.
  • A mismapped import: the SKU column wired to the item name, while the real description sits in a column nobody read.
  • A line added for an arithmetic purpose — a rounding difference, a fee, a discount line — named - or + or a single letter.
  • The unit of measure typed into the name field instead of its own: kg, m, hr, several of which are one or two characters.
  • A row with no name in an imported file, where the system writes a one-character placeholder rather than stopping and asking.
  • And the other direction: a full specification or a scope of work typed into the name field, running past the thousand.

How to fix it

3 steps, then send the invoice again.

  1. 1
    Write the item name as the buyer reads it, not as your system codes it

    The name field belongs to whoever reads the document: Brand identity design, Split air-conditioner service, A4 copier paper. The internal code belongs in the line description, not in the name. Three characters is a very low floor — any real name clears it without your having to think about it.

  2. 2
    Check the column mapping before the validator does

    If the lines arrive from a store, a spreadsheet or the API, check which column fills name: the description or title column, never the SKU column. A row with no name should be stopped or named, not filled with a placeholder — a placeholder passes your system and stops at the Authority.

  3. 3
    The ceiling is a thousand characters — room, not an invitation

    A thousand characters holds a whole paragraph, so being anywhere near it means a specification or a scope of work is being written into the name field. Keep the name to one line that says what was sold, and put the detail in the line description underneath it. In ZATCA Tools that description is a field of its own: it prints under the name and is never sent to the Authority at all, so it falls under neither this rule nor any other length rule.

This code does not block acceptance, so the invoice you have is compliant. Correct the data so the warnings disappear from future invoices.

Does ZATCA Tools prevent it?

No. A document line in ZATCA Tools goes through one reading shared by all four doors — the invoice form, the quotation form, the note form and the API — and that reading drops only a line whose name is empty. It imposes no minimum length and no maximum. So a line named with a single character leaves here and comes back with this warning. The one exception is an item saved in your item list: there we require at least two characters and at most two hundred — and two is still under the three the Authority asks for, so the check narrows the gap without closing it, while two hundred makes the thousand-character ceiling unreachable through that door alone. We state the gap rather than hide it: the correct check is three characters at every door, and it is not built today.

Related codes

Frequently asked questions

Is my invoice rejected because an item name is short? +
No. This code is a warning, and it comes back in warningMessages alongside the acceptance, not in the errorMessages that reject. The document is cleared and recorded at the Authority; what remains is a line that does not say what was sold. How to read the response is covered in ZATCA error codes explained.
I looked for this code in the Authority list and could not find it +
That is correct, and we say so plainly: the extract published with the Authority SDK does not contain BR-KSA-F-06-C19, and the live interface returns it. We added it to the error codes page from a response we captured ourselves, in the Authority's own words character for character — down to "3 character" in the singular, exactly as it reached us. This is the second time it has happened to us; the first was BR-KSA-F-13.
My item is named A4 — two characters. Is that enough? +
No: the floor is three, and two is under it. And A4 is a size rather than a name in any case — A4 copier paper describes what was sold and clears the limit at the same time.
Is the name counted in characters or in bytes? +
The message says character, and we have no test that settles where the Authority draws the line between a character and a byte. Arabic is safe under either reading: three Arabic letters are three characters and six bytes, and both are over the limit. What deserves care is a two-letter Latin name.
My invoice has ten lines. Which one is short? +
The response does not say. Validation messages arrive with a code and a sentence and no line number, so the check is yours: read the item names and look for one shorter than three characters. On a long invoice arriving from another system it is faster to check the source — the column that fills the name — than the invoice.
Does it cover the line description or the invoice notes? +
No. This rule is about the item name (BT-153) alone. Other field lengths have their own codes in the same family — the buyer name in BR-KSA-F-06-C12, the buyer street in BR-KSA-F-06-C23, the reason for a note in BR-KSA-F-06-C13 — and their minimum is one character, not three.
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