The Bill and the Sum of Its Parts
A freight bill is a fixed amount of money. However many containers the order arrives in, the goods have to carry that amount between them and no more. Ours carried it once per delivery — so an order that came in two parts booked twice the freight that was paid. We found it by writing the test that did not exist, and this post is what it taught us.
Here is a claim so obvious it sounds like it needs no checking. You paid one freight bill. You spread it across the goods it brought. Add up what every unit is now carrying and you get back the bill. Not approximately — exactly, because it is the same money looked at from the other end.
We checked ours in August 2026, because we were writing about landed costing and wanted to describe it accurately. An order for a hundred units, one freight charge, delivered in two parts: sixty, then forty. The goods came out carrying double the freight that had been paid.
Not a rounding difference. Exactly twice, because each delivery had been given the whole bill.
Why we are telling this to the islands first
Because of where an error like this can hide, which is not where you would guess.
A distributor buying from a supplier an hour up the road pays freight that rounds to nothing against the value of the goods. Double it and the unit cost barely moves. The error is real, and it is invisible because it is small.
An importer in Port Louis, Victoria, Antananarivo or Moroni is in the opposite position. Sea freight, insurance, port handling and inland delivery are not a rounding item against the value of a container of goods — they are a large and well-understood share of what those goods end up costing, which is exactly why landed costing matters more here than in most places, and why anyone running an import business in these markets can quote the share from memory.
Double a rounding error and it stays a rounding error. Double a number that genuinely drives your unit cost and it does not look like a bug. It looks like a bad quarter.
That is the whole argument for putting this post here. The error is least visible precisely where it is largest, because where freight matters most, a unit cost that has come out high is the most ordinary thing in the world. You do not go looking for a defect. You go looking for a cheaper shipping line.
And the trigger is routine here, not exceptional
The defect needed one condition: an order arriving in more than one delivery. On a short road route that is an exception worth a phone call. Where stock arrives by sea against a sailing schedule, an order split across two sailings — or arriving with a container short, the balance following a fortnight later — is not an exception at all. It is Tuesday. We have argued elsewhere that ordering to a sailing schedule breaks the assumption that a lead time is a single number; this is the same calendar breaking a different assumption, one module downstream.
So the population most exposed to the arithmetic is also the population where the triggering event is normal, and where the resulting number is least likely to be questioned. Three properties that individually mean nothing and together mean a defect can sit undisturbed for as long as you like.
What was actually wrong, in English
Costs are attached to the order and allocated when goods arrive, which is how landed costing works in any system that does it properly. That allocation ran every time something was received, which is correct. But when it ran, it looked only at the delivery that had just landed and gave that delivery the entire order's costs. Run it once, and one delivery holds the whole bill. Run it again when the balance arrives, and the second delivery holds the whole bill too. Nothing subtracted what had already been allocated, because nothing was looking further back than the most recent arrival.
The figures on screen were individually plausible throughout. A consignment carrying a freight allocation is what you expect to see. Nothing anywhere reconciled the total of those allocations back to the bill that had been paid, and until we wrote a test that did exactly that, nothing ever had.
| One order, 100 units, one freight bill of 1,000 | Before | After |
|---|---|---|
| Freight carried by the first delivery of 60 | 1,000 | 600 |
| Freight carried by the second delivery of 40 | 1,000 | 400 |
| Total carried by the goods | 2,000 | 1,000 |
| The bill that was actually paid | 1,000 | 1,000 |
| Landed unit cost | inflated by the number of deliveries | the same whether it came in one part or four |
The fix is the obvious one once the invariant is written down: allocate across every settled receipt on the order each time, in proportion to what each one actually holds, so the total is the bill by construction rather than by luck. The order now costs the same whether it arrives in one delivery or four, which is the property that should have been true from the beginning.
The lesson we would rather you took than the bug
We had met this exact blind spot before. An earlier audit found that our over-receipt guard — the control stopping a supplier delivering more than you ordered — could be walked past by splitting the delivery, because it compared each receipt against the order rather than against everything received so far. We fixed it there and wrote up the lesson.
And then the identical assumption was sitting one service over in the costing code, untouched, because the fix had been applied to the place the bug was found rather than to the class of bug. That is a more useful thing to know about software than any individual defect.
So the question worth carrying into any evaluation is not "does your system handle partial deliveries", which every vendor answers yes to and every vendor believes. It is narrower and much harder to answer falsely: which of your controls compare a receipt against the order, and which compare it against everything received so far? Anywhere the answer is the first, splitting a delivery changes the outcome.
Costs attached to an order and allocated to the goods at arrival
Freight, duty, insurance, handling and inland transport become part of unit cost rather than a separate expense line.
Allocation that totals the bill across any number of deliveries
Recomputed across every settled receipt on the order as each one lands, in proportion to what it holds. Fixed August 2026 and locked down by a test that reconciles the total back to the bill.
The allocation kept on the consignment
So what a specific arrival cost to land is recoverable afterwards rather than being folded away into an average.
Allocation by weight or volume
Not built. Costs are apportioned by value or by quantity only, so freight on heavy-but-cheap goods cannot be spread by mass.
Re-costing stock that has already been sold
Not built. A late-arriving freight invoice moves the cost of what you still hold; it does not reach back into sales already posted.
Two, both of which this audit made obvious
The defect is fixed. These are the two things that would have caught it sooner, or made it matter less.
A reconciliation view: costs charged against costs allocated
One screen per order showing what was billed, what has been allocated to goods so far, and the difference. On a fully received order the difference is zero and the screen is boring, which is the point — a number that should always be zero is the cheapest possible control, and it is the thing whose absence let this run.
Allocation by weight or volume
Sea freight is commonly charged by whichever of weight or measurement is greater, and neither is available to us as a basis today. Spreading a container's freight by the value of its contents subsidises the bulky, heavy, low-value goods at the expense of the small dense ones — which for an importer is not a rounding decision.
The first of those two is the one we would do first, and it is small. A defect that survives because nothing ever adds two numbers together is not really a costing problem; it is a missing screen.
Talk to us about import costingFour questions that find this class of defect in any system
Receive one order in two deliveries. Do the allocations add back up to the freight bill?
What a straight answer sounds like
Two numbers and their total, on screen, next to the bill.
Why it matters
This is the whole test. It takes ten minutes and nobody runs it, which is why we did not either.
Which of your receiving controls compare against the order, and which against everything received so far?
What a straight answer sounds like
A specific answer per control. Anything vaguer is a no.
Why it matters
Every control of the first kind can be walked past by splitting a delivery. This is the general form of the bug.
What happens to unit cost if the same order arrives in four parts instead of one?
What a straight answer sounds like
Nothing. It should be identical.
Why it matters
If the number moves, the allocation depends on delivery shape, and delivery shape is your supplier's decision rather than yours.
Show me a test that reconciles allocated cost back to the invoiced cost.
What a straight answer sounds like
A test, named. Or an admission that there is not one.
Why it matters
An untested invariant is an opinion. Ours was an opinion for as long as it took somebody to check.
What AWRA OpsHub does today
- The total allocated equals the bill, across any number of partial deliveries, now enforced by a test rather than by assumption.
- Allocation in proportion to what each delivery actually holds, so the order costs the same however it is split up.
- Costs attached at the order and applied at receipt, which is the point at which the goods and the charge are both known.
- The allocation retained per consignment, so the landed cost of one arrival can be reconstructed later.
What it does not do
- No allocation by weight or volume. Value and quantity are the two available bases, which is a poor fit for freight billed by measurement.
- No re-costing of stock already sold, so an invoice arriving after the goods have moved corrects the future and not the past.
- No cost types beyond the five that ship, so charges that do not fit those names are filed under whichever is closest.
- No record of who was contractually liable for a cost, so nothing objects if a charge that was the seller's is attached to your order.
Not ours, by choice
- We are not going to tell you what share of your landed cost freight ought to be. You know your lane better than we do, and a vendor quoting an industry figure at an importer is telling you something about themselves.
- We found this in a test we wrote for this post, not in anybody's data. We are not claiming to have detected it in the field, and we are not claiming to know who it affected.
The verdict
We would rather publish this than not, and not out of penance. The defect is fixed and the fix is tested, so the news value is small. What is worth carrying away is the shape of it: an invariant that everybody assumes, that nothing checks, in a number that is large enough to matter and ordinary enough never to be questioned. If you import into a small market where freight is a serious share of what your goods cost, you have systems making exactly this kind of assumption right now. The test is ten minutes long. Receive one order in two parts and add up what the goods are carrying.
Bring us a real consignment
One order, its freight and clearing charges, and the way it actually arrived — in parts, short, or a fortnight late. We will show you exactly what it costs to land in our system and where our allocation is still too blunt for your lane.
Talk to us about landed cost