When this guide is useful
Finance, procurement and operations teams controlling business purchasing
- Purchases are approved in chat or email with no reliable final record.
- Approvers see a total but not the supplier, purpose or budget context.
- A requester changes an order after approval without triggering review.
- Requests stall whenever a manager is on leave.
Separate the stages and their owners
Start with the business need, then map request, review, approval, supplier order, receipt and invoice handling. Microsoft describes a purchase requisition as an internal authorisation document and a purchase order as the external document issued to a vendor. Keeping that distinction in your design prevents an unapproved request from being mistaken for a supplier commitment.
Give each stage an owner and an explicit status. Draft, awaiting review, returned for changes, approved, ordered and cancelled should have clear meanings. Decide which actions are allowed in each state and which information becomes fixed. Preserve links between the request and any resulting order or invoice.
Use rules that reflect the actual risk
Define approval conditions using the information that matters: amount, cost centre, budget, supplier status, purchase type and any specialist review. Do not assume that a low-value purchase is always low risk; a service with access to customer data may need a security review even when its initial price is small.
Document whether approval happens at document or line level. Microsoft supports both patterns in its requisition workflow guidance; your process should choose deliberately. A mixed request covering several departments may need different reviewers, while a simple operational purchase may not. Keep the rules visible enough that staff understand why a request is waiting.
Make changes and absence predictable
Set a clear rule for what invalidates an approval. Increasing the amount, changing the supplier or adding a materially different item may require a new decision. Record the version the approver reviewed and avoid a design in which an approval silently follows a changed request.
Provide controlled delegation for absence, with a defined scope and end date. Escalation should move a stalled decision to an authorised person, not automatically approve it because a timer expired. Give approvers enough context to decide, and provide a return-for-information route so unclear requests do not become permanent rejections.
Connect the decision to downstream records
After approval, create or update the purchase order once and record the supplier-facing reference. Handle integration retries without issuing duplicate orders. Keep a visible state for an approved request whose order failed to reach the next system, because it needs technical follow-up rather than another approval.
Test the complete path with a normal request, a rejected request, a mixed-department order, a changed amount and an absent approver. Review cycle time and exceptions by cause. The goal is a controlled purchasing process that staff use, not a digital copy of every historical workaround.
From diagnosis to delivery
How Britixo can help
Britixo can configure or develop a purchase workflow that connects requests, approval rules, suppliers, orders and the relevant business records. An engagement can include process mapping, role design, notifications, controlled delegation and integration with your chosen accounting or procurement platform. Finance and procurement remain responsible for the approval policy and commercial decisions. Bring representative requests, your current spending matrix and examples of stalled or disputed approvals; we can turn them into a testable workflow with clear responsibilities and a practical exception route.
Talk through your requirementsCommon questions
Should every purchase follow the same approval route?
Usually the route should reflect value and risk. A simple repeat purchase can differ from a new service with sensitive-data access. Define the rules explicitly and confirm that lower-friction routes still meet the business's control requirements.
Can approval happen by email?
It can be part of the experience if identity, authority, request version and the recorded decision remain reliable. The email should lead to a controlled decision process rather than becoming an unstructured substitute for the audit record.
What happens when an approved order changes?
Apply an agreed change policy. Material changes should trigger the appropriate review and retain the earlier decision history. The system should make clear which version is approved and which version was sent to the supplier.
Sources and further reading
Use the original documentation to check current product terms, eligibility and technical details.
Published by Britixo on 29 October 2026. How these guides are prepared. Product availability and delivery scope are confirmed for your requirements.