An issued purchase order may need to change when a forecast or delivery slot changes. The team can then hold an approved original, an approved revision, a sending record and a supplier reply that agrees with only part of it. Treating the newest file as the current instruction can leave the kitchen planning around terms the supplier did not accept.
This guide helps the reviewer establish which revision has internal approval, which was sent, which terms the supplier confirmed and what still needs resolution. The example, PO-026, is original fiction. It concerns the revision trail; the related receiving and invoice guides cover the later records.
Three facts that are easy to merge
Internal approval, sending and supplier agreement are separate events. Tie the approval to a specific revision and its authorised reviewer. Record which version was actually transmitted through the established channel. Retain the supplier response and identify whether it explicitly accepts that version or specifies particular terms.
An approved revision may not have been sent, and a delivered message does not by itself establish agreement. A supplier can explicitly accept an identified revision without repeating every field. A generic acknowledgement or a reply that counters a term needs different treatment. Verify the evidence for each event rather than filling one entry from another.
Fix the basis before comparing revisions
Identify the issued order and every affected line, specification and unit before comparing versions. PO-026 uses one item, ITEM-026, and the same unit throughout: a case of 6 containers at INR 200 per case, on a net goods basis. Taxes and other charges are outside the illustration and remain a separate review. If a revision changes a unit or specification, preserve the old and proposed values as an explicit change instead of silently converting or replacing them.
Store every revision as an unchanged snapshot with its parent revision ID. Never overwrite Rev0 when Rev1 appears. Then compare field by field: quantity, price, delivery date and time, and any other term. Amount arithmetic, such as 10 cases at INR 200 being INR 2,000, is a check on the document, not accounting approval.
Worked example: PO-026 as of 7 November 2026, 17:00 IST
In this fictional case Outlet North ordered ITEM-026 from supplier SUP-026. Rev0 was approved (AP0), sent at 09:00 on 6 November (SENT0) and confirmed exactly by the supplier at 10:00 the same day (CONF0). On 7 November the buyer proposed Rev1 at 11:00. It was approved at 12:00 (AP1) and sent at 12:15 (SENT1). At 14:00 the supplier replied with REP1.
At the review cutoff, no Rev2 has been issued and the current executable instruction is recorded as Unresolved. The INR 2,000 calculation for Rev1 is separate from what the supplier actually stated in REP1.
| Record (fictional) | Quantity and net goods | Delivery (IST) | Evidence | Review meaning |
|---|---|---|---|---|
| Rev0 | 12 cases × INR 200 = INR 2,400 | 9 Nov 09:00 | AP0, SENT0, CONF0 | Last fully matched historical record |
| Rev1; parent Rev0 | 10 cases × INR 200 = INR 2,000 | 10 Nov 09:00 | AP1, SENT1 | Approved and sent; whole revision not confirmed |
| Supplier reply REP1 | 10 cases and INR 200 per case agreed; total not explicitly stated | Proposes 11 Nov 09:00 | Reply received 7 Nov 14:00 | Quantity and price match; date countered |
Reading REP1: partial agreement is not confirmation
REP1 matches Rev1 on two fields and differs on one. Quantity and price agree; the delivery date does not. That makes it a partial agreement with a counterproposal, not confirmation of Rev1. Record it field by field: quantity agreed, price agreed, date countered with 11 November 09:00.
Do not infer a current instruction from REP1 alone. Rev0 remains the last fully matched historical snapshot, with its original approval, sending and confirmation evidence. That describes the document trail; it does not establish which terms legally bind the parties, cancellation rights or authority to withhold payment.
What to tell receiving and finance at the cutoff
This is the operator's decision point. At 17:00 the honest answer is that the current executable instruction is unresolved. Do not tell receiving to work to Rev0 because it was confirmed, or to Rev1 because it is newer. Either would present a guess as an instruction.
In this fictional organisation the buyer flags the case, resolves the delivery date with the supplier, prepares any resulting revision and obtains the required approval before communicating the resolved version through the established process. Log communications to purchasing, receiving and finance with their time, sender, recipient and revision reference. The example records no actual delivery, invoice posting, payment or fulfilment.
Recording the resolution without rewriting history
When the date is settled, any new revision gets its own ID, parent link, approval, sending and confirmation evidence. Until then, Rev2 does not exist and must not be shown as approved or confirmed. Add each later event as a dated review beside the 17:00 position rather than editing it, and record corrections with a reason, reviewer and time.
After the authorised buyer communicates the resolved instruction, receiving and finance apply their own checks against the relevant records. Use the related receiving and invoice-reconciliation guides for those steps. A completed revision record does not replace their separate evidence or controls.
Where the distinction comes from
Microsoft Learn's article on approving and confirming purchase orders separates internal approval from confirmation once the vendor agrees, keeps an exact copy of each confirmed version so history can be reviewed, and describes changes to an approved order going back through a defined review. Only those general distinctions inform this record. Its product statuses, automation, inventory, accounting and budget behaviour are not adopted, and no Keystonne feature is implied.
Put it into practice
Your action checklist
Your progress saves in this browser. No sign-up needed.
0 of 10 complete
From reading to doing
Purchase Order Revisions
Open Purchase Order Revisions for one issued order, recording the case reference, item specification, unit, amount basis and review cutoff. The worksheet is fully manual. Sections cover preserved revision snapshots with revision and parent revision IDs; a field-level comparison of before, proposed and supplier-confirmed values for quantity, price, delivery and other terms; separate internal approval, sent and supplier-reply evidence for each revision with actor, time and reference; a conflicts register with an explicit current-instruction field that can stay Unresolved; a communication log for purchasing, receiving and finance; and later resolution and dated review rows that preserve earlier entries. It performs no automatic approval, active-version selection, posting, payment or tax calculation.
Open the Purchase Order Revisions tab in the launch workbook. Keep a copy for your own business.
Download the free workbook See what’s inside the toolkit →Sources & further reading
- Approve and confirm purchase orders (Microsoft Learn, Dynamics 365 Supply Chain Management) ↗
Retrieved 8 November 2026; page last updated 5 November 2026. Used only for the general distinctions that internal approval is separate from confirmation after the vendor agrees, that an exact copy of each confirmed version supports a history of versions, and that changes to an approved order go through a defined review. Its interface, status automation, inventory, accounting and budget behaviour, cancellation and quantity rules are not adopted, and nothing here concerns legal enforceability. PO-026, its references, figures and workflow are original fiction.
Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.