Identity
Supplier identity resolved against the vendor master, including normalised names, aliases and tax identifiers. Prevents the classic near-name substitution.
Platform
One service owns the lifecycle. Everything else is evidence.
Procure-to-Pay Platform is not a document router with matching bolted on. It is a state machine over a transaction case, fed by evidence from your suppliers, your receiving bays and your systems of record, governed by versioned rules and an append-only audit ledger.
The transaction case
Document-led processes lose. State-led processes hold.
In most organisations the procure-to-pay process is a sequence of files moving between people. Nothing owns the transaction, so nothing can say what state it is in or which transitions are legal. When something goes wrong, the answer has to be reconstructed from mailboxes.
Here, a match case is the aggregate. It links the order version, the supplier's response, the delivery note, the receipt evidence, the official goods receipt, the invoice and any adjustments. It has a state, a version, an owner and a complete evidence timeline. Every evaluation pins the evidence versions it was computed against, so a result can always be reproduced and explained months later.
Why version pinning matters: without it, a match result computed on Tuesday can
silently become indefensible on Thursday because someone amended the order. With it, the result
says exactly which order version, which goods receipt version and which rule version produced it.
Case states
Illustrative. States, transitions and their guards are configured per customer.
AWAITING_ACKNOWLEDGEMENT
AWAITING_RECEIPT
AWAITING_INVOICE
EVALUATING
EXCEPTION
MATCHED_WITH_WARNINGS
MATCHED — READY FOR PAYMENT REVIEW
APPROVED_FOR_PAYMENT
REOPEN_REVIEW_REQUIRED
A late correction from an approved or paid state does not overwrite history. It raises REOPEN_REVIEW_REQUIRED, preserves the prior decision and remittance record, and routes to independent finance disposition with the amount at risk attached.
Match & decision
Matching is a set of dimensions, each of which can explain itself.
A match is not one pass/fail. It is an evaluation across dimensions at both header and line level, including permitted one-to-many relationships — one order against several deliveries, one invoice against several receipts.
Version
Which order version was live, which version the supplier accepted, and whether the document under evaluation belongs to that version.
Line identity
Canonical line matching across supplier SKUs, internal codes, aliases and units of measure. Low-confidence candidates never auto-link — they route to controlled mapping with versioned alias approval.
Quantity
Ordered against committed, delivered, received, rejected and invoiced. Partial and over-delivery handled explicitly, with configurable tolerance by line, supplier or category.
Price & amount
Unit price, extended amount, currency, tax treatment, discounts and rounding — measured against the accepted commitment, not just the original order.
Date & sequence
Committed delivery date against actual, and the ordering of events. An invoice may arrive before a receipt; payment readiness may not.
Tax & compliance
Whether the invoice carries a valid electronic tax document under the applicable regime, and whether it is correctly attributed to your entity.
Duplicate
Layered: file hash and event identity, then invoice identity, then near-duplicate business attributes — checked across every intake channel.
Fraud risk
An overlay rather than a dimension. A matched case with an active high-risk or duplicate overlay stays held until an authorised investigator clears it with a reason.
Configurable, not hard-coded. Which dimensions apply, what the tolerances are, what
counts as a warning versus a failure, and who resolves each — all of that is configuration scoped to
document class, supplier, entity, business unit or process. Changing a tolerance is a governed
configuration change with its own version and audit record, not a support ticket and a release.
Surfaces
Five workspaces, one policy engine.
What a person can see and do is decided by the policy engine, not by hiding menu items. A user never sees a control they cannot use; where an action is partially available it is shown disabled with the reason. Every case, queue view and report is a deep link — shareable, auditable and correct on the back button.
Buyer workspace
Work queues, the case workspace with evidence side by side, per-dimension match detail, line-identity mapping, payment review, re-open review and reporting.
Supplier portal
Invitation and onboarding with MFA, orders addressed to that supplier only, line-level response bound to an order version, delivery note creation or upload, invoice upload, exception response and remittance download. Mobile-responsive, because many suppliers are on a phone.
Receiving
Line-level receipt capture at the point of delivery, rejected and damaged quantities, batch and expiry evidence, and the proposed receipt that reconciles against the official goods receipt.
Control & investigation
Duplicate and fraud investigation with restricted access, information requests, SLA and escalation, separation of duties, and disposition capture that feeds the feedback model.
Administration
Entities, business units, branches, users, roles and policies, rule sets and tolerances, document classes, adapters and source health, entitlements, retention and export.
Assistive AI panel
Natural-language query that is read-only and scope-enforced and shows the query it generated; case summaries labelled as AI-generated and requiring human verification; suggested exception resolutions with rationale. None of it can mutate a case.
Entitlement model
The core is mandatory. The rest you license.
Entitlements control what is available. Feature flags control safe rollout. Configuration controls behaviour. Disabling a module preserves its historical records and their audit access — you do not lose the past by changing the future.
Product core — cannot be disabled
- Tenant and licence entitlement management
- Advanced IAM: users, groups, roles, policies, resources, conditions, explicit deny, separation of duties
- Entity, business unit, branch, location, currency, time zone and rule configuration
- Tamper-evident append-only audit and event history
- Notification framework and observability
- Workflow and decision orchestration with versioned rule sets and human overrides
- Integration runtime, canonical data model, mapping tools, retries, idempotency, reconciliation, dead-letter handling
- AI/ML governance: feature provenance, model registry, evaluation approval, inference audit, monitoring, rollback
Licensable modules
- Omnichannel intake
- Document AI
- Supplier collaboration
- Receiving
- Match & decision
- Exception intelligence (advisory)
- Workflow automation
- Duplicate detection
- Fraud risk intelligence
- Supplier management
- Adjustments & returns
- Remittance advice
- Analytics & assistive AI
- AI/ML data & model enablement
- Cash-flow forecasting (governed opt-in, advisory only)
AI posture
Governed intelligence, with a permanent line drawn.
AI in this product does classification, extraction, normalisation, duplicate and fraud signalling, triage ranking and suggested resolutions. Everything it produces records feature provenance, the rule or model version, confidence, evaluation status and the human disposition that followed.
Autonomous approval of a payment is a permanent non-goal. Not a roadmap item, not a future toggle. A matched case still requires an authorised finance user to approve payment preparation. Advisory features rank and suggest; they never change a case state or apply a tolerance without an approved configuration change.
The OCR engine and the governance substrate that manages it are both per-customer, opt-in profiles behind an engine-neutral seam: self-hosted vision-language OCR by default, cloud document AI or a classical fallback where you choose it. Whichever you pick, there is no shared-model training on your data and no cross-customer learning by default.
What is advisory, and what is a control
| Capability | Status |
|---|---|
| Match evaluation & tolerances | Deterministic control |
| Duplicate: file & event identity | Deterministic control |
| Document classification & extraction | Model, human-correctable |
| Near-duplicate detection | Model, thresholded |
| Fraud risk score | Explainable, holds for human |
| Exception triage & suggestions | Advisory only |
| Cash-flow forecasting | Advisory, opt-in |
| Payment approval | Human, always |
Architecture
Modular services, hard boundaries, one deployable.
We build modular services aligned to stable business domains and deliberately avoid unnecessary service fragmentation. Module boundaries are enforced by import linting and contract tests, so extracting a module into its own service later is a refactor, not a rewrite. Document AI workers and the integration runtime are the first natural extractions because they are asynchronous and compute-bound.
Backend
Python 3.12, FastAPI and Pydantic v2 with the canonical data model enforced at the boundary, SQLAlchemy 2.0 and Alembic. One language across backend, document AI and the data pipeline.
Data
PostgreSQL 16 as the system of record. Row-level security scopes every table by tenant. Optimistic concurrency via a monotonic case version. Audit and document tables partitioned by tenant and time.
Frontend
A single typed SPA with a design system built on accessible primitives. Canonical types are generated from the OpenAPI specification, so a backend contract change breaks the build in CI rather than in production.
Explainability components
Dimension results, risk explainers, evidence timelines and AI labels are first-class reusable components — the explainability principle encoded in the interface, not left to each screen.
Accessibility
Contrast ratios enforced at build; a tenant cannot theme into a WCAG failure. Reduced motion respected. Comfortable and compact density for power users.
Isolation, tested
Cross-customer isolation is verified by a two-tenant adversarial negative-access suite across dataset, queue, cache, audit and ML-export boundaries, and independently reviewed.
See it against your own process.
Bring one exception that cost you a week. We will show you what the match result would have said and who it would have gone to.