Platform & security
A deterministic core, with AI kept at the edges.
كل رقم قابل لإعادة الاحتساب، وكل قرار موثّق
Data to decision
One platform, not a collection of bots.
01
Data
GL · TB · AP · AR · invoices · credit notes · FS · tax returns · contracts · e-invoice data
02
Standardisation
Chart-of-accounts mapping · vendor and customer mapping · tax codes · sign conventions · currency · transaction classification
03
Agents
VAT · WHT · zakat · accounting · reconciliation · risk · review · filing support
04
Controls
Rules · materiality · confidence · historical behaviour · effective dates · exception logic
05
Human review
Approve · reject · send for rework · comment · override with a reason
06
Output
Excel working paper · dashboard · draft return · audit trail · ZATCA response pack
The biggest design decision is not the model. It is the common transaction schema that lets every module read the same fields, mappings, evidence and review history.
Minimum data contract
Every client dataset becomes one schema before any module runs.
| Field | Why it is there |
|---|---|
| Transaction ID | Unique source key |
| Entity / branch | Legal entity or reporting unit |
| Posting date | GL posting date |
| Document date | Invoice or document date: the tax point test |
| Account code / name | Source account and the standardised category |
| Debit / credit / amount | The raw value and the normalised economic sign, both kept |
| Currency / FX rate | Source currency and the conversion to riyals |
| Vendor / customer | Master-data reference |
| Country / residency | For WHT, reverse charge and cross-border logic |
| Tax code / rate | The ERP tax set-up |
| Invoice / credit note reference | Document-level matching |
| Journal source / type / user | Manual-journal detection |
| Description | Input to AI classification |
| E-invoice UUID / status | E-invoice reconciliation |
| Evidence link | Invoice, contract, declaration or working paper |
| Reviewer decision | Approved treatment and its rationale |
Architecture
Seven layers, from ingest to the signed deliverable
- 7
Experience
Review console · exception queue · gate sign-off · client portal (PBC)
Keyboard-first review UI: source document, extracted fields and AI evidence side by side.
- 6
Deliverables
Workpaper builder · report builder · PDF
Every artefact generated from engine output, with the tie-out asserted before it is produced.
- 5
Workflow
Engagement state machine G0 → G7 · human tasks · review notes · SLA timers
Long-running engagements with human steps; a worker can die mid-run without corrupting an engagement.
- 4
Deterministic core
VAT reconciliation engine · WHT engine · customs reconciliation · zakat engine
Pure, decimal arithmetic, no network, no clock. PASS / FAIL / INDETERMINATE. Fed by a versioned, effective-dated, cited rulebook owned by Tax Technical.
- 3
AI services
Transcribe (T1) · Extract (T1) · Classify (T2) · Draft (T3) · Retrieve
Swappable providers behind one interface: frontier API, open-weights models in-Kingdom, or a rules fixture. Guarded by an evaluation harness: golden sets, regression diff, calibration, drift.
- 2
Data
Standard transaction schema · client mappings · decisions · audit events · object store
Every client dataset is converted to one data contract before any agent runs, so no module re-solves the same ERP differences. Lineage from source to engine to workpaper; source documents immutable and hashed at G1.
- 1
Ingest
ERP connectors · GL/TB loaders · sales and purchase registers · e-invoice extracts · document upload · bank files
ZATCA portal exports are uploaded by the client, never scraped.
Engineering principles
Six design rules that make the work reproducible
Thin API, idempotent jobs
Every unit of work is a queued job keyed on engagement, stage and attempt. A worker can fail mid-run without corrupting an engagement.
Every AI capability behind an interface
The classifier interface is identical for a rules fixture and a frontier model. Moving to an in-Kingdom model is a configuration change.
The core is pure
No model, no network, no clock inside the engine. That is what makes the workpapers reproducible and the regression suite meaningful.
Append-only
Extractions, AI proposals, reviewer decisions, rulebook versions and engine runs are versioned. You can always answer: what did we conclude on 22 Sep, on which rulebook, and who decided line 688?
Normalise once, reuse everywhere
Sign conventions, tax codes, dates and currencies are normalised on the way in, with the raw value kept beside the normalised one. Client mapping decisions are stored and reused next period, and stay overridable.
Corrections are data
Every reviewer override becomes a labelled example for the next golden-set refresh. After a few engagements it becomes the most valuable asset in the system.
AI capability map
Where AI is used, and why it is used there
| Capability | Technique | Tier | Used in | Why this approach |
|---|---|---|---|---|
| Page triage & document typing | Small vision model on thumbnails | T1 | Customs, e-invoices, PBC intake | Cheap and fast; tells the user what is missing before the expensive work starts |
| Transcription (scans, Arabic) | Vision read; text layer where it exists | T1 | Customs, e-invoices, TRCs, notices | Classic OCR is weak on Arabic; the text layer is free where present |
| Field extraction | Schema-constrained JSON output | T1 | TRCs, e-invoices, contracts, notices | Structured output removes parsing failures; arithmetic cross-checks the result |
| Nature-of-payment / account classification | LLM with closed label set, evidence quotes, abstention | T2 | VAT return, WHT, GL risk scan, zakat, TP | Judgement on free text is what LLMs are good at; the gate and golden set bound the risk |
| Similar-decision retrieval | Embeddings over past reviewer decisions | T2 aid | WHT, VAT | Shows the reviewer how a similar line was decided before, for consistency across the firm |
| Entity / identifier resolution | Normalisation rules + fuzzy match + learned aliases | T1/T2 | Landed cost, AP anomalies, TP | The same B/L can appear four ways in one pack. Rules first, model second. |
| Anomaly detection | Statistical outliers, duplicate and split patterns | AP anomalies, VAT reconciliation | Explainable: a reviewer must be able to say why a line was flagged | |
| Research & drafting | Retrieval over a curated corpus, mandatory citations, verification | T3 | Research copilot, notice triage, report narrative | Highest hallucination risk; built only after the Tier-3 controls exist |
| Long-document clause extraction | Long-context extraction with page citations | T2/T3 | Contract & PE analyser | Contracts run 20 to 200 pages; the clause location must be cited |
Integrations
Works from the systems you already run
| Source | Method | What we take |
|---|---|---|
| SAP S/4HANA / ECC | CDS views / OData, or scheduled extracts | AP payments, WHT items, vendor master, GL |
| Oracle Fusion / EBS | BI Publisher reports / REST | AP invoices and payments, supplier master, GL |
| Microsoft Dynamics 365 F&O / BC | Data entities / OData | Vendor transactions, GL |
| Odoo, Zoho Books, Qoyod, Daftra | REST / XML-RPC | Common among SME clients of KSA consultancies |
| ZATCA portal | Client-uploaded exports only | Form Q history, acknowledgements, DTA application refs. No scraping, no credential sharing, no automated filing. |
| FATOORA e-invoices | XML / QR parsing; client-provided extracts | Sales e-invoice population (UUID, clearance status) and supplier invoices received by the client |
| Customs declarations | Client-provided export and import declarations | Export evidence for zero-rating; import VAT paid at the border |
| Banks | MT940 / CAMT.053 / CSV | Bank reconciliation, remittance evidence (SADAD receipts) |
| Document management | SharePoint / Google Drive / upload | Contracts, TRCs, notices |
| SAMA FX | Published reference rates, stored per line | Riyal conversion on the payment date |
Security & data residency
Residency is agreed in writing at G0, not assumed.
Hosting & residency
Chosen at G0 and put in writing: a KSA cloud region for data and compute, and for inference either a disclosed offshore API under a DPA or open-weights models on in-Kingdom GPUs. FlowCount never markets residency it does not deliver.
NCA ECC-2:2024 / CCC
Asset inventory, IAM with MFA, logging and monitoring, vulnerability management, backup, third-party risk (the model provider is a third party), cloud controls.
PDPL
Records of processing; a DPA per client; data minimisation to models (descriptions only); cross-border transfer assessment where inference is offshore; retention per engagement.
Minimised model input
Only description fields, GL, country and service location go to a model. Bank details, amounts and personal names do not; classification does not need them. No training on client data.
Encryption & tenancy
TLS 1.2+ in transit, AES-256 at rest, per-tenant keys for the white-label platform, row-level security, no cross-tenant retrieval.
Audit trail
Append-only audit events for every view, edit, disposition, sign-off, export and model call, logged with the prompt version, input hash, output and latency.
Certification. ISO/IEC 27001:2022 and SOC 2 are on the platform roadmap. Until they are issued we share our NCA ECC control mapping and answer your security questionnaire directly.
Unit economics
The technology is cheap. The professional time is the product.
| Item | Cost per engagement | Note |
|---|---|---|
| AI classification, frontier model | ~150 | About 0.03 per line |
| Extraction of 200 contracts / TRCs | ~300 | Measured ~1.16 per 23-page pack |
| Compute, storage, observability | ~200 | Shared platform, amortised |
| Technology cost | < 1,000 | |
| Professional time (G0 to G7) | 8 to 15 person-days | The real cost, and the real value |
This is why our fees are set by population size and professional effort, not by the number of model calls.
Bring your security questionnaire.
We will walk your IT and risk team through hosting, data flows and the audit trail before any data moves.