Direct Answer / Quick Summary:

Under Saudi Arabia's ZATCA Phase 2 E-Invoicing mandate, issued electronic invoices can never be edited, deleted, or retroactively cancelled. Any post-issuance financial adjustment—such as merchandise returns, agreed rebates, pricing errors, or supplementary billings—must be executed exclusively through an electronic Credit Note (*Ish'ar Da'in* / إشعار دائن) or Debit Note (*Ish'ar Madeen* / إشعار مدين).

Mandatory Reference Linkage (`BR-KSA-70`): Every credit or debit note must be cryptographically and structurally linked to the original tax invoice. The UBL 2.1 XML must contain a `<cac:BillingReference>` element embedding the original invoice's unique RFC 4122 UUIDv4*, commercial serial number, and original issue date.

Inherited Clearance vs Reporting Rules: Adjustment notes inherit the exact integration pathway of the parent invoice. A credit note adjusting a Standard B2B Invoice must undergo real-time pre-clearance via `/invoices/clearance/single`; a credit note adjusting a Simplified B2C Invoice must be reported to `/invoices/reporting/single` within 24 hours*.

Independent Counter & Hash Chaining: A credit or debit note is an independent legal document. It receives its own next sequential Invoice Counter Value (ICV) and embeds the SHA-256 hash of the immediately preceding invoice (PIH)*, maintaining uninterrupted cryptographic chain continuity.

The Legal Mandate: Articles 40, 53 & 54 of the VAT Regulations

Under the Saudi VAT Implementing Regulations, taxable entities are legally prohibited from modifying accounting ledgers retroactively.

Article 40 defines the strict statutory grounds under which an enterprise may adjust the tax liability declared on an original tax invoice:

Total or partial cancellation of a commercial contract or supply of goods.
Documented physical return of defective, damaged, or unaccepted goods.
Agreed retroactive commercial discounts, trade rebates, or volume allowances.
Material clerical or mathematical errors in the unit price or tax rate calculation.
Stage 01Original UUID Generated

Original Sale Finalized

Standard B2B invoice cleared by ZATCA and delivered to corporate buyer

Stage 02Legal Justification

Dispute / Return Occurs

Buyer returns 30% of inventory; parties agree on financial downward adjustment

Stage 03Linked Architecture

Credit Note Generation

ERP generates UBL 2.1 Credit Note (Type 381) embedding original invoice UUID

Stage 04Real-Time Clearance

ZATCA Clearance Engine

Credit Note clears in real time; ZATCA ledger automatically reduces seller output VAT

Stage 05Tax Ledger Balance

VAT Return Reconciliation

Adjustment reflected automatically in quarterly VAT Return Line 1 (Standard Rated Supplies)

Architectural Taxonomy: Credit Notes (381) vs Debit Notes (383)

ZATCA enforces international OASIS UBL 2.1 document types to distinguish between downward and upward ledger adjustments:

Architectural DimensionCredit Note (Ish'ar Da'in)Debit Note (Ish'ar Madeen)
Document Type Code<cbc:InvoiceTypeCode>381</cbc:InvoiceTypeCode><cbc:InvoiceTypeCode>383</cbc:InvoiceTypeCode>
Financial NatureDownward Adjustment (Decreases receivable / payable).Upward Adjustment (Increases receivable / payable).
Common Business TriggersCustomer returns, post-sale discounts, billing overcharges.Post-sale freight additions, under-billed quantities, price increases.
Output VAT ImpactReduces Seller Output VAT owed to ZATCA.Increases Seller Output VAT owed to ZATCA.
Input VAT ImpactReduces Buyer Input VAT deduction entitlement.Increases Buyer Input VAT deduction entitlement.
Root XML Element<CreditNote> or <Invoice><DebitNote> or <Invoice>
Mandatory Reference<cac:BillingReference> linking original UUID.<cac:BillingReference> linking original UUID.

Technical Anatomy of Mandatory Reference Linkage (BR-KSA-70)

The single most common rejection error encountered by enterprise developers when issuing credit notes is `BR-KSA-70: A credit or debit note must reference the invoice that is being amended.`

In the UBL 2.1 XML schema, the adjustment note must inject the parent document's metadata inside the <cac:BillingReference> block immediately following the invoice type definition:

xml|Technical Specification / Reference
Verified Schema
<!-- MANDATORY ORIGINAL INVOICE LINKAGE -->
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <!-- 1. Original Commercial Serial Number -->
    <cbc:ID>INV-2026-00842</cbc:ID>
    
    <!-- 2. Original Invoice RFC 4122 UUIDv4 (CRITICAL) -->
    <cbc:UUID>c4a1e9b2-3f84-4e91-8a62-1029481bc39a</cbc:UUID>
    
    <!-- 3. Original Invoice Issue Date -->
    <cbc:IssueDate>2026-01-15</cbc:IssueDate>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>
Mandatory Regulatory Requirement

Strict Validation of the Original UUID:

When a Standard B2B Credit Note is submitted to ZATCA's live clearance API, ZATCA's database cross-references the <cbc:UUID> against its historical clearing ledger. If the referenced UUID does not exist, belongs to a different taxpayer TRN, or was previously cancelled, the credit note is rejected with HTTP 400 Bad Request: Original Invoice Not Found.

Mandatory Instruction Note: Stating the Reason for Adjustment

Under Schematron business rule `BR-KSA-72`, every credit or debit note must articulate a clear legal reason for the adjustment. This justification must be injected inside <cac:PaymentMeans> under <cbc:InstructionNote>:

xml|Technical Specification / Reference
Verified Schema
<!-- MANDATORY REASON FOR ADJUSTMENT -->
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>10</cbc:PaymentMeansCode>
  <cbc:InstructionNote>Defective goods return - 40 units of Model X4 damaged during transit. Agreed credit agreement #CR-912.</cbc:InstructionNote>
</cac:PaymentMeans>

Acceptable standard reasons recognized during tax audits include:

Cancellation of commercial contract before fulfillment.
Return of damaged or non-conforming merchandise.
Agreed retrospective volume rebate for Q4 commercial target.
Correction of unit price calculation error on original line items.

Financial Arithmetic & Line Item Restrictions

Developers must adhere to strict mathematical constraints when building adjustment payloads:

Statutory Safeguards & Rights Protection

Mandatory protections enforced by MHRSD & Saudi Labor Law

1
No Negative NumbersZATCA strictly prohibits negative numeric values inside line-item price tags (<cbc:PriceAmount>) or quantity tags (<cbc:InvoicedQuantity>). All quantities and amounts inside a Credit Note must be positive integers or decimals; the document type '381' inherently signifies deduction.
2
Value Cap RestrictionA Credit Note cannot exceed the monetary value or quantity of the original invoice. Attempting to credit SAR 15,000 against an original invoice of SAR 10,000 results in immediate Schematron rejection.
3
Partial Credits PermittedEnterprises may issue multiple partial credit notes against a single parent invoice, provided the cumulative sum does not exceed the parent invoice's total taxable amount.
4
Tax Category MatchingCredit note lines must inherit the exact VAT Category Code (e.g., 'S' for Standard 15%, 'Z' for Zero-rated) used in the original transaction.

Complete Working UBL 2.1 XML Credit Note Snippet

The following excerpt demonstrates the core structure of a ZATCA-compliant Phase 2 Credit Note:

xml|Technical Specification / Reference
Verified Schema
<?xml version="1.0" encoding="UTF-8"?>
<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
            xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
            xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:ID>CN-2026-00041</cbc:ID>
  <cbc:UUID>8e1f4a9b-2c34-4d81-9f62-71029481bc5e</cbc:UUID>
  <cbc:IssueDate>2026-02-07</cbc:IssueDate>
  <cbc:IssueTime>11:20:00</cbc:IssueTime>
  <cbc:CreditNoteTypeCode name="0100000">381</cbc:CreditNoteTypeCode>
  
  <!-- Billing Reference to Original Cleared Invoice -->
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>INV-2026-00842</cbc:ID>
      <cbc:UUID>c4a1e9b2-3f84-4e91-8a62-1029481bc39a</cbc:UUID>
      <cbc:IssueDate>2026-01-15</cbc:IssueDate>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>

  <!-- Sequential Counter & Hash Chain -->
  <cac:AdditionalDocumentReference>
    <cbc:ID>ICV</cbc:ID>
    <cbc:UUID>1043</cbc:UUID>
  </cac:AdditionalDocumentReference>
  <cac:AdditionalDocumentReference>
    <cbc:ID>PIH</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
        bWVMZXhlMjAyNmhhc2hvZnByZXZpb3VzaW52b2ljZTMyeWVz==
      </cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>

  <!-- Adjustment Justification -->
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
    <cbc:InstructionNote>Customer return: 10 units defective hardware.</cbc:InstructionNote>
  </cac:PaymentMeans>

  <!-- Financial Tax Summary -->
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="SAR">150.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="SAR">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="SAR">150.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>15.00</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>

  <!-- Credited Line Item -->
  <cac:CreditNoteLine>
    <cbc:ID>1</cbc:ID>
    <cbc:CreditedQuantity unitCode="PCE">10</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="SAR">1000.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Network Switch 24-Port Gigabit</cbc:Name>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="SAR">100.00</cbc:PriceAmount>
    </cac:Price>
  </cac:CreditNoteLine>
</CreditNote>

Real-World Case Study: Handling a SAR 120,000 Industrial Equipment Return in Jeddah

In December 2025, a heavy machinery importer in Jeddah supplied 3 industrial generator sets valued at SAR 120,000 + 15% VAT (SAR 18,000) to an infrastructure contractor:

The Problem: Upon site delivery, one generator set (valued at SAR 40,000 + SAR 6,000 VAT) failed field commissioning and was rejected.
The Compliant Resolution:

1. The supplier's ERP located the original cleared invoice UUID (f72b...) issued two weeks earlier.

2. The system generated Credit Note CN-2026-0012 specifying <cbc:CreditedQuantity>1</cbc:CreditedQuantity> with line extension SAR 40,000 and VAT SAR 6,000.

3. The credit note inherited sequential counter ICV = 412 and embedded the hash of transaction 411.

4. The document cleared through /invoices/clearance/single within 1.1 seconds.

5. The contractor received the cleared PDF/A-3 credit note, allowing both parties' accounting ledgers to reconcile their VAT returns without discrepancy.

Common Credit & Debit Note Rejection Codes & Developer Fixes

Schematron CodeUnderlying ErrorImmediate Developer Remedy
`BR-KSA-70`Missing <cac:BillingReference> structure.Inject <cac:InvoiceDocumentReference> with valid original ID, UUID, and IssueDate.
`BR-KSA-71`Original invoice UUID syntax is invalid or not RFC 4122 Version 4.Verify that the referenced UUID contains exact 36-character hyphenated UUIDv4 syntax.
`BR-KSA-72`Missing adjustment reason text.Add <cbc:InstructionNote> inside <cac:PaymentMeans> explaining the adjustment.
`BR-KSA-73`Negative values passed in line amounts or quantity tags.Convert all quantities and unit prices to positive positive values; document type handles sign.
`400 Bad Request`Referenced invoice UUID belongs to a different VAT registration number.Verify your multi-tenant ERP database logic; ensure the parent invoice belongs to the same seller TRN.

Frequently Asked Questions (FAQ)

Can an enterprise delete an erroneous invoice instead of issuing a Credit Note?

No. Under Saudi tax law and ZATCA Phase 2 tamper-proofing rules, electronic invoices can never be deleted or removed from the database. Any error must be rectified by issuing a formal Credit Note (for cancellations/rebates) or Debit Note (for upward corrections).

What happens if I issue a Credit Note against an un-cleared invoice?

A Credit Note can only reference an invoice that has already been successfully cleared (for B2B) or reported (for B2C). Attempting to clear a credit note referencing an un-cleared or rejected UUID will result in immediate API rejection.

Does a Credit Note have its own QR Code?

Yes. On Simplified (B2C) Credit Notes, a complete Phase 2 cryptographic QR code must be printed on the credit receipt, encoding all 9 mandatory TLV tags reflecting the credited financial values.

Can a single Credit Note adjust multiple original invoices?

Under ZATCA Phase 2 UBL 2.1 specifications, each Credit Note should reference a single original invoice via its primary <cac:BillingReference> to preserve clean one-to-one audit traceability in tax reconciliation ledgers.

How do Credit Notes affect the quarterly VAT return filed on ERAD?

Credit Notes automatically reduce the taxpayer's declared Output Tax on Line 1 of the VAT return, while Debit Notes increase declared Output Tax. During ZATCA audits, the total values declared on Line 1 are automatically cross-checked against cleared credit and debit notes on the Fatoora Portal.