Number7AI — Docs
Multi-client AP management
BPOs and shared-services teams need a fundamentally different operational model from single-entity AP. Scale comes from shared automation with hard client isolation — not from running separate tools per client.
Last updated: April 2026
TL;DR
- •Client isolation is enforced at the data layer — not just through UI access controls.
- •Validation policies, vendor masters, and audit logs are per-client, not shared.
- •Extraction and exception tooling is shared, giving BPOs the benefit of scale without per-client customisation overhead.
- •Exception queues are designed for operator efficiency — not for invoice volume.
The core tension: isolation vs. scale
Multi-client AP has a structural tension: clients need strong data isolation and custom controls, but BPOs need operational scale through shared tooling. Most AP platforms are built for single entities and bolt on multi-tenancy as an afterthought — resulting in either weak isolation (shared validation logic, shared vendor masters) or poor scale (separate logins, separate queues per client). The patterns below describe how to resolve this tension correctly.
Client isolation patterns
Data boundary enforcement
Each client entity is a hard namespace. No cross-client data leakage is possible in queries, exports, or audit logs regardless of operator permissions.
Per-client validation policies
Tolerance thresholds, required fields, mandatory three-way match, and approval chains are configured independently per client — not shared across the account.
Client-specific vendor masters
Vendor identity data (names, GSTINs, bank details) is maintained per client. An ABC Traders for Client A is independent of ABC Traders for Client B.
Separate audit logs
Every extraction event, edit, approval, and export is logged in client-scoped audit trails. Cross-client views are not possible without explicit admin escalation.
Shared automation patterns
Shared extraction engine
The same trained extraction models serve all clients. BPOs benefit from scale — model improvements from high-volume clients flow to all without per-client retraining.
Centralised exception dashboard
Operators see a unified queue across clients with client-level filters. Exception SLAs are tracked per client without requiring separate logins.
Bulk upload routing
A single upload endpoint accepts batches and routes pages to the correct client namespace based on filename patterns, folder structure, or metadata tags.
Cross-client benchmarking
Aggregated (anonymised) metrics across clients allow benchmarking of STP rate, error rate, and cycle time without exposing individual client data.
Exception queue design
Exception-first queue design
Operators work exceptions, not the full invoice flow. Normal invoices post without human touch. Queues surface only items that require a decision.
Priority lanes
High-value invoices, overdue items, and SLA-at-risk exceptions are surfaced in a priority lane above standard-queue items.
Client SLA tracking
Each client can have a different exception-resolution SLA. The queue surface shows time-to-breach prominently to prevent SLA misses.
Bulk action capability
Common exception types (e.g., missing PO reference for a specific vendor) can be resolved in bulk with a single policy decision rather than one-by-one.