We created and launched a middleware platform for e-invoicing that meets ZATCA standards, specifically designed for businesses in Saudi Arabia needing to comply with Phase 2 e-invoicing requirements on tight timelines. Our clients included everything from mid-sized trading companies to large retail and service firms, using a variety of systems like SAP, Odoo, custom ERP setups, and even Excel for their accounting. Instead of overhauling their entire ERP, they just needed a dependable way to produce compliant invoices, link with ZATCA’s Fatoorah platform, and steer clear of fines.
At aTeam Soft Solutions, we developed a middleware layer that easily fits into their current systems. It handles everything from UBL 2.1 XML generation and TLV QR code creation to cryptographic stamping, real-time API interactions, and status updates. We got the main platform up and running in just 10 weeks and quickly integrated our clients using straightforward connections and workflows.
In the 12+ months since we started, the platform has helped over 200 Saudi businesses, managing around 50,000 to 80,000 invoices daily, and we’ve achieved 99.7% uptime, with no penalty incidents since going live.
When the ZATCA Phase 2 rollout began to impact businesses exceeding revenue thresholds, many companies reaching out to us weren’t having trouble with invoicing as a concept. Instead, they were grappling with the technical gap between their current software and the new legal requirements.
Typically, our clients fell into one of four categories. Some had established ERP systems like SAP, but their invoice formats and internal approval processes were heavily customized. Others were using Odoo, but lacked sufficient in-house technical expertise to implement the Phase 2 regulations properly. There were also businesses with custom-built billing systems created years ago that worked for internal accounting, yet lacked structured XML export capabilities. And surprisingly, quite a few mid-sized companies still depended on Excel for their accounting, managing manual invoice generation, and partial bookkeeping workflows.
ZATCA Phase 2 raised the stakes for these limitations almost overnight. Companies now require electronic invoices that meet specific structural criteria, validated in real time or accurately reported based on the invoice type, and linked to the Fatoorah platform. This wasn’t just about changing print formats; it demanded XML generation with precise rules, QR code creation with TLV encoding, cryptographic signing or stamping workflows, API integration, and effective error handling for rejected invoices.
Most finance and operations teams had never had to consider UBL 2.1 XML schemas, X.509 certificates, or how to validate API responses. They were proficient in invoicing operations, but lacked the tools or engineering bandwidth to transition into compliance integration teams within just a few months. Some clients faced a tight 3-6-month deadline, and their existing software vendors were often unprepared, unresponsive, or provided timelines that extended beyond the compliance deadline.
The ramifications for businesses were significant. Non-compliance could incur penalties starting from SAR 5,000 per invoice, and for companies dealing with high volumes of invoices, the financial and reputational stakes were too high to ignore. Moreover, invoice rejections in production could directly impact sales, shipping, collections, and customer relations. We witnessed businesses operating in panic mode, with 30-40% rejection rates in sandbox environments due to minor formatting or validation errors.
By the time they reached out to us, these clients weren’t looking for an extensive digital transformation plan. What they needed was something more immediate and practical: an e-invoicing solution for Saudi Arabia that they could implement swiftly without overhauling their entire ERP system. They sought a partner who could navigate the compliance layer, integrate across various systems, and help them go live before the deadline.
Many businesses we work with reached out to us through referrals, implementation partners, and technical consulting discussions after exploring other options. What made them choose aTeam Soft Solutions was more than just our ability to code quickly; it was our approach to framing the problem right from the start.
Instead of viewing ZATCA Phase 2 as just another integration task, we recognized it as a critical compliance issue that could impact middleware and operations reliability. This distinction was important, as clients were concerned not just about connecting to an API, but also about potential rejections, downtime, delayed invoices, and risks of penalties. We talked directly about invoice lifecycles, fallback handling, bulk processing, and support models during peak business hours.
As a software development company in India, we were also able to offer a dedicated engineering team with a cost structure that worked well for both mid-sized and large businesses in Saudi Arabia. Our alignment with KSA time zones made it easy to onboard and manage production issues. For many clients, this time-zone alignment was crucial, especially during rollout week when they couldn’t afford to wait for answers overnight.
Additionally, we brought a comprehensive integration mindset to the table. aTeam Soft Solutions has experience with ERP systems, custom applications, API integrations, and enterprise workflows, which was beneficial since each client had a unique invoicing source system. Some needed work on SAP connectors, others required Odoo integration, and some needed us to create adapters for local systems that had limited documentation. Although we’re often introduced as a web development company in India, what clients appreciate most in these projects is our expertise in integration engineering, observability, and ensuring production reliability.
Trust played a significant role as well. These businesses were managing tax data and financial records, so enforcing NDAs, being disciplined with credential handling, and maintaining controlled deployment processes were essential. aTeam Soft Solutions had the maturity needed for this, and our strong reputation on Clutch and GoodFirms helped assure clients and reduce the risk of vendor selection when they needed to make fast decisions.
Given the real pressure of deadlines, we put together a discovery process that was both short and structured. We couldn’t afford to spend months on analysis, yet we also needed to ensure our compliance mapping was thorough to avoid stumbling upon critical gaps during user acceptance testing (UAT). Our main aim was to get each client onto a functioning production path as quickly as possible while steering clear of any hidden points of failure.
To start, we categorized clients based on integration patterns rather than by industry. This choice was one of the most significant in the project. While a retail chain and a service-based business might differ commercially, if both required high-volume streamlined invoices from a custom billing system, their integration patterns would be quite alike. Similarly, though two trading companies using SAP could be similar, one might need different handling if it featured custom invoice output logic while the other stuck closer to standard SAP workflows.
During the onboarding process, we took care to document the fields from the invoice source, tax logic, invoice types (B2B/B2C), requirements for credit/debit notes, branch structures, and existing approval workflows. We also gathered sample invoices and tested how their current systems showed timestamps, tax totals, discounts, and line-item data. These specifics were crucial, as minor formatting discrepancies could lead to rejections from ZATCA later on.
For delivery, we developed the core platform while simultaneously creating client onboarding templates. The platform team concentrated on building the invoice generation engine, cryptographic module, integrating the Fatoorah API, and setting up the monitoring dashboard. Meanwhile, the integration team worked on connectors and adapters for the various client systems. At launch, the core team comprised six developers, one QA engineer, and one project manager. During our busiest onboarding stretch, we ramped up to ten developers to manage multiple client integrations and production support.
We followed a short sprint approach and leveraged Jira to monitor both platform features and specific client onboarding tasks. For daily interactions with client IT and finance teams, we used Slack and Microsoft Teams. We also implemented Git-based branch controls and established staged environments for sandbox and production rollout sequencing. For clients lacking strong technical support, we designed structured onboarding checklists, allowing finance stakeholders to validate invoice fields without having to fully grasp the entire implementation process.
This method allowed us to keep up our pace while maintaining auditability and release discipline — key components for rolling out any ZATCA Phase 2 compliance software.
Our first design decision was to steer clear of asking clients to replace their current ERP or accounting systems, as that could have worsened the compliance issue. Instead, we created a middleware architecture that interfaces between the client’s invoicing source system and ZATCA’s Fatoorah platform.
This middleware takes invoice data from various sources, standardizes it into a common internal format, generates compliant XML and QR payloads, employs cryptographic stamping workflows, and manages real-time API submissions, response parsing, and status tracking. By keeping the compliance layer separate from the client’s main ERP, we provided businesses a quicker route to go live while minimizing the risk of upsetting their financial operations.
For many clients, this solution offered exactly what they needed to: maintain their ERP while integrating a compliance engine.
At the core of the platform, we had our invoice generation engine, which transformed business invoice data into the ZATCA-compliant UBL 2.1 XML format. This process was more intricate than just mapping templates; different systems had various ways of representing totals, taxes, discounts, and line items. Our middleware played a crucial role in standardizing these inputs before we could create XML that would meet validation criteria.
We developed a transformation pipeline that started by normalizing incoming data into a standard invoice object. Next, it enforced business rule validation, checking for mandatory fields, tax consistency, timestamp formatting, and the presence of branch/seller information, among other things, prior to generating the XML. This layer of validation was essential as it helped us identify any issues before interacting with the ZATCA API, which ultimately minimized unnecessary rejection cycles and enabled our client support teams to respond more swiftly.
Additionally, we took great care to version the mapping logic. As we gained insights from sandbox testing and resolving production edge cases, we needed to fine-tune specific validation and transformation rules without disrupting the clients already using the system. Thankfully, the engine’s design allowed us the flexibility to do just that.
We created a QR code generator that generates the required TLV (Tag-Length-Value) encoded information, including the seller’s name, VAT number, invoice timestamp, total amount, and VAT amount. For many of our clients, this was often a point of failure during their initial implementations before they sought our help, as the QR image appeared correct, but the encoding or value formatting was incorrect.
To prevent these kinds of issues, we designed the TLV generation as a strict module with input checks and encoding tests, rather than relying on makeshift code in each connector. This approach made it reusable for all clients and easier to validate during the onboarding process. The QR output could then be seamlessly embedded in invoice documents or returned to client systems, depending on how they handle invoice rendering.
Our cryptographic stamping module takes care of certificate-based tasks using X.509 digital certificates, built around OpenSSL workflows for managing those certificates. This part made some client teams a bit anxious, as it brought together compliance, security, and operational aspects, which they’re less familiar with—they were more accustomed to handling invoice templates and accounting rules than managing certificate lifecycles.
To make things smoother, we designed the module to keep certificate operations separate from the application’s business logic. We ensure that credentials and certificate materials are managed through secure storage and deployment processes, and stamping operations are triggered through safe service interfaces. We also keep a log of stamping results and related transaction details, allowing support teams to track failures without putting sensitive certificate information at risk.
This clear separation enhances the platform’s safety and makes maintenance easier. Plus, it minimizes the chance of mistakes by developers impacting production certificate workflows, especially during fast onboarding periods.
We created a seamless real-time API integration with ZATCA’s Fatoorah sandbox and production environments. This included everything from submitting requests and handling responses to parsing errors and implementing retry strategies when needed, all while ensuring that status was preserved. This approach enabled our clients to transition smoothly from testing to production without the hassle of changing tools or altering fundamental logic.
A crucial aspect of our design was observability. We aimed to avoid the middleware acting like a “black box” that only indicated success or failure. Instead, we organized invoice processing states and response details in a clear structure, allowing users to see whether an invoice was pending, cleared, reported, rejected, or waiting for resubmission. This proactive design became a significant advantage for support, especially when clients were onboarding under tight deadlines and needed quick answers.
For companies on the lookout for a ZATCA Fatoorah integration developer, this distinction often makes the difference between merely having a technically functional integration and having a system that is truly operational. Just making API calls isn’t sufficient; teams need insight into what happened and what steps to take next.
The platform was designed to support both clearance and reporting flows for handling B2B tax invoices and B2C simplified invoices. We created the middleware to ensure that the processing path was chosen based on the invoice type and the client’s setup, all while maintaining a seamless monitoring experience in the dashboard.
This was particularly important for retail and mixed-business clients who might generate both types of invoices on the same day. Their finance teams required consistent status tracking and exception handling, even when the underlying compliance behaviors varied. We also adapted the framework to accommodate edge cases like credit and debit notes, which became crucial as clients expanded their operations beyond just basic invoice flows.
We created a React.js web dashboard to give both our client teams and support team a common view of operations. This dashboard displayed important information such as invoice statuses, reasons for rejection, processing timelines, and actions for resubmission. It also assisted clients in spotting recurring data issues, like specific formatting problems associated with branches or missing tax fields from their source systems.
The aim wasn’t to replace ERP reporting, but rather to enhance visibility for compliance operations. Finance and IT teams found it helpful during the rollout, and many continued using it as part of their daily monitoring after things stabilized. This significantly reduced the instances of “silent failures,” which often only became apparent during later reconciliation.
Since our client base is quite diverse, we developed pre-built connectors for SAP, Odoo, and custom REST API integrations. While each connector did need some adjustments specific to the client, particularly in SAP setups with unique invoice formats, having this connector framework really cut down on the repetitive tasks.
We also embraced flat-file and batch ingestion methods for businesses that were leaping from manual or semi-manual systems. This approach enabled some Excel-heavy businesses to meet compliance requirements even before they completed a full ERP modernization. Although it wasn’t the perfect final long-term architecture for them, it effectively and safely addressed their immediate regulatory needs.
This connector-based strategy laid the groundwork for our ZATCA e-invoicing integration India delivery model and eventually transformed into a more universal integration framework used across various clients.
Several clients generate thousands of invoices each day, especially when there are sharp peaks during promotions, weekends, Ramadan sales, and Black Friday campaigns. To handle this, we created a bulk invoice processing pipeline using AWS Lambda for seamless serverless processing bursts, Redis for effective queue management, and PostgreSQL for reliable status tracking.
This processing model allowed us to manage spikes in demand and keep the platform running smoothly, avoiding bottlenecks during busy times. We also integrated queue monitoring and throttling controls to ensure that the system maintains stability when it’s most needed. Thanks to this architecture, the platform can scale efficiently across multiple clients without requiring each client to set up separate infrastructure.
For businesses looking to choose a Saudi e-invoicing development company, this layer of scalability is sometimes overlooked. Many solutions perform well in low-volume tests, but struggle under real commercial pressures. We built our system with production volume in mind from the very start.
One of the early challenges we faced was dealing with incomplete documentation and vague validation behavior for edge cases during the initial Phase 2 rollout. While the official APIs and guidelines addressed core processes, certain scenarios—like credit notes, debit notes, and advance payment patterns—weren’t as clear as businesses needed for implementation. This led to a common issue: invoices that seemed valid to finance teams were still failing in the sandbox environment.
To tackle this, we took a systematic approach to sandbox testing, treating it like a structured reverse-validation program instead of just random trial and error. We created a catalog of edge cases, generated controlled test payloads, and monitored response patterns to pinpoint which validation rules were actually enforced. We documented our findings internally and turned them into reusable validation logic in the middleware. This not only reduced repeated mistakes across clients but also sped up onboarding after handling the initial complex cases.
The second major hurdle was the variability in SAP integration. While “SAP connector” sounds straightforward, each client’s SAP instance came with years of customizations, different invoice layouts, and the availability of fields. Some clients had line-level data presented clearly, while others needed extra work to extract tax-relevant structures.
Our solution was to separate the connector transport from the mapping logic. Rather than hard-coding each client’s SAP format into the connector, we developed adapter layers and mapping profiles that could be tailored for each client. Although this required more upfront effort compared to a quick custom script, it ensured the connector remained maintainable and simplified long-term support. This approach also allowed us to onboard SAP clients within 1-3 weeks, depending on their readiness, rather than starting from scratch with the integration each time.
The third challenge was managing peak-hour loads for multiple large clients. During busy periods, several businesses could generate bulk invoices at once, leading to queue spikes and pressure on response times. This issue was particularly evident during seasonal campaigns and peak retail periods like Ramadan.
We resolved this with queue-based processing using Redis, burst processing via AWS Lambda, and improved queue observability. We also implemented client-specific rate controls and retry policies to prevent a single high-volume integration from exhausting system capacity for others. After fine-tuning our processes, the platform consistently handled daily processing in the 50,000-80,000 invoice range, all while ensuring fast response times and stable operations.
Lastly, we encountered challenges with the delivery process: clients often contacted us late in the game, sometimes just weeks before their compliance deadlines. To address this, we standardized onboarding checklists, connector templates, and test plans, enabling us to streamline integration cycles without sacrificing validation quality.
The key takeaway was quite straightforward: businesses managed to ensure compliance before the deadline and maintained it in production. Throughout the rollout, over 200 Saudi businesses successfully integrated with the middleware, transitioning from compliance uncertainty to a reliable invoicing system linked to ZATCA.
During testing, many clients faced rejection rates in the 30-40% range, largely due to issues with XML formatting, inconsistencies in tax fields, QR encoding problems, or challenges in handling edge cases. However, after onboarding to our platform and stabilizing their source mappings, the production rejection rates fell to under 2%, with an average blended rate of 1.7% reported across active clients following the initial learning phase. Most remaining rejections were actually tied to upstream data issues, rather than mistakes in middleware generation.
The platform also offered impressive speed. On average, invoice processing time, from generation to ZATCA clearance/reporting response handling, clocked in at just 1.2 seconds under normal operating conditions. This speed really made a difference for high-volume retail and service businesses, where any delays in invoicing can impact customer checkout experiences and internal operations.
On the infrastructure front, the system has shown an impressive 99.7% uptime over 12+ months of operation, even during peak commercial times. The queue-based and serverless processing design allowed us to manage volume spikes smoothly without major failures.
Another outcome that really mattered to clients was the avoidance of penalties. After going live in production, there were no penalty incidents reported among clients using the platform within the designated compliance workflows. This achievement quickly built trust, especially among finance leaders who initially viewed e-invoicing as a technical risk beyond their control.
Additionally, we observed operational benefits extending beyond compliance. Finance and IT teams gained improved visibility into invoice statuses, rejections, and resubmissions via the dashboard, which reduced the time spent on tracking silent failures and handling manual reconciliation surprises. For several clients, the middleware catalyzed broader ERP and process improvements, as it highlighted areas where their upstream invoicing data quality was lacking.
From our perspective, this project has enhanced how aTeam Soft Solutions approaches compliance middleware in regulated markets. It has also demonstrated that a software development company in India can deliver swift, production-grade integration systems to meet Saudi mandates, focusing on reliability, observability, and consistent onboarding, rather than merely custom coding for each client.
One of the key takeaways from this project was that focusing on an integration strategy is more crucial than just compliance logic. In the beginning, we moved swiftly by creating several integrations tailored for specific clients because we had tight deadlines and they needed quick results. While this approach worked, it also led to repetitive efforts. Reflecting on it now, we realize we should have prioritized developing a more universal connector framework right from the start.
After implementing a more robust connector abstraction layer and reusable mapping profiles, we saw a significant boost in onboarding speed. We believe that if we had taken this approach from the beginning, we could have saved around 30% of development time for the initial group of clients. Although we eventually reached that point, it came after doing more custom client work than was really necessary.
We also discovered that compliance projects require equal focus on both engineering and operations. The technical components—like XML, certificates, and APIs—are just one part of the puzzle. The other part involves monitoring, handling rejections, managing resubmission flows, and providing finance teams with visibility without burdening them with developer tools. This is why the dashboard and status model became just as important as the API integration layer.
At aTeam Soft Solutions, we now kick off similar projects using a stronger connector-first architecture and a more detailed onboarding readiness checklist. This approach has made our delivery model more consistent and has allowed us to scale efficiently without compromising on production quality.
If your business in Saudi Arabia is navigating the complexities of ZATCA e-invoicing, facing invoice rejections, or experiencing slow responses from your ERP vendor, we’re here to help. aTeam Soft Solutions specializes in creating compliance middleware, ERP integrations, and efficient high-volume invoicing workflows that are proven to perform in real-world scenarios, not just in presentations.
Whether you require ZATCA Phase 2 compliance software, a custom connector, or a dedicated ZATCA e-invoicing integration team from India to assist with your rollout, we can often outline the best approach within a week of our first conversation. If you’re considering a web development company in India or an engineering partner focused on tax compliance systems, please share your current setup and sample invoice flow with us. We’ll let you know what elements can be reused, what needs adjustments, and how quickly we can get you up and running.
