Process and control
Why purchase approval and payment approval should be separate decisions
Committing to buy and releasing money occur at different times and rely on different evidence. Clear states and permissions make exceptions traceable.
Many organisations use “approved” for everything from a purchase request to the bank payment. Because approvers see different evidence at each point, the same word makes it unclear what was actually accepted and what must be reconsidered when quantity, price or delivery changes.
This is process-control guidance, not a universal legal requirement. Segregation should reflect team size, value, risk and the organisation’s own policy.
Purchase approval: review the commitment before placing it
Before a Purchase Order, establish who requested the purchase, what is needed, quantity, price basis, business purpose and delivery or payment terms. Define which material changes after approval require renewed review.
ERPNext describes a Purchase Order as a binding agreement with a supplier under stated conditions and supports payment terms that can include advance or staged payment. This illustrates that the purchase decision occurs before all delivery evidence exists.
References: [1]
Payment approval: compare what happened with what was agreed
Before money leaves, review the relevant agreement or PO, receiving/service evidence, supplier invoice, returns or deductions and payee bank details. Advance payment can have its own approved basis rather than pretending full receipt has occurred.
ERPNext distinguishes a Payment Request from actual settlement: submitting the request does not by itself settle the invoice or post a bank transaction. This is a useful example of why requesting payment and money movement are different states.
References: [2]
Use states that say which decision has been made
An illustrative flow is Draft Request → Purchase Approved → Ordered → Partially Received → Ready for Payment Review → Payment Approved → Paid → Reconciled. Names can differ, but users should know which decision has occurred and which evidence remains outstanding.
ERPNext Workflows support multiple approval levels and conditional transitions. The useful design idea is to let transitions depend on defined roles and conditions rather than giving every user equal status-changing authority.
References: [3]
Exceptions should not force people to falsify status
Urgent purchases, deposits, services without stock receipt or invoice differences can use explicit exception paths with a reason, approver and compensating evidence such as a contract or service acceptance.
If a system permits payment only after “fully received”, users may mark a delivery complete just to move the workflow forward. A traceable exception path is safer than forcing operational data to become untrue.
Start with a minimum permission matrix before designing screens
Map actions to roles: request, maintain supplier details, approve purchase, confirm receipt, approve payment, prepare bank file and reconcile. Add thresholds and combinations that should not be performed by the same person. Where a small team cannot separate every action, document the actual compensating review.
Test absent approvers, changed supplier bank details after approval, payment above the PO and a grouped payment for several invoices. Acceptance means the system can explain who decided what and when, not merely that a payment succeeded.
A practical starting checklist
- Define Purchase Approved and Payment Approved separately.
- Specify minimum evidence and exception paths for each decision.
- Assign permissions and thresholds to actions rather than broad role names.
- Define re-approval triggers for supplier, price, quantity or bank-detail changes.
- Test deposits, partial receipts, differences and absent approvers before launch.
Apply it to your business
Separating purchase and payment approval is not about adding clicks. It gives “approved” a precise meaning at each point so exceptions retain an accountable decision trail.
References
- Frappe. (n.d.). Purchase Order. Retrieved October 1, 2026.
- Frappe. (n.d.). Payment Request. Retrieved October 1, 2026.
- Frappe. (n.d.). Workflows. Retrieved October 1, 2026.
Numbered references support the attributed statements. Scenarios and recommendations are Linda’s examples, not verified client outcomes.
This article provides process-design guidance and illustrative examples, not an accounting, tax or legal determination or certification of every software module. Apply it with regard to your business, permissions and actual system scope.