Need date vs promise date: what to plan and score against
Keep need date, PO due date and promise date in separate fields, plan against the confirmed date, and score suppliers on their first promise.
A PO line can carry three dates: what you asked for, what the supplier promised, and the date your build needs the part. Mix them up, or let a later promise quietly overwrite the need date, and a slipping order looks on time until the part is missing at the line. Keep the three dates in separate fields, plan against the one the supplier has confirmed, and score deliveries against the first promise instead of the last one. Your team then catches a slipping order while there's still time to act on it.
What is a need date?
A need date is the date your build requires a purchased part on hand and ready to issue. MRP sets it from the demand the part feeds, such as the start of the work order that consumes it. The part's lead time then decides when to place the order. When that demand changes, the need date moves with it.
The need date lives in your MRP or planning system, not on the purchase order. It's the number your planner and expediter act on; the supplier never sees it unless you choose to share it. A part that arrives before its need date is early inventory, and a part that arrives after it is a shortage, whatever date the PO shows.
What is the difference between a PO due date and a promise date?
The PO due date is the delivery date you asked for when you sent the order. The promise date is the date the supplier commits to on its acknowledgement. A re-promise is a later promise date the supplier gives after missing or revising an earlier one.
A promise date can be the day the supplier ships or the day the part reaches your dock. The gap between them is transit time, so ask the supplier which one it means before you record it. Purchase order acknowledgement turns a request into a line-level confirmed date. A supplier on EDI sends the same commitment as an X12 855 (EDI 855) or EDIFACT ORDRSP message.
The figure below lines up the requested date, need date, first promise and current promise for one PO line.
Four dates on one PO line
An illustrative timeline for a single purchase order line showing four dates in calendar order: the PO due date (requested delivery date) on November 6, 2026; the need date on November 10, 2026, four days after the requested date; the first promise date on November 14, 2026, four days after the need date; and the current promise date, after one re-promise, on November 21, 2026, seven days after the first promise and eleven days after the need date. Brackets between the points label each gap in days, showing that the supplier's very first promise already missed the need date, and that a later re-promise widened the miss.
- 1
PO due date (requested)
- What it marks
- The delivery date you asked for when you sent the PO
- Illustrative date
- November 6, 2026
- Gap
- Baseline
- 2
Need date
- What it marks
- The date your build requires the part, set by MRP
- Illustrative date
- November 10, 2026
- Gap
- 4 days after the requested date, the buffer built into the request
- 3
First promise
- What it marks
- The date the supplier confirmed on its first acknowledgement
- Illustrative date
- November 14, 2026
- Gap
- 4 days after the need date, already a gap worth flagging
- 4
Current promise
- What it marks
- The date the supplier confirmed after a later re-promise
- Illustrative date
- November 21, 2026
- Gap
- 7 days later than the first promise, 11 days after the need date
An illustrative PO line where the first promise already missed the need date, and a re-promise made the gap worse; scoring against the current promise would hide the seven-day re-promise slip.
They match only when the supplier confirms without changing anything.
Why keep need date and promise date in separate fields?
Need date, PO due date and promise date answer different questions, so keep each one in its own field. Overwrite the requested date with the promise date, or the need date with either one, and you lose the gap that told you the order was at risk in the first place.
A buyer who types the supplier's promise date over the requested date on the PO line erases the record of what was asked for. A planner who lets the promise date stand in for the need date loses the number MRP is supposed to protect. Keep all three, plus every date a supplier re-promises, so a later review can tell whether a delivery missed the date you asked for, the date the supplier committed to, or the date the build needed.
Which date should you plan against?
Plan against the confirmed promise date wherever a line has one. Where a line has no confirmed date yet, treat it as a risk, and work from the requested date only as a placeholder until the supplier confirms it, and chase that confirmation.
A common blind spot in a build plan is an unconfirmed line, because the requested date sits in the system looking like a real commitment when no one has agreed to it. When an order has no confirmed date, a readiness signal opens a task, and Cartograph hands it to your team or Scout Agent. Scout Agent emails and calls the supplier for a line-level date, within the permissions your team sets.
The table below matches each purpose to the date it should use.
Which date to use for what
A four-row table matching a purpose to the date to use and why. Planning the build uses the confirmed promise date where one exists, and treats an unconfirmed line as at risk, because MRP needs a date it can trust to sequence work. Setting expediting priority uses the gap between the current promise and the need date, because the part with the largest gap is usually the one holding up the build. Scoring supplier on-time delivery uses the first promise date, or the requested date on the PO if the supplier never confirmed one, because scoring against the latest re-promise rewards a supplier for moving the goalposts. Quoting a date to your customer uses the later of the need date and the confirmed promise date for the parts still to arrive, plus your own build and ship time, because promising the need date when a part will still arrive later overpromises the customer.
| Purpose | Date to use | Why |
|---|---|---|
| Planning the build (MRP, kitting, clear-to-build) | The confirmed promise date where one exists; treat an unconfirmed line as at risk | MRP needs a date it can trust to sequence work; an unconfirmed line is a request, not a commitment |
| Setting expediting priority | The gap between the current promise date and the need date | The part with the largest gap to its need date is usually the one holding up the build |
| Scoring supplier on-time delivery | The first promise date, or the requested date on the PO if the supplier never confirmed one | Scoring against the latest re-promise rewards a supplier for moving the date instead of hitting it |
| Quoting a date to your customer | The later of the need date and the confirmed promise date for the parts still to arrive, plus your build and ship time | If a part will still arrive after the need date, promising the need date overpromises the customer |
The same PO line carries several dates; which one belongs in a decision changes with the decision.
What is the gap between need date and promise date?
A promise date on or before the need date covers the build. A promise date after the need date is a shortage in the making, whether or not anyone has noticed it yet. The gap between the two tells you whether an order is on track or at risk.
Watch this gap on every open line, including ones that look fine today, because a promise date that once covered the need date can slip on a later re-promise. When the current promise moves past the need date, expediting starts. When an order will arrive after the part runs short, a readiness signal opens a task, and Cartograph hands it to your team or Scout Agent.
How does a need date move?
A need date moves whenever the demand behind it changes: a customer pulls in a ship date, a work order is rescheduled, or a higher-level assembly's schedule shifts. MRP reflects the new date as a reschedule message, telling the planner to move the linked purchase order in or out to match.
Act on the reschedule-in and reschedule-out messages MRP raises promptly, because a purchase order left at its old date no longer matches what the build needs. Pushing an order out when its need date moves later can also free supplier capacity for a line that just moved earlier.
Which date should you score supplier on-time delivery against?
Score on-time delivery against the first promise date the supplier gave, or the requested date on the PO if the supplier never confirmed one. Scoring against the latest re-promise instead lets a supplier who keeps sliding its own date score as on time, because each new date replaces the one it missed.
Record every re-promise as a new date on the line, but keep the first promise date in its own field so a later review can compare what the supplier delivered against what it first said it would. A pattern of re-promising on the same supplier is a reason to review that supplier's capacity and lead times.
In the United States
A supplier may not accept a DPAS-rated order for a delivery date it cannot meet. It must tell you the earliest date it can deliver and offer to accept the order on that date. 15 CFR 700.13(b)(1). If it accepts and later finds delivery will be late, it must notify you immediately with the reasons and a new date, and confirm a verbal notice in writing or electronically within one working day. 15 CFR 700.13(d)(3). Check the acceptance window and the rest of the process in DPAS rated orders.
Questions teams ask
Should the requested date on the PO ever be earlier than the need date?
Yes. Some teams request a date a few days or weeks ahead of the need date on purpose, to leave room for a short slip without missing the build. Keep that buffer visible as its own gap instead of hiding it inside a single date field.
What do you do when a supplier only acknowledges the PO without giving a ship date?
Treat the line as unconfirmed and keep chasing it. Purchase order acknowledgement turns a receipt-only acknowledgement into a line-level confirmed date.
Does the current promise date replace the first promise date in your records?
No. Record the current promise date as the date the plan uses now, but keep the first promise date so you can still see how far the supplier's own date has moved.
Which date should OTIF be measured against?
The first promise date, or the requested date if the supplier never confirmed one. OTIF measures whether a delivery arrived on time and in full against that date, so using the latest re-promise instead of the first promise changes the result.
If unconfirmed lines and slipping promises keep reaching your build plan, talk to our team about how Cartograph's readiness signals turn them into tasks for your team or Scout Agent.
This article is general information, not legal or tax advice. Check how the rules apply to your business with your legal or tax advisor.