{"id":4202,"date":"2024-09-01T13:01:49","date_gmt":"2024-09-01T13:01:49","guid":{"rendered":"https:\/\/invoiceq.com\/%d9%85%d8%b1%d8%ad%d9%84%d8%a9-%d8%a7%d9%84%d8%b1%d8%a8%d8%b7-%d9%88%d8%a7%d9%84%d8%aa%d9%83%d8%a7%d9%85%d9%84-%d9%85%d8%b9-%d9%87%d9%8a%d8%a6%d8%a9-%d8%a7%d9%84%d8%b2%d9%83%d8%a7%d8%a9-%d8%a7%d8%b7\/"},"modified":"2025-10-07T13:00:04","modified_gmt":"2025-10-07T13:00:04","slug":"zatca-integration-phase-2-your-compliance-guide","status":"publish","type":"post","link":"https:\/\/invoiceq.com\/en\/e-invoicing-articles\/zatca-integration-phase-2-your-compliance-guide\/","title":{"rendered":"ZATCA Integration Phase 2: Your Compliance Guide"},"content":{"rendered":"\n

Intro<\/strong><\/h2>\n\n\n\n

ZATCA integration Phase 2<\/strong> is critical for organizations in Saudi Arabia as it mandates them to ensure that their ERP systems, accounting systems, and internal systems all adhere to the local tax regulations legislated by the authorized tax authorities; which in Saudi Arabia is managed by ZATCA. Consequently, this forces businesses that are included in any of the waves shared, so far by ZATCA, to take action and manage their integration process with the FATOORA platform properly.<\/p>\n\n\n\n

However, ZATCA integration Phase 2<\/strong> is a systematic process that requires some preparation before proceeding with the system integration part and the rest of the requirements needed to carry out the process known as onboarding with ZATCA<\/strong> which we have explained thoroughly in a previous article<\/a>. Nevertheless, we\u2019ll go over it real quick so you\u2019re able to follow on with us!<\/p>\n\n\n\n

Onboarding with ZATCA in A Nutshell<\/strong><\/h2>\n\n\n\n

Onboarding with ZATCA starts by accessing the FATOORA platform to request a new E-invoice Generation Solution also known as EGS. <\/strong>This step is usually handled without requiring technical skills as it\u2019s almost similar to creating an account and filling out any info needed. However, following this step is a whole different process that does indeed require technical assistance which InvoiceQ, of course<\/strong>, can offer. This ensures that businesses adhere to the technical requirements published for ZATCA integration Phase 2.<\/p>\n\n\n\n

The ultimate goal of the onboarding is to ensure the following requirements are met before proceeding with the rest of the invoice cycle integration process between InvoiceQ and ZATCA: <\/strong>
<\/span><\/span><\/div><\/h3>\n\n\n\n
    \n
  1. Successful generation of the CSR, and Private\/Public Keys [symmetric key].<\/strong><\/li>\n\n\n\n
  2. A signed compliance certificate, password, and request ID number.<\/li>\n\n\n\n
  3. Compliance testing of invoices with ZATCA.<\/li>\n\n\n\n
  4. Requesting the production certificate & password from ZATCA via the request ID to get the production certificate.<\/li>\n<\/ol>\n\n\n\n

    The invoice type is determined in the CSR to state whether it\u2019s a B2B invoice, a B2C invoice, or both types. For B2B and B2C invoices, testing requires issuing 3 invoices (one of each): <\/strong>
    <\/span><\/span><\/div><\/h3>\n\n\n\n

    1- A Normal Invoice.<\/strong><\/p>\n\n\n\n

    2- A Credit Note.<\/strong><\/p>\n\n\n\n

    3- A Debit Note.<\/strong><\/p>\n\n\n\n

    Upon gathering all mandated data, it\u2019s encrypted and saved in a vault to keep it from unauthorized access.<\/p>\n\n\n\n

    What Follows ZATCA Onboarding?<\/strong><\/h2>\n\n\n\n

    After finalizing the onboarding process with ZATCA which is the foundation for the rest, comes the process of having all systems communicate properly with one another through proper integration solutions. Thus, InvoiceQ ensures that all required keys and certificates obtained are valid, data is secure, and proper communication between the client’s system and the InvoiceQ system happens.<\/p>\n\n\n\n

    ZATCA relies on XML <\/strong>and generally speaking this is the preferred go-to in the fintech field due to the sensitive information it’s concerned with. ZATCA uses the Universal Business Language UBL 2.1<\/strong> invoice message XML;<\/strong> which is considered as a standard XML template that includes all invoice data and values to be added. This template is utilized by ZATCA, however, it’s not <\/strong>ZATCA-restricted as it follows globally <\/strong>enforced criteria and rules.<\/p>\n\n\n\n

    InvoiceQ generates the UBL invoice with the values received from the client. Upon the generation of the XML form, we get it through a validation phase for the first step to ensure that the XML structure is set properly.<\/p>\n\n\n\n

    This is to validate the technical specifications. After ensuring the technical validation part, we move on to ensure another type of validation which is the business validation. For business validation, we ensure that all required values such as tax number are correct before sending any invoice to ZATCA. The UBL entails a UBL extension which plays a big role in setting our security measures.<\/p>\n\n\n\n

    How Do We Handle The Security Part?<\/strong><\/h2>\n\n\n\n

    Through the XML invoice, we do Hashing; which is used to implement one-way encryption. This is to ensure that the data in question didn\u2019t go under any modifications or manipulation. Each XML is compressed into a hash string, which in turn means that each invoice has a unique hash.<\/p>\n\n\n\n

    After generating the hash from our side, ZATCA performs the same process and then checks if the hashes on both sides match to eliminate any tampering attempt.<\/p>\n\n\n\n

    The hash is then signed by the private key to generate the digital signature. The purpose of this step is to ensure that the EGS has been issued by the right person and that it has not been manipulated by anyone else. In other words, increased security.<\/strong><\/p>\n\n\n\n

    After that, InvoiceQ generates the EGS certificate Hash using the SHA-256 algorithm to make sure that the issued invoice from the EGS uses the certificate that we have acquired during the onboarding process.<\/p>\n\n\n\n

    Following this is the process of populating the signed properties that we have generated in the previous steps, having them hashed again, and then populating them inside the UBL extension tags.<\/p>\n\n\n\n

    Additionally, each invoice would have a unique hash to identify as well as another one to refer back to the preceding invoice. The purpose of this is to verify the identity of the sender through another added security layer. As a result, this ensures:<\/mark><\/strong><\/p>\n\n\n\n

    – The sequencing.<\/strong><\/p>\n\n\n\n

    – The request is not manipulated.<\/strong><\/p>\n\n\n\n

    – The identification if the sender for each invoice matches or not.<\/strong><\/p>\n\n\n\n

    – Another layer of protection through the preceding invoice hash.<\/strong><\/p>\n\n\n\n

    B2B VS B2C Invoices: How Does it Happen?<\/strong><\/h2>\n\n\n\n

    This process applies to invoices whether they’re B2B or B2C. Nevertheless, a slight difference should be considered.<\/p>\n\n\n\n

    In B2B <\/strong>invoices, it’s not mandatory (optional)<\/strong> for the cryptographic stamp or QR code to be sent to ZATCA as it’s not allowed for the business to issue any invoice unless it’s approved by ZATCA in the first place<\/strong> since part of ZATCA\u2019s response is to add\/modify cryptographic stamps and QR codes. In other words, it is a sync approach where the business can’t send the invoice to the customer unless it’s approved by ZATCA first.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    In B2C invoices, an async approach is implemented where the cryptographic stamp or QR code for the invoice is generated from the business side before sharing it with ZATCA and sending the invoice within 24 hours. <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The Major Difference Between B2B & B2C is:<\/strong><\/h3>\n\n\n\n