Who Should Approve Merchandise Spend — And When Self-Approval Is Correct
Published 2026-08-05 by Barath A. R.
Every company store eventually needs an answer to "who signs this off". The instinct is to route everything to a manager and move on, which produces an approval queue that either becomes a rubber stamp or becomes a bottleneck. Neither is a control.
Maker-checker, and what it is actually for
The maker-checker pattern is simple: the person who raises a transaction is never the person who releases it. It comes from banking, and its purpose is not to catch mistakes — a second pair of eyes is a poor error-detection mechanism — but to make a single person unable to complete a transaction alone.
That distinction shapes where to apply it. It belongs wherever a single person could otherwise commit company money without anyone else being involved. It does not belong wherever the money has already been committed by an earlier decision.
The case where self-approval is correct
Consider a department head who holds spending authority for their cost centre and orders merchandise for their own team. Routing that to themselves for approval, or to a peer, adds a step and changes nothing: they already have the authority, the order is already attributable to their cost centre, and the spend is already visible.
Making them queue behind themselves buys no control. It buys a delay and an approval record that everybody knows is ceremonial. In this case the honest design is to let the order through and rely on attribution — the cost centre and the name are on the order — rather than on a signature that means nothing.
The case where it must never be allowed
Now consider the same person requesting more budget for themselves. Superficially it looks similar — a person with authority, making a request within their own area. It is not similar at all.
Approving your own budget is not approving a transaction; it is creating the authority you are then going to spend under. Whatever limit existed becomes self-administered. There is no amount of existing seniority that makes that acceptable, because the control being bypassed is the one that defines what seniority means in spending terms.
Approving your own order can be reasonable. Approving your own budget never is — that is not an approval, it is minting.
A workable policy
- **Orders billed to a cost centre** — approved by the department's checker. Where the checker is also the maker and holds authority for that cost centre, let it through, and record it.
- **Requests for more budget** — never self-approvable. Route to the checker; if the requester is the checker, escalate to the administrator.
- **Above a threshold** — escalate regardless of who raised it. Set the threshold per department, because a fifty-thousand-rupee order means different things in different teams.
- **Spending an allowance already granted** — no approval at all. The decision was made when the allowance was granted.
Rejections need reasons, and the reason is the useful part
A rejection without a reason is worse than no rejection, because the person who raised it now has to guess what to change. Most will simply re-raise the same thing, which converts a control into a loop.
Requiring a reason costs the approver ten seconds and saves the requester a cycle. It also produces something auditable: a record of why things were refused, which over a year tells you more about your policy than the approvals do.
Approval must be a gate, not a note
The final structural point: approval has to actually hold the order. If a "pending approval" order is already visible to the warehouse, or already committed to stock, then approval is a notification rather than a control, and the first time somebody is on leave you will find out which.
Until a checker signs, nothing should be picked, nothing reserved and nothing charged. Approval is what releases the order — that is what makes it worth having.
See how approvals work → · WhatsApp us on +91 98866 01717