You Cannot Miss a Charge You Never Wrote Down

On the third of the month, somebody in a third-party warehouse exports movements into a spreadsheet and rebuilds last month's storage and handling billing by hand. They look up storage from a stock report, count inbound and outbound handling from transfer lists, ask the supervisor what value-added work was done, and remember the accessorials they can remember. It takes two or three days. It has taken two or three days for years.

The revenue that never reaches that invoice is not recoverable, and it is not measurable either. A charge that was never recorded at the moment it happened cannot be found later, because nothing distinguishes work that was free from work that was forgotten. This is why leakage in a 3PL is not a pricing failure or a credit-control failure: it is a recording failure, and the remedy is that the billable event is captured when it occurs by the same system that directed the work, so the invoice is computed rather than reconstructed.

Which leaves three things worth setting out: what a third-party warehouse is actually selling, why storage is a measurement question long before it is a pricing one, and what the word computed has to mean before it is worth anything.

The four things you sell, and which one leaks

A third-party warehouse sells four distinct things, and they fail in a very specific order. This is the commercial half of the case we make to a business that stores, moves and clears in the same week; the operational half is what makes it possible.

Storage. Space held over time. It is the most visible charge and the one most likely to be roughly right, because it can be approximated from a stock report at a point in time. Roughly right is doing a lot of work in that sentence — see below.

Handling. Receiving, putting away, picking, packing, loading. Usually charged per unit, per line or per pallet. This is mostly captured, because it corresponds to documents that had to exist anyway.

Value-added work. Kitting, labelling, re-packing, assembling displays, applying customer-specific paperwork. This is where the leak is. It is real labour, it is requested informally, it is performed by people who are proud of being helpful, and it is recorded nowhere. Almost every 3PL we look at is giving some of this away, and none of them can say how much.

Accessorials. Everything else the contract lists and nobody invoices: out-of-hours work, a special count for a customer's auditor, a pallet rebuild after a damaged inbound, waiting time, an urgent order pulled forward past everything else. Individually small. Collectively not.

The pattern is consistent: the further a charge sits from a document that had to be produced anyway, the more likely it is to be lost. Which means the fix has to make the charge a by-product of the work, not an additional act of administration performed by a busy supervisor.

Storage is a measurement problem first

Ask three people in the same business how storage is charged and you may get three answers, all of them sincere.

The variables are: what is measured — pallets, square metres, cubic metres, weight; when it is measured — daily, at a period boundary, on a peak; how a part period is handled — a pallet in for nine days of a month; whether an empty location reserved for a customer is chargeable; and whether the unit is the pallet position or the pallet. Each of those is a legitimate commercial choice. The problem is that the contract usually names one and the spreadsheet implements another, and nobody notices for years because both produce a number that looks plausible.

Two specific traps are worth naming. A month-end snapshot is not the same as a daily average, and the difference is systematically in the customer's favour for a seasonal account that clears its stock before the month closes. And a pallet is not a pallet position — a customer storing half-height pallets in full-height locations is consuming space you cannot sell, and if you charge by pallet you are absorbing that difference silently. Both are decidable. Neither is decidable retrospectively, which is why the measurement has to be designed at the same time as the price.

This is also where the handling unit as a real record stops being a warehouse-operations argument and becomes a commercial one: if the pallet is an object with an owner, dimensions and a location history, then storage on any of those bases is a query. If it is not, storage on any basis is an estimate, however confident the spreadsheet looks.

What "computed" has to mean

The word is used loosely by everybody selling software. Four properties make it real, and a system missing any one of them is still reconstructing.

The billable event is the operational event. The same task record that directed a picker to a bin is the record that produces the handling charge. Not a second entry made afterwards; not a report someone interprets. If a supervisor has to remember to log the value-added work separately from doing it, it will be logged on quiet days and lost on busy ones, which is exactly backwards.

The run is idempotent. Running the billing for August twice must produce the same result, and re-running it after a correction must produce a correct result rather than a doubled one. This sounds obvious and is routinely untrue. Anyone who has watched a month-end job be run "carefully, once, by the only person who understands it" has seen a business quietly organised around a program nobody trusts.

The rate card is data. Customer-specific rates, minimums, tiers, free periods and escalation live in records the commercial team can read and change — not in a formula inside the code that requires a developer and a release. A 3PL signs contracts faster than any software vendor ships, and a pricing model that needs an engineer is a pricing model that will be worked around in a spreadsheet within a quarter.

There is a leakage report. A reconciliation between the work the operation recorded and the charges the invoice carries, which should read zero for a fully billed period. Its value is not the number — it is that somebody looks at it monthly and asks about the difference. Without it, "computed" is a claim, and the whole point is to stop trusting claims. This is the same discipline that makes automation worth having at all, and the measurement of what an automation actually saved is the general case of it.

The dependency nobody wants to hear

Computed billing rests on the operation recording what it did, accurately, as it did it. That is the uncomfortable part, because it means the billing project is downstream of the warehouse-execution project.

If work is hunted off a list and confirmed with a button rather than a scan, then the events underneath the invoice are assertions. Billing computed from assertions is a faster way to produce the same wrong number, and it is worse than the spreadsheet because it wears the authority of a system. The sequencing is therefore not negotiable: directed work, confirmed by scan first, billing on top of it second.

The good news is that the second step is comparatively cheap once the first is done, and it is the step that pays. A business that has invested in warehouse execution and stopped short of billing has bought the cost and left the revenue.

What it is worth, honestly

We will not put a percentage on recovered leakage, because we have not measured one that would survive being quoted. What can be said without inventing anything:

• The value-added and accessorial categories are where the loss concentrates, and they are the two that are never in the spreadsheet.
• The recovery is permanent rather than one-off, because it changes what gets recorded rather than what gets chased.
• The two or three days a month of rebuilding stop, and the person who does it stops being irreplaceable — which is worth something on its own, and is usually the argument that carries the room.
• Invoice disputes get shorter, because a charge traceable to a scanned task at a timestamp is a different conversation from a charge traceable to a spreadsheet cell.

That last point has a collections consequence that is easy to miss. A disputed invoice is not merely a late invoice; it is an invoice whose ageing tells you nothing, and a receivables ledger full of them stops being a management report. The mechanics of that are worked through in how credit limits and collections behave when the invoice itself is arguable.

Where to start

Take one customer — not the largest, the most operationally complicated — and do four things over a month.

1. Write down what the contract says you may charge, in the units it says. Not what you do charge. The gap between those two documents is usually the first surprise.
2. Have the floor record every value-added task and accessorial for four weeks, on paper if necessary. This is a measurement exercise, not a systems change, and it is deliberately crude. You are establishing a baseline you can defend.
3. Compare that to the invoice you sent. This is the leakage number for one account, and it is the business case.
4. Then decide what to automate, in the knowledge of which categories actually matter in your operation rather than in general.

Doing it in this order costs a month and produces a number nobody can argue with. Doing it the other way round — buying the billing engine and discovering afterwards which charges were being lost — costs the same money and forfeits the argument.

The forwarding side of the same business has its own version of this problem, where the margin on a file is known only after the file is closed and reported. That one is arithmetic rather than recording, and it is the subject of why a freight file's margin arrives too late to do anything about. Both come down to the same principle: a number produced after the decision is a number that cost you the decision, which is why getting the process right before automating it is the order that works.