BR-KSA-15 Warning — the invoice is accepted

Tax invoice without a supply date (KSA-5)

A tax invoice carries two separate dates: the date it was issued and the supply date. The second is mandatory by the text of the rule even though its severity is a warning, and it often goes missing from invoices for services and monthly contracts, because its XML element is called Delivery and looks like it belongs to shipping.

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

The tax invoice ((invoice type code (BT-30) = 388) and (invoice transaction code (KSA-2) has "01" as first 2 digits)) must contain the supply date (KSA-5).

What does this mean?

The rule concerns the tax invoice alone: document type 388 with a transaction code (KSA-2) whose first two digits are 01. It does not name the credit note (381), the debit note (383) or the simplified invoice (02). Note that the message above labels the document type BT-30, while the other rules — BR-KSA-05 among them — call it BT-3; either way the element is cbc:InvoiceTypeCode.

The supply date (KSA-5) is the element cbc:ActualDeliveryDate inside cac:Delivery at invoice level, written as YYYY-MM-DD like the other dates (BR-KSA-F-01). It is not the issue date (BT-2) in cbc:IssueDate: one says when the supply took place, the other when the document was issued, and the two can differ.

The element name misleads anyone who sells a service: Delivery suggests a parcel, so a maintenance firm or a consultancy concludes the field is not for them and drops it. The rule calls it the supply date and requires it on every tax invoice, with no distinction between goods and services.

Beside it in the same block sits the supply end date (KSA-24), cbc:LatestDeliveryDate, which is how a document states a period rather than a day. No rule in the list requires it on a tax invoice, but once it is present it brings two rules with it: BR-KSA-35 asks for the supply date alongside it, and BR-KSA-36 requires the end date to be no earlier than the supply date — both warnings. A simplified summary invoice, by contrast, needs both dates under BR-KSA-72, which is an error.

It is a warning: the Authority clears the invoice and returns the warning alongside that acceptance. The field is still mandatory by the text of the rule, and an invoice without it does not say when the supply it bills took place — exactly what someone matching a monthly contract invoice to the period it covers wants to know. The warning also returns on every tax invoice for as long as your system does not write the field.

Why does it happen?

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

  • A cac:Delivery block built only when there is a shipping address — online-store logic — so invoices for services and contracts go out with no supply date.
  • A template built on the European EN 16931 specification, where the delivery date is optional: it passes European validation and fails here.
  • A recurring-billing system that generates the monthly invoice from the contract with an issue date alone, and leaves the service period to a free-text note.
  • A supply end date (KSA-24) sent on its own for the service period with no supply date beside it, so this warning arrives together with BR-KSA-35.

How to fix it

4 steps, then send the invoice again.

  1. 1
    Emit the block on every tax invoice

    cac:Delivery at invoice level, holding cbc:ActualDeliveryDate as YYYY-MM-DD, on every document of type 388 whose transaction code starts 01 — goods or services, with a shipping address or without one.

  2. 2
    Decide once where the date comes from

    For a sale delivered on the day it is invoiced, the two dates usually match. For an invoice issued before or after the supply — a contract instalment, a service performed last week — give the supply date its own source in your system instead of copying the issue date automatically. Which day counts as the date of supply for a continuous service is a tax question for zatca.gov.sa, not an XML one.

  3. 3
    For a period, two fields

    If the invoice covers a period — a month of a maintenance contract, say — the file has two fields for it in the same block, the supply date (KSA-5) and the supply end date (KSA-24), provided the end is not earlier than the supply date (BR-KSA-36). A period written as free text in a note stands in for neither. Why a monthly retainer is twelve separate invoices rather than one is covered in e-invoicing for software and IT companies.

  4. 4
    Fix the generator, not the invoice

    The invoice that carried the warning was cleared and does not need reissuing to stand. Fix the XML build so it always writes the field, and the next invoices go out clean — and check the issue time (KSA-25) while you are there, another field that goes missing in systems storing only a date: BR-KSA-70.

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. Every tax invoice ZATCA Tools issues carries a supply date: the invoice form sets it to the invoice date unless you change it under Service date, the API reads supply_date and defaults it to the issue date when it is not sent, and converting a quotation into an invoice takes the day of conversion. The payload builder itself writes the issue date when a tax invoice reaches it with no supply date stored, so no tax invoice file leaves here without KSA-5 — and a credit or debit note on a tax invoice carries one too, dated the day the note is issued, although this rule does not ask for it. The printed document labels it Service date. What we do not have, in the same honesty: a supply end date (KSA-24). There is no field for it in the form or in the API, so an invoice covering a month carries a single date in its file — which is also why BR-KSA-35 and BR-KSA-36 cannot come from us.

Related codes

BR-KSA-35
The official message text is in the Full reference.
BR-KSA-36
The official message text is in the Full reference.
BR-KSA-72
The official message text is in the Full reference.
BR-KSA-70 Rejects the invoice
Invoice issue time (KSA-25) missing or in the wrong format

Frequently asked questions

Does this code reject my invoice? +
No. It is a warning: the invoice is cleared and the warning is recorded with it. The field is mandatory by the text of the rule all the same, and the warning repeats on every tax invoice until your system writes it — so fix the generator rather than the invoice.
I invoice a monthly contract at the start of the month for that month. Which date do I write? +
The rule requires the field to exist; it does not say which day goes in it. The file has two fields for a period like this, the supply date (KSA-5) and the supply end date (KSA-24), with the end no earlier than the supply date (BR-KSA-36). Which day counts as the date of supply for a continuous service under the VAT rules is a tax question for zatca.gov.sa, and we do not rule on it. The practical advice: settle the rule for your contracts once, and apply it in your system to every instalment.
Can the supply date differ from the invoice date? +
They are separate fields, and none of the 135 rules we index compares one with the other in its text: BR-KSA-04 keeps only the issue date out of the future, and BR-KSA-36 compares the supply end date with the supply date, not with the issue date. When an invoice must be issued relative to the supply is a regulatory matter for zatca.gov.sa.
We sell services and nothing is delivered. Why a Delivery element? +
Because the name is inherited from UBL. What the rule checks is the supply date, and it requires it on every tax invoice, goods or services. Write the date the service was supplied in cbc:ActualDeliveryDate, and do not drop the block because there is no parcel.
Is it required on a simplified invoice or on notes? +
This rule does not name them: its condition is type 388 with a transaction code starting 01. One exception is worth knowing: a simplified summary invoice — the sixth digit of KSA-2 set to 1 — needs both the supply date and the supply end date under BR-KSA-72, which is an error, not a warning.
I sent a supply end date and got BR-KSA-35. How are they connected? +
The two dates are a pair: once the supply end date (KSA-24) is present, the supply date (KSA-5) must be there too. A tax invoice carrying the end date alone collects both warnings — this one for the missing supply date, that one for an end date with no supply date — and both disappear once the supply date is written.
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