In a corporate AP shop, approval is often one step: a manager clicks approve under a dollar threshold and the invoice posts. In a public school district, that model falls apart on contact. Money is spent at the site level, authorised at the budget level, and processed centrally — three different people with three different responsibilities, and an attestation step that turns "approved" into a personal certification. Getting that chain right is most of the work of automating district AP on Oracle E-Business Suite.
Why one approval step isn't enough
A district invoice carries more obligations than a corporate one. The person who knows the goods or services were actually received works at the school. The person with authority over the budget the money comes from may sit somewhere else. And the people who own tax treatment, fund coding, and the posting to the ERP are central AP. No single approver can stand behind all of that.
So the routing has to reflect how the district actually delegates authority — typically a chain of three:
- Bookkeeper (site level). The person at the school or department who initiated the purchase and received the goods. They start the invoice and confirm what arrived.
- Budget manager. The person with authority over the budget being charged. They're the one who attests that the spend is legitimate and correctly funded.
- AP specialist (central). The team that validates the invoice, handles tax and fund coding, and posts it natively into Oracle.
Each step exists because it carries accountability someone else can't. Collapse them and you lose the control that public accountability demands.
The attestation step is the point
The most important moment in this chain isn't a routing decision — it's the attestation. When the budget manager approves, they shouldn't just be clicking a button; they should be presented with an explicit attestation statement and approving against it. The statement makes the approval a certification: that the goods or services were received, that the charge is appropriate, and that the budget being charged is correct.
That single design choice changes the character of the workflow:
- It puts a name behind every dollar. An auditor tracing a payment can see not just that it was approved, but who attested to what, and when.
- It moves the certification to the person who can actually make it. The budget manager owns the budget; they're the right party to attest, not central AP, who can't know whether a given site purchase was legitimate.
- It's captured, not assumed. The attestation is recorded as part of the audit trail, so the control is provable after the fact rather than implied by a signature on paper somewhere.
For public money, "approved" is too weak. "Attested by a named budget owner" is the bar.
Routing has to follow the fund and the site
The chain above is the shape; the routing logic fills it in. Two things drive who actually sees an invoice:
- The site. A bookkeeper starts the invoice and selects the budget manager it should route to — because the system can't always know which budget owner is responsible for a given site purchase, the initiator names them. From there the path is deterministic.
- The fund. Once the budget manager has attested, the invoice routes to the correct central AP queue based on the fund being charged. Districts often split central AP responsibility — for example, bond-funded or grant-restricted spend may go to a specialist who only handles those funds, while general operating spend goes to another. The routing has to read the fund coding and send each invoice to the queue that owns it, with the logic covering every valid fund so nothing falls into a gap.
Done right, each role sees only what's theirs. Bookkeepers see their site's invoices; budget managers see what they're accountable for; AP specialists see the funds they own. Nothing sits in a shared pile waiting for someone to claim it, and nothing slips between schools.
Notify at every step, and don't rely on rejection
Two operational details make a multi-step chain actually move instead of stalling:
- Notify at every hand-off. A three-step workflow has two hand-offs where an invoice can go quiet. An email at each step — to the next approver, and where appropriate to administrators — keeps the chain flowing and gives AP visibility into where anything is stuck.
- Design for send-back, not rejection. In a district, an invoice that isn't right usually needs to go back a step to be corrected and re-routed — not be killed. A send-back flag that returns the task to the previous role, with the reason captured, keeps the audit trail intact and avoids the dead ends that hard rejection creates. The goal is to get every legitimate invoice paid, with a record of every correction along the way.
Why this matters for K-12 AP on Oracle EBS
This routing-and-attestation model is exactly what generic AP automation gets wrong: it assumes one approver, a dollar threshold, and a profit-and-loss mindset, when a district needs a chain of accountable roles ending in a posting to the right fund. It's the same operating-model mismatch that makes fund accounting break generic AP automation.
EZ Cloud models the bookkeeper to budget manager to AP chain on top of Oracle EBS, with an explicit attestation step, fund-aware routing to the correct central queue, send-back instead of rejection, and a complete audit trail for public accountability. It's part of how we approach K-12 AP on Oracle EBS and the Education on Oracle EBS solution.
If your district's approvals live in a shared queue with a single approval step, the constraint isn't your ERP — it's the workflow on top of it. That's the layer worth building deliberately.