Full assistance to comply with all ZATCA regulations

No, as specified in the table provided under paragraph 7.3 of XML Implementation Standard, there are no

restrictions on the decimal places for Unit Price.

Yes, as long as the submitting device includes the CSID of the device that applied the stamp to the document. It is advisable for each Electronic Government System (EGS) to have the capability to independently submit documents to ZATCA.

An error is a validation failure associated with a rejected document, while a warning is a validation failure associated with an accepted document. If a submitted document has even one error, it will be rejected entirely.

Document 4 (Re-submission of Document 2 after addressing errors) this new document should indicate the

Previous Document Hash as the hash of the document that was generated immediately before the resubmitted document and not of the document that was generated before the original rejected document.

For example, consider the scenario:

• Document 1 is submitted and accepted

• Document 2 is submitted and rejected

• Document 3 is submitted and accepted

• Document 4 (Resubmission of Document 2 after addressing errors)

In this case the Previous Document Hash of the Resubmitted document should be the hash of Document 3 and not Document 1.

Note that the ZATCA's platform will be storing and tracking the hash of rejected documents as well.

Accordingly, in the example above Document 3 should have its Previous Invoice Hash as the hash of Document 2 even though it was rejected.

Invoice counter value should not be re-used. Once a document is generated with an Invoice Counter Value (ICV), then that ICV cannot be mentioned on another document. A new document should have its own ICV.

In case of Simplified Tax Invoices, if the reporting fails, then the taxpayer must correct the error from to prevent it from happening on subsequent documents.

The error in rejected document can be rectified and a new document can be submitted for Reporting. As the invoice would have already been issued to customer, there is no need to issue another invoice (in most cases customer may not be available to share the invoice again and therefore such a requirement would be impractical). Transaction should be included in monthly or quarterly VAT return submission. Intention is not to stop B2C transactions for technical failures or errors in XML documents.

There is no dependency on ZATCA's clearance for generating new invoice. ZATCA's stamp or QR Code string is not part of the Hash. Taxpayers can continue generating invoices without waiting for Clearance from ZATCA as Clearance does not change the hash of the document.

Billing Reference ID is the link to Original Invoices for which Debit and Credit Note is generated. It is a mandatory field. As per Article 54 of KSA VAT Regulations, every Debit and Credit Note should refer to Original Invoice that it relates to.

OTP are valid for 1 hour from the date of her generation

Email notifications will be sent to the Taxpayer once the status of an EGS Unit changes. In addition, Taxpayers can view the status of their EGS Unit(s) through the summary list of onboarded EGS Unit(s) that is a part of the FATOORA Portal. Once an EGS Unit has been onboarded, renewed or revoked, the respective fields of the list are updated to reflect the status accordingly.

A certificate signing request (CSR) is one of the first steps towards getting the EGS's own Cryptographic Stamp Identifier (Certificate). It includes the following:

• Common Name: Name or Asset Tracking Number for the Solution Unit

• EGS Serial Number: Manufacturer or Solution Provider

• Name, Model or Version and Serial Number

• Organization Identifier: VAT or Group VAT Registration Number

• Organization Unit Name: Organization Unit

• Organization Name: Taxpayer Name

• Country Name

• Invoice Type: Standard, Simplified or both

• Location: Location of Branch or Device or Solution Unit

• Industry: Industry or location

A CSID is technically a cryptographic certificate, which is a credential that allows for authenticated signing and encryption of communication. The certificate is also known as a public key certificate or an identity certificate. It is an electronic document used as proof of ownership of a public key.

A CSID is used to uniquely identify an Invoice Generation Solution Unit in possession of a Taxpayer for the purpose of stamping (technically cryptographically signing) Simplified Invoices (B2C) and for accessing the Reporting and Clearance APIs.

A Production CSID is a CSID that is used by the EGS to call the core e-invoicing production APIs such as reporting, clearance, etc. This CSID is generated by ZATCA CA and returned to the EGS which it can use to invoke the aforementioned APIs.

Additionally, the Production CSID is added as a request header and also is used to authenticate and authorize the EGS.

A Compliance CSID is a CSID that is used by the EGS to call the compliance APIs and perform compliance checks, specifically the Compliance CSID is added as a request header when calling those APIs.

Moreover, the Compliance CSID is generated by the e-invoicing platform itself rather than ZATCA CA since it is used only to ensure the compliance of the EGS with ZATCA specifications.

After an invoice gets rejected UUID and ICV should not be re-used. System should assign a new ICV when the

document is submitted after fixing errors.

In case of reporting rejection from ZATCA, the taxpayer can fix the error and re-submit the Simplified Tax Invoice for reporting.

The new invoice should include its own new unique hash, UUID, invoice counter value and timestamp. The date on invoice should remain as when transaction took place. Previous Invoice Hash will be based on immediately preceding document (not necessarily linked to the rejected invoice).

In case of clearance rejection from ZATCA, the taxpayer can fix the error and re-submit the Standard Tax Invoice for clearance.

The new invoice should include its own new unique hash, UUID, invoice counter value and timestamp. The date on invoice should be updated as non-cleared invoice is not considered as a valid Tax Invoice from ZATCA’s perspective.

Previous Invoice Hash will be based on immediately preceding document (not necessarily linked to the rejected invoice).

In case of any incidents, technical errors, or emergency matters in your E-Invoicing solution which hinder the

generation of Electronic Invoices or Electronic Notes, taxpayers are required to notify ZATCA using the service https://zatca.gov.sa/en/E-Invoicing/FailureNotifications/Pages/VerifyTaxpayer.aspx

Once the system failure is resolved, all the transactions that took place during the system downtime should be cleared/reported in compliant XML format.

There are no limitations on the sequence of uploading or submitting invoices to ZATCA, it can be uploaded in any order so long as they are generated in a sequence.

Sequence will be validated only in backend (and not real-time validation at the time of receiving invoices).

For example, if invoices 1, 2 and 3 were generated in sequence they can be submitted as 3, 1 and 2, while keeping in mind Clearance requirements for standard invoices.

Any gaps identified in the sequence during backend validation will be subject to further investigation by ZATCA and may result in penalties if found to be non-compliant.

No, you should not resubmit an invoice for which the response was “202 - Accepted with warnings” as it has been accepted by ZATCA. However, the warnings should be investigated and resolved at the earliest.

Repeated non-compliance (that result in warnings) will be investigated by ZATCA and may be subject to applicable penalties.