A purchase request form is how somebody asks to spend money before they spend it. It is the front door of a purchase order system and the part that decides whether approval is a decision or a rubber stamp, because an approver can only weigh what the form captured. Most small businesses either have no form, in which case requests arrive as messages saying is it okay to order this, or a form with twelve fields that nobody fills in. This page is about the five that matter and when the form should stop being a form.
The five fields
What is being bought, in enough detail that somebody else could order it. Why, in one line, because the approver is deciding on the reason rather than the item. How much, including tax and shipping, since an approval given on the ex-tax figure is an approval for the wrong number. Which budget it comes out of, which is the field that turns a guess into a decision. And who is asking, with the date. Five fields, and the fourth is the one most often missing and the one that does most of the work.
Why the budget field decides everything
An approver looking at a request without a budget line can only ask whether the thing is worth having, and almost everything is worth having. With a budget line the question becomes whether there is room, which is answerable and is the question the business actually needs asked. If your company does not run budgets at that granularity, use the nearest thing you have, a department or a project, because even a rough attribution turns approval from a taste judgement into an arithmetic one.
When a purchase request becomes software
The form is a way of getting five fields and a decision recorded. Purchase request software earns its price when three things start to hurt: the requester cannot see where their request got to, the approver is a bottleneck who cannot act from a phone, and nobody can add up what has been approved but not yet ordered. Below that, a form and a log is honest. Above it, you are maintaining the join by hand and the join is the product.
Purchase approval as a written rule
Whatever captures the request, the approval rule has to be written down: the threshold above which approval is needed, who approves, who deputises when they are away, and what happens if nobody answers. A rule that lives in people's heads is applied differently by each of them, and the first time it matters is the time it was not followed. Purchase approval software enforces the rule you wrote; it cannot decide it, and buying a product in the hope that it will is how companies end up with somebody else's process.
Questions people ask about purchase request form
What should a purchase request form include?
What is being bought, why, how much including tax and shipping, which budget it comes from, and who is asking. The budget field is the one most often missing and the one that makes approval a real decision.
Why include tax and shipping on the request?
Because an approval given against the ex-tax figure is an approval for a number that is not the one you will be invoiced. Approve the amount the business will actually pay.
When is a form no longer enough?
When requesters cannot see status, approvers cannot act from a phone, and nobody can total what has been approved but not ordered. That last figure is the committed spend, and maintaining it by hand is the work software removes.
Does approval software set the rules?
No. It enforces the rule you wrote: the threshold, the approver, the deputy and the timeout. A product cannot decide your policy, and buying one hoping it will means adopting somebody else's.