Case studies.
Three engagements, described honestly — including the parts that went wrong. Clients are not named and identifying details are removed, because most of this work sits under confidentiality and a logo wall is worth less than a straight account of what actually happened.
ZATCA Phase 2 on SAP ECC, with 73 days' notice.
A Saudi manufacturing entity received its ZATCA integration notice on a Sunday afternoon. By the time it reached us on Monday morning, 73 days remained. It went live on day 67.
What was in scope. SAP ECC 6.0 (EHP 8) at the Saudi entity, two SAP systems — production and quality — and eleven document types across standard tax invoices, credit notes and debit notes. Five days of assessment before a line of configuration, which is the part organisations under deadline pressure always want to skip.
What went wrong. Two things, both organisational rather than technical. The Phase 1 private key and certificate turned out to be on a laptop belonging to an employee who had left the company, and the certificate had lapsed with their departure — so the cryptographic stamp identifier had to be reapplied for from scratch. Locating it took two days; resolving the key custody question took four.
What we would do differently. Nothing about the integration. But we now ask "who physically holds your signing key, and are they still employed here" in the first hour of every discovery call, because that single question has since moved more timelines than any technical finding.
The key pair was regenerated on the client's own SAP application server and held in the secure key store managed by the ABAP layer — not a file system, not a shared folder, and not with us.
Read the full day-by-day account →- Jurisdiction: Saudi Arabia — ZATCA Phase 2 (Integration)
- ERP: SAP ECC 6.0 EHP 8, two systems
- Scope: 11 document types
- Window: 73 days from notice; live on day 67
- Critical path: not the integration — the lapsed certificate
- Key custody: retained by the client throughout
A white-label Fawtara platform for a firm serving its own clients.
A GCC audit and advisory firm wanted to offer Oman e-invoicing to its own client base under its own brand — not to resell someone else's portal, and not to become a technology company in the process.
What was in scope. A white-label deployment of our platform under the firm's domain and branding, with a tenancy model that matters more than it sounds: the firm operates a parent organisation, and each of its clients sits beneath it as an isolated child organisation with its own data boundary. The firm can see and administer its clients; the clients cannot see each other. Bilingual Arabic and English throughout, because their client base expects it.
The hard part. Not the platform — the onboarding model. An advisory firm bringing dozens of clients onto a mandate is running a small programme per client: registration data, identifiers, master data, and each client's own readiness. We built the assessment and intake tooling around that, because a portal without an onboarding process just moves the bottleneck.
Where it stands. The platform is delivered and client onboarding is underway ahead of Oman's first wave in August 2026. We are deliberately not claiming cleared production invoices for this engagement, because Oman's first wave has not yet run — anyone claiming Fawtara production go-lives before that is describing a test environment.
- Jurisdiction: Oman — Fawtara, PINT OM
- Model: white-label, partner-branded, own domain
- Tenancy: operator organisation with isolated child organisations per client
- Languages: Arabic and English
- Status: platform delivered; client onboarding in progress ahead of the first wave
- What they kept: the client relationship, and their brand on it
Multi-entity readiness, where the real problem was master data.
A diversified Omani group with several VAT-registered entities across different lines of business, one finance function, and a mandate arriving in waves. The question they asked was which platform to buy. The question that mattered was which entities were in scope and whether their data could clear.
What was in scope. A readiness assessment across the group: confirming which entities fall in which Fawtara phase, mapping each entity's registration data and participant identifiers, and testing the master data against the format's actual requirements rather than against an assumption.
What we found. The usual thing, which is why we now lead with it. The integration was straightforward; the counterparty master was not. Registration details captured at onboarding and never revalidated, inconsistent identifiers across entities that shared customers, and tax treatment mapped in ways that worked for reporting but would not survive validation. None of this is visible until documents start being rejected — by which point you are inside a wave window.
How it was sequenced. Data remediation first, structure second, integration last — the reverse of how these programmes are usually sold. The group also gets a reusable answer: the same corrected master data serves Saudi and the UAE when those obligations arrive, which for a GCC group is most of the value.
Where it stands. Readiness work complete, entities mapped to phases, and the group positioned for its wave rather than reacting to it. As above, we are not claiming production clearance ahead of Oman's first wave.
- Jurisdiction: Oman — Fawtara, phased
- Shape: several VAT-registered entities, one finance function
- Engagement: readiness assessment and master-data remediation
- Finding: counterparty master data, not integration, was the risk
- Sequencing: data → structure → integration
- Reusable: the same foundation serves KSA and UAE obligations
What we will and will not claim.
Compliance buyers are lied to constantly, usually with percentages. Ours are deliberately plain.
Why are there no client names or logos?
Most of this work sits under confidentiality, and tax compliance is not something clients generally want advertised. Where we have permission to name a client we will, and we will say so explicitly. Until then, anonymised and accurate beats named and vague.
Why so few percentages?
Because we will not publish a number we cannot evidence. The figures here — 73 days, day 67, eleven document types, SAP ECC 6.0 EHP 8 — come from the engagement record and are set out in full in the linked field note. Where we have not measured something, we describe what happened instead of inventing a statistic for it.
Why do the Oman cases stop short of "go-live"?
Because Oman's first Fawtara wave begins in August 2026 and has not yet run. Claiming production clearances before that would mean describing a test environment as production. When those go-lives happen we will update these pages and date the change — that is the same standard we apply to our published mandate research.
Can we speak to a reference?
Ask on the call. Reference conversations are arranged case by case with the client's consent, which is the only way we will do it.
Your programme is probably one of these.
A deadline you did not set, an ERP that was not built for it, and master data nobody has looked at in years. Tell us which one you are, and we will tell you honestly what it takes — with a written fixed-fee quote within 24 hours.