A purchase request can be technically approved yet still stall between budget owner, procurement and the person who issues the order. A useful workflow makes the next decision visible without weakening financial controls.
Define the decision before designing the route
Write down what the requester is asking for, the business reason, expected value, cost centre, required date and supplier. Then define who may approve the spend, who checks the supplier and who may issue the purchase order. These may be different people. Keep the source of authority in the appropriate finance or purchasing policy.
Give each handoff an owner and an outcome
- Request: capture enough detail for a decision, including quotation or comparison where required.
- Validate: check coding, budget, duplicate requests, supplier details and whether an existing contract applies.
- Approve or return: show the approver the decision they must make. A returned request should say what is missing and who must fix it.
- Order: issue the purchase order in the ERP after the required approvals. Keep its number linked to the request.
- Receive and reconcile: let the normal receiving and invoice controls confirm what was delivered and billed.
Handle urgent work without invisible exceptions
Urgent requests need a documented route, not an informal bypass. Record the reason for urgency, the person authorising the exception, any spending limit and when normal evidence must follow. Delegation should be time-bound and visible. The same person should not silently request, approve and complete every control step.
What the workflow should show
- Current owner, pending decision and time waiting at each stage.
- Approval outcome, date, authority basis and evidence reviewed.
- Supplier verification status, missing documents and changes after approval.
- Purchase order reference and reason for rejection, cancellation or rework.
Where the ERP remains authoritative
Keep vendors, budgets, purchase orders, receipts and invoices in the systems that already govern them. A process layer can coordinate decisions and follow-ups around those records. Do not assume a new workflow replaces native ERP approvals; compare the existing capability first and add only the cross-team visibility or evidence steps that are genuinely missing.
Example: a delayed branch equipment request
A branch requests replacement equipment and attaches a quote. Finance returns the request because the cost centre is missing; the requester corrects it. A budget owner approves, procurement checks the supplier, and the ERP purchase order is issued. If the supplier changes the price, the request is routed back for the required decision instead of quietly changing the approved amount.
Measure the right delay
Track elapsed time by step, return-for-information rate, urgent exceptions, approvals outside policy and requests with no linked order after approval. Start with one purchasing category and test the complete path, including rejection and delegation, before expanding it.
How Intelliflow fits
Intelliflow can make ownership, decisions and evidence clearer across teams while preserving the ERP as the purchasing record. The exact approval rules, integrations and permissions depend on the deployment and should be verified in the configured environment before a production promise is made.
Separate authority from administration
A buyer may prepare the request while a budget owner approves spending and procurement verifies the supplier. The workflow should show those distinct roles. It should also prevent an approval from being reused after a material change in amount, scope or supplier. The policy owner defines thresholds and delegation; software should not invent them. Where segregation of duties is required, test that the requester cannot grant their own approval simply by changing a role or forwarding an email.
Five exceptions to test before launch
- Price rises after approval: pause order issue and return the revised value to the authority required by policy.
- Supplier details change: use the approved supplier-verification control before changing master data or payment instructions.
- Approver is absent: route to an authorised substitute with the delegation reason and time recorded.
- Purchase is split: check for related requests that could bypass a threshold; do not automatically treat separate legitimate purchases as misconduct.
- Goods differ from the order: retain the receiving exception and route the invoice difference to the proper purchasing or finance owner.
Test rejection and withdrawal too. A rejected request must not leave an active downstream purchase order. A withdrawn request needs a reason and should preserve the history of decisions already made.
What a useful acceptance test looks like
Take one ordinary request and one urgent or changed-scope request in the safe test environment. Confirm who can submit, edit, approve, reject and see supplier evidence. For each path, verify the policy threshold, the decision record, the linked ERP order, the receiving result and any invoice exception. If the integration fails, leave the request visibly blocked with a recovery owner; do not show an “approved and ordered” outcome without a real order in the source system. The test result should identify the exact record IDs, not just a screenshot of a green status.
Review the process after use
Compare like-for-like requests by time awaiting requester information, approval, supplier validation and order issue. Review emergency-route volume, policy overrides and orders issued after changed terms. A faster median is not a success if controls are skipped or suppliers receive incorrect orders. Keep an owner for each finding and confirm the revised route with another real test case.
Start with native Odoo workflow options before adding a coordinating layer. For proof quality, see evidence and auditability.
Frequently asked questions
Can an urgent request bypass all controls?
Only the organisation's approved emergency policy can define a shorter route. Retain the reason, authority and any required later review.
Is an approved request the same as an issued order?
No. The purchase order must exist in the authoritative purchasing system and match the approved terms before the workflow can claim that the order was issued.
To test one purchasing journey and its exceptions, book a process review. Intelliflow Editorial Team. Examples are illustrative; validate purchasing policy, supplier controls and integration in the target deployment.