How to Track Supplier On-Time Delivery

Late, probably. Now prove it.

Every plant has a version of this supplier. The planner pads its lead times without being asked. Expediting calls cluster around its POs. Someone says "they are always late" in a meeting and nobody disagrees, but when the account rep answers "we had one rough month, we are back on track," the room has nothing to say. An impression is arguing with an impression, and the supplier's impression is better rehearsed.

The evidence already exists. It has been arriving for years in the acknowledgments, shipping documents, and receiving records that flow through your inbox and across your dock. A supplier can argue with your memory. It cannot argue with its own acknowledgment. Tracking on-time delivery is the work of putting those documents side by side, and it comes down to two dates.

The two dates, and where they live

The promise date.Your PO carries the date you asked for. The vendor's order acknowledgment carries the date the vendor committed to, and when the two differ, the acknowledgment governs the on-time question, because it is the vendor's own signature on a date. Measuring a supplier against a requested date it never agreed to produces a number the supplier can dismiss in one sentence, and it will. If the vendor never sent an acknowledgment at all, that is its own finding, and its own article: tracking PO acknowledgments covers the confirm-or-chase loop that comes before delivery measurement.

The actual date. The bill of lading carries the date the goods actually shipped. The packing slip and your goods receipt carry the date they actually arrived. Match the measurement to the promise: a vendor that commits to ship dates gets measured on the BOL, and a vendor that commits to delivery dates gets measured on the receipt. Mixing the two manufactures disputes, because transit time becomes an argument about whose fault the gap is.

Both dates sit in documents you already receive. Nobody has to ask the supplier for data, and that matters: a lateness measurement built from the supplier's own acknowledgments and shipping papers cannot be waved off as your system's error.

Why ERP receipt data alone under-measures

The obvious shortcut is to pull a receipts report from the ERP and compare receipt dates to PO due dates. It is better than nothing and quietly wrong in two directions.

First, the clock starts at entry. The receipt date in the ERP is the date receiving keyed the transaction, not the date the truck arrived, and the gap between dock and keyboard varies with workload. The BOL and the packing slip carry the real dates; the ERP carries the data-entry date.

Second, and worse, the ERP misses the promise chain. The due date on the PO record is usually the date you requested, not the date the vendor committed to. The acknowledgment that committed a different date is a PDF attached to an email that nobody keyed in. The revised date the rep sent three weeks later exists nowhere in the system. So vendors get blamed for dates they never agreed to, and vendors that slipped their own commitments look fine because someone updated the due date to match reality before receiving posted. Your ERP is a system of record; it stores data you enter. The promise chain lives in documents it never sees.

Two numbers per vendor

With promise and actual dates lined up per order line, the metric is deliberately simple:

• On-time rate: the share of order lines received on or before the promised date. Count lines, not POs, because partial shipments are exactly the behavior you want visible.
• Typical lateness:the median days late among the late lines. Median, not average, so one blizzard or one port strike does not define a vendor's number.

Resist the urge to build a weighted composite score on day one. Two plain numbers survive a vendor conversation; a proprietary index invites a debate about the formula instead of the lateness. (Retail and logistics teams use a stricter shipper-side cousin of this metric called OTIF, on time in full, with chargebacks attached. You do not need that vocabulary to answer the buyer-side question.)

Predicting the next order, honestly

Once the history exists, the honest forecast for the next order is the vendor's own track record: its on-time rate says how likely the promise date is to hold, and its typical lateness says how far the date slips when it does. A vendor at 95 percent on-time gets planned at face value. A vendor that misses a third of its promises by about a week gets padded by about a week, or gets a harder conversation.

Be suspicious of anything fancier. Models that claim to adjust delivery risk for part category, order size, or seasonality need far more history per vendor than a mid-market manufacturer's document volume provides; slicing a few dozen order lines into subcategories produces confident noise. Vendor-level history is the prediction you can defend across a table from the vendor, because every input is a document the vendor sent you.

What to do with the number

The vendor conversation.Bring lines, not adjectives. A table of PO number, promised date from the vendor's own acknowledgment, receipt date, and days late changes the meeting: the rep cannot answer fifteen specific lines with "one rough month." Ask what changed, ask for a recovery plan, and reset promise dates to numbers the vendor will actually sign. The same evidence rolls up into the quarterly view covered in supplier scorecards from documents.

Second-sourcing thresholds.Decide the trigger before you are angry, and write it down. For example: an on-time rate below 80 percent for two consecutive quarters starts qualification of an alternate source; typical lateness above a week moves the vendor's planning lead time up by that amount until two clean quarters pass. The numbers are yours to set; the point is that the threshold exists before the miss, so the response is policy instead of mood. Qualifying the alternate is its own workflow, covered in vendor intelligence for procurement.

What the number looks like

A machine shop supplies brackets on roughly weekly POs. Over twelve months: 45 order lines with a promised date on the vendor's acknowledgment, 15 of them received after that date. On-time rate: 67 percent, late on roughly a third of orders. Median lateness on the late lines: 6 days. One line was 19 days late during a documented outage; the median keeps that outlier from becoming the story.

Those two numbers convert directly into action. The planner stops padding by instinct and pads by 6 days, visibly, as a costed decision instead of quiet buffer stock. The buyer walks into the quarterly call with the 15 lines printed, promised date next to receipt date, and asks which of the next quarter's promise dates are real. And if the on-time rate is still under 80 percent two quarters from now, the second-source qualification starts on schedule, because the threshold was written down before the meeting.

Doing this from documents instead of a spreadsheet

Everything above works in a spreadsheet. What kills it is maintenance: the promise dates arrive as PDF acknowledgments attached to emails, the actuals arrive as BOLs and packing slips, and the person who owns the spreadsheet has a full-time job that is not retyping dates. The measurement decays the week that person gets busy.

This is the part Kynthar automates. Forward your procurement emails to a Kynthar address and it reads the bodies and the attachments together, no templates, no per-vendor setup, and connects each acknowledgment, BOL, and receipt to the PO and vendor it references, within minutes of the email arriving instead of whenever someone opens it. From that history it tracks promise date against actual per vendor: the on-time rate, the typical lateness, and the delivery risk on open orders, scored from the vendor's own track record. It also watches the front of the chain: POs still unacknowledged past a follow-up window get flagged, and because per-vendor response time is learned, a vendor that normally confirms in 2 days and has gone quiet for 6 surfaces as a finding in your team's work queue, ready to assign. Historical documents can be uploaded to seed the baseline, and ERP history arrives the same way: export it, and Kynthar ingests it alongside the documents your ERP never sees.