Skip to main content
DoneThat

AI Adoption GuideProcurementOrder

Delivery lead time prediction

ML predicts actual delivery dates using supplier history, carrier data, and logistics signals, enabling proactive escalation.

Procurement processRequestApproveSourceEvaluateSelectOrderReceiveReview

By Don, DoneThat’s AI coach · updated

The date that matters is goods receipt, not the supplier promise

The useful forecast is when this line will post at your dock. Train it on your goods receipts for this vendor, this lane, and this item, then update it with in-transit events. The confirmed date on the PO is a commercial commitment. It is not a prediction of arrival.

A buyer who sequences a fill, a production slot, or an outbound truck from that confirmation is using the date that is easiest to read. MRP and the plant still treat it as fact until someone at the dock writes a different GR date. Your own receipts on this vendor and lane often disagree with the promise. Sometimes they are earlier.

What the model should return is a goods-receipt date with a range, plus why it diverges from the promise. It is not an on-time in-full (OTIF) percentage, and it is not a new date you send back as a revised commitment. You already have a promise. You need a date you would stake a production sequence on.

If you have never received this vendor on this lane for this item, you do not have a forecast. Write unknown. Do not copy a category average and call the line on time.

Slice history by vendor, lane, and item, then add carrier events

Start from receipts you already posted. Historical performance retrieval is that file at evaluation time: dated GRs against a vendor number, not a brochure. For an open PO you need the same timestamps as training data, cut so a different plant, ship-from, or material family cannot leak into this line.

Pin the grain before you train:

  • Vendor number you pay, plus the ship-from that actually loads. A mill is not a distributor that shares a logo.

  • Lane: origin, mode, and the ship-to that will receive. Punctual into a coastal DC is not the same as inland plant receiving.

  • Item or material family. Bagged product and a bulk tanker on the same vendor number do not share a lead time.

The target is actual goods-receipt date, the dock timestamp, not the accounting posting date. If receiving backdates GR to the PO delivery date so inventory looks clean, you are teaching the model to reproduce the lie. Fix capture first. Receipt quality scoring will later fold those timing events into a running KPI. This page is the live date on an open order, not the quarterly card.

Then overlay in-transit events while freight is moving: ASN, gate-out, carrier scans, appointment. Visibility platforms in this class include FourKites and project44. ERP and source-to-pay suites such as SAP and Coupa are where the PO, the confirmed date, and the GR usually live. This page does not rank those products. None of them creates dock history you never posted. An ASN with no movement behind it is a restated promise, not a location.

Output for the planner:

  • Predicted GR date, plus a range (best / typical / late) from this vendor+lane+item history.

  • The promise date still on the PO, so the gap is visible.

  • The last carrier or ASN event used, with its timestamp.

  • A flag when predicted GR is after the promise and there is still time to call.

Do not emit an OTIF from this model. If your ERP already computes one, and you can open the report, the period, and the vendor number, that is a separate scorecard. It is not this order's arrival date.

The promise date is often stamped when the PO is created from an approved requisition. PO auto-generation from requisition does not change this job. Prediction does not rewrite the PO. It tells you whether that date is still a plan you can run.

Flag before the promise date dies

The value is a warning while the confirmed date is still in the future, when a buyer or materials planner can still escalate. After GR posts late, you have an exception, not a forecast. Delivery discrepancy classification types that miss (late, short, damaged, wrong item) for claims and AP. This use case is the days before that posting.

Watch open POs where predicted GR is later than the promise, and the remaining window is long enough that a call can change something: a split shipment, a different load, a production resequence, a spot buy, or an honest delay to the plant.

The flag is a work queue for a person. The buyer or planner still decides whether to call, expedite, resequence, or wait. An amber prediction is not a freight upgrade. Auto-expediting every amber spends premium freight on loads that would have arrived, trains suppliers to ignore the panic, and buries the few lines that needed a truck. Someone has to own the queue. A dashboard nobody opens is decoration.

Re-score when a new event arrives. A late gate-out should move the predicted GR. An ASN that restates the original promise without a new scan should not. Trust dock history and current location more than a refreshed confirmation.

Worked example: a Monday fill the ASN still calls on time

The walk-through is illustrative, not a measured result.

A plant materials lead needs a resin grade for a Monday fill. The PO in the ERP shows a confirmed delivery of Friday. The supplier ASN still says Friday. Production has sequenced the line on that assumption.

History on this vendor number, this origin, this plant, this grade shows goods receipts that usually post after the confirmation, not on the promised Friday. There is no OTIF on this screen. There are dated GRs.

In transit, the load gated out later than the pattern that would support a Friday dock. Visibility still shows a Friday ETA because the carrier appointment was never revised.

The model should output a predicted GR in the following week, with a range, and flag the line now, while Friday has not yet passed. The materials lead calls the buyer. The buyer calls the supplier and the carrier. They may get an honest new date, a split, or nothing. Production can then pull a different order forward or delay the fill on purpose.

If this were a new converter with no receipts on this lane, do not print Friday, do not promote the ASN over the GR file, and do not auto-expedite.

If Monday's fill still runs because someone trusted the ASN, the failure is not that the supplier "broke OTIF." The failure is that the plant planned from a confirmation this lane's own receipts had already contradicted.

Do not treat a missing history or a pretty ASN as on-time

Trusting the ASN over the dock. An advanced shipping notice is a statement of intent. Your goods-receipt file is what happened on this lane. When they disagree, the live forecast should follow receipts and current scans, not a restated Friday.

Auto-expediting every amber. Premium freight is a decision with a cost. A queue of flags without a human who knows the plant sequence will either expedite everything or ignore everything. Keep the action as a call. Persistent lateness belongs in total cost of ownership modeling at the next award, not as this week's unapproved freight spend.

Treating a new supplier with no history as on-time. No receipts means unknown, not a pass. Do not fill the gap with a category median, a sister plant's lane, or the confirmation on the PO. A new vendor can still have carrier events. Use those as in-transit only, and keep confidence low until you have GRs of your own. The first load is a trial, not a learned lead time.

Before you show planners a queue, spot-check open orders against recent GRs on the same vendor+lane+item. If the predicted date hugs the ASN whenever the ASN is refreshed, stop. The model is reading the promise, not the dock.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first