Process and control
When an approved document changes, what needs review again?
Classify material changes, preserve versions and before/after values, apply re-approval rules and review downstream impact.
A Purchase Order approved for supplier A at 100 per unit may later change to supplier B at 98. The new price is lower, but the supplier, terms, bank details and risk can be different. Carrying the old Approved state forward without review can make the approval refer to a document that no longer exists in substance.
This is Linda change-control guidance, not a rule that every field always needs re-approval. Each organisation should define material change according to document type, value, risk and policy.
Separate cosmetic change from material change
Group fields into presentation-only information, operational information that affects handoffs and material information affecting price, counterparty, quantity, authority, payment or accounting. Supplier, quantity, price, bank account and UoM are common examples, depending on the document.
Do not make every post-approval edit impossible until users work around the system, but do not make every field freely editable until approval has no meaning. Define which changes require which level of review.
Preserve the approved version instead of overwriting history
ERPNext documents that submitted documents are generally changed through Cancel and Amend, with dependent documents considered before the parent can be amended. The broader design principle is to preserve approved document lineage rather than editing history until nobody can tell what was previously approved.
Where a system permits selected custom fields to be editable after submission, use that only for fields the organisation has classified as non-material and still retain who changed what and when.
Write re-approval rules around the type of change
Illustrative rules: description change → no re-approval; delivery date change → notify owner; supplier or bank change → counterparty review; price change beyond tolerance → value approval; UoM or pack change → re-evaluate comparison and cost basis.
Evaluate before/after values and the policy version in force, not just a generic “document changed” flag. A spelling correction and a payee-bank change should not share the same risk response.
Know which downstream records the change invalidates
If an order changes after receipt or invoice creation, verify quantity, rate, UoM, supplier, terms and allocation in linked records. If the source can change without downstream awareness, drift often appears later during payment or reconciliation.
Maintain an impact map: does this change invalidate quotation comparison, approval, expected receipt, invoice match, payment request or report? Move affected downstream states to Need Review rather than assuming they remain approved.
Change evidence should explain who changed what and who accepted the consequence
Retain document/version, before/after values, field classification, reason, evidence, requester, approver, timestamp and the rule or policy applied. Overrides should record the authorised person and reason separately from normal approval.
UAT should include a non-material edit, supplier change, price beyond tolerance, bank change after payment approval and amendment after downstream documents exist. The goal is to prove that Approved cannot silently outlive the context in which it was granted.
A practical starting checklist
- Classify fields as cosmetic, operational or material.
- Preserve versions and before/after history instead of overwrite.
- Define re-approval rules by change type and size.
- Map downstream impact and send affected records to review.
- Test supplier, price, bank and linked-document changes before launch.
Apply it to your business
Traceable approval belongs to a specific version of a document. When material facts change, the system should explicitly determine whether that approval still applies rather than preserving an Approved label out of context.
References
- Frappe. (n.d.). Edit Submitted Document. Retrieved October 1, 2026.
- Frappe. (n.d.). Edit a Field after Submission. 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.