A Debit Note is an official document a seller issues to increase the amount due on a previously issued invoice. When you discover that the original invoice was lower than it should have been, or you add fees or quantities that were not accounted for, you do not amend or delete the old invoice. Instead, you issue a debit note carrying only the value of the difference and referencing the original invoice. Under Phase Two of electronic invoicing in Saudi Arabia, this note is built as an XML file compliant with the UBL 2.1 standard and carries document type code 383. This technical reference breaks down every field in the debit note by its actual wording inside the file, with ready-to-use XML snippets and reference tables.
This guide is part of the technical documentation series for electronic invoicing. It focuses exclusively on the debit side, that is, the case of an increase on an existing invoice. The case of a decrease, cancellation, or discount is the subject of the separate «Credit Notes» guide. The debit note and the credit note are twins in structure but opposite in direction: the debit note raises the amount, and the credit note lowers it. Before we begin, it helps to review the Invoice Header in XML, because the debit note shares most of the header fields with the invoice.
What is a debit note and when do you issue it?
The debit note is a correction tool for increases. A business uses it when it turns out the amount invoiced to the customer is lower than the correct amount. Instead of amending an approved, signed invoice already sent to the Fatoora platform, you issue an independent document carrying only the value of the increase and linking it to the original invoice. This rule is fundamental: an approved invoice is neither amended nor deleted after it is signed; it is corrected by a subsequent note.
The need for a debit note recurs in clear practical cases. Among them: issuing an invoice at a price lower than agreed and then discovering the difference. Or adding a service or quantity that was not included in the original invoice and wishing to link it to that invoice rather than issuing a separate new one. Or an increase in fees agreed to be tied to a prior deal, such as late fees or additional charges on an existing contract. In all these cases the direction of correction is upward, so the correct document is the debit note, not the credit note.
From an accounting standpoint, the debit note increases the customer’s liability toward the business and increases the value of VAT due on the increase. It is therefore subject to the same electronic invoicing requirements as the original invoice: a digital signature, a unique identifier, a QR code, and integration with the Fatoora platform. The only difference is that it is a corrective document that always references a prior original, so it never stands alone.
Some accountants confuse a debit note with a new invoice. The difference is that a new invoice establishes an independent transaction in its own right, whereas a debit note corrects an existing transaction already documented by a prior invoice. When the increase is tied to the original invoice and an extension of it, the more appropriate step is to issue a debit note that links it to its original. But if it is an entirely separate sale, the more appropriate step is a new invoice. This distinction preserves the clarity of the accounting record and makes it easier to track corrections per customer.
The document type code for the debit note (383)
The document type is defined inside the XML via the cbc:InvoiceTypeCodefield. The numeric value of this field determines the nature of the document under a unified coding adopted by the Zakat, Tax and Customs Authority (ZATCA). For a tax invoice the value is 388, for a credit note 381, and for a debit note 383. This value is the first marker the system reads to know it is dealing with a debit note rather than an ordinary invoice.
Alongside the number 383, the field carries an attribute name made up of seven positions describing the document’s sub-characteristics. The most important position in it is the one that distinguishes a business-oriented document (B2B) from a simplified consumer-oriented document (B2C). The value 0100000 indicates a standard business-oriented document subject to clearance, and the value 0200000 indicates a simplified consumer-oriented document subject to reporting.
Note that the root element remains <Invoice> even if the document is a debit note. The UBL 2.1 standard uses the same root element for the invoice and both notes, distinguishing between them only by the document type code. This design simplifies processing: any system reading the file starts from the same element, then reads the code 383 to know it is dealing with a debit note.
A visual illustration of code 383 and its location
388: Tax invoice
381: Credit note (decrease)
383: Debit note (increase)
Subtype 01 for B2B and 02 for B2C
The following table gathers the three document type codes you deal with daily, so you can quickly tell them apart when reading any file:
| Document | Code | Direction | References an original? |
|---|---|---|---|
| Tax invoice | 388 |
Original record | No |
| Credit note | 381 |
Decrease or cancellation | Yes |
| Debit note | 383 |
Increase | Yes |
Referencing the original invoice (cac:BillingReference)
The debit note does not stand alone. It must explicitly reference the original invoice it corrects. This link is made via the cac:BillingReference block, which carries within it the reference to the invoiced document. The absence of this block in a debit note leads to rejection of the file, because the system cannot verify the original document the note corrects.
The value inside cbc:ID is the commercial number of the original invoice as it appeared on it, not the unique identifier UUID. As for cbc:IssueDate it is the issue date of the original invoice, and it helps the system pinpoint the document accurately when similar numbers exist across different periods. Precision here matters: any error in the original invoice number leaves the reference dangling with no original, and the note is rejected.
In compliant systems you do not write this block manually. You select the original invoice from the list of invoices, and the system fills the BillingReference block automatically with the correct number and date. This reduces linking errors to a minimum. The Qoyod electronic invoicing software handles this linking on your behalf, so you do not need to remember invoice numbers or copy them manually.
The unique identifier, counter value, and linking sequence (UUID, ICV, and PIH)
The debit note carries its fully independent identity just like the invoice. Three technical fields govern this identity and its sequence within the business: the unique identifier UUID, the counter value ICV, and the previous document hash PIH. Understanding these three fields explains how the system links each document to its predecessor in a single chain that admits no gaps.
The unique identifier cbc:UUID is a global number the system generates for each document, distinct from the commercial document number. This identifier never repeats across all of the business’s documents, which guarantees the debit note is distinguished definitively even if commercial numbers resemble one another across the years.
The counter value ICV (short for Invoice Counter Value) is a sequential counter that increases by one with every document the business issues, whether an invoice, a credit note, or a debit note. This counter proves the issuance sequence and prevents gaps. The ICV comes within a cac:AdditionalDocumentReference block under the identifier ICV.
The previous hash PIH (short for Previous Invoice Hash) is the fingerprint of the document immediately preceding this note in the business’s chain. Every document carries the hash of its predecessor, forming an interlinked chain into which no document can be inserted or deleted without breaking the chain. This chain is what guarantees the integrity of the business’s entire record. Any tampering with an old document breaks the hash match in everything after it, so it shows immediately.
How a business’s documents interlink in a single chain
Invoice (ICV=45)
Debit note (ICV=46 + reference to the original)
Next invoice (ICV=47)
These three fields are generated automatically in compliant systems. You do not compute the hash yourself nor manage the counter manually. It is enough to issue the debit note, and the system takes over computing the next ICV, fetching the PIH from the previous document, and generating a new UUID. This automatic generation is what makes adherence to the chain practical without manual burden.
Clearance and reporting for the debit note
The debit note’s path through the Fatoora platform follows the same rule as the original invoice and depends on the document’s audience. A business-oriented (B2B) debit note is subject to Clearance, and a consumer-oriented (B2C) debit note is subject to Reporting. This distinction is the same one we saw in the name attribute within the document type code.
In the clearance path, the debit note is sent to the Fatoora platform before it is delivered to the customer. The system verifies its validity and stamps it with its seal, so it reaches the customer only after it is approved. This path applies to standard business-oriented documents, where prior verification is a condition of the document’s validity.
In the reporting path, the simplified debit note is issued and delivered to the consumer immediately, then reported to the Fatoora platform within twenty-four hours. This path applies to simplified consumer-oriented documents, where prior verification is not required, only subsequent reporting within the specified window. For a deeper look at the clearance mechanism and its steps, see the guide on Clearance in electronic invoicing.
The clearance and reporting paths for the debit note
| Criterion | B2B (clearance) | B2C (reporting) |
|---|---|---|
| Timing | Before delivery | Within 24 hours |
| Verification | Prior approval | Subsequent reporting |
| name | 0100000 | 0200000 |
Issue your debit notes without touching XML
Qoyod generates code 383, the note block, and the link to the original invoice automatically, and handles signing and clearance with the Fatoora platform entirely on your behalf.
The difference between a debit note and a credit note
The two notes are twins in structure: both carry a BillingReference block referencing the original invoice, both carry a UUID, ICV, and PIH, and both are subject to clearance or reporting according to the audience. The fundamental difference between them lies in the direction of correction and in the document type code.
The debit note corrects upward and carries code 383. You use it when the invoiced amount is lower than the correct one, so it raises the customer’s liability and the value of tax due. The credit note, on the other hand, corrects downward and carries code 381. You use it when the invoiced amount is higher than the correct one, or when cancelling part of the invoice or granting a subsequent discount, so it lowers the customer’s liability and the value of tax.
Choosing the wrong type has a direct accounting impact. If you issue a credit note where a debit note is required, you lower the amount instead of raising it, and you erroneously reduce the tax due. Every correction therefore begins with a single question: is the new amount higher than the original or lower? If it is higher, the document is a debit note; if it is lower, the document is a credit note.
| Aspect | Debit note | Credit note |
|---|---|---|
| Type code | 383 |
381 |
| Direction of correction | Increase | Decrease |
| Effect on customer liability | Raises it | Lowers it |
| Effect on tax due | Increases it | Decreases it |
| Reference to the original invoice | Mandatory | Mandatory |
| Path through the platform | Clearance or reporting | Clearance or reporting |
Tax on the increase amount (cac:TaxTotal)
The debit note carries only the value of the increase, not the full invoice value. VAT is therefore calculated at its usual rate on this increase alone. This tax appears in the cac:TaxTotal block at the document level, exactly as it appears in the original invoice, but the taxable amount here is the upward correction amount, not the original total.
In the example above, the increase amount is SAR 200, and the tax on it is SAR 30 at 15%. These values are calculated on the correction amount alone, not on the original invoice value. The code S inside cac:TaxCategory indicates the category subject to the standard rate. If the increase amount were exempt or zero-rated, the code and tax rate would differ according to the nature of the item.
The total tax in the TaxTotal block must match the sum of the taxes at the line level within the note. Any discrepancy between the document-level total and the line-level sum leads to an arithmetic rejection by the system. Compliant systems guarantee this match automatically, computing the tax on each increase line and then summing it into the total with no manual intervention.
Signing, the QR code, and integration with the Fatoora platform
After the debit note’s fields are complete, the document goes through the same protection steps the invoice goes through. The first is the digital signature via the approved stamping certificate. This certificate is known as the Compliance Cryptographic Stamp Identifier (CSID), and it is the certificate that proves the document was issued by a business registered with the Authority without subsequent tampering.
The signature is followed by generating the QR (Quick Response) code, a machine-readable code carrying summary data from the note such as the seller’s name, tax number, issue date, tax value, and the signature fingerprint. This code enables quick verification of the document via the Authority’s app without needing to open the full file. Its presence is a condition in simplified consumer-oriented documents.
The final step is integration with the Fatoora platform, either by clearance before delivery in the business case, or by reporting within twenty-four hours in the consumer case. Registering the business’s CSID certificate with the Authority is a step the customer performs once, and the accounting system guides them through it. After that, the system handles signing, code generation, and integration in every note without any manual burden on the user.
This integrated sequence, from generating the fields to signing to integration, is what makes the debit note a document fully compliant with Phase Two. Every step in it is automated in compliant systems, so the business needs no programming expertise to issue a correct note. It is enough to enter the increase amount and select the original invoice, and the system handles the rest.
The reason for issuance and the note field (cbc:Note)
Electronic invoicing requires stating the reason for issuing the note. This reason explains why the correction was issued, and it usually appears in the note field at the document level cbc:Note or within the dedicated note reasons. The reason is a short, understandable text such as «increase in quantity on the original invoice» or «additional agreed-upon fees».
Clarity of the reason for issuance serves two purposes. The first is oversight: it makes it easier for the internal reviewer and the external auditor to understand the correction without referring to outside correspondence. The second is operational: it helps the accounts team track adjustments for a specific customer across periods. Write the reason in clear, concise language, and link it to the original invoice number so the context is complete.
Common errors in the debit note and how to avoid them
A few errors recur when issuing debit notes, and most of them lead to file rejection or to an incorrect accounting impact. Knowing them in advance saves you tiring correction cycles.
The first of the errors is using the wrong code. Writing 381 instead of 383 turns the document from an increase into a decrease, so its content contradicts its code. The second of the errors is the absence of the BillingReference block or its containing a wrong original invoice number, so the note becomes dangling with no original and is rejected. The third of the errors is a currency mismatch between the note and the original invoice, since the debit note must carry the same currency as the invoice it corrects.
The fourth of the errors is breaking the ICV counter sequence or an error in the PIH value, which is rare in compliant systems because they generate both fields automatically, but it appears with manual processing. The fifth of the errors is attempting to amend the original invoice instead of issuing a note, which is a conceptual error that violates the fundamental rule: an approved document is not amended but corrected by a subsequent document.
The best prevention against these errors is leaving the generation to a compliant accounting system. When you select the original invoice from the list, the system fills the reference block, carries over the correct currency, and computes the counter and hash, leaving you only to enter the value of the increase and its reason. This narrows the margin of error to the lowest possible level.
| Error | Impact | Prevention |
|---|---|---|
| Code 381 instead of 383 | Correction in the opposite direction | Select the correct document type in the system |
| Absent BillingReference | File rejection | Select the original invoice from the list |
| Currency different from the original | Mismatch and accounting distortion | Inherit the currency from the original invoice |
| Gap in the ICV | Broken issuance sequence | Automatic generation of the counter |
| Amending the original invoice | Violation of the no-amendment rule | Issue a debit note instead of amending |
A complete practical example of a debit note
Let us apply the above to a real case. A business issued an invoice worth SAR 1,000 before tax for a consulting service, then both parties agreed on additional hours worth SAR 200 that were not part of the original invoice. The invoice is approved and signed, so it cannot be amended. The solution is to issue a debit note carrying the increase amount of SAR 200 and its tax of SAR 30, and referencing the original invoice.
The system begins by generating document type code 383 in the header, then adds a BillingReference block carrying the original invoice’s number and date. Then it generates a new unique identifier UUID, computes the next counter value ICV in the business’s chain, and fetches the previous document’s hash PIH. Then it computes the tax on the increase amount alone in the TaxTotalblock. Finally it signs the file with the CSID certificate, generates the QR code, and sends it for clearance if it is business-oriented.
The result is an independent document with a total value of SAR 230 including tax, linked to the original invoice, raising the customer’s liability by the amount of the increase only. The original invoice remains as it is, untouched, and the debit note completes it. This separation between the two documents preserves the integrity of the record and shows the auditor that the increase is a documented correction, not tampering.
Special cases when issuing a debit note
You may issue more than one debit note on a single invoice over time. This is permitted, since each note carries its own number and unique identifier, and all of them reference the same original invoice via the BillingReferenceblock. Each note takes its place in the ICV counter sequence according to its issuance order, and carries the hash of the document immediately preceding it in the business’s chain, not necessarily the original invoice.
As for a currency difference, the rule is that the debit note inherits the currency of the original invoice. A debit note may not be issued in a currency different from the currency of the document it corrects, because that breaks the accounting match between the original and the correction. If the original invoice is in Saudi riyals, the debit note is in Saudi riyals. This inheritance happens automatically in compliant systems when the original invoice is selected.
Another case relates to the consumer-oriented debit note. This note is simplified, carrying document type code 383 with an attribute name of value 0200000, and it is delivered to the consumer immediately with a QR code, then reported within the specified window. The difference from the business-oriented note is that it does not wait for prior clearance, but is issued and reported afterward within twenty-four hours.
A reference summary of the debit note’s fields
The following table gathers the essential fields that distinguish the debit note, to serve as a quick reference while reading a file or diagnosing a rejection:
| Field | Function | Mandatory? |
|---|---|---|
cbc:InvoiceTypeCode |
Document type code (383) | Mandatory |
cbc:ID |
Commercial note number | Mandatory |
cbc:UUID |
The globally unique identifier | Mandatory |
cac:BillingReference |
Reference to the original invoice | Mandatory for the note |
cac:AdditionalDocumentReference (ICV) |
The sequential counter value | Mandatory |
cac:AdditionalDocumentReference (PIH) |
The previous document hash | Mandatory |
cbc:DocumentCurrencyCode |
The note’s currency | Mandatory |
cbc:Note |
The reason for issuance | Recommended |
Where does the debit note fit within the rest of the documentation series?
The debit note is an extension of the invoice structure, not a document independent of it. It shares nearly all the header fields with the invoice, adding to them its type code and its block referencing the original. It therefore helps you to master the header fields first before delving into the notes.
To review the header fields in detail, see the guide on Invoice Header in XML. And to understand the mechanism by which a document is approved via the platform before it is delivered to the customer, see the guide on Clearance in electronic invoicing. And for the full picture of the invoicing software and how it generates these documents automatically, see Qoyod electronic invoicing software.
The debit note is a precise tool for correcting invoices upward without touching the original document. Once you understand its code 383, its block referencing the original, its three identity fields, and its path through the platform, reading it and diagnosing any rejection in it becomes straightforward. The good news is that you write none of these fields manually: a compliant accounting system generates them according to the standard, and handles signing and integration with the Fatoora platform on your behalf in every note.
