
After Approval, Price Is No Longer Just a Field That Can Be Quietly Overwritten
Before an order is approved, sales may still clarify quantity, change items, recalculate discounts, or discuss other terms.
But once the company and customer have agreed, the price becomes part of that confirmed agreement.
If it is simply overwritten, several important questions lose their answers: what amount did the customer see? At what price may an invoice already have been issued? How much has already been paid? Did margin change? Does the order need approval again? Can shipment still continue?
I would therefore separate editing a draft from changing an already approved order.
What I Would Preserve When a Price Changes
The new price matters, but without context it does not explain what actually happened.
Previous Price
The value that existed before the change and may already have been agreed with the customer.
New Price
The value proposed or approved after the change.
Reason
Discount, correction, quantity change, new terms, supplier adjustment, or another real reason.
Initiator
Who proposed or made the change and when it happened.
Decision
Whether approval is needed and who has authority to allow a change of this size.
Consequences
What changed for payment, documents, margin, reservation, and shipment eligibility.
How I Would Design a Price Change After Approval
I would not ban changes completely. The business needs flexibility, but the change itself should follow a clear path.
Order Is Already Approved
Current items, quantities, prices, and total amount represent the confirmed version of the agreement.
A Price Change Is Requested
The user does not simply overwrite the value but starts a change with a recorded reason.
System Evaluates the Change
The difference in price, total amount, discount, margin, or another important business metric is calculated.
Authority Is Checked
A small correction may be allowed for sales while a significant discount requires another approval level.
Reapproval Is Created if Needed
The responsible person sees the old value, new value, difference, and reason instead of only an "approve" button.
New Price Becomes Active
Only after an allowed decision does the new value become the current commercial condition.
Financial Consequences Are Recalculated
The system determines the new amount due, remaining balance, overpayment, or another difference.
Documents Are Reviewed
If an invoice or another document already exists, it should not silently remain at the previous amount.
Shipment Eligibility Is Rechecked
If the financial condition is no longer satisfied after the change, the process should make that visible.
Change History Is Preserved
It remains clear what existed before, what became active afterward, and who made the decision.
| Situation | What I Would Allow | What I Would Check |
|---|---|---|
| Obvious correction before payment | May be a simple correction | Reason and change history |
| Small discount within sales authority | No separate approval may be needed | Discount limit and margin |
| Discount above the limit | After approval | Amount difference and reason |
| Price increased after customer approval | Requires separate attention | Customer reapproval |
| Order already partially paid | Possible according to business rules | New balance or overpayment |
| Part of the order already shipped | Do not rewrite the past transaction | Which remaining quantity receives the new price |
It is especially important to define what happens when the customer has already paid.
The order total was 10,000, the customer paid 5,000, and after the price change the new total becomes 9,000. The remaining amount is now 4,000 rather than 5,000.
If the new total becomes 4,500, the situation is different: the customer has effectively overpaid by 500.
I would not allow sales to manually edit a separate "amount remaining" field. It should be a consequence of the confirmed price and actual payments.
Price changes the agreement. Payment remains a fact.
A price change can also affect shipment.
For example, the business requires 100% prepayment. The order total was 10,000 and the customer already paid 10,000. After an approved change, the total becomes 11,000.
Payment exists, but the new financial condition is no longer fully satisfied.
I would not rely on a sales manager remembering to message the warehouse and say "wait". After the price changes, the system should recheck every condition that controls the next stage.
I Would Separate Permission to Edit From Authority to Change the Agreement
Technical access to a field does not mean someone should have unlimited authority to change a commercial term.
Sales Manager
May work within an approved discount range or other predefined rules.
Sales Lead
May approve larger deviations or non-standard commercial terms.
Finance
May not define the commercial price but should see the effect on payments and financial documents.
System
Checks rules, preserves history, and prevents required approval from being bypassed invisibly.
A Few Questions About Changing Price After Approval
The main principle is not to prevent the business from changing terms, but to make those changes controlled.
Does every price change need approval?
Is storing the old and new price enough?
What if the customer already made a partial payment?
What if an invoice already exists?
What if part of the order has already shipped?
Where should improvement begin?
How I Would Design This Business Process
In this series, I take real business processes and show how important changes, decisions, and their consequences can remain visible instead of becoming silent data edits.
Can Prices in Your Orders Change Without Anyone Later Knowing Why?
Take several real orders with changed prices and check whether the previous value, reason, author, approval, and effect on payments and documents are visible. If that history has to be reconstructed from messages, the process is already worth examining.




