How to Switch Accounting Software Without Breaking Your CSID



Switching your accounting system under Phase 2 of Saudi Arabia's e-invoicing regulations without a clear operational plan means an immediate break in your cryptographic Hash Chain — exposing your business to automatic invoice rejection and compliance penalties. The core rule is that the Cryptographic Stamp Identifier (CSID) cannot be transferred between systems.

It must be decommissioned for the old solution via the Fatoora portal, and a new one issued for the new system using a one-time password (OTP). The real secret to a safe migration is carrying over the hash of your last approved invoice (Previous Invoice Hash – PIH), so the first invoice in your new system links seamlessly to the historical chain registered with the Zakat, Tax and Customs Authority (ZATCA).

This guide walks you through the full process, the risks to avoid, and how Wafeq compresses the entire migration into minutes.

• What the CSID is — and why it inevitably "breaks" when you change accounting software.
• The critical difference between orderly manual revocation and automatic revocation by ZATCA (and which one protects you).
• The safe migration roadmap: three practical, approved steps from decommissioning the old system to activating the new one.
• Risk comparison table: traditional manual migration vs. the automated transition via Wafeq.
• Why Wafeq customers stay calm: a migration experience that doesn't require an IT team.

What Is the CSID — and Why Does It Break When You Change Accounting Systems?

The Cryptographic Stamp Identifier (CSID) is the digital and legal identity that ZATCA grants to your organization's E-invoicing Generation Solution (EGS). It functions as a security certificate built on Public Key Infrastructure (PKI), digitally signing every invoice you issue to prove its origin and guarantee that its financial data and timestamps cannot be tampered with after issuance.

When you make the strategic decision to move from a legacy ERP or desktop accounting system to a modern cloud solution, the software environment that generates and signs your invoices changes. From both a cryptographic and regulatory standpoint, the private key created in the old system's environment cannot be moved to the new one; ZATCA's technical specifications require new keys and certificates for each independent operating environment.

The unavoidable consequence: changing your accounting software means revoking the old CSID and generating a new one — and the real challenge is doing so without breaking your invoice sequence in ZATCA's eyes.



Manual Revocation vs. Automatic Revocation by ZATCA

There are two ways a CSID goes out of service, and the difference between them is the difference between a controlled transition and a stained compliance record:

1. Orderly manual revocation (EGS Decommissioning): The officially recommended path. Your organization proactively submits a decommissioning request for the old invoicing solution through the Fatoora portal, formally notifying ZATCA that the system has left service. This precisely records the decommissioning date in your compliance history and protects you from any unauthorized use of the old identifiers.
2. Automatic revocation or suspension by ZATCA: Triggered when the Authority's servers detect anomalous behavior — such as invoices carrying the same identifier arriving from two different environments simultaneously, attempts to sign with an expired certificate, or a serious break in the cryptographic chain. This path means immediate rejection of invoices submitted via API, and can place your business under audit scrutiny as an operationally non-compliant entity.

B. The Risk of Breaking the Hash Chain During Data Migration

Phase 2 relies on a cryptographic Hash Chain that links your invoices to one another in a tamper-proof sequence: every new invoice carries the hash of the invoice immediately before it, in a field called the Previous Invoice Hash (PIH). The most expensive mistake during a system change is failing to carry over the hash of the last approved invoice from the old system. If the new system starts issuing invoices with a default or empty PIH value, the chain breaks instantly on ZATCA's side, resulting in:

• Automatic rejection of tax invoices (B2B) submitted for Clearance.
• Compliance warnings and errors on simplified invoices (B2C) submitted for Reporting.
• Complications with returns: the system becomes unable to link credit and debit notes to historical invoices issued in the previous environment.

For the detailed rules on handling returns without disrupting the chain, see our guide on: How to handle credit notes in KSA e-invoicing.

How to Migrate to a New System Without Breaking the CSID (The Practical Steps)

To execute a smooth transition that fully complies with ZATCA's requirements — without pausing sales — follow this approved methodology in exact order:

1. Decommission the old system's EGS identifier via the Fatoora portal.
2. Carry over the last invoice hash (PIH) from the old system to the new one.
3. Generate a new OTP and activate the Production CSID for the new system.

Step One: Decommission the Old E-invoicing Solution (EGS) via ZATCA's Fatoora Portal

Before setting up the new system, close out the old one in an orderly way:

1. Freeze financial activity: Stop entering new transactions in the old system, and export final sales reports and tax filings for the period.
2. Log in to the Fatoora portal: Use your organization's ZATCA credentials.
3. Locate the solution unit: Navigate to the list of registered E-invoicing Generation Solution (EGS) units.
4. Submit the decommissioning request: Select the old system's identifier, choose the deactivate/decommission option, and confirm.
5. Keep the evidence: Save the decommissioning confirmation issued by the portal in your internal audit files — it is your official proof in any future review.

Step Two: Link the Last Invoice from the Old System (Previous Invoice Hash – PIH) to the New System

This is the pivotal step that prevents the chain from breaking:

1. Extract the final invoice file: The last invoice successfully issued and approved by ZATCA from the old system (as XML or from the specialized technical report).
2. Copy the cryptographic value (PIH): A Base64-encoded string belonging to that invoice.
3. Enter it in Wafeq: In the e-invoicing setup panel, paste the value into the "Previous Invoice Hash" field.
4. Lock in the cryptographic reference: Wafeq automatically applies this value when generating the first invoice from the new system, so the chain continues on ZATCA's side as if nothing changed.

Step Three: Generate a New OTP and Activate the Production CSID for Wafeq

1. Request a new OTP: In the Fatoora portal, select Onboard New Solution Unit/Device, specify the number of devices, and generate the OTP code.
2. Copy the code immediately: It has a short validity window.
3. Paste it into Wafeq: In the Fatoora connection settings inside your dashboard, paste the code and click Connect.
4. Let the system handle the rest: Wafeq creates the encryption keys and Certificate Signing Request (CSR) behind the scenes, communicates directly with ZATCA's servers, receives the Compliance Certificate followed by the final Production CSID, and shows you an on-screen connection success confirmation.



For an illustrated, step-by-step walkthrough of entering codes and confirming the connection, see our full guide:

How to connect your accounting system to the Fatoora portal: step-by-step

The Risks of Improper Migration — and How Wafeq Protects You



How Wafeq Makes Migration Painless — No Errors, No Penalties

Every finance leader who has lived through a system change knows this truth: the technical complexity is not the real problem — the anxiety is. The worry about a rejected invoice reaching a customer, an unexpected fine, a full week with invoicing frozen. Wafeq was built to take all of that off your desk.



1. A Guided Fatoora Connection — No IT Team Required

Forget generating encryption keys and Certificate Signing Requests (CSR) through complex command-line tools. In Wafeq, the process starts right from your account settings: you fill in your company details (trade name, VAT number, national address) in clear forms in both Arabic and English, then paste the OTP code issued by the Fatoora portal — and that's it. The system communicates with ZATCA's servers, receives and activates your digital stamp, and displays an instant on-screen success confirmation. It's a process an accountant finishes over a single cup of coffee — no support ticket, no developer.

2. Chain Continuity You Never Have to Think About (Instant PIH Mapping)

Instead of hunting for cryptographic values inside XML files, Wafeq gives you a clearly labeled "Previous Invoice Hash" field in the e-invoicing settings. Paste the value from your old system's final invoice once, and Wafeq automatically embeds it into the first invoice it issues — your cryptographic chain continues in ZATCA's records without a single gap. You copy and paste; the system guarantees compliance.

3. Pre-Validation That Stops Rejections Before They Happen

The worst moment in any accountant's day: a rejection message from ZATCA for an invoice already delivered to the customer. Wafeq prevents that scenario at the source with a pre-validation engine that reviews every invoice before submission — VAT numbers, national addresses, tax rates, and the required XML structure. If anything is missing, a clear message tells you exactly what to fix before the invoice leaves your system, not after it hits ZATCA's servers.

4. Full Flexibility When Your Company Details Change Later

Migration doesn't end on activation day. If you later need to update your trade name, VAT number, or registered address, Wafeq lets you disconnect from the ZATCA integration and reconnect yourself directly from your organization settings — no waiting on support, no disruption to operations. That operational flexibility is what separates a system that is "compliant on paper" from one genuinely designed for how real businesses change.

Read Also: Post-Integration Audits: Key KPIs to Track Your Success on the ZATCA Fatoora Portal

Upgrading your accounting stack or moving to a modern cloud system should be a growth milestone — not a source of anxiety about tax violations. With a precise understanding of how the CSID works, and a methodical approach to preserving your Hash Chain, your business can execute the transition safely and in record time.

FAQs about Changing Accounting Systems and the CSID

Do I need to notify ZATCA when changing accounting software?

Yes — and the notification happens through two technical actions: decommissioning the old system's EGS identifier on the Fatoora portal, then generating a new OTP to register the new system and obtain a fresh CSID. There is no separate paper notification form; the portal actions themselves constitute the official notice.

What happens if the Hash Chain breaks during migration?

ZATCA's servers reject B2B tax invoices submitted for Clearance and flag compliance errors on B2C simplified invoices submitted for Reporting. Fixing it requires re-entering the hash of the last approved invoice (PIH) in the new system's settings to restore chain consistency before invoicing resumes.

Are old invoices lost when the previous CSID is revoked?

No. Decommissioning only stops the old system from issuing new invoices — it does not affect the legality of invoices already issued. Your business remains obligated to archive old invoices (in XML and PDF/A-3 formats) for the statutory retention period set out in the executive regulations, which is no less than six years for most establishments.

How long does it take to obtain a new CSID for Wafeq from ZATCA's portal?

Just a few minutes. Once you paste the OTP code from the Fatoora portal into Wafeq's settings, the system automatically communicates with ZATCA's servers, generates the cryptographic certificates, receives the approved Production CSID, and shows an instant on-screen connection confirmation.

How can I verify that the last invoice migrated correctly from the old system?

By matching the hash value of the final invoice issued from the old system against the Previous Invoice Hash (PIH) field recorded in the first invoice created in the new system. Wafeq runs this check automatically before issuing the first invoice, so nothing is sent to ZATCA until the chain is confirmed intact.