A colleague asks if the business can buy a new tool. The manager replies that it looks useful. A subscription starts immediately, although nobody agreed the plan, owner or recurring commitment.
A purchase-request approval workflow defines what is proposed, who can approve it and who is authorised to place the order. An encouraging comment should not silently become permission for every version of the purchase.
Photo by Antonio Uquiche on Unsplash.
Separate the internal request from the supplier order
The CIPS explanation of purchase requisitions distinguishes the internal purchase request from the purchase order sent to a supplier. That distinction is useful even when a small business uses a simpler shared record.
Agree the actual authority with your business owner or finance lead. This article does not prescribe monetary limits, accounting treatment or who legally binds the business. Its purpose is to make the operating decision visible before action.
What should the request explain?
Business need and intended user.
Item or service specification and proposed supplier.
Quotation reference and what the price includes.
Initial and recurring commitment, with assumptions.
Available alternatives or an existing resource that may meet the need.
Required-by date and consequence of waiting.
Operating owner, setup work and relevant specialist checks.
Requested approver, decision and conditions.
Do not treat a budget label as proof that the purchase is appropriate. Equally, do not require a large business case for every routine item. Use a proportionate route agreed by the authorised owner.
An illustrative software request
A team proposes a reporting subscription. Its request identifies the actual plan, expected users, setup owner and renewal timing. Approval covers that defined arrangement, subject to access and data suitability being checked.
If checkout presents a different plan or an additional commitment, the purchaser returns for the required decision. They do not rely on the earlier approval because the product name is similar. The authorised order record refers back to the accepted request.
Confirm who may act on approval
A decision saying approved needs a scope, approver, date and any conditions. Name the person placing the order and the receiving owner. Use your decision-rights record to distinguish reviewing usefulness from authorising the commitment.
Keep the handover connected to supplier onboarding where a new supplier needs access, contacts or service arrangements. Approval to buy does not automatically make that supplier operationally ready.
Check completion beyond the purchase
Confirm that the intended item or service arrived, the owner can use it and the accepted record is available to finance. Close unused requests explicitly so a second colleague does not later act on an obsolete approval.
If purchases begin with vague messages and end with unclear obligations, Hili Consulting can help define a practical request-to-order workflow.
