Direct Answer / Quick Summary:

To eradicate tax evasion, phantom billing, and secondary parallel accounting ledgers (Al-Dafātir Al-Muzdawajah), the Zakat, Tax and Customs Authority enacted strict Anti-Tampering and Software Architecture Regulations under Phase 2 of the Saudi E-Invoicing mandate.

The Core Prohibited Capabilities: Software developers and enterprise IT teams are legally forbidden from deploying billing solutions that support: (1) Manual editing, deletion, or overwriting of issued invoices; (2) Uncontrolled sequential counter resets; (3) Multiple simultaneous sequence counters on a single EGS unit; (4) Plaintext extraction or network export of EGS private keys; (5) System clock manipulation; (6) Absence of cryptographic hash chaining; and (7) Hidden training, demo, or secondary offline cash modes*.

Statutory Penalties: Incorporating or utilizing prohibited functions is classified as willful tax fraud under Article 40 of the Saudi VAT Law (Royal Decree No. M/113), carrying fines up to 25% to 100% of the unpaid tax difference, minimum procedural fines up to SAR 50,000*, immediate establishment closure, and criminal prosecution.

Joint Vendor Liability:* ERP vendors and software houses that deliberately program prohibited features face permanent revocation of their ZATCA accreditation and civil/criminal joint liability alongside the taxpayer.

The Legal Mandate: Anti-Tampering Standards in Saudi Law

Under Resolution No. 09-08-2021 (The E-Invoicing Controls and Implementing Provisions), an Electronic Generation Solution (EGS) is treated as a statutory legal ledger.

Historically, legacy cash registers allowed dishonest retail operators to operate an unrecorded "Training Mode" to issue receipts to consumers for cash payments, and then delete the transaction data before filing quarterly VAT returns. ZATCA's Phase 2 technical specifications permanently criminalize these architectural shortcuts:

Step 1Static Code Audit

Code Architecture Review

Software vendor audits codebase to strip out delete/update SQL triggers and manual counters

Step 2Database Hardening

Database Constraints

Database enforces 'INSERT ONLY' append-only architecture; DELETE/DROP permissions revoked

Step 3Immutable Ledger

Cryptographic Binding

System binds transactions to dedicated secp256k1 key; hash chain permanently anchors sequences

Step 4Government Audit

ZATCA Field Inspection

Tax inspectors run digital forensic audits on POS binaries; scan for hidden dual-ledger triggers

Step 5Full Protection

Compliance Certification

Compliant software maintains unbroken audit logs; protects business from tax fraud penalties

Detailed Analysis: The 7 Prohibited Software Capabilities

The following section breaks down the specific capabilities explicitly banned under ZATCA Phase 2 regulations:

1. Prohibited: Modifying or Deleting Issued Invoices

Under Saudi tax law, an invoice once finalized, cryptographically signed, or issued to a customer can never be deleted, updated, or removed from the database.

The Prohibition: SQL commands such as UPDATE invoices SET total = ... or DELETE FROM invoices WHERE id = ... must be permanently disabled in software logic and blocked by database foreign key triggers.
The Compliant Pattern: Any adjustment—whether for an error, customer return, or price reduction—must be handled by creating a new, sequential Credit Note (Type 381) or Debit Note (Type 383) referencing the original invoice's UUID.

2. Prohibited: Uncontrolled Resetting of the Sequential Counter (ICV)

The Prohibition: The Invoice Counter Value (ICV) cannot be reset to 1 at the beginning of a new month, a new fiscal year, or after a system restart.
The Compliant Pattern: The ICV must be an immutable, strictly incrementing positive integer (1, 2, 3, 4...) that runs perpetually for the entire operational life of the EGS unit. Skipping numbers or jumping backwards is flagged as an audit violation under Schematron rule BR-KSA-53.

3. Prohibited: Multiple Concurrent Sequences on a Single Device

The Prohibition: An individual EGS unit (such as a POS register or billing workstation) is strictly forbidden from maintaining multiple parallel numbering sequences (e.g., maintaining an "Invoice Series A" for cash and "Invoice Series B" for card payments).
The Compliant Pattern: Each EGS unit must maintain a single unified numbering sequence. If a retail store requires separate sequences for separate cashiers, each cashier station must be onboarded as an independent EGS unit with its own distinct serial number and dedicated CSID.

4. Prohibited: Exporting or Exposing the EGS Private Key

The Prohibition: The ECDSA secp256k1 private key generated during EGS onboarding must never be exported in plaintext, transmitted over unencrypted networks, shared with external vendors, or stored in readable configuration files.
The Compliant Pattern: Private keys must be stored in encrypted file systems, operating system secure keystores, or dedicated Hardware Security Modules (HSM) compliant with FIPS 140-2 Level 2 standards.

5. Prohibited: Manual System Clock Manipulation

The Prohibition: Software cannot allow users to manually alter the invoice issue timestamp to backdate transactions to a previous tax period or manipulate fiscal quarters.
The Compliant Pattern: The EGS must synchronize its internal system clock automatically using an authenticated Network Time Protocol (NTP) daemon. Invoices must record local Saudi Arabia standard time (YYYY-MM-DDTHH:MM:SS) without arbitrary manual overrides.

6. Prohibited: Absence of Cryptographic Hash Chaining

The Prohibition: Billing solutions cannot issue standalone, disconnected electronic invoices.
The Compliant Pattern: Every invoice must mathematically incorporate the SHA-256 hash of the immediately preceding invoice (Previous Invoice Hash - PIH). Omitting hash chaining breaks the cryptographic chain and renders the entire billing ledger non-compliant.

7. Prohibited: Dual Accounting / Hidden "Training Mode" Functions

The Prohibition: Software cannot incorporate hidden operational modes—such as "Training Mode", "Demo Mode", or "Temporary Mode"—that print realistic customer receipts without recording the financial transaction in the permanent tax ledger.
The Compliant Pattern: Any test transactions must be generated exclusively within the official Simulation Sandbox Environment using designated test credentials.

Technical Hardening: Database-Level Immutability Safeguards

Enterprise database administrators (DBAs) must enforce immutability at the database architecture level rather than relying solely on front-end application checks:

sql|Technical Specification / Reference
Verified Schema
-- PostgreSQL Enterprise Hardening: Prevent Invoice Deletion or Updates
CREATE OR REPLACE FUNCTION prevent_invoice_tampering()
RETURNS TRIGGER AS $$
BEGIN
    IF TG_OP = 'DELETE' THEN
        RAISE EXCEPTION 'ZATCA Phase 2 Compliance Violation: Deleting issued tax invoices is strictly prohibited under Saudi VAT Law.';
    ELSIF TG_OP = 'UPDATE' THEN
        -- Allow updating only the ZATCA clearance status and response payloads, never financial data
        IF (NEW.total_amount <> OLD.total_amount OR 
            NEW.vat_amount <> OLD.vat_amount OR 
            NEW.icv <> OLD.icv OR 
            NEW.invoice_hash <> OLD.invoice_hash) THEN
            RAISE EXCEPTION 'ZATCA Compliance Violation: Financial fields on issued invoices are immutable.';
        END IF;
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_zatca_invoice_immutability
BEFORE UPDATE OR DELETE ON tax_invoices
FOR EACH ROW EXECUTE FUNCTION prevent_invoice_tampering();

Statutory Penalties for Prohibited Architecture Violations

The legal consequences of violating anti-tampering regulations are severe under the Saudi VAT Law (Royal Decree No. M/113):

Violation CategoryLegal ClassificationMinimum Statutory FineMaximum Legal Penalty
Deliberate Deletion or Modification of InvoicesIntentional Tax Evasion (Article 40)SAR 10,000Up to 100% of unpaid tax + Criminal prosecution
Operating Un-Chained or Tampered SoftwareRegulatory Non-Compliance (Article 47)SAR 5,000SAR 50,000 per occurrence
Using Hidden "Training Mode" for Live SalesFraudulent Tax EvasionSAR 25,000Complete business license suspension + Public naming
Counter Resets & Artificial Sequence GapsProcedural Accounting FraudSAR 1,000SAR 20,000 + Mandatory tax audit reassessment
Vendor Deployment of Prohibited FeaturesCommercial Fraud & Aiding EvasionAccreditation RevocationCommercial blacklisting + Civil joint liability

Statutory Safeguards & Rights Protection

Mandatory protections enforced by MHRSD & Saudi Labor Law

1
Taxpayer Joint LiabilityEven if a business owner claims they were unaware that their software vendor programmed prohibited functions, the taxpayer remains 100% legally liable for all resulting tax assessments and fines.
2
Mandatory Forensic DisclosureDuring ZATCA field audits, tax inspectors possess statutory authority to confiscate server hard drives, review source code repositories, and inspect database transaction logs.
3
Whistleblower ProtectionsZATCA enforces a formal financial bounty reward program for corporate employees who report software vendors or businesses operating dual parallel tax evasion software.

Real-World Case Study: Riyadh Electronics Retailer Fined SAR 85,000

In late 2025, ZATCA tax inspection teams executed a surprise audit on an electronics retailer operating four storefronts in Riyadh:

The Infraction: The POS software contained a custom-coded keypress shortcut (F11) that switched the cash register into a hidden "Provisional Cash Mode". The receipt printed an authentic-looking Phase 1 QR code, but the transaction was written to an unindexed temporary table that purged every midnight.
The Forensic Discovery: ZATCA auditors compared inventory stock movements registered in the company's warehouse against reported POS invoices. The physical stock outflow did not match the reported VAT return by SAR 340,000.
The Sanctions:

* ZATCA reassessed unpaid VAT of SAR 51,000.

Imposed an intentional tax evasion fine of SAR 51,000 (100% penalty)*.

Imposed an administrative software tampering penalty of SAR 34,000*.

Total financial penalty: SAR 136,000*.

* The software vendor that coded the F11 shortcut was permanently banned from the ZATCA Solution Provider Directory.

Pre-Deployment Compliance Checklist for Enterprise CTOs

Before clearing software for production use, enterprise technology leaders should verify the following safeguards:

Statutory Safeguards & Rights Protection

Mandatory protections enforced by MHRSD & Saudi Labor Law

1
Immutability VerificationEnsure that neither database administrators nor application users possess UI buttons or database privileges to DELETE or UPDATE posted invoices.
2
Perpetual Counter AuditVerify that the ICV generator relies on atomic database sequences that never reset across calendar boundaries.
3
Cryptographic EnclaveConfirm that private keys are generated inside secure enclaves and never logged in text files, debug logs, or remote monitoring systems.
4
NTP Clock SynchronizationEnsure system clocks are locked to official Saudi NTP time servers with automated drift alerts.
5
Vendor Accreditation AuditConfirm that third-party software providers are officially listed in ZATCA's verified Solution Providers Directory.

Frequently Asked Questions (FAQ)

Can an accounting system provide an invoice "Draft" or "Proforma" mode?

Yes. Creating draft estimates or proforma quotes is permitted, provided the document clearly states in large, legible font: "THIS IS NOT A TAX INVOICE" (*هذه ليست فاتورة ضريبية*). A draft document must not generate an official ICV, must not claim VAT, and must not carry a Phase 2 cryptographic QR code.

What should an enterprise do if an invoice was issued with incorrect customer details?

Under no circumstances should the invoice be edited or deleted. The enterprise must issue a Credit Note (Type 381) referencing the incorrect invoice's UUID to cancel the financial transaction, and then issue a new, corrected Standard Tax Invoice with a fresh sequential ICV and unique UUID.

Are software developers legally liable if their ERP software contains prohibited features?

Yes. Under Saudi commercial and tax anti-fraud statutes, software vendors and individual developers who intentionally build features designed to facilitate tax evasion face joint liability, statutory fines, and potential criminal referral.

Can an enterprise reset its invoice numbering if it changes its ERP software?

No. While an enterprise may onboard a new ERP system with a new EGS serial number, the new system's initial invoice must start its own documented chain. The historical invoices in the retired ERP must be permanently archived and accessible for 5 years for audit review.

Is it permissible to store private keys in cloud environment variables?

Storing private keys in plaintext environment variables is highly discouraged. ZATCA security guidelines mandate encrypting private keys at rest using key management services (AWS KMS, Azure Key Vault, HashiCorp Vault) or hardware security modules (HSM).