The Order the Supplier Already Accepted
A supplier rings to say they can only do forty, at a higher price, and somebody opens the purchase order and types the new numbers over the old ones. The order is now right and the record is wrong: nobody can say what was approved, what the supplier accepted, or why it moved. Why a sent order should change by revision, never by edit.
The order went out on a Monday: fifty tins of floor paint at 100 each, 5,000 in all, approved by the operations manager and acknowledged by the supplier the same afternoon. On Wednesday the supplier rings. They are short. They can do forty, and the price has gone up to 110 because their own supplier put theirs up. The buyer says fine, opens the order, types 40 over the 50 and 110 over the 100, and saves. The order now says 4,400. It is correct.
Three weeks later the invoice arrives for 4,400 and matches perfectly. Then an auditor asks a simple question: the approval on file is for an order of 5,000 at 100 a tin, so who approved 110? Nobody did. The approval is still attached to the order, but the order it approved no longer exists anywhere. The acknowledgement the supplier gave was for fifty tins. The reason for the change lives in one person’s memory of a phone call.
Nothing dishonest happened. The edit was reasonable, the numbers were right, and the record was destroyed anyway.
A purchase order is an agreement, not a form
It is tempting to treat a purchase order as a record you keep up to date. It is closer to a contract two parties have signed. Your side signed it when somebody with authority approved it. The supplier signed it when they acknowledged it. Both signatures are attached to a specific set of lines, quantities, prices and a delivery date.
Overwrite the lines and both signatures are left pointing at text they never saw. The approval is now an approval of something else. The acknowledgement is now an acknowledgement of something else. And because the old values are gone, there is no way to tell, from the order itself, that anything moved at all.
Editing the sent order in place
- The approver’s sign-off silently transfers to new quantities and prices.
- The supplier’s acknowledgement still shows, for a version they never accepted.
- The original lines are overwritten, so the change cannot be reconstructed.
- The reason is wherever the buyer happened to write it, if anywhere.
- Any increase in spend skips whatever budget check the original went through.
Changing it through a revision
- The change is proposed, and a second person approves that change specifically.
- The supplier’s acknowledgement is cleared, and they are sent the order again.
- The before and after versions are both kept, line by line.
- A reason is required before the proposal can be submitted.
- The increase, and only the increase, is tested against the budget.
An edit makes the order right and the record wrong. The approval and the acknowledgement are still attached, and both now describe a document that no longer exists.
What a change order is, in AWRA
In AWRA an issued purchase order is not edited in place. The old edit address for an order now simply opens the order page. Changing a sent order means proposing a change order, which is stored as a revision of that order with its own number, status and history.
-
Someone who can raise orders proposes the change
The form shows the order’s current lines. You set new quantities and unit prices, set a quantity to 0 to drop a line, move the delivery date if needed, and say why. The reason is required and kept with the revision. Nothing on the order changes yet.
-
The approvers are told
Everyone who can approve purchase orders is notified with the order and its total before and after. The proposer is left off that list.
-
A different person approves it
Approval needs the approve-orders permission, and the person who proposed the change is refused even if they hold it. A rejection is recorded with who decided, when, and an optional note, and the order stands as it was.
-
The increase meets the budget
If any line rises, the rise is passed through the same budget gate that requisitions, quotation awards and reorders go through, set per workspace to off, warn or block.
-
The change is applied as a new revision
The lines, total, balance due and delivery date are updated, the revision number goes up by one and shows beside the order number, and an audit entry records the totals before and after and the reason.
-
The supplier is asked to accept it again
The supplier’s acknowledgement is cleared, because they accepted the old order, not this one. If your workspace sends purchase orders to suppliers by email, the order is sent to them again in its revised form.
The paint order, done as a change order
Revision 1 keeps both versions. Six months later the order page still shows 50 × 100 becoming 40 × 110, who asked, who approved and why.
The guards, and what each one is for
A change order is only worth having if it refuses the changes that would make the record lie. Most of the rules below come from one question: what would this change claim that is not true?
| A proposal that… | What happens | Why |
|---|---|---|
| Cuts a line below what has already been received | Refused, naming the item and the quantity received | Goods booked into the warehouse are a fact. An order for fewer than arrived would turn honest receipts into over-receipts. |
| Removes a line that has been partly received | Refused | Same fact, one step further. Cut it down to the received quantity instead. |
| Takes every line to zero | Refused, with a pointer to cancel the order | An order with nothing on it is a cancellation, and cancelling has its own consequences. |
| Is approved by the person who proposed it | Refused, whatever their role | The point of the second person is that they are a second person. |
| Was proposed before the order changed some other way | Refused at approval, with a request to propose again | Applying it would overwrite a change the approver never saw. |
| Targets an order that is paid, completed, closed or cancelled | Refused | That agreement has been settled or ended. |
The stale-proposal check is the easiest one to leave out
A proposal is a picture of the order at a moment, plus the change you want. If the order moves before it is approved, applying it as written would quietly undo whatever moved it. So each revision stores the lines and date as they were when proposed, and approval compares that picture with the order as it is now. If they differ, approval is refused and the change is proposed again against the current version. A newer proposal also marks any older pending one as superseded, so the approver only ever faces one live question.
An increase is new spend, and it is measured per line
A change order that raises an order’s value is a spending decision taken after the original one was checked. If budgets matter at requisition and award, they matter here, or the change order becomes the side door round them.
AWRA tests only the rise, not the whole order, because the original value already went through the gate once. And it works out the rise line by line. If one line goes up by 600 and another comes down by 600, the order total is unchanged but the budget is still asked about the 600, against the category of the item that rose. That is deliberate. Budgets are held by category, and a saving on cleaning supplies does not pay for a rise in paint.
What the gate does with the answer depends on how your workspace is set. With budget control off, nothing is checked. With it on warn, the change goes through. With it on block, a rise past what the budget has left after spending and commitments is refused unless someone holding the override permission gives a written reason of at least ten characters, which is stored with the change.
Why the supplier has to accept it again
Clearing the acknowledgement looks like friction, and it is the part that matters most. The acknowledgement is the supplier’s promise to deliver what is on the order. Leave it in place after a change and the record says they promised forty tins at 110 when they said yes to fifty at 100. When the delivery is late or short, that mismatch becomes an argument about who agreed to what.
So applying a revision clears the acknowledgement and, where purchase orders go out by email, sends the supplier the current order. They acknowledge it again through the supplier portal or a remote signature, exactly as they did the first time. Until they do, the order holds no acknowledgement for the new version, which is true.
The revised lines also become the lines everything downstream reads. The receiving check that refuses an over-delivery measures against the order’s current quantities, and so does the three-way match before payment. That closes the loop described in the delivery that was bigger than the order: when a supplier legitimately sends more, the honest way through is to amend the order, and a change order is that amendment, approved, budget-tested and recorded.
When to use one, and when not to
The supplier delivers part now and the rest later
Change nothing
A short delivery is reported as an exception and the order stays open for the balance. Changing the order would erase a back-order that is still owed.
The supplier will never send the rest
Change order, cutting to what arrived
The line can go down to exactly what was received and no further, which keeps receiving and matching consistent with the goods on the shelf.
The price moved or the quantity needs to rise
Change order
The rise goes through the budget gate, a second person approves it, and the supplier accepts the new version.
It is now a different supplier or different goods
Cancel and raise a new order
A revision changes lines, prices and the delivery date of an agreement with one supplier. A new supplier is a new agreement and deserves its own approval from the start.
What a revision keeps
A revision covers the order’s lines (item, quantity, unit price) and its delivery date. Everything else on the order, from the supplier to the receiving warehouse, is outside it. Within that scope, here is what is held and what you see.
The history behind a revised order
| For each revision | Stored | Shown on the order page |
|---|---|---|
| Every line before the change, with quantity and price | Yes | Partly — configurable by you |
| Every line after the change | Yes | Partly — configurable by you |
| Order total before and after | Yes | Yes |
| Delivery date before and after | Yes | Yes |
| The reason given | Yes | Yes |
| Who proposed it and when | Yes | Partly — configurable by you |
| Who approved or rejected it | Yes | Yes |
| The note left with a rejection | Yes | No |
| Rejected and superseded proposals | Yes | Yes |
Built and maintained Configurable by you, not maintained by us Not built
Part means the page shows only the lines that changed, and the proposer’s name without the time. The full versions are kept on every revision, with an audit entry each time one is applied.
The short version
A sent purchase order carries two signatures, yours and the supplier’s, and both belong to one version of it. Edit it in place and both signatures quietly move to numbers nobody signed. AWRA changes a sent order by revision instead: a reason is required, a second person approves, a rise in value is tested against the budget, the supplier is asked to accept the new version, and the version they first accepted is kept. The order ends up right and the record stays true.
What AWRA OpsHub does today
- Change orders on an issued purchase order, proposed by anyone who can raise orders, covering quantities, unit prices, dropping a line and the delivery date, with a reason required.
- A second person approves every change, holding the approve-orders permission, and the proposer is refused whatever their role.
- Guards against a change that would make the record lie: below what was received, removing a partly received line, emptying the order, an unchanged proposal, or a proposal made before the order changed some other way.
- A rise in value tested against the workspace budget gate, per line and per item category, in the workspace’s off, warn or block mode.
- A numbered revision kept with both versions, totals, reason, proposer and decider, plus an audit entry each time one is applied.
- The supplier’s acknowledgement cleared on every applied change, with the order sent again by email where your workspace sends orders that way.
- The same flow on the web and in the mobile app, with propose, approve and reject on both.
More we can add to your workspace
- A revised-order email that says it is a revision. The supplier currently receives the standard purchase order email again, headed as a new order; a revision-aware version would carry the revision number and list the lines that moved, so the supplier sees the change rather than having to spot it.
- A budget override reason on a change order approval, on the web and in the app. The API already accepts one; adding the field to both screens lets an authorised person clear a blocked rise with a recorded reason instead of raising the budget.
- A warn-mode budget notice on a change order. In warn mode a rise past the budget is approved, and the notice the gate produces could be shown to the approver at that moment.
- Adding a new line from the web change form. The change service and the API take a new item on a revision; the web form currently lists the order’s existing lines.
- Fractional quantities on a change order, for goods bought by weight, volume or length. Revisions take whole units at present.
- An order status that returns to awaiting acknowledgement when a revision is applied, to match the cleared acknowledgement.
- A notice to the proposer when their change is decided, so the buyer who spoke to the supplier knows to call them back.
- Supplier response time counted from the latest revision. Sourcing analysis measures hours from the original order date to the acknowledgement, so a supplier re-accepting a revision looks slow for a delay that was ours.
- Change orders on orders still carrying the older approved status, which the change service currently groups with paid and completed orders.
Where we point you to a specialist
- We will not let the person who proposed a change approve it, for any role in any workspace, administrators included. A workspace with one person who can approve orders gets a second one before it gets change orders.
- We will not offer a setting to edit an issued order’s lines in place, even for a correction that looks trivial. A typing mistake is fixed by a revision with a reason, because the order the supplier saw is part of the record.
- We will not decide whether a supplier’s price rise on an accepted order is enforceable against you. That depends on your contract and the law that governs it, and it is a question for whoever reviews your supplier agreements.
The revision email and the override field are the two that change how a change order feels to the people using it, and both sit on parts that already exist: the revision already holds the per-line differences, and the API already takes the override reason. The response-time measure is a one-line change in where the clock starts, once you decide whether a revision should restart it.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsFour questions for any purchasing system
If I change a sent order, can I still see the version the supplier acknowledged?
What you will probably hear
There is an audit log.
How to read it
Ask to see it on a real order. A log line saying a field was updated is a different thing from the full set of lines before and after, side by side, with the reason.
Who approves a change to an order that is already approved?
What you will probably hear
Anyone with approval rights.
How to read it
Ask whether that includes the person who made the change. If it does, the change has one signature, whatever the screen calls it.
Does a price rise on a change go through the budget check?
What you will probably hear
Budgets are checked when the order is approved.
How to read it
That is the first approval. Ask what happens to the second one, and whether a rise on one line can hide behind a saving on another.
What does the supplier see after the order changes?
What you will probably hear
They can log in and see the current order.
How to read it
Ask whether their earlier acceptance still shows against the new version. If it does, the system is recording a promise the supplier never made.
See purchase orders, receiving and matching
Orders with numbered change orders, receiving that refuses an over-delivery against the current lines, and a three-way match before payment.
Explore purchase ordersFrequently asked questions
Can I just edit a purchase order after it has been sent?
Not in AWRA. Once an order is issued, its lines, prices and delivery date change only through a change order: you propose the change with a reason, a second person approves it, and it is applied as a new numbered revision. The old edit address for an order opens the order page instead.
What can a change order change?
The quantity and unit price on each line, dropping a line by setting it to zero, and the delivery date. Through the API a new item can also be added. The supplier, the warehouse and the rest of the order are outside a revision; if the supplier changes, cancel the order and raise a new one.
Can I approve a change I proposed myself?
No. The person who proposed a change is refused at approval even if they hold the permission to approve purchase orders, whatever their role. Someone else who holds that permission has to approve it.
What happens to the supplier when a change is approved?
Their acknowledgement of the order is cleared, because they accepted the earlier version. If your workspace emails purchase orders to suppliers, the order is sent to them again in its current form, and they acknowledge it again through the supplier portal or a remote signature.
Can a change order reduce a line below what has already been delivered?
No. A line can be cut to exactly what has been received and no lower, and a line that has been partly received cannot be removed. Those goods are already in the warehouse, and an order for fewer would make honest receipts look like over-receipts.
Does an increase go through the budget check?
Yes, when your workspace has budget control switched on. Only the rise is tested, worked out line by line and grouped by item category, so a saving on one line does not cover a rise on another. In block mode a rise past the remaining budget is refused unless an authorised person gives a written reason.
