In a public school district or agency, the right question for any invoice isn't "who's senior enough to approve this?" It's "whose budget does this spend?" The two are not the same, and confusing them is why so much public-sector AP routing is done by hand every morning.
Money is decentralized. A single ERP instance covers dozens of schools, departments, programs, and sites, each with its own budget and its own owner. The person who actually knows whether a cost was authorized — and who answers for it at budget time — is the manager who owns that budget line. Routing has to find that person, every time, without an AP clerk holding the map in their head.
Why the org chart is the wrong source
The tempting approach is to encode an org chart: this department's invoices go to that director, escalate above a threshold, and so on. It works until it doesn't, which is immediately:
- Budgets don't follow reporting lines. A program funded out of a specific grant may be owned by someone who isn't anyone's "manager" on the org chart. The funding decides accountability, not the hierarchy.
- One invoice can spend several budgets. A vendor bills for work touching two schools or two programs. There's no single org-chart node that owns it — there are two budget owners, and each needs to see their portion.
- Org charts go stale. People move, sites reorganize, programs get reassigned. A hardcoded reporting tree is wrong within a year and silently routes invoices to the wrong desk in the meantime.
Dollar-threshold routing has the same blind spot from the other direction — it answers what level of authority is needed, never which person owns the spend. Budget-owner routing fills that gap: the signal lives on the accounting line, so the invoice finds the manager who actually owns the money it spends.
The funding line already knows who owns it
Here's the insight that makes this tractable. By the time an invoice is coded, the GL/funding line already encodes which budget it spends — the fund, the cost center, the program, the site. That distribution is the routing key. You don't need a separate org chart; you need a mapping from each budget dimension to the person who owns it.
So the model becomes:
- Read the funding line(s) on the coded invoice.
- Look up the budget owner for each — the manager accountable for that fund, department, or program.
- Route to that owner automatically, so the correct manager sees the invoice and only that manager does.
When an invoice spends one budget — the common case — it goes to one owner. When it spends several, each owner sees their slice and nothing else. The routing tracks the money, not the title.
The customer controls the mapping
This only works if the people who actually run the district control the rules. The budget-owner mapping is the customer's to define and maintain, not something baked into the software:
- Finance defines who owns what. Which manager owns which fund, department, or program is a decision only the organization can make — and it's the decision that makes routing correct on day one.
- It updates as the organization changes. When a program is reassigned or a new site comes online, finance updates the mapping; the routing follows immediately. No code change, no waiting on a vendor.
- It's auditable. Because the mapping is explicit, you can show an auditor exactly why a given invoice reached a given approver — the funding line said so, and the mapping is on record.
Putting the mapping in the customer's hands is what turns routing from a clerk's institutional memory into an enforced, inspectable control.
Each manager sees only what's theirs
The flip side of routing to the right owner is not routing to the wrong ones. In a shared-pile model, every approver can see — and act on — invoices that aren't theirs, which is both a workload problem and a segregation-of-duties problem.
Budget-owner routing fixes both. Each manager opens their queue and sees a clean list of the invoices that spend their budget, waiting on their approval — nothing from the school across town, nothing from a program they don't own. The work is partitioned the way the budgets are, so:
- Nothing falls through the gap between departments, because every funding line maps to an owner.
- No one wades through noise, because the queue is scoped to what they're accountable for.
- Accountability is unambiguous — the person approving is the one who owns the budget and knows whether the spend was authorized.
A sensible design keeps an override for the exceptions — someone on leave, an unusual cost — so AP can reassign in one action without fighting the rule. Automation handles the routine majority; the override handles the rest.
Where EZ Cloud fits
Routing each invoice to its budget owner — derived from the funding line, governed by a mapping the customer controls — is exactly the kind of decentralized-AP problem that years of real Oracle public-sector work teaches you to design for. EZ Cloud reads the coded distribution at approval, looks up the budget owner from your mapping, and routes each invoice (or each portion of a multi-budget invoice) to the right manager's queue, with a one-click override for the exceptions. It pairs naturally with threshold and attestation controls in K-12 approval workflows and is part of the Education on Oracle EBS solution, built on our Oracle EBS & Fusion integration.
If your AP team is reassigning invoices by hand every day because the system can't tell who owns which budget, that knowledge is sitting in someone's head — and it doesn't have to be. The funding line already knows the answer.