BR-KSA-42 Warning — the invoice is accepted

Tax invoice without a buyer name (BT-44)

A tax invoice and its credit and debit notes carry the buyer name in its own field. It is a warning, so the document is accepted and goes out signed with a seller and no buyer on it. The usual source is a simplified-invoice template reused for a tax invoice, or the name written in the trading-name element instead of the registered-name one.

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

The buyer name (BT-44) must be present in the tax invoice and associated credit notes and debit notes (KSA-2, position 1 and 2 = 01).

What does this mean?

The rule reads a document family: the tax invoice and its notes, the documents whose KSA-2 code begins 01. The field is the buyer name (BT-44), at cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName: the establishment's registered name as on its commercial registration or VAT certificate, or a person's name as on their ID when the buyer is an individual buying in a business capacity. The simplified invoice (02) is outside the rule, except in two cases named by two other rules.

UBL gives the buyer two name elements that get confused: this registered name (BT-44) in PartyLegalEntity, and the trading name (BT-45) in cac:PartyName/cbc:Name. The rule looks at the first alone; a name written only in the second does not settle it. The name also has a length rule of its own, BR-KSA-F-06-C12, from one character to a thousand.

It is a warning: the document is accepted and the warning recorded with it. But the cost here is heavier than a format warning. The VAT Implementing Regulations list the customer's name among the contents of a tax invoice (Article 53), and the tax invoice is the buyer's evidence for deducting input VAT. A document that names no buyer is hard for their accounts department to match against a purchase order, and hard to rely on. The Authority cleared the document technically; for the party it was issued to, it is incomplete.

Three rules sit on the same buyer block: BR-KSA-14 on the identifier and its scheme, BR-KSA-44 on the shape of the VAT number, and BR-KSA-81 on the presence of another identifier when there is no VAT number. The name does not stand in for the identity nor the identity for the name; a sound block carries both.

Why does it happen?

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

  • A simplified-invoice template reused for a tax invoice: its buyer block is optional, so a document coded 0100000 goes out with an empty or absent buyer party.
  • The name in the wrong element: the system writes cac:PartyName/cbc:Name (the trading name, BT-45) and leaves PartyLegalEntity/cbc:RegistrationName empty, so the name shows on the printed document and the validator does not find it.
  • An empty name at the source: the store sent blank first and last names for a customer who registered with a phone number only, or the system reads the «company» field, which is empty, while the name sits in the «person» field.
  • A credit or debit note built from a template that copies the buyer's VAT number and leaves the name, or from a customer record whose name was deleted or blanked after the original invoice.
  • A name made of spaces, or a placeholder such as «cash customer» or «-» on a tax invoice: it silences the rule and puts a buyer who does not exist on the document.

How to fix it

4 steps, then send the invoice again.

  1. 1
    Write the registered name in BT-44

    Inside the buyer party, in cac:PartyLegalEntity: <cbc:RegistrationName>Example Trading Co.</cbc:RegistrationName>. The name as on the commercial registration or the VAT certificate, not the trading name on the sign and not the employee who placed the order. If the buyer is a person, their name as on their ID.

  2. 2
    Make the name a requirement in your system before it is a warning at the Authority

    As long as the document is a tax invoice, refuse to build it from a buyer record with no name, and ask for the name at the same moment as the VAT number. A check on your side prevents the warning on every invoice to that buyer, and with it what the blank usually hides: a buyer whose details were never collected at all.

  3. 3
    Carry it onto the notes

    A credit or debit note against a tax invoice carries a full buyer block of its own, not just a reference to the original invoice. Build it from the same buyer record — name, identity and address — not from a copy of the number. The rest of what a note needs is in BR-KSA-17 and BR-KSA-56.

  4. 4
    Fix the record; the accepted document is your customer's call

    A document accepted with this warning is issued and stays in your chain, and nothing in the rule asks for a reissue. Correct the buyer record so their next invoices go out under their name. If your customer asks for an invoice bearing their name so they can deduct the VAT on it, the route is a credit note against the incomplete document and a new, complete invoice; see credit and debit notes.

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?

Yes on every path. A tax invoice is never built here except for a saved customer: the invoice form refuses one without a customer, issuing a draft — one converted from a quotation included — repeats the same check, and the API refuses a tax invoice without a customer object and refuses the object without a name. The customer record itself is never saved with a name shorter than three characters, from the form or from the spreadsheet import, and cannot be deleted while it is in the system. The record's name is what is written into RegistrationName, not into the trading-name element. A credit or debit note takes the original invoice's customer with their whole record, from the screen and from the API alike. An order from a connected store becomes a tax invoice only for a customer record the merchant confirmed, and that record was saved with its name. What we do not prevent is the correctness of the name itself: a trading name in place of the registered one, or an employee's name in place of their establishment's, passes with us and with the Authority, and the care there is yours.

Related codes

BR-KSA-14 Rejects the invoice
Buyer identification (BT-46) missing or without its scheme
BR-KSA-44 Rejects the invoice
Buyer VAT number invalid on the invoice
BR-KSA-81 Warning
Tax invoice to a buyer with neither a VAT number nor another ID (BT-46)
BR-KSA-71
The official message text is in the Full reference.
BR-KSA-F-06-C12
The official message text is in the Full reference.

Frequently asked questions

Was my invoice rejected because of this code? +
No. BR-KSA-42 is a warning: the document is accepted and the warning recorded with it. If your invoice really was rejected, the cause is another code in errorMessages; on the buyer block specifically, see BR-KSA-44 for the VAT number and BR-KSA-14 for the identifier. How to read the response is in ZATCA error codes explained.
The buyer is a person, not a company. What do I write? +
Their name as on their national ID or Iqama, in the same field, BT-44; the rule makes no distinction between an establishment and an individual. They are identified by that ID in BT-46 with the scheme NAT or IQA as the message of BR-KSA-14 names it, and the Authority checks the check digit of both (BR-KSA-F-13).
What is the difference between BT-44 and BT-45? +
BT-44 is the registered name in PartyLegalEntity/RegistrationName, the one this rule checks. BT-45 is the trading name in PartyName/Name, optional, and on its own it does not settle the rule. If you have one name, put it in BT-44.
Does it apply to the simplified invoice? +
No; this rule is on documents coded 01. But the simplified invoice has two cases where the buyer name is required by two other rules: the summary simplified invoice (BR-KSA-71), and a line exempted under the education or healthcare exemption for a citizen (BR-KSA-25, with the national ID under BR-KSA-49). The difference between the two documents is in standard versus simplified tax invoices.
The original invoice is fine and the credit note against it carried the warning. Why? +
Because a note is a document of its own with its own buyer block; it inherits nothing from the original invoice but the reference to it by number. If the note was built from a template that writes the VAT number alone, or from a customer record whose name was blanked after the invoice, it goes out with no name. Build it from the full customer record the way you build the invoice.
Is the name enough without a VAT number? +
The name settles this code and no other: a tax invoice identifies its buyer by their VAT number in BT-48 if they are registered, or by another identifier with its scheme in BT-46 if they are not (BR-KSA-81). The name and the identity together are the sound buyer block.
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