An off-hire written at the gate and typed again at the desk, a weighbridge slip copied into the day book — one fault in trade after trade, and the number nobody in your building has written down.

The delivery ticket in your hand has already been typed into two systems, and it is 17:40 on Thursday 10 September. The driver took the signature at the site gate on Tuesday and the top copy came back on the van on Wednesday. This morning someone at the counter keyed the quantities, the short pick and the order reference into the invoice run. Now the customer is on the phone saying they took nine, not twelve, and the evidence is a docket in a folder behind you. The same folder holds last week's, and the week before that. You will raise a credit on Monday, and nobody here did anything wrong today. Nobody writes it down as a cost. It looks like Thursday.

The through-line this week: every company that buys, holds and sells or hires goods can count the points where the same fact is typed twice, almost nobody writes that number down because it belongs to no single department, and it is the cheapest diagnostic you have.

1. The count - what it is, and why the number does not exist in your building

Keyed twice means the same fact, a quantity, a price, a date or a part number, is typed by a person into two places. Not checked twice. Typed twice. The distinction matters, because double data entry has two meanings and only one is a problem. Double-key verification, where the same figure is entered twice, often by a second person, so the system can compare the two, is a control somebody chose. Re-keying, where a fact recorded in one place is typed again into another because the two do not talk, is waste. We count the second one.

The count is a plain number, taken per week, on one link of your chain. You get it by walking that link with the people who run it, asking one question at every desk, device and pad: where did that number come from. When the answer is a screen somebody else filled in, mark a point.

The reason the number does not exist is not laziness. It is ownership. In a builders merchant the driver owns the signed ticket, the branch owns the invoice run, and neither owns the gap. In a motor factor the returned part is written on a paper note in the van, credited from that note later, the core surcharge chased when the statement disagrees. In an engineering stores a part number goes on a requisition pad, into the purchase order, then onto the works order. Everyone is doing their job. Every point looks trivial on its own. Nobody stands where they can see all of them at once, so the total has never been written down, and a total nobody has written down cannot be argued about.

It is also the only number that belongs to the chain rather than to a department. Days to invoice belongs to accounts. Stock accuracy belongs to whoever runs the yard, the stores or the bay. The count belongs to the seam between them.

Ask your own team this week: "From the moment this fact is first written down to the moment it reaches an invoice, how many keyboards does it pass through, and who owns the gaps?"

2. Why it survives every upgrade - why the fix is almost never a new system

Almost nobody with this problem needs a new system. They need the one they already own to stop asking a person to be its integration layer.

Software is sold, in part, as the end of re-keying. The trouble is that re-keying does not live inside a system. It lives in the seams, between one system and the next, between a phone call and a screen, between a gate, a ward store or a venue loading door and a desk two miles away. A migration moves the seams; whether it removes them depends on whether anybody counted them first.

The delivered chain is in wholesale and distribution, for one wholesale group; in every other sector this is method, drawn from the same seven links and not yet built for a customer there. Those links are the same everywhere: supplier offer, purchase order, goods in, stock, allocation, goods out, invoice and payment. Only the words change.

The same fault, six trades:

  • Tool and plant hire: the off-hire. Written on a sheet at the gate, typed into the contract next morning, typed again when the stop date is queried. Keyed once: taken on a phone at collection.
  • Manufacturing: the goods received note. Written on the GRN pad, keyed against the works order, keyed again when the invoice will not match. Keyed once: scanned against the purchase order line at the bay.
  • Food and drink production: the batch code. On the pallet label, in the intake spreadsheet, then on the despatch note. Keyed once: taken at intake, carried to despatch.
  • Healthcare supplies: the lot number. Read off the delivery note, typed into the stock record, typed again onto the invoice with the customer's purchase order reference. Keyed once: lot and expiry captured at receipt and carried to the invoice.
  • 3PL and logistics: the billable movement. Handling units on a job sheet, into a client workbook, into an invoice three weeks later. Keyed once: billed from the movement itself.
  • Event and AV hire: the kit list. Typed into the quote, retyped into the prep sheet, retyped into the invoice. Keyed once: one list, quote to bill.

Ask in your next vendor meeting: "Which of the points where we key the same fact twice does this remove, and which does it move?"

3. What the count costs - why the minutes are the smallest part of it

Three-way matching checks the purchase order, the goods received note and the supplier invoice against each other before payment is approved. When one of the three is a pad in a drawer, the second keystroke stops costing seconds and starts costing a fortnight.

The count is a forecast of where your arguments will be. Every point where a fact is keyed twice is a point where two records can disagree, and every disagreement arrives dressed as something else: a credit note, a stock figure edited in three places that oversells a retail line by Thursday, a recall query in healthcare supplies answered from a filing cabinet.

Drift is the other cost, and it reaches the bank. The gap between goods leaving and the invoice going out is made of transcription steps, each waiting for somebody to have time. In an agricultural merchant in season the net weight prints at the bridge, goes into the day book, then into the invoice. By Friday the day book is a week behind, and the invoice cannot be ahead of it.

These are illustrative figures for the method, not a benchmark; run them on your own counts. Suppose one link carries twelve points, each ninety seconds, each forty times a week. That is twelve hours a week of typing before one error is chased.

We publish no benchmark for days from the trigger event to the invoice, whether that event is a delivery, an off-hire or a job closing. Distrust anyone who does without publishing their method. We measure yours: median and 90th percentile, last three months, from your own export. Suppose your export gives a median of two days from the trigger event to the invoice, with a 90th percentile of nine. That is not a two day problem. It is a handful of jobs where the top copy went into a tray and stayed there. Those customers write the emails.

Ask your finance manager: "Of the credits we raised last month, how many trace back to a fact typed into two places, and what is the median gap between goods moving and the invoice going out?"

4. Fix one link, not seven - what to measure before anyone writes code

The temptation is to fix all of it. That is not a scale problem but an exceptions problem. Each link has its own bad-day cases: the part delivery, the short pick, the hire back a day early with a broken door. A design covering seven links covers none properly, because nobody can describe every link's exceptions in one sitting. It is why a pilot's first two weeks produce a signed design rather than a build: those exceptions are the work.

A Chain Map is half a day of process mapping on site that ends in a written two page map, one chosen link, a countersigned baseline and a fixed pilot quote. The room is three: you, the person who runs the link, and whoever bills.

Rank the candidates on days from trigger event to invoice and on credits a month; the worst on both is worth six weeks. Then sign the number. A number the supplier produced is marketing. A number the customer produced is a claim. A number both parties took together from the customer's own exports, on a dated sheet with two signatures, is evidence.

Four rules keep it honest. No baseline, no build. No access in writing, no build. Every export kept with its date and file hash. Same exports, same period, same stopwatch at week six. The second decides whether anything can start: an ERP, hire or trade system usually has one honest route in, an API, a database or a scheduled import, and which yours allows is settled in writing before any code.

Nobody can put a fee at risk on a migration, because it runs for many months, touches every link at once and its measure cannot be isolated. The same constraint binds us: a fee can only be risked on one link, one site, one system and one number. So ask any supplier what happens if the number does not move, and listen for whether the answer contains money.

Ask whoever proposes the work, including us: "Which single number are you willing to be judged on, how will it be taken, and who signs the sheet it is written on?"

The arithmetic

  • Six measures, all from your own data: days to invoice, median and 90th percentile; points keyed twice, counted on site; documents handled by hand; credits a month; stopwatch minutes on ten to twenty transactions; desk hours a week, signed by whoever does it.
  • Illustratively: twelve points on one link, ninety seconds each, forty times a week is twelve hours a week of typing. Run it on your own counts.
  • Six weeks for a pilot: two to a signed design, three building in a test copy of your system, one live at one site, then 30 days of fixes.
  • One stop point, at the end of week two, after the design is signed off: stop there, owe the kick-off invoice only, and keep the map.
  • The Chain Map is one fixed fee, confirmed in writing before anything is booked and credited in full against the pilot, with the map, baseline sheet and pilot quote on your desk within ten working days. The pilot is a fixed price, quoted in your Chain Map. The retainer is monthly, quoted only after the pilot has passed its measure.

What to do on Monday morning

  1. Walk one link with a notebook and count. Pick the link that generated your last credit note, not the biggest. Start where the fact is first written down, at the gate, on the bay, in the van, at the hire desk, at the requisition pad, and follow it to the invoice, marking every time somebody types what already exists elsewhere. Then ask whoever does the work how many hours a week that takes, and have them sign it.
  2. Pull three months of exports and measure the gap. Take the date the trigger event happened and the date the invoice or credit was raised, then write down the median and 90th percentile. Do not average them: an average hides the tail. Do it even if you buy nothing this year: that sheet is what turns a supplier's claim into a result.
  3. Send your system vendor one written question. "Which access route does our contract allow, API, database or scheduled import, and is there a fee?" That answer decides what is possible, and is the commonest reason a pilot never starts.

If any of this is close to your week, I am glad to have a quiet conversation about your chain: no pitch, no deck, and you keep whatever we work out. FlyWei Robotics Ltd is a team of AI specialist engineers who automate the buy, hold and sell chain, purchasing to invoicing, inside the ERP, hire or trade system a company already runs, rather than beside it. We work that way because the delivered chain is in wholesale and distribution, for one wholesale group, and because a company told to replace its system first never starts. The Chain Map is at https://flywei.co.uk/services/chain-map/