Approval is the point of a purchase order system. Everything else, the number, the template, the log, exists so that somebody with authority can say yes before the money is committed rather than after. Most small businesses have approval in the sense that people ask, informally, sometimes. This page is about turning that into a rule that gets followed: where to set the threshold, what a PO request has to capture for approval to be a real decision, and why an approval that takes two days will be routed around.
Set the threshold where it changes behaviour
A threshold so low that everything needs approval trains people to route around it, and one so high that nothing does is decoration. The workable place for a small business is the amount above which you would want to have known beforehand, which is usually much lower than people guess and is best found by looking at last year's invoices and asking which ones were a surprise. Write the number down, put it where people can see it, and review it once a year rather than adjusting it case by case, since a threshold that moves is a threshold nobody believes.
What the po request has to capture
Five fields make approval a decision rather than a rubber stamp: what is being bought, why, how much including tax and shipping, which budget it comes out of, and who is asking. The budget field is the one most often missing and the one that makes the approver's job possible, because the real question is rarely whether the thing is worth buying but whether there is room for it. The free purchase order request form on this site captures exactly those five and produces something an approver can act on rather than a message asking if it is okay to order something.
Speed is a feature, not a nicety
An approval path that takes two days will be bypassed by anyone with a deadline, and the bypass becomes the process. A po approval app earns its price mostly by being fast: notify on a phone, show the five fields, approve or reject with a reason, done. If your evaluation of approval software does not include timing the path from request to decision on a phone, you are comparing features rather than the thing that decides whether the system is used.
Delegation and the single point of failure
The other reliable failure is that the only approver is on holiday. Any approval rule needs a named deputy and a rule for what happens when nobody responds within a stated time, and both belong in the written policy rather than in somebody's head. Products differ here more than they advertise: ask specifically what happens to a request nobody answers, because silently sitting in a queue is the most common answer and it is the one that trains people to phone the supplier instead.
Questions people ask about po approval software
Where should the purchase order approval threshold be set?
At the amount above which you would want to have known beforehand. Find it by looking at last year's invoices and asking which were surprises, then write it down and leave it alone for a year.
What should a PO request capture?
What, why, how much including tax and shipping, which budget, and who is asking. The budget field is the one most often missing and the one that lets an approver decide rather than guess.
How fast does approval need to be?
Fast enough that nobody with a deadline routes around it. Time the path from request to decision on a phone when comparing products; that single test predicts whether the system will be used.
What happens when the approver is away?
Whatever your written policy says, which should name a deputy and a timeout. Ask each product what it does with a request nobody answers, because sitting silently in a queue is the common answer and the damaging one.