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.

The commencement date for Phase II of e-invoicing in KSA is set for January 1, 2023.

In addition to the Phase 1 requirements outlined here, starting on January 1, 2023, Phase 2 will be implemented in waves, and taxpayers should adhere to the following: 1. Use a compliant invoicing solution that meets Zatca E invoicing requirements, which includes: - The capability to generate and store e-invoices in the required formats (XML) or (PDF/A3 with embedded XML) containing the necessary fields. - Ensuring that the e-invoicing solution is compliant with all e-invoicing requirements, including the ability to connect to the internet. 2. Integrate the e-invoicing solution with ZATCA's Fatoora portal.

Phase II of ZATCA E invoicing will be rolled out in waves, commencing on January 1, 2023, targeting specific groups of taxpayers. These groups will receive notification of the system's new requirements at least six months prior to their respective implementation dates. ZATCA has accordingly notified the waves, as indicated in the table below:

You should review the Dictionary & Data implementation rules , along with ensuring compliance with the current e-invoicing regulations.

All data fields visible in the human-readable form of the invoice must be in Arabic as per VAT Regulations, which mandate that Tax Invoices and Simplified Tax Invoices (including associated credit notes or debit notes) must be exclusively in Arabic. However, invoices can also be bilingual, including English.

ZATCA E invoicing Phase 2 primarily focuses on integration. Taxpayers subject to these regulations must integrate their systems with ZATCA's through e-invoicing solutions. Each invoice will require approval from ZATCA, which will affect various aspects of your invoice generation process, including printing, presentation, reporting, auditing, and VAT return filing. Preparing for Phase II may necessitate substantial process adjustments, particularly if your existing e-invoicing system isn't Phase 2-ready. Collaboration between both business and IT teams will be essential for successful implementation.

You should correct the invoice according to the identified issue and resubmit it to ZATCA. While sharing the corrected invoice with the buyer is optional, it's advisable to do so for reconciliation purposes.

A tax invoice needs to be created for the balance amount after adjusting advances. Also, a tax invoice should be created when receiving the advance payment.

The ApiZatca solution is compatible for integration with any in-house ERP or POS system. For more information, please contact us.

Standard tax invoices: Standard tax invoices and associated Credit Debit Notes (CDNs) must be promptly uploaded to the ZATCA Platform for real-time clearance. Upon successful clearance, ZATCA will issue a cryptographic stamp in real-time. Your e-invoicing solution should generate a QR code (containing specific ZATCA-required fields), which must be included in the standard tax invoice. You can share these invoices with your customers only after they have been successfully cleared and a valid QR code has been generated. As a result, all standard tax invoices must be uploaded to ZATCA in real-time. Simplified tax invoices: Simplified tax invoices and related CDNs can be generated, printed, and electronically shared through your e-invoicing solution without ZATCA's direct involvement. However, these simplified tax invoices and related CDNs must be reported to the authority within 24 hours of their creation. After being uploaded to ZATCA, simplified electronic invoices will undergo validation by ZATCA, and you will receive an acknowledgment as the API response.