Saudi E-Invoicing Phase 2: Integration and Incident Handling

What Changes on Your Integration Date

Phase 2 adds prescribed document data and formats, onboarding and submission to FATOORA. Standard tax invoices and associated notes normally require clearance before delivery to the buyer. Simplified invoices and their notes are generated and stamped by the compliant solution and reported within 24 hours of generation.

The obligation starts on the date applicable to the targeted taxpayer group, rather than on 1 January 2023 for every business simultaneously. Implementation Resolution First, Second and Sixth and the enforcement columns in its annexes must be read together. The overview explains person and transaction scope, including the exclusion for fully exempt supplies.

Establish the Wave and Preserve Earlier Duties

Use the actual ZATCA notification and the relevant public criteria. Resolution Sixth provides for notification at least six months before the due date. Test every specified reference year; current turnover alone is insufficient.

Wave 25 targets VAT-subject revenue exceeding SAR 187,500 in any of 2022–2025, with integration by 1 February 2027. That announcement does not defer an earlier obligation. A business that had already been targeted must assess its earlier date and any existing gaps. See the Wave 25 analysis for the threshold test and notification distinction.

Prepare Formats, Data and Document Routes

Annex One requires XML generation and transmission for integration. PDF/A-3 with embedded XML is an optional human-readable format for sharing with the customer; the FATOORA API submission is XML. A readable customer copy alone does not demonstrate successful integration.

Do not use a universal “nine fields on every QR code” rule. Annex One and Technical Guideline 6 identify document-specific treatment, including the optional public-key field for standard documents and the technical-CA signature field for simplified documents. Our solution-requirements guide explains the field distinctions.

Map Units Before Onboarding

The production credential must match the taxpayer, EGS unit and required document functions. An expired or revoked credential, or an incorrect functionality mapping, prevents compliant submission. Portal access does not establish that the production unit is onboarded.

Technical Guideline 3.5 provides the following architecture scenarios:

Accordingly, twenty checkout screens do not automatically mean twenty CSIDs. Nor does a central server justify sharing a credential across unrelated taxpayers or document sequences. Prepare a diagram identifying where documents are generated, signed and sent, and reconcile it with the actual onboarding design.

The portal supports OTP and identifier-management steps. Follow the technical onboarding sequence, including the required compliance checks and production credential process. The SDK and integration sandbox are useful testing tools; do not confuse optional pre-production tools with mandatory onboarding checks.

Read Responses Beyond the HTTP Status

Technical Guideline 4.3 distinguishes valid documents, accepted documents with warnings and invalid documents. An accepted warning is not a finding of full compliance. Investigate it and correct the underlying configuration for later documents; the reporting FAQ says not to resubmit an already accepted-with-warnings invoice merely because of that warning.

For standard clearance, retain the returned cleared document and stamp before ordinary buyer delivery. For a rejection, retain the error response and original generated-document integrity, correct the error and generate the required new document with fresh identifiers. A timeout is different from a validation rejection: retries of the same generated document should not be converted into duplicate sales.

If ZATCA disables clearance and returns the specified 303 response, the Technical Guideline directs standard documents to the reporting API. That is an authority-directed route. An individual taxpayer cannot elect it simply because ordinary clearance is inconvenient.

Preserve the Actual Generation Sequence

The previous-document hash refers to the immediately preceding generated document, not necessarily the most recent accepted submission. Keep rejected documents in the integrity trail, and do not reuse their UUID or counter value for a new document. Submission order and generation order are distinct; standard clearance timing still applies.

Dariba illustration: Documents A, B and C are generated in that order. B is rejected, while C has already been generated. A corrected new document D refers to C’s hash as its predecessor. It does not automatically refer to B merely because B contained the error. C’s own predecessor remains B. This illustrates Technical Guideline 4.3 and its rejection FAQs; it is our lettering of the sequence, not a verbatim official example.

For rejected simplified documents, the technical FAQs contain both a correction/resubmission answer that does not generally require another customer copy and a separate NOT_REPORTED answer referring to a credit note and new invoice. Those answers should not be collapsed into a universal instruction to cancel every rejected receipt. Identify the actual response and error, apply the relevant Article 54 correction rules and obtain ZATCA clarification where the differing instructions leave the procedure uncertain. Prevent duplicate revenue and preserve the audit trail.

Apply the Correct Outage Procedure

Resolution Seventh 5 requires notification of relevant incidents and their resolution, followed by prompt generation and integration of affected documents. Detailed Guideline section 10 distinguishes an authority outage, taxpayer connectivity failure and inability to generate invoices.

The official bank scenario mentions approximately five minutes before interim sharing and approximately fifteen-minute retries, but expressly marks those timings as to be confirmed. They are not fixed statutory waiting periods or a general permission to release rejected invoices. Its footnote treats the interim document as a VAT invoice pending prompt replacement with the compliant cleared document. The lawyer scenario separately addresses extended taxpayer connectivity failure and notification.

The simplified reporting limit remains 24 hours from generation. Weekends do not create an ordinary extension. Actual failures must nevertheless be analysed under the incident rules rather than ignored through a statement that outages can never affect the prescribed response. Retain evidence identifying whose system failed and what the business did.

Reconcile VAT and Keep the Archive

Technical failure does not extinguish output VAT on the underlying transaction. The Technical Guideline expressly separates payment of VAT from issuance of a valid invoice. Reconcile sales and the VAT return even while a document error is being resolved.

For a buyer, Resolution First 3 and VAT Implementing Regulations Article 49 require the applicable invoice and deduction evidence to be assessed together. A warning is not an automatic permanent denial of deduction; nor should the buyer disregard missing required clearance. Obtain the corrected evidence and examine the relevant period and conditions.

FATOORA’s stored copy does not replace the taxpayer’s archive. Resolution Fifth and VAT Article 66 govern records, access and retention, including the ordinary six-year minimum from the relevant tax period’s end and longer capital-asset rules. Maintain original generated documents, submissions, responses and correction links through migrations.

Confirm Readiness with Finance and the Vendor

Dariba recommends separate tests for invoice type, taxable treatment, buyer data, each production unit, standard clearance, simplified reporting, warnings, rejection sequences and genuine outages. Reconcile generated documents to accepted submissions and the tax return; investigate missing or duplicate references.

Review the penalty categories against any actual breach. The current waiver announcement excludes Article 45 fines, so an initiative end date is not a reason to defer integration or assume relief. These implementation controls support compliance; they do not certify a particular vendor or replace the current XML, Data Dictionary and Security Standards.