AWRA OpsHub Search

On Time Means Seven Days to Everybody

Our vendor scorecard reports an on-time delivery rate. On time means the order's planned delivery date falls within seven days of the order being raised — seven, for every supplier, in every country, for every kind of goods. It never checks when anything actually arrived.

Procurement Insights AWRA OpsHub Team 11 min read

There is a supplier scorecard in this product. It reports an on-time rate, a response rate, an average lead time, a consistency rating and a risk score out of a hundred, with a verdict of Excellent, Good or Needs Improvement.

One of those five numbers is derived from something a supplier did. The other four rest on a comparison that is worth setting out in full, because once you have read it you will never look at the score the same way.

What "on time" means here

An order counts as on time if its delivery date field falls within seven days of the date the order was created.

Read that twice, because there are three separate things wrong with it and they compound.

  1. Seven days is a constant

    It is written into the code. It is not your agreed lead time, not the supplier's quoted delivery time — which the system does hold — and not configurable anywhere. Every supplier in every organisation is measured against the same week.

  2. It compares a plan to a plan

    The delivery date on an order is what was intended, not what happened. The comparison never looks at when the goods were actually received, even though the receipt is recorded with a date and matched against the order. A supplier who promised five days and delivered in forty is on time.

  3. The denominator is every order

    The on-time count is divided by all purchase orders for that supplier, including ones still open and not yet delivered. So placing an order lowers a supplier's score until it is delivered, and a supplier you order from frequently is penalised for the orders in flight.

The number is not a measurement of a supplier. It is a measurement of how somebody filled in a date field.

What that does to a Zimbabwean supply base

It converts a legitimate business model into a permanent failing grade.

A great deal of what is bought here is imported, and the honest lead time on an imported order — order, manufacture, ship, clear, transport inland — is measured in weeks at best. Any supplier operating on that basis has a planned delivery date well beyond seven days from the order, on every single order, forever.

Their on-time rate is zero. Not low: zero. And because on-time carries half the weight of the risk score, they are rated Needs Improvement no matter how reliably they perform.

Meanwhile the local supplier who quotes three days and takes three weeks scores a hundred per cent, because the field on the order still says three days.

Two suppliers, one scorecard

Importer: promised 45 days Delivered in 44
Importer on-time rate 0%
Local supplier: promised 3 days Delivered in 21
Local supplier on-time rate 100%
Weight of on-time in the risk score 50%
Reported verdict The reliable supplier needs improvement; the late one is excellent

The two suppliers here are illustrative. The mechanism is not — it is exactly what the code does, and the direction of the error is systematic rather than random: it rewards optimistic date entry and penalises honest long lead times.

The one number that is real

The response rate. It counts orders the supplier has acknowledged, and the acknowledgement is something the supplier actually does, through their portal login, with a timestamp on it.

That is a genuine measure of a genuine behaviour, and it is the only one here that cannot be produced by somebody typing a date. If you use the scorecard at all, use that column and ignore the rest.

It carries thirty per cent of the risk score, which means the composite is thirty per cent evidence and seventy per cent arithmetic on planned dates. That ratio is why we would not put the composite in front of a supplier.

Our position

Do not use the on-time rate, the average lead time, the consistency rating or the composite risk score for any decision that affects a supplier. Use the response rate, which is real. Measure actual delivery performance yourself by comparing the order's delivery date to the receipt date — both are recorded, on every order, and the comparison the scorecard should be making is available to you in a spreadsheet today.

The supplier-scorecard ledger, precisely

What AWRA OpsHub does today

  • A vendor scorecard with an on-time rate, a response rate, an average lead time, a consistency rating and a composite risk score with a verbal rating.
  • A response rate derived from the supplier's own acknowledgement through the portal, with a timestamp — the one figure here that measures a behaviour.
  • Order dates, planned delivery dates and receipt dates all recorded, so the correct comparison is available in the data.
  • A supplier portal in which acknowledgement, acceptance, rejection and shipping status are all recorded.

What it does not do

  • Any comparison of a promised delivery date against an actual receipt date. The on-time test compares the planned date to the order date.
  • A configurable on-time window. Seven days is hardcoded and universal.
  • Per-supplier or per-category lead-time expectations for the score to measure against.
  • Exclusion of undelivered orders from the denominator, so open orders lower a supplier's rate.
  • Any use of the separate supplier-performance model, which has never held a value and is dead code.

Not ours, by choice

  • This is a live computation producing a real number on a real screen, which makes it more dangerous than an absent feature. An empty report tells you nothing; this one tells you something wrong.
  • The response rate is genuinely good and we would keep it. The criticism is specific to the delivery-timing half.
  • Nothing here is Zimbabwean. It is what a seven-day constant does to a long lead time, and an import-dependent supply base is where every supplier has one.

This is scope, not a ceiling

What is not built for Southern Africa today can still be built for you

Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Southern Africa. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a revenue authority pipeline, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.

Tax pipelines and return output

Return output in the shape your revenue authority expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.

Banks, EFT and card acquirers

Bank statement feeds, EFT and debit-order files and card acquirer settlements pulled into the Payments Register so receipts match invoices without re-keying.

The operational work, which is what most commissions actually are

An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.

Payroll and statutory returns

Payroll tax and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.

Systems you already run

The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.

How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.

Tell us what you need integrated

Four questions about any supplier scorecard

What two dates does on-time compare?

A good answer sounds like

The promised date and the actual receipt date.

What it actually means

Ours compares the planned date to the order date. This one question settles whether a scorecard measures anything.

Where does the on-time window come from?

A good answer sounds like

The order, or the supplier agreement.

What it actually means

A constant means every supplier is judged against the same lead time, which is only fair if all your suppliers are the same kind of supplier.

Are undelivered orders in the denominator?

A good answer sounds like

No.

What it actually means

If they are, ordering more from a good supplier makes them look worse, which is the opposite of what a score is for.

Which figure here is derived from something the supplier did?

A good answer sounds like

A short, honest list.

What it actually means

This is the question to ask of any scorecard in any product. The answer is usually shorter than the column count.

Measure delivery properly, in a spreadsheet, this week

Order date, promised date, receipt date. Three columns you already have, one subtraction, and you will know more about your suppliers than any score in this product can tell you.

Build the real measure

Frequently asked questions

Can I change the seven-day window?

No. It is written into the calculation rather than held as a setting, so there is no screen where it can be adjusted and no per-supplier override.

Does the scorecard affect anything else in the system?

It feeds insight screens and can influence the language of a suggestion, and it does not gate anything — no order is refused and no supplier is deactivated because of it. That is fortunate, given what the number is.

Would you fix this?

The right fix is to compare the promised delivery date against the receipt date, both of which are already recorded on every order, and to make the tolerance a setting rather than a constant. It is a small change with a large effect on whether the figure means anything, and if supplier performance measurement matters to you it is worth raising as a requirement rather than waiting.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center