Stop Unauthorized Purchasing: PO and Budget-Gate Approval

A site manager at a precision parts maker in Shizuoka, about 280 staff and supplying automotive OEMs, needs a replacement spindle motor for a CNC latte. The line is down and every hour costs roughly 200,000 yen in lost output. He emails a supplier, copies the purchase order to accounting, and the part arrives two days later. The invoice lands on the desk of a finance clerk who notices, for the first time, that the order came in at 6.4 million yen. Nobody asked the executive who is supposed to approve anything above 5 million. By then the part is installed, the line is running, and the company is left explaining the breach at the next internal-control review.

That is maverick buying in one clean example. It is not fraud. It is the slow erosion of the ringi authority rules (what Japanese firms call the approval-authority regulations) when purchasing runs on email and spreadsheets. Orders above a manager's real authority slip through because nobody checks the amount against the threshold. Budget overruns surface only at month-end close, far too late to act. This post is about how a core business system stops both problems at the point of request, with an approval gate that routes by amount and flags the moment a request crosses its budget line.

The Quiet Cost of Ungated Purchasing

The authority rules are supposed to be the spine of procurement governance. A typical manufacturer writes them down once, prints them in a policy binder, and then never enforces them again. What follows is predictable. A purchase order for 4.9 million yen is approved by a section chief whose limit is 1 million, because the amount was split across two lines. An order for 8 million is approved by a department head whose limit is 5 million, because nobody on the email chain checked. The rules exist on paper and nowhere else.

Maverick buying is the name for purchases made outside negotiated supplier contracts and approved channels. It is well established that off-contract spend carries a price premium over governed purchasing on the same goods, because it skips the negotiated rates, the volume rebates, and the supplier vetting that the contract was built around. For the Shizuoka maker spending roughly 3 billion yen a year on materials and parts, even a small premium on a fraction of off-contract orders is millions of yen that never needed to leave the building. The exact size of that premium varies by category and supplier, but the direction is never in doubt: ungated purchasing costs more than governed purchasing on the same goods.

Then there is the budget side of the same coin. A request might sit inside the requester's authority limit and still blow a budget line. The factory maintenance budget for the quarter is 40 million yen. The spindle motor plus a earlier tooling order quietly push actual spend to 46 million. Nobody knew, because the budget and the purchase order live in two separate systems that do not talk. The overrun is discovered when finance closes the books at month-end, by which time the cash is gone and the only option is to explain the variance in the management meeting.

A core business system changes where this gets caught. It moves the checkpoint from month-end backwards to the moment a person types the amount into a purchase request. That single shift is the difference between preventing a problem and documenting one.

An Approval Gate That Reads the Amount and the Budget

The engine that does this lives inside the workflow layer of a modern ERP. It is built and running today, and it is the same system that already owns the ledger and the purchase orders. Reading the actual approval code, here is what genuinely exists versus what is still on the roadmap. Honesty about that line matters more than overselling.

Routing by amount threshold, automatically

When a purchase request is submitted, the system reads the total and routes it along the correct approval path based on the amount. This is conditional threshold routing, and it is live today, not a roadmap item. A request under 1 million yen can be approved by the requester's own manager. The moment the total crosses 1 million, the system adds the department head to the chain. Cross 5 million, and the route extends to an executive. The requester does not choose the approver. The amount does. There is no way to slip a 6.4 million yen motor past a section chief, because the system never sends it there.

This matters because it makes the authority regulations self-enforcing. The rule that lives in the policy binder becomes the rule that actually decides where the request goes. The logic survives reorganizations too, because approvals route to the role (manager of the purchasing department) rather than to a named person. When someone changes seats, the flow keeps working.

A budget-overrun gate that catches the cross

The second gate is the one most companies do not have at all. Each request can be tied to a budget line. When the request is submitted, the system can flag that the projected spend would cross that budget line, and trigger an extra approval before the request proceeds. This is the difference between an order that is within authority but over budget being caught on submission, and the same order being discovered in the management variance report a month later.

This is also where the honesty line sits. The approval routing and the threshold logic are built and live. The budget-overrun gate, in its fullest form where the workflow reads live committed budget from the core business system and writes the approved amount back to the budget line on approval, is on the roadmap today. The conditional routing and the threshold trigger are the guardrails you can switch on now. Automatic creation of the purchase order record and the budget writeback are what comes next. Stating that boundary plainly is how trust stays intact.

A Scenario: The Shizuoka Precision Parts Maker

Return to the maker in Shizuoka. Before the approval gate, the spindle motor order would have sailed through on an email. The site manager types the request into the system instead. He enters the supplier, the part number, and the 6.4 million yen total, and he tags the request to the factory maintenance budget.

Two things happen before any human sees it. First, the amount crosses 5 million yen, so the system routes the request past the section chief and the department head, straight to the executive who holds authority at that level. The section chief cannot rubber-stamp it because it never lands in his queue. Second, the request is flagged against its budget line, because the quarter's maintenance budget is already close to spent. The executive sees both signals on one screen: this is a large order, and it crosses the budget. He approves it with full knowledge, or he asks the maintenance team to defer it to next quarter. Either way the decision is deliberate, not accidental.

Multiply that across a year. The maker runs roughly 4,000 purchase orders annually. At a conservative 25 minutes of handling per paper-and-email order, and eight minutes in the gated flow, that is about 1,130 hours of purchasing time saved each year, which at a 3,000 yen loaded back-office rate is around 3.4 million yen in direct labor. The larger figure, the one that resists clean accounting, is the off-contract premium and the budget overruns that no longer happen because the gate stopped them at request time. A single large off-contract order caught at submission, rather than explained at month-end, can outweigh the direct labor savings many times over.

Why Month-End Discovers What Approval Should Have Caught

The reason budget overruns surface at month-end close is structural. In a fragmented setup, the purchase order is an email, the budget is a spreadsheet, and the books are an accounting package. Nothing connects them until a person sits down at month-end and reconciles the three. By then the spend is history. The variance report becomes a postmortem, not a control. An ERP with the workflow, the budget, and the purchase orders in one place changes that.

An ERP with an approval gate inverts that timeline. The purchase request, the authority rule, and the budget line all live in the same system, so the comparison happens at submission, not at close. Month-end gets shorter because there are fewer surprises to investigate. Finance stops being the team that reports bad news a month late and becomes the team whose rules prevented the bad news from forming in the first place.

This is the deeper argument for governing purchasing in the core business system rather than in a standalone procurement tool. A standalone tool can route an approval. It cannot, on its own, read the live budget ledger or post the commitment back. That connection is what turns an approval flow into spend control. It is also why a core business system that already owns the ledger, the purchase orders, and the workflow engine is a better home for this gate than yet another point solution.

Common Questions, Answered Honestly

Can the approval thresholds match our existing authority regulations?

Yes, and they should. The thresholds are configurable, so the 1 million and 5 million yen breakpoints in the example map directly to whatever your ringi authority rules already say. The point of automating them is not to invent new policy but to enforce the one you already wrote. A common first step is to transcribe the current authority table into the routing rules verbatim, then refine from there.

What happens to a request that crosses a budget line?

It gets flagged for an extra level of review before it proceeds. The requester still files it, but the system adds the budget owner or the finance lead to the approval chain because the projected spend crosses the line. The honest qualifier is that the fully integrated budget-overrun gate, where the workflow reads committed budget live and writes the approved amount back to the budget line automatically, is on the roadmap. The approval routing and the threshold trigger that catch the breach at request time are built and live today.

Does approving a request automatically create the purchase order?

Not yet, and we will be direct about that. The approval gate and the conditional amount routing are built and running. Automatic creation of the purchase order record on approval is on the roadmap, as is the budget writeback. Today an approved request produces a clean, fully-audited approval record, and the purchase order itself is created from that record in the normal flow. The removal of that last manual step is what the roadmap closes.

Does this survive when managers are out of the office?

Yes. The workflow layer supports safe delegation, so a traveling manager can delegate approval authority to a named substitute, with mandatory re-approval for high-risk items when they return. The request does not stall for a week waiting for someone to fly back, and the audit trail records exactly who stood in for whom. This alone removes one of the most common reasons staff route around the official process.

Key Takeaway

Unauthorized purchasing is rarely malicious. It is what happens when authority rules live on paper and budget checks happen at month-end. A core business system with an approval gate moves both checks to the moment of request. The amount decides who approves. The budget line decides whether extra review is needed. Orders that used to slip through quietly now stop at the gate, and the finance team stops writing variance postmortems for spending they could have prevented.

Get Started With Kikan System

If purchase orders keep arriving above the real authority of whoever approved them, look at Kikan System. The workflow engine routes every purchase request by amount threshold and flags the moment a request crosses its budget line, so the gate runs at submission instead of at month-end. The approval routing and threshold logic are live today, with automatic purchase order creation and budget writeback on the roadmap. You can start on the free plan with up to 2 users, no credit card required. Begin at /#get-started.