"Just Update the PO": Famous Last Words

The rant

“Just update the PO.”

Those four words have launched more chaos than any server outage I can remember.

Because a purchase order is not a draft email. It is a contract, a planning signal, a receiving roadmap, and an invoice matching anchor. When you casually edit it after the fact, you are not “keeping it current.” You are rewriting history, and every downstream team pays for it in a different way.

In manufacturing, this gets ugly fast. Change a date and master planning may re-peg supply to demand. Change a quantity and you can break production coverage. Change an item and receiving loses the thread. Change a price late and AP gets stuck doing detective work. D365 is built to help you control this, but it will not save you from a culture that treats the PO like a live chat message.

If you want a simple rule: POs can change, but they need change control. Otherwise you do not have a process. You have edits.

Dad joke for the road: A PO without change control is like letting your kids “help” bake cookies. Sure, something comes out of the oven. It is just not cookies.

</Rant>

What D365 is trying to protect you from

Dynamics 365 Supply Chain Management has a few concepts that matter here:

• Change management for purchase orders is a real feature you enable via Activate change management in Procurement and sourcing parameters. When it’s enabled, POs start as Draft, go through an approval workflow, and if you want to modify an approved PO you must use Request change.

• When an order is confirmed, D365 creates a confirmation journal that stores an exact copy of what was confirmed. If the order gets changed and confirmed again, you get additional journals so you can see version history.

• D365 calls out that both the Confirmation action and the Confirm action set the PO to Confirmed, and confirmation triggers accounting distributions plus optional order and budget checks.

That is the system saying, politely: “Please stop editing committed supply like it is a suggestion.”

The two confusions that cause most PO change chaos

1) Confirmation vs vendor acknowledgment

These are not the same thing.

• Confirmation in D365 is your internal commitment step. It creates a journal snapshot and moves the PO to Confirmed.

• Vendor acknowledgment is the supplier saying “yes,” “no,” or “yes but…” In vendor collaboration, you send the PO for confirmation, the PO goes to In external review, and the vendor can accept, reject, or suggest changes.

If you treat vendor acceptance as “cool, we’re done,” you will miss the point: vendor acceptance is often where the change requests begin.

2) Editing the current PO vs issuing a new version

When a vendor has already responded, D365 expects you to send a new version of the PO back to the vendor for confirmation, and it tracks that history.

That is the discipline most teams skip, then wonder why receiving and AP are referencing different “truths.”

Why POs change in the real world

PO changes are normal. What is not normal is pretending they are not impactful.

In manufacturing, changes usually come from:

• Supplier capacity, lead time slips, backorders

• Partial shipments

• Substitutions due to shortages

• Lot sizing changes, packaging constraints, minimum order quantities

• Expedite requests from production

• Price changes, surcharges, freight, accessorials (iykyk)

• Engineering changes (what you ordered is no longer what you need)

Your process has to assume these will happen, then control how they happen.

The failure modes

Here are the ones that blow up the most implementations, with the “why” behind each.

1) Buyers overwrite reality after receiving has started

Symptom: receiving cannot reconcile what showed up to what the PO now says.

What’s really happening: you changed the contract after execution began.

2) AP gets an invoice for a version of the PO that no longer exists

Symptom: invoice match failures, manual research, “can you resend the PO” emails.

Fix: version discipline, and stop changing price and charges late without process.

3) Planning gets whiplash

D365 explicitly notes that relationships between supplying POs and downstream demand can come from master planning pegging, inventory marking, and demand-created purchase orders (including projects).

Symptom: planners lose trust in the signals because POs keep moving.

4) Vendor says “accepted with changes” and nobody actually processes the response

In vendor collaboration, vendors can suggest changes like date, quantity, line splits, substitutions, and they can add notes.

Symptom: you think you have agreement, vendor thinks you accepted their changes, and the dock is where you discover you did not.

5) You use “Process PO update” without understanding the limits

D365 allows processing vendor-suggested updates, but only certain header updates and line date and quantity updates can be automatically applied. Some changes require manual updates, and the action can only be run one time per header or line.

Symptom: teams assume “the system applied everything” when it did not.

6) Reapproval is inconsistent

With change management enabled, making changes typically drives the PO back to Draft and through approval again. D365 also supports configuring that specific field changes do not require full re-approval in some scenarios. Symptom: buyers route around controls because the rules feel random.

7) The “latest version problem”

D365 notes that other processes always see the latest version of the PO, even if it has not yet been registered in vendor collaboration. Symptom: internal teams think the vendor saw “the latest,” but the vendor is still acting on the prior version.

8) Change control is “tribal knowledge”

Symptom: changes depend on who is working that week, not on policy.

9) “Small” changes that trigger big downstream impact

A date change looks small until it impacts production work, service work orders, or sales orders. The Confirmed purchase orders with changes workspace exists specifically to highlight that kind of downstream impact.

10) Late charges and freight treated as an afterthought

Symptom: costs drift, disputes rise, and everyone blames AP.

The operating model that actually works

If you want PO change control to stick, treat it like a production process: defined steps, clear ownership, visible exceptions.

Rule 1: Decide what is allowed to change without escalation

Examples of “low impact” changes might include earlier dates or increased quantity that do not break demand coverage. D365 even groups changes into low impact and high impact in the Confirmed purchase orders with changes workspace. Your job is to define your policy so the system supports it.

Rule 2: After vendor acknowledgment, changes require a new version

If the vendor has already responded, your update is not a casual edit. It is a new version you are asking them to accept.

Rule 3: Confirmations are snapshots, treat them as such

Confirmation journals exist for a reason: you need to know what was committed when.

Rule 4: If it affects receiving or invoicing, it affects control

Quantity, date, item, price, charges, delivery terms, mode of delivery. Treat these as controlled changes, not “buyer preferences.”

The checklist you can steal

Use this as your PO change control policy starter.

Setup and governance

• Enable PO change management where you need real control and approvals.

• Define who can Request change, who approves, and what triggers reapproval.

• Define what constitutes “low impact” vs “high impact” changes for your business.

Version discipline

• If the PO is in external review or already vendor-responded, issue a new version and send it back.

• Do not rely on “they saw the email.” Track vendor response status and the version trail.

Receiving and AP alignment

• Lock a rule: once receiving starts, changes that affect receiving require coordination with the warehouse lead.

• Lock a rule: price and charge changes after vendor acceptance require a controlled approval, because AP inherits the mess.

Exception management

• Use the Confirmed purchase orders with changes workspace to review changes after confirmation and assess downstream impact.

• Decide how you will handle vendor-suggested changes: manual review, Process PO update where appropriate, and a standard communication template back to the vendor.

DynamicsDad sign-off: If your process is “just update the PO,” your real process is “discover the problem at the dock.”

DynamicsDad