Deployment & security

Same build. Your environment. No customer fork.

Most of this category is multi-tenant SaaS and nothing else. That is a reasonable engineering choice and a bad answer for an organisation whose regulator, board or data-protection authority requires the financial record to stay in a specific place. Procure-to-Pay Platform ships as containers so the deployment decision is yours, not ours.

Deployment profiles

Three profiles, one codebase.

What differs between deployments is configuration, entitlements and adapters — never a fork of the product. That is what stops the second customer costing what the first one did, and it is what makes an upgrade a routine operation instead of a bespoke project.

Dedicated on-premises

Runs entirely inside your data centre, with no dependency on a hosted control plane. For organisations whose financial record cannot leave the building — regulated financial services, public sector, and anywhere a board policy or a national cybersecurity framework says so.

The honest trade-off: you own the infrastructure, the upgrade window and the operational monitoring. It is not the cheapest way to run this. For some organisations it is the only way, which is why it exists.

Dedicated private cloud

Your AWS, Azure or GCP account, your VPC, your region, your keys. Delivered as containers to EKS, ECS, AKS, GKE or any conformant Kubernetes. The most common choice for organisations with a data-residency requirement but no desire to run racks.

Regional footprint is your decision: Middle East, Europe, Africa, or wherever your obligation points.

Multi-tenant SaaS

We run it, you consume it. Appropriate where there is no residency constraint and you would rather not carry the operational load. Tenant isolation is enforced at the database, not by application code alone.

A customer that contractually requires physical isolation can be given a dedicated database rather than shared tables.

Isolation

Tested, not asserted.

Every vendor asserts tenant isolation. Very few show you the test. Isolation here is a control with evidence behind it: row-level security policies scope every table by tenant in the database, so a bug in application code cannot leak across a boundary that the database itself enforces.

On top of that sits a deliberate adversarial test layer. With two configured tenants, customer A must be unable to read, export or train a model on customer B's data across dataset, queue, cache, audit and ML-export boundaries — and that suite is graded by a reviewer independent of the team that built it.

PostgreSQL row-level security scoped by tenant on every table
Optimistic concurrency on the case aggregate; stale writes are rejected, not merged
Dedicated database available where physical isolation is a contractual requirement
Two-tenant adversarial negative-access suite, independently reviewed
Audit and document tables partitioned by tenant and time

Advanced IAM

Users, groups, roles, resources, conditions and explicit deny, with separation-of-duties controls across internal, supplier, service and external actors. Access scope follows entity, business unit and branch.

Append-only audit

Tamper-evident event history covering every action, decision, evidence version and configuration change — including who changed a tolerance, when, and what it was before.

Supplier data isolation

A supplier sees only their own organisation's data. Exception views are a deliberately narrow projection: the order reference, match state and failing dimensions — never risk indicators, fraud scores or investigator notes.

Idempotency everywhere

Files are hashed and messages, attachments, uploads and job events are identified so that a retry, a resent email or a re-uploaded document cannot create a second payable transaction.

AI engine & governance substrate

Selectable, not hard-wired — including the option where nothing leaves your network.

Document AI is where most of this category quietly sends your invoices to somebody else's cloud. Here the OCR engine and the substrate that governs it are both per-customer, opt-in profiles behind an engine-neutral seam.

Engine options

Self-hosted vision-language OCR — the default. No document leaves your environment.
Cloud document AI — opt-in, where you accept it and a data-processing agreement is in place
Classical fallback — for constrained environments

Governance substrate options

On-premises registry — the default
Snowflake Model Registry with Snowpark Container Services — opt-in
Native cloud MLOps — opt-in

Whichever combination you choose: no shared-model training on customer data, isolation per customer, recorded provenance, and a governed lifecycle covering evaluation, approval, deployment, monitoring, rollback and retirement. Any external engine requires a no-training, zero-retention, isolation data-processing agreement before it can be selected at all.

Operations

Built to be run by someone who is not us.

An on-premises product that only the vendor can operate is not really an on-premises product. These are the things your platform team will ask about in the first hour.

Delivery

Container images with Helm charts for Kubernetes; suitable for EKS, ECS, AKS, GKE or self-managed clusters. Document AI workers and the integration runtime scale independently of the transactional path.

Observability

Structured logs, metrics and traces. Source-system sync status and freshness are exposed as first-class operational data, not buried in logs — an operator can see which adapter is stale and how stale.

Dead letters & replay

Failed integration events land somewhere visible, with the reason attached and a controlled replay path. Reconciliation between the source system and the canonical model is a routine job, not an incident.

Retention & export

Configurable retention aligned to your jurisdiction's obligations, with controlled export. Anonymised ML export is schema-validated, lineage-tracked and access-controlled.

Accessibility

Contrast ratios are enforced at build time — a tenant cannot theme the interface into a WCAG failure. Reduced motion respected; comfortable and compact density for high-volume users.

Upgrades

Because there is no customer-specific fork, an upgrade is the same operation everywhere. Contract tests and import linting keep module boundaries honest between releases.

Bring your architect to the working session.

Residency constraints, isolation requirements, ERP estate, network posture. Forty-five minutes, technical, no slideware.

Book a working session How to buy