One multi-tenant platform exposing eleven shared capabilities as APIs and SDKs. We buy the commodities and
build the moat: the reconciliation, the rules engine, the connectivity, the inference gateway, and — above all — the
cross-vertical intelligence that only a shared platform can accumulate.
The architectural thesis
OCR is a commodity. Model inference is a commodity. Reconciliation, per-country rules, tax-office & bank
connectivity, and pooled cross-vertical intelligence are the product. Build those; rent everything else. Every
layer is swappable except the two that compound with scale — the gateway
and the intelligence pool.
5.1 The eleven layers, as one stack
Top = what the operator's app touches; bottom = the shared foundation. The two highlighted layers are the defensible core.
So what: an operator integrates once and inherits all eight bands. They ship a recovery business in weeks, not the 12–18 months and $0.5–2M it costs to build this alone (Competition §4).
5.2 End-to-end: document in → cash out
Ingestion and inference are fungible; the reconcile → rules → connectivity path is the product. Filing stays human-in-the-loop until confidence and volume justify auto-submit. Every filed and settled claim becomes a training signal.
5.3 The inference gateway
Every model call — extraction, classification, drafting, RAG — passes through one optimised gateway. It is where cost
is controlled and quality is enforced, per tenant, at scale. This is the "single gateway tuned per use case" from the thesis.
Why a gateway, not direct calls
Cost control: route cheap high-volume tasks to small models; reserve large models for hard reasoning. Semantic caching removes repeat spend — the single biggest lever at platform volume.
Safety & compliance: PII redaction and guardrails on every call; structured-output enforcement means a wrong VAT number fails loudly, not silently.
Portability: providers are swappable behind one interface — no lock-in, and price/quality arbitrage as the market moves.
Accountability: per-tenant token & cost metering is what makes usage-based pricing (§6) even possible.
Build-vs-buy: start on an off-the-shelf gateway (LiteLLM / Portkey / OpenRouter) to move fast; harden the routing, caching and eval logic in-house as it becomes a cost centre and a differentiator.
5.4 The data network effect — technically
The single most important defensibility argument: pooled data becomes a compounding moat — without ever leaking a tenant's raw data.
The flywheel: more verticals → more claim outcomes → better fraud & success models → higher recovery → more operators. The pool holds aggregated, privacy-safe features — never a tenant's raw documents.
Isolation without isolationism
Tenant data is strictly isolated at rest and in transit. What enters the shared pool is aggregated,
de-identified signal — "invoices from supplier X in country Y are rejected 40% of the time," not the invoices
themselves. Federated / aggregated features give every operator the benefit of the whole network while each keeps its
own data private. This is both the moat and the EU-AI-Act / GDPR-aligned design.
5.5 Multi-tenancy, security & compliance
Tenant isolation
Row-level + schema separation per operator; per-tenant keys; strict boundary between tenant data and the aggregated intelligence pool.
EU data residency
EU-region hosting, encryption at rest & in transit, DPAs with model vendors (or self-host OCR for PII). GDPR & DORA by construction.
Human-in-the-loop
Confidence thresholds route low-certainty or high-stakes claims to review — satisfying the EU AI Act's oversight expectations for automated decisioning.
Auditability
Immutable audit log of every extraction, decision, and filing — evidence for tax authorities and a debugging spine for the platform.
5.6 Recommended stack — buy the commodity, build the moat
Layer
Recommended tech
Build / Buy
Foundation
EU-region cloud (AWS/GCP eu-*), Postgres / Supabase, Cloudflare R2 object store, Temporal for the extract→validate→file workflow
Versioned config-driven engine (per-country recoverability, caps, deadlines) — never hardcode
Build
Connectivity
Tax-office APIs (AEAT, ELSTER, SdI…), open banking via Tink/TrueLayer/GoCardless, VIES
Build
Cross-vertical intelligence
Feature store + fraud/success models trained on aggregated signals — the moat
Build
Developer surface
Multi-tenant REST/GraphQL APIs, TypeScript/Python SDKs, operator dashboards, Stripe for billing
Buy + Build
So what: ~70% of the stack is rented and swappable; the ~30% we build — reconciliation, rules, connectivity, gateway, intelligence — is exactly the part that compounds and can't be bought.
5.7 Build sequencing
Thin slice — one vertical, end-to-endRun the truck-tax reference vertical fully through the platform. Fake what you can (concierge filing, human rules) to prove the pipeline recovers real €.
Multi-tenant-iseExtract the shared layers behind clean APIs; add tenant isolation, per-tenant cost metering, and the operator dashboard. Onboard a second vertical to prove reuse.
Turn on the poolStand up the aggregated feature store; ship the first cross-vertical model (fraud or success-prediction) once ≥2 verticals feed it.
Fan outAdd verticals and countries against the versioned rules + connectivity layers. Automate filing as confidence and volume justify it.
Fast-iteration principles
Measure € recovered, not documents processed · fake the tax logic before you build the rules engine ·
OCR is a commodity, reconciliation is the product · one vertical flows end-to-end before fanning out · every rejected
claim feeds a rule, every human fix tunes a threshold, every outcome feeds the pool.
Sources & basis:
Architecture generalises the reference vertical's product/tech design (TTR / research §6, internal). ·
Gateway options — LiteLLM, Portkey. ·
IDP — Mindee / Veryfi. ·
Open banking — Tink / TrueLayer. ·
Connectivity & compliance detail in Risks §9. Stack choices are recommendations (md confidence); validate per-country integration effort before committing.