A purchase request approval workflow

What a purchase request is

A purchase request is an internal document created before the organisation buys goods or services. It states what is needed, why, the estimated cost, and when it is required. It differs from a purchase order, which is issued after the request is approved and goes to the supplier.

Because it is internal, a purchase request often feels lightweight. That is exactly where budgets slip. Many small repeated purchases without approval can consume a budget faster than one large purchase that is carefully reviewed.

The usual sequence

The exact order varies between organisations, but the frame below covers the checks most often needed. Adjust the number of steps to the value and nature of the purchase.

1. The requester states the need, reason, estimated cost, and when it will be used.
2. The line manager confirms the need is real and a priority.
3. The budget owner checks available funds and picks the budget source.
4. Procurement checks the supplier, comparative pricing, and purchase terms.
5. The authorised party approves according to the applicable value threshold.
6. A purchase order is issued and its number is recorded on the request.

When a request is rejected or postponed, the reason should be recorded. A budget postponement differs from a rejection because the need is not urgent, and that difference matters when the requester resubmits.

Role split and value thresholds

One person should not decide the need, the budget, and the supplier at once. That separation is not distrust. It is how a decision becomes easier to defend.

Value thresholds speed the route up. Routine purchases below a set amount can be approved at one level, while larger purchases pass several. Set the thresholds, write them down, and review them quarterly.

What every request should record

A complete record at the start saves many questions later. At minimum, make sure the request carries the following before it enters the route.

• The request number, date, and requester's name.
• A description of the goods or services specific enough to review.
• The reason for the need and the impact if it is not met.
• The estimated cost, currency, and budget source.
• The proposed supplier and the reason for choosing them.
• The date required and the consequence of delay.

When the request relates to an existing contract, include the contract number. When it relates to a project, include the project name. These links make checking easier when the invoice arrives and when the budget is reviewed.

Linking request, order, and invoice

These three documents are often treated separately, yet their value appears when they are linked. The request explains why the cost should exist. The order records what was agreed with the supplier. The invoice charges for what was delivered.

When the three are linked, finance can match an invoice against the order and the approved request. When they are not, every invoice must be checked from scratch, and purchases that were never approved can slip into payment.

If one document is missing, the approval record still helps. At least you can see who approved and when, so the search does not start from zero.

Evidence to keep after the order is placed

Once the order is issued, keep the approved request and its history. A sealed approval record carries the document hash, the decision order, and a timestamp. If the document changes after approval, the hash will no longer match.

For audit purposes, add the order number, any contract number, and proof of receipt. That chain lets an auditor follow the route from need to payment without guessing.

What this workflow does not solve

An approval workflow does not judge whether a supplier's price is fair, does not guarantee availability, and does not replace competent procurement. It only ensures the decision is taken by the right people and recorded.

Segel is also not a procurement system and not a certified electronic signature. Segel preserves the approval evidence and file integrity around the decision.