Securing E-Invoicing Pipelines: API Penetration Testing for ZATCA Compliance

If your business had more than SAR 187,500 in VAT-taxable revenue in any year from 2022 to 2025, it falls under ZATCA’s Wave 25 criteria. The authority announced this group in July 2026, giving affected businesses until 1 February 2027 to connect their e-invoicing solutions to Fatoora. For some small businesses, this means their billing software will need to connect to Fatoora, ZATCA’s e-invoicing platform, either directly or through a service provider.

Many businesses are now preparing for the next phase of e-invoicing, including the technical work needed to connect their systems to Fatoora.

Many conversations focus on getting the connection to work and passing the required checks. Businesses should also ask whether the APIs linking their systems could be misused, and what an attacker might access if they were poorly secured. This blog explores that question. ZATCA compliance means meeting the required e-invoicing rules; API penetration testing helps assess whether connected systems can withstand attacks.

What Is ZATCA E-Invoicing?

ZATCA is the Zakat, Tax and Customs Authority, and its e-invoicing program runs on a platform called Fatoora, the Arabic word for invoice. Phase 1 began on 4 December 2021 and asked businesses to stop issuing handwritten invoices or invoices made using text-editing or spreadsheet software. Businesses had to use an electronic solution instead, with a QR code required on simplified tax invoices. Phase 2 started on 1 January 2023 and goes a step further. The invoicing software must connect to Fatoora through an API, which is how one piece of software talks to another.

After that connection exists, invoices take one of two routes:

• Invoices between businesses must be sent to ZATCA for clearance before the buyer receives them.
• Simplified tax invoices issued to walk-in customers are sent to ZATCA for reporting within 24 hours of issuance.

Invoice data must follow ZATCA’s required format, which uses structured, machine-readable data. The solution generates a hash for each invoice and links it to the next invoice in the sequence, helping detect deletion or replacement. Simplified tax invoices also require a cryptographic stamp. The software used to generate invoices is called an e-invoicing generation solution (EGS). It might be accounting software, a point-of-sale system, a system that runs a whole company’s operations (known as an ERP), or something a developer built for one business.

How Saudi Arabia’s E-Invoicing System Works: Phases, Requirements, and Compliance

Phase 2 does not start for everyone at once. ZATCA selects taxpayers in waves based on their revenue subject to VAT and notifies them at least six months before their integration date. Wave 25 covers taxpayers whose revenue subject to VAT exceeded SAR 187,500 in any one year from 2022 to 2025. ZATCA has set 1 February 2027 as the deadline for this group to connect their e-invoicing solutions to Fatoora. If you are unsure whether your business is included, check ZATCA’s announcements and any notifications sent directly to your business.

Layla runs a building materials business in Dammam with eleven employees and a few hundred invoices a month. Layla and her business are fictional. The blog draws on documented vulnerabilities and uses hypothetical findings to explain what a security test might find. Her invoices come from a cloud accounting tool, and a freelance developer wrote the plugin that connects it to Fatoora. The developer completed the plugin’s tests in ZATCA’s simulation environment within a week, and Layla assumed the job was done. Her invoices were passing the required checks, so she had no reason to think otherwise.

Why Secure E-Invoicing APIs?

Passing the compliance checks shows that your invoices meet ZATCA’s technical rules. It does not tell you who else might access the system that creates them. Layla’s plugin stores a digital certificate and a private key, which help prove that an invoice came from her business. If someone gains access to the private key, they may be able to use it to sign invoices as her business, depending on how the key and signing process are protected. The invoices also contain buyer names, VAT numbers, locations and itemized prices. Together, these details can reveal who she sells to and how much she charges.

Protect invoice and taxpayer data

Invoice data can be exposed when a billing tool has a security flaw. In March 2026, a flaw tracked as CVE-2026-2343 was reported in the PeproDev Ultimate Invoice plugin for WordPress. The vulnerability affected versions through 2.2.5 and could allow unauthenticated users to retrieve invoice archives with predictable filenames. A business could use a billing tool for everyday work and still expose customer information because of a flaw in that tool, even if the business had no reason to suspect a problem.

Prevent unauthorised access and invoice tampering

ZATCA’s digital stamps and invoice-hash links help protect invoices against changes. However, they cannot confirm that every action taken inside a business’s system was approved. If an attacker gains access, they might change an invoice amount, replace payment details or create a credit note without permission. API penetration testing can help find weaknesses that could let someone access or change invoice data they should not be able to control.

Maintain reliable invoice submission and reporting

Invoices between businesses need ZATCA clearance before the buyer receives them. If Layla cannot connect to Fatoora, her invoices may be delayed. Submission problems can also occur if the API is overwhelmed with requests or a required certificate expires. Her customers may have to wait for their invoices, which could also delay payment.

What Should API Penetration Testing Cover?

A penetration test is a controlled attempt to break into a system. A tester with written permission tries to find ways into your system through its API, then reports what they found. For an e-invoicing setup, they follow an invoice from the moment it is created to ZATCA’s reply and check where someone might access or change data without permission.

Key Areas Covered in E-Invoicing API Penetration Testing

• Access and permissions – Testers check who can log in and what each user can access. For example, can changing an invoice number in a request let one customer view another customer’s invoice?
• Keys and certificates – They look for exposed passwords, certificates and private keys in code, backups, settings files and error messages. They also check how certificates are renewed before they expire.
• XML and invoice checks – Since invoices are sent to Fatoora in XML format, testers send invalid or altered files to see how the system handles them. They check whether it rejects incorrect data or reveals sensitive details in its error messages.
• Invoice submissions and duplicate requests – The submission process is tested too. What happens if the same invoice is sent twice, or if the connection fails before the system receives ZATCA’s reply?
• Request limits and error messages – Testers check whether the API limits repeated requests from the same user or system. Without these limits, an attacker may send so many requests that the service slows down or stops responding. Error messages are checked for details such as internal file paths that should not be exposed.
• Logs and connected systems – They also review activity logs and connections between accounting software, point-of-sale systems, cloud storage and third-party add-ons. This helps check whether important actions are recorded and suspicious activity can be detected.

ZATCA’s technical requirements cover e-invoice formats, security features and connection to Fatoora. These requirements help explain what an e-invoicing solution must do, but they do not, by themselves, create a general requirement for every business to carry out API penetration testing. A test can help a business check for weaknesses that invoice validation may not catch, particularly when its systems exchange sensitive data or rely on third-party software.

Common E-Invoicing API Vulnerabilities

Layla’s developer agreed to a test mostly to calm her nerves. The tester spent the first afternoon learning how the plugin worked before trying to break anything, and the first problems appeared in the way the system handled access.

Broken access control was the first finding. Each invoice had a number in its web link, and the API returned the invoice to any logged-in user who supplied that number. It did not check whether the user was authorised to view that invoice. A staff account created for a part-time warehouse worker could read every customer’s invoices. Security teams call this broken object-level authorisation, and it is the first risk on OWASP’s API Security Top 10, a guide developers use to understand common API weaknesses. The tester also found a login account that had been left open after setup.

Exposed credentials and keys were the next finding. The private key sat in the plugin’s settings file, and three former staff members could still access a copy of that file in a backup folder. Someone who obtained the key might be able to misuse it to sign invoices as Layla’s business, depending on how the signing process was protected.

Key Security Risks Found During E-Invoicing API Penetration Testing

Unsafe XML processing and input validation came next. The plugin passed uploaded XML files straight to its XML reader, and the tester found that a specially crafted file could make the server try to open files stored on its own system. This type of weakness is known as XML external entity (XXE) injection. The tester also found that the system accepted invoice values it should have rejected.

Invoice tampering and duplicate submissions caused further concern. Sending the same request twice could create duplicate records in Layla’s system if the integration did not handle repeated submissions safely. The tester also found that a draft could be edited after approval but before signing, allowing invoice details to be changed without the required approval.

Excessive data exposure appeared in another test. The API returned full customer records when the screen only needed a name, exposing more information than necessary.

Finally, weak login protection allowed repeated attempts without a suitable limit, giving someone time to keep guessing passwords. Each issue might look minor on its own, but together they could expose customer data or let someone misuse the invoicing system.

How to Prepare for Testing

Getting ready takes less effort than many business owners expect. It mostly means understanding how your own system works and deciding what the tester is allowed to check.

1. Map your setup by drawing the path an invoice takes from creation to Fatoora. Include the plugin, accounting system, cloud storage, everyone with access and any third-party services in between. This may reveal an add-on that nobody remembers approving.
2. Agree on the scope in writing. List the systems to be tested, the dates and the methods the tester can use. Keep ZATCA’s own production systems out of scope unless you have explicit authorisation to test them.
3. Use ZATCA’s Integration Sandbox for integration checks. It is a test environment that simulates some of Fatoora’s functions. Developers can use it to test API requests, invoice submissions and parts of the onboarding process. Passing these checks does not mean that your own systems are secure against attacks.
4. Run security tests in a safe environment using a copy of your own system and made-up customer data wherever possible. This helps prevent test requests from changing live invoices or exposing customer information. If production testing is necessary, agree on strict limits and safeguards first.
5. Keep the findings and fixes together. Record each issue, who is responsible for fixing it, the target date and the result of the follow-up test. This gives your team a clear record to share with an auditor or client when needed.

The sandbox and a penetration test answer different questions. The sandbox checks whether your e-invoicing solution can exchange requests and documents with Fatoora and meet the relevant technical checks. A penetration test looks for ways someone could misuse your own systems or access data without permission.

How Qualysec Supports E-Invoicing Security

Passing ZATCA’s invoice validation checks does not, by itself, show whether the connected systems are secure. For a setup like Layla’s, Qualysec’s API penetration testing could examine access controls, private-key protection, invoice handling and connections between systems.

Qualysec follows its Three Layered Defence System, combining automated tools in Layer 1, AI-Powered Analysis in Layer 2 and Human-Led Validation in Layer 3. Rather than relying on automated scan results alone, the approach includes expert review of the findings.

For an e-invoicing setup like Layla’s, Qualysec’s testing could cover:

• API access controls – Check whether users can view or change invoices without permission.
• Certificate and key security – Check how private keys and certificates are stored and protected.
• Invoice handling – Test for unauthorised changes, duplicate submissions and weaknesses in error handling.
• Connected systems – Check the links between accounting software, e-invoicing plugins and other services.

Qualysec provides a report describing the findings, their potential impact and recommended fixes. Retesting can then check whether the reported weaknesses have been resolved.

Could the same issues affect your business? Perhaps your team is unsure who can access stored invoices, where API keys are kept, or whether a failed submission could cause duplicate records. These are worth checking before they lead to data exposure or disruption to invoicing.

Contact Qualysec to discuss your e-invoicing setup and the security checks your business may need.

Prepare for Your Next Cybersecurity Audit with Qualysec

Choose a partner that helps you identify and fix real security risks before attackers do. We are here to help.

Talk to an Expert→

Conclusion

API penetration testing helps find security weaknesses in an e-invoicing integration while there is still time to fix them. It complements ZATCA’s technical and integration requirements without replacing them. For a small business entering Phase 2, particularly one in Wave 25 with an integration deadline of 1 February 2027, the months before that date give the team time to find and fix weaknesses before the deadline.

For Layla, the test is about more than getting invoices through Fatoora. She also needs to know that only authorised people can access her customers’ records, that her private keys are protected and that her team can explain what happens when something goes wrong.

If you’re preparing for Zatca compliance, contact Qualysec to discuss how API penetration testing could help check your integration for security weaknesses before go-live.

Frequently Asked Questions

1. Does ZATCA require API penetration testing?

ZATCA sets technical and security requirements for e-invoicing solutions. These requirements do not, by themselves, require every business to carry out API penetration testing. Testing can help find weaknesses that invoice validation may not catch.

2. What does an e-invoicing API penetration test cover?

It checks user access, private keys and certificates, XML and invoice data, duplicate submissions, request limits, error messages and the systems linked to the invoicing process.

3. Can ZATCA integration be tested in a sandbox?

Yes. ZATCA provides an Integration Sandbox and API documentation to test connections, onboarding steps and invoice submissions. The sandbox checks integration, not the security of your own systems against attacks.

4. How does API testing support e-invoicing security?

It can find ways someone might access or change invoices without permission, or disrupt submissions. The report helps your team prioritise fixes, and a follow-up test checks whether those fixes worked.