The problem
Approver routing is the field nobody thinks about until it goes wrong. Every invoice and PO needs to be routed to the right approver before it can post. In small organizations, there is one approver and it is obvious. In growing organizations, the approval matrix gets complex: cost-center owners approve their cost-center spend, project managers approve their project spend, department heads approve above a threshold, the CFO approves above a higher threshold, and the auditor flags any out-of-policy routing.
The complexity is exactly the shape of the conditional probability problem. Given the supplier, the category, the amount, the cost center, the project — who has approved this combination 47 times out of the last 50 occurrences? That is the answer the routing decision should default to.
How it works
The same _predict query that predicts GL code and cost center predicts the approver. Inputs: supplier, category, amount, cost center, project, customer_id (multi-tenant). Output: predicted approver with calibrated probability and $why factor decomposition. The approval matrix policy still applies — predicted approvers must be authorized at the relevant amount tier — but the prediction handles the routing layer above the policy.
The system handles role changes naturally. When an approver leaves or moves teams, their override pattern stops appearing in new transactions; the conditional probability on combinations they used to approve drops; the prediction shifts toward the new approver. No retraining; the data flow handles it. Person-keyed predictions need to be more reactive to recent overrides than account-keyed predictions — handled automatically because every override is the next prediction's training signal.
{
"from": "purchase_orders",
"where": {
"supplier": "Acme Supply Oy",
"category": "office_supplies",
"amount": 1240.00,
"cost_center": "CC-EUR-MARKETING-2026"
},
"predict": "approver",
"select": ["$p", "$why", "approver"],
"limit": 3
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🧾 Accounting demo today. Click through to the live application and inspect the queries that produce the result. Source is on GitHub under Apache 2.0.
Frequently asked
How does this respect our approval matrix policy (limits, escalation thresholds)?
The policy applies as a constraint on top of the prediction. Aito returns the most-likely approver; the application checks the predicted approver against the policy — if the predicted approver is not authorized at the relevant amount tier, the application escalates to the next-most-likely qualified approver. The prediction is the routing default; the policy is the constraint.
What happens when an approver leaves the company?
Their override pattern stops appearing in new transactions; the conditional probability on combinations they used to approve drops over time. The system shifts the prediction toward the new approver as the new approver's pattern accumulates. Person-keyed predictions need to be more reactive to recent overrides than account-keyed predictions — handled automatically because every override is the next prediction's training signal.
Can the prediction handle multi-approver workflows (parallel sign-off)?
Yes. Multi-approver workflows are a top-N prediction rather than top-1. The system returns the predicted approver for each role (cost-center owner, project manager, finance) as separate predictions. The application orchestrates the parallel routing. The predictions are independent per role; combinations come from the application logic.
How does this work with SAP, Oracle, or NetSuite approval flows?
The integration is HTTP and JSON. The ERP queries Aito for the predicted approver, gets a calibrated probability, and either auto-routes (above threshold) or surfaces the suggestion in the existing approval UI. The predictive operators that have run in Nordic enterprise AP since 2018 sit behind a SAP + UiPath + Aito stack; analogous integrations exist with Oracle and NetSuite.
What if the predicted approver is out of office?
The application checks the approver's calendar or status before routing. If the approver is unavailable, the system can route to the second-most-likely approver (using the same prediction's top-2) or to the approver's delegate as configured in the ERP. The prediction surfaces the alternatives; the calendar check picks among them.
