Resources / Business Office / Approval routing

Why doesn't the accounting system route approvals?

The short answer

The accounting system is built to be the district's financial record, and most of them are genuinely good at it. Routing approvals is a different job: it happens before the money moves, it involves people who never touch the finance system, and it has to enforce the district's own sequence of steps exactly, every time. Some financial platforms sell an approval or requisition module alongside the core system, and districts that praise the accounting side often quietly stop using the module, because an add-on rarely does its job as well as the platform does its own. The result in most districts is that the record of spending lives in the accounting system while the approval of spending lives in email, and the two only meet after the fact.

On this page

Two different jobs Why the add-on module usually goes unused Where the gap actually shows

What doing it well actually requires Common questions How Flow Forms handles it

Two different jobs

A ledger answers what happened: what was spent, from which fund, coded where. It is built for accuracy after the fact, and the major school accounting systems do that job well. Routing answers something earlier: who has to say yes before this happens, in what order, under what conditions. That job has different requirements. It involves the teacher requesting, the principal approving, the second approver above a dollar threshold, people who have no reason to hold a license or a login for the finance system and never will. It has to carry processes that aren't finance-shaped at all when the district wants one consistent way of approving things. And it has to hold the district's exact sequence rigid, because an approval path that can be varied under pressure isn't a path, it's a suggestion.

Why the add-on module usually goes unused

Many financial platforms offer a requisition or approval module, often sold separately, and the pattern business offices describe is consistent: strong core platform, weak module. That's not an indictment of the vendor; it's what happens when a product built to be a ledger grows a feature outside its center of gravity. The module tends to assume everyone in the chain works inside the finance system, and often prices accordingly, and handles the one process it was built for, the requisition, while everything else the district approves stays in email anyway. So the district ends up running two processes: the module for the workflows it fits, when it's used at all, and the informal channel for everything else. Most quietly consolidate on the informal channel, because at least it's one system everyone can operate.

Even a well-funded office doesn't escape this. The Montana Office of Public Instruction, before moving its requisitions into a routed workflow, ran the approval side on digital forms, email, and files on an internal hard drive, workable, in Annette Young's words, but slow enough that a snagged document could take days to locate. The financial system was doing its job the whole time. The approval process simply wasn't living in it.

Where the gap actually shows

The approval happens in email, the record happens in the ledger, and the space between them is where the audit questions live: who approved this, when, was the second signature obtained before the purchase or after. The business office ends up reconstructing the approval story at processing time, from threads and memory, to support numbers the accounting system holds perfectly. And because the informal channel enforces nothing, the district's actual approval practice drifts from its written one, person by person and shortcut by shortcut, without anyone deciding it should.

What doing it well actually requires

Running the approval layer well means keeping it rigid, universal, and separate from the ledger, and it comes down to a few specific parts.

The routing layer holds the process in stone

A routed workflow is the district's approval sequence made physical: the steps happen in the order defined, the conditions apply every time, and there is no informal variant, because the path is the only way through. Stephen Schreibeis, superintendent at Glendive Public Schools, describes the shift in exactly those terms: he sets the steps, the system carries them, and everyone involved knows what they need to do whether they're new to the role or twenty years in. Consistency stops depending on people remembering to be consistent.

It reaches everyone in the chain, not just finance system users

The people who initiate and approve requests work in classrooms, gyms, and bus barns. A routing layer has to reach them where they are, on whatever device is in their hand, without a finance license per person. That's the structural reason approval routing keeps ending up in email in the first place: email was the only tool everyone already had. The fix keeps that universality and adds the enforcement email never had.

It carries every process, not just the finance-shaped ones

The same routing that moves a requisition moves a professional development request, a maintenance report, a leave request. Districts like Glendive run a dozen and more workflows across every department through one routing model. No accounting module is built to do that, and it shouldn't be; it has a ledger to run.

It hands the accounting system exactly what it needs

Flow Forms runs alongside the accounting systems districts already rely on, Tyler, Black Mountain, and PowerSchool among them, handling the approval path upstream and handing the finished, documented decision to the ledger. The two systems meet at a clean seam: approvals complete upstream, and what reaches the business office is ready to process. Philipsburg School District No. 1 exports its month's purchase orders with everything needed for claims processing, out of the workflow and into the format the finance side expects. The ledger stays the record of money. The workflow is the record of permission.

Common questions

Questions we hear from every business office.

Why do districts still approve purchases by email when the accounting system has a requisition module?

Usually because the module fits only part of the picture: it assumes approvers work inside the finance system, it covers requisitions but not the dozens of other things a district approves, and licensing everyone who ever touches an approval rarely makes sense. Email is universal, so the process migrates there, and the module sits unused. The durable fix isn't forcing everyone into the finance system; it's a routing layer that's as universal as email and as rigid as the written process.

Does moving approvals out of the accounting system mean replacing it?

No, and it shouldn't. The accounting system stays the financial record; that's the job it's good at. The routing layer runs in front of it, and what crosses over is complete: approved, documented, ready to process.

How do the approval records and the financial records stay connected?

The workflow holds the approval story, who approved, when, in what order, searchable per request, and delivers its output in the form the business office processes from, including structured exports. When an auditor asks who approved a purchase, the answer comes from the routing record; when they ask what it cost, from the ledger. Each system answers the question it was built for.

Can approval routing handle dollar thresholds and second approvers the way our policy requires?

Yes, that's the core of what routing means: the path branches on the conditions the district sets, an amount over the threshold picks up the second approver automatically, and the condition applies every time rather than when someone remembers it. The policy and the process become the same object.

Our accounting software is fine. What problem is this actually solving?

Exactly the right frame. The problem isn't the accounting software; it's everything that happens before a transaction is ready to be one, the request, the yes, the second yes, the documentation, currently living in email and inboxes. That layer is the one with no system behind it.

How Flow Forms handles it

Flow Forms builds the approval layer as its own routed workflows, shaped to the district's exact steps and conditions, reaching everyone in the chain on the devices they already carry, across every process the district approves and not only the finance-shaped ones. The accounting system stays precisely where it is, receiving work that arrives complete. The same team that builds the routing stays on to change it when the policy changes.

See how it would work for your district →