Keep project purchase approvals valid after a change

Capture the purchase version, supplier, scope, quantities, currency, amount, tax assumptions, payment terms, delivery conditions and budget references. Attach the comparison or justification where required. The approver should be able to see the complete decision without reconstructing it from several emails.

Separate technical acceptance, budget availability and authority to commit funds. One person may hold several roles, but the decisions are still different. A technical approval does not necessarily authorise an advance payment, and an available budget does not automatically establish that the supplier or scope is acceptable.

ERPNext's workflow documentation describes approval states, roles, conditions and transitions. These mechanisms can implement an authority policy, but the company must define the policy and test how changes affect approval validity.

Create a change matrix with the relevant functions. Quantity, value, supplier identity, specification, payment terms, delivery obligations and contractual conditions may require different reviews. Some changes need the entire approval chain; others need only the affected reviewer.

Avoid using value increase as the sole trigger. A lower-priced substitute may introduce a technical difference. An unchanged total with a larger advance may change financial exposure. A supplier legal-entity change may affect due diligence and payment setup even when the commercial offer appears identical.

Minor administrative corrections can have a simpler route if the policy defines them clearly. Record who made the correction and why it did not alter the approved commitment. The distinction should be reviewable, rather than left to whichever user edits the document.

Assume a synthetic order proposes ten units at ₹50,000 each, excluding taxes for this illustration. The base amount is ₹5 lakh. Four additional units increase it to ₹7 lakh. Suppose the organisation's illustrative authority matrix permits the original approver to authorise up to ₹6 lakh.

The revised order crosses that limit and needs the appropriate higher authority. It also needs a quantity and budget review. If the advance changes from 10% to 20%, the proposed advance rises from ₹50,000 to ₹1.4 lakh on the simplified base amounts. That is a separate commercial change worth making visible.

These limits and percentages are example assumptions, not recommended policy. The important control is that the approval remains attached to the ten-unit version until the fourteen-unit version has completed its required review.

Show approvers the changed fields and the reason for change, with access to the full revised document. Preserve the earlier version and its approval evidence. A concise difference view reduces the chance that a material change is hidden inside a familiar-looking order.

Where an order has already been issued, distinguish an internal revision from a communicated amendment. Record what was sent to the supplier and any acknowledgement required by the process. Procurement and site teams must know which version governs the expected delivery.

Do not release the revised commitment while its required approvals are pending. The system may allow preparation and review in parallel, but its issue action should respect the agreed control. If the business needs an emergency exception, use that explicit path.

A delegation should state who grants it, to whom, for which scope, within what limits and for what period. Check those conditions at the approval event. A person who could approve last month may no longer hold that authority today.

Decide how the policy treats approvals already given when a delegation expires. That is a governance choice requiring a clear rule; the system should not silently invent one. New revisions or new commitments may need reassessment even when an earlier version was validly approved.

Check conflicts of role where relevant. A requester approving their own purchase may be prohibited or require additional oversight under company policy. Role names in software are not enough if a user has several roles that together bypass the intended separation.

Several small orders may legitimately serve different packages or delivery periods. They may also collectively exceed an approval threshold that applies to the overall requirement. Review related purchases using the organisation's aggregation rules rather than treating each document in isolation.

Useful signals include the same requester, supplier, specification, work package and short ordering period. A signal should prompt review, not automatically accuse the buyer of avoiding controls. Record the business explanation and the applicable approval decision.

Emergency procurement needs a named authoriser, defined limits, minimum evidence and a deadline for completing the record. A later review should examine why the emergency arose. Repeated retrospective approvals indicate that the normal workflow may be impractical or routinely bypassed.

Test the system by changing an approved quantity, payment term and supplier separately. Confirm that each change reaches the correct reviewer and that the issued document shows the approved version. Test a value exactly at the authority boundary and one just above it, using the policy's rounding and currency rules.

Then try an expired delegation and a user with multiple roles. Check that notifications, audit history and release restrictions behave as intended. A successful happy-path approval proves little about the exceptions that create purchasing risk.

Review approval lead times alongside returned requests and emergency overrides. A slow process may encourage workarounds; a fast process that approves incomplete decisions offers little assurance. Use the evidence to simplify unnecessary steps while retaining reviews that change the decision.

An approval is useful when the organisation can show what was authorised and why the issued order still matches it. Version-aware controls make that relationship visible.

1. Define the fields and documents that form the purchase decision.
2. Agree a material-change matrix with procurement, technical and finance owners.
3. Apply current authority and delegation rules to the proposed version.
4. Test changes, boundary values and urgent exceptions before rollout.
5. Review recurring overrides and delays to improve the process.