Walk into almost any operations-heavy business and you'll find the same rule, unwritten but iron: anything over a certain dollar amount waits for the owner.
Invoices over the threshold. Credits over the threshold. Purchase orders, refunds, change orders. They queue in an inbox, and the inbox belongs to the busiest person in the company. The work is usually done in minutes. The waiting is done in days.
Nobody designed this. It's scar tissue. Years ago something went out that shouldn't have, it cost real money, and the fix was "from now on, I see everything over five grand." That rule was correct on the day it was written. Then the company doubled, and the rule became the slowest conveyor belt in the building.
What it actually costs
The direct cost is easy to feel and hard to see. Vendors call about late payments, so someone spends the morning apologizing. Early-payment discounts expire in the queue. A crew waits on a part because the PO that buys it is under a beach umbrella with the only person who can approve it.
The indirect cost is worse. Our own audit math says two days a week of manual work is roughly a $70K salary wasted, and most companies this size run two or three leaks like that at once. Approvals-by-inbox is usually one of them, and it's the one that also taxes the most expensive calendar in the company: the owner's.
Why nobody fixes it
Because the rule feels like control, and removing it feels like losing control. That instinct is right, and it's why the usual advice, "just delegate it", doesn't land. Delegation moves the bottleneck to a different person. It doesn't remove the judgment problem: which of these actually needs eyes?
Here's the thing we keep finding when we sit with an owner and actually read the queue together: almost all of it is the same approval, over and over. Same vendor, same range, same job code, matched to a PO that was already approved once. The owner isn't making a decision. The owner is confirming a pattern.
The fix is a rule, not a person
Patterns are what software is for. The fix we build is a rules engine with three outcomes:
Approve automatically when the invoice matches the PO, the PO was approved, the vendor is known, and the amount is inside the pattern. This is the bulk of the queue, and it clears in seconds instead of days.
Route to the right person when it's routine but outside one variable: a new vendor, a small overage, a job that's over budget. That goes to the controller or the ops manager, with the reason attached, not to the owner.
Stop and escalate when it's genuinely odd: an amount out of pattern, a duplicate, a vendor nobody's used. That's the short list the owner should see, and now it arrives with the context that used to take twenty minutes of digging.
Notice what the owner gave up: nothing. Every rule in the engine is the owner's own judgment, written down once instead of applied by hand forever. The exceptions still get human eyes. That's our standing commitment anywhere automation touches money: a human reviews the exceptions, in the contract, in writing.
What this looks like in practice
This is one of the leaks we price in every Workflow Sprint, because it's fast to find and fast to fix. Reading the queue takes a day. Writing the owner's judgment into rules takes another. And it's the kind of automation that can be live on real data inside the sprint window, which is exactly why we like it as a first build.
The return gets named before we build, like everything we ship: this one is usually save it, cost out of the approval loop, and sometimes make more of it, when the unstuck POs are what's holding up billable work.
If your version of the five-grand rule is older than your last office move, that's the tell. The rule didn't get worse. The company outgrew it.
