A multi-site Saudi e-invoicing project needs an operating model for its e-invoicing generation solution units, or EGS units, as well as an invoice connector. Know which unit belongs to which configuration, who can onboard or change it, where its credentials are protected, and how staff recognise a unit that has stopped working.
ZATCA’s detailed technical guidelines describe onboarding and Cryptographic Stamp Identifiers, or CSIDs, associated with EGS units. This article examines the business software around that lifecycle. It does not decide which integration wave or tax treatment applies to a company; confirm that scope against its ZATCA notification and current official requirements.
The authority’s Wave 25 announcement is a current example of the staged integration rollout. The useful engineering response is to make onboarding repeatable and supportable as the business and its systems change.
The overlooked transition from one unit to many
Consider a fictional distributor with several sales sites and a central finance team. Its first integration works in a controlled demonstration. Months later, equipment changes at one site, a new site opens, and the person who performed onboarding leaves. Finance can see an invoice problem but cannot identify the responsible configuration.
This is an ownership problem that surfaces as an API problem. A dashboard showing request counts cannot answer which unit is affected, which credentials it uses, or whether a recent configuration change caused the issue.
Do not assume one physical branch always corresponds to one EGS unit. Establish the unit model for the actual solution architecture, supported invoice types, legal entities, and applicable requirements. Record that decision with the implementation team rather than deriving it from an organisational chart.
Create an EGS register with operational meaning
The register should connect technical identity with the people and systems that depend on it. It can live in a controlled administration tool rather than a spreadsheet circulated with sensitive configuration.
Useful records include:
- ▸Internal unit identifier and its associated business context.
- ▸Environment, software version, and deployment location.
- ▸Responsible operational and technical owners.
- ▸Onboarding state and references to approved evidence.
- ▸Credential references, renewal responsibilities, and relevant dates.
- ▸Last successful operation and unresolved incidents.
- ▸Retirement or replacement decision and its approval.
Store references to secrets rather than exposing private keys or tokens in the register. Restrict administration by role and keep a history of changes. An operator investigating a failed unit should not automatically gain permission to replace its credentials.
Make onboarding a controlled workflow
Onboarding combines business authority, configuration, secrets, and technical checks. Define who performs each step and what proves completion. Separate test and production identities clearly so that a successful experiment cannot be mistaken for a live unit.
As a concrete product example, Microsoft’s Dynamics 365 Finance onboarding documentation distinguishes compliance and production CSIDs and describes obtaining one-time passwords for solution units. Those product instructions illustrate the moving parts; another ERP’s implementation must follow its own supported configuration and ZATCA’s requirements.
Rehearse the workflow before a large rollout. Record prerequisites, approvals, unsuccessful steps, and recovery actions. Where time-limited credentials or codes are involved, arrange the people and systems before generating them rather than leaving a half-finished process for another shift.
Monitor business consequences, not only connectivity
A unit can be reachable while its documents are not completing the expected processing path. Connect technical telemetry to business records so support can see which documents require attention and which operations remain healthy.
Keep clearance and reporting behaviour distinct according to the applicable document flow. An administration screen should not collapse all responses into an unexplained green or red indicator. Show meaningful states, references, last attempts, and the authorised next action.
Avoid automatic resubmission based only on a timeout. The recovery procedure should establish what the remote service received and follow the interface’s permitted handling. Finance must be able to distinguish a known rejection from an outcome still being investigated.
Treat replacement and retirement as releases
When an invoicing component moves to new infrastructure or a unit is replaced, review identity, configuration, credentials, routing, and retained records together. Do not copy an entire production folder and assume the resulting installation represents a correctly onboarded unit.
Prepare a change record with the old and new states, approved timing, validation steps, and fallback decision. Check who can still access the retired configuration. Preserve the records needed to explain historical activity without leaving unnecessary active credentials behind.
Our cloud and code handover guide helps frame ownership, while the software maintenance agreement guide covers ongoing support responsibilities.
Commission the operational layer explicitly
Ask for a proposal covering unit inventory, controlled onboarding, configuration history, monitoring, exception handling, and the support runbook. Require demonstrations of an unavailable unit, rejected document, uncertain response, planned replacement, and an operator who lacks permission to change secrets.
Evaluate existing ERP administration capabilities first. Custom software may only need to connect their records with your support and finance workflow. The objective is a manageable operating process, not a second competing invoice platform.
TuniCyberLabs can help scope custom software and integration development around a multi-site operation. Describe your ERP, EGS architecture, rollout stage, and the incidents your team struggles to diagnose to discuss the missing operational layer.