Why is your supplier OTIF ninety-eight percent when…

Why is your supplier OTIF ninety-eight percent when deliveries are late?

Because you are measuring arrivals against the date the vendor most recently agreed to, and the vendor has moved that date three times. Measured that way, a supplier who slips a month scores the same as one who never slips at all. The number is not wrong. It is a tautology.

OTIF (on-time in-full — the share of supplier deliveries that arrive complete and on the agreed date) is only a supplier measure if "agreed" is fixed at a point in time. In Dynamics 365 Supply Chain Management the field it is usually computed from is not fixed. It is the current value of a field the vendor is allowed to change.

What the product actually stores

Purchase orders carry four dates, and Microsoft's Calculate requested ship dates for purchase orders page defines each one:

**Requested ship date** — Microsoft's definition: "The date on which you want the vendor to ship the goods" · Who sets it: You
**Requested receipt date** — Microsoft's definition: "The date on which you want to receive the goods" · Who sets it: You
**Confirmed ship date** — Microsoft's definition: "The date on which the vendor ships the goods, as confirmed by the vendor" · Who sets it: The vendor
**Confirmed receipt date** — Microsoft's definition: "The date on which you receive the goods, as confirmed by the vendor" · Who sets it: The vendor

The same page adds a line worth reading twice: confirmed dates are "Manually entered by the vendor and not adjusted by any calendar." Requested dates are calculated from lead time, transport days and calendars. Confirmed dates are typed by a counterparty.

This behaviour needs the Supplier requested and confirmed shipment dates option on the Procurement and sourcing parameters page, Delivery tab, and Microsoft states the prerequisites plainly: "You must be running Dynamics 365 Supply Chain Management version 10.0.40 or later" and "You must be using Planning Optimization, not the deprecated master planning engine" [DEPR].

The overwrite is the whole problem

Each field holds one value. Microsoft documents the recalculation chain: "If the Confirmed ship date value is changed, the Confirmed receipt date value is recalculated," and the reverse. There is no second column holding what was confirmed the first time.

The vendor is the one changing it. Through the vendor collaboration interface [GA], on the header a vendor "can change the following information": vendor document reference, mode of delivery, delivery terms, and Confirmed receipt date. On the lines, "the vendor can change the quantity and the receipt dates". And on processing: "Every line that has a status of Accepted will have a confirmed receipt date. When you run the Process PO update action, this date is updated on the PO."

Then the sentence that connects this to your plan, from the same page:

"The version of the PO that is available to other processes in Supply Chain Management is always the

latest version, even if that version hasn't yet been registered in the vendor collaboration

interface."

So the field your OTIF report reads and the field your master plan reads are the same field, and it always shows the most recent promise. A supplier who re-promises often is, by construction, a supplier who is always about to be on time.

What history does survive

Dynamics 365 does not throw the earlier promises away. It just does not put them where a measure would naturally look.

**Confirmation journals — What Microsoft says it holds: "A journal is created to store an exact copy of what was confirmed in the system… additional journals are created after the updated order is confirmed. These journals let you view the history of the various versions of the order that were confirmed" — [Approve and confirm purchase orders](https://learn.microsoft.com/en-us/dynamics365/supply-chain/procurement/purchase-order-approval-confirmation) · Where it lives: Created by the Confirmation or Confirm** action on the purchase order
**Purchase order vendor confirmation history page** — What Microsoft says it holds: "lets you and your vendors track the history of each order" — Vendor collaboration with external vendors · Where it lives: Vendor collaboration
**Confirmed purchase orders with changes workspace [GA]** — What Microsoft says it holds: The line list shows "the item number, product name, original quantity, new quantity, original confirmed receipt date, and new confirmed receipt date" — Review and accept changes to confirmed purchase orders · Where it lives: Procurement and sourcing > Workspaces > Confirmed purchase orders with changes

Read the third row carefully, because it is the shape of the gap. The workspace shows the previous confirmed receipt date against the new one — one delta, the most recent one — and it is built for triage: "When a purchase order that was previously confirmed is changed, it's moved back to the Approved state," and a purchaser reconfirms. It does not claim to tell you that this line has been re-promised four times. The measure you want is a lifetime property of the line; the workspace is a queue.

The measure we would build

This design is ours, not Microsoft's, and it has three parts. Nothing here is a product feature; it is how we would define the metric before anyone writes a query.

**On-time against first confirmed date — Definition: Actual receipt against the earliest** confirmed receipt date recorded for that line, not the current field value · Why it is the honest one: Fixes "agreed" at the moment the commitment was made. A supplier cannot improve this score by re-promising
**Confirmation change count* — Definition: The number of confirmations recorded against the line, minus the original · Why it is the honest one: Separates late from unreliable*. A vendor who confirms once and delivers a week late is a different problem from one who hits every date after moving it three times
**Promise drift, in days** — Definition: Latest confirmed receipt date minus first confirmed receipt date · Why it is the honest one: The number your planner actually needs, because it is how far the supply moved after you had already planned against it

Two honest caveats attach. It depends on the confirmation journal genuinely retaining the confirmed dates per line — Microsoft describes it as "an exact copy of what was confirmed", which is the right shape, but confirm what your version retains before building on it. And the change count is only meaningful split by who initiated the change, which is the next section.

Report all three together. On-time against the first confirmed date says whether the supplier keeps promises; the change count says whether the promise was worth planning against. Neither is interesting alone, and the pair is hard to argue with in a supplier review.

Why a replenishment plan cares

A replenishment plan is only as good as the lead time it trusts, and under Planning Optimization [GA] the date it trusts on a released purchase order is the one currently on the order. Microsoft's date and time parameters page names it: the expected receipt time parameter is "The expected receipt date for a released receipt. The user sets the value in Supply Chain Management," and the page states it is not adjusted by Planning Optimization. The planned receipt time maps to the Delivery date field, or to Requested date where the order is not yet released.

Put the two halves together and the loop is visible. The vendor moves the confirmed date. The plan re-plans against the new date, calmly, because that date is now the truth. The OTIF report reads the same field and reports success. Nothing in that loop carries the information that the item is three weeks later than the day you committed to your own customer.

That is why the forecast side of this cluster is not enough on its own. Netting the forecast correctly fixes the demand your plan sees; it does nothing about a supply date that has been quietly rewritten. The companion piece on forecast double-counting handles the first half.

The counter-argument, which is partly right

"Half those date changes are ours. We moved the requested date, the vendor re-confirmed, and you are about to blame them for our schedule change."

Correct, and any change count that ignores this is a weapon rather than a measure. Dynamics 365 gives you the raw material to split it: under change management a purchase order moves through documented approval statuses — Draft, In review, Rejected, Approved, Confirmed, Finalized — and a buyer-initiated change goes through Request change and back to Draft, while a vendor-initiated change arrives as a response and the order "is moved back to the Approved state". Two paths, both recorded.

Publish both halves and the supplier conversation gets better rather than louder. If most of the drift is yours, that is a finding worth having too — and it is a planning finding, not a procurement one.

What to do this week

Find out which field your current OTIF report reads. If it is the confirmed receipt date on the purchase order line, you have a tautology, and you can stop reading and go and fix that.
Take the orders carrying your three worst-performing part numbers and open the Purchase order vendor confirmation history page for each — Microsoft describes it as tracking "the history of each order" — then count the versions. That count is your unreliability signal.
Open the Confirmed purchase orders with changes workspace and read the original and new confirmed receipt dates on the current queue. That is today's drift, not the trend — which is the point.
Before you change any lead time in item coverage, check whether the value you are about to enter is the one the vendor quotes or the one the vendor achieves. The plan only sees the one you type.

Where we would draw the line

We would not build a supplier scorecard that reads the current confirmed date, whatever it is called in the report. We would not present a change count without splitting it by initiator, because the unsplit version is dishonest in a way that gets found out in the first review meeting. And we would not put a vendor-facing number in front of a supplier until the first-confirmed-date extract has been reconciled against a handful of orders by hand — a scorecard that loses one argument on a data error never recovers.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If your supplier scorecard says one thing and your planners say another, book a call and we will walk the first-confirmed-date measure against your own confirmation history. https://cognilium.ai

Why is your supplier OTIF ninety-eight percent when deliveries are late?