Freight That Cannot Be Shared by Weight
Our landed-cost engine spreads a freight bill across a consignment by value or by quantity. It cannot spread it by weight or by volume. For a landlocked buyer whose largest single cost is a lorry charging by the tonne, those are the two bases that would have been right.
Landed cost is the discipline of getting the true cost of a good onto the good, rather than leaving it in a freight account where it explains nothing. It is the single most valuable thing an inventory system does for an importer, and the whole exercise turns on one question: how do you divide one bill across many different things?
We offer two answers. By value, so an expensive item carries more of the freight. Or by quantity, so each unit carries the same. There is no third.
What the engine does well
Two things, and the second one was a genuine defect until recently, so it is worth stating plainly.
Costs are attached to the order and apportioned across every settled receipt on that order, in proportion to what each batch actually holds. So a consignment that arrived in two deliveries has the bill divided between them by what each one contained, and the allocated total equals the invoice by construction rather than by luck.
That was not always true. The allocation used to fire per delivery and re-resolve the whole order's cost each time, so a bill received in two parts was booked twice. And the per-unit divisor used to be the ordered quantity rather than the received one, so a short delivery under-costed every unit that did arrive and left the balance attached to goods that did not exist. Both were fixed, both are covered by tests, and we published the finding rather than quietly patching it.
The arithmetic is now exact. The question is whether the basis it is exact about is the right one.
Where value and quantity both give the wrong answer
Consider a container carrying two things: a pallet of small, expensive electronic components, and a large consignment of cement, roofing sheet or fertiliser. Now divide the inland freight.
| Basis | Who carries the freight | Is that right? |
|---|---|---|
| By value | The electronics, overwhelmingly | No. They weigh almost nothing and took almost none of the lorry |
| By quantity | Whichever has more units | Coincidence. A unit of cement and a unit of component are not comparable |
| By weight | The heavy goods | Yes, for road freight — this is how the lorry was charged |
| By volume | The bulky goods | Yes, for anything charged on cubic capacity |
The two bases that match how the bill was actually raised are the two that are not available. So the allocation is exact about the total and wrong about the distribution, and the error is systematic rather than random: light, valuable goods are permanently over-costed and heavy, cheap goods are permanently under-costed.
Why a landlocked buyer feels it most
Because of the ratio. For a coastal importer the inland leg is a modest fraction of the landed cost, so a mis-apportioned share of a small number is a small error. For a Rwandan importer, the leg from the port is a large fraction of everything, and a wrong basis applied to a large number produces a large error in the unit cost of both product families at once.
It compounds with something else. That inland cost has nowhere precise to go. The cost types are a fixed global list of five — freight, customs duty, insurance, handling and local transport — and nothing can add a sixth. So port storage, demurrage, wharfage, inspection and biosecurity charges all land in handling, and there is no report totalling landed cost by type across shipments or suppliers.
The result is a cost you cannot apportion correctly and cannot analyse afterwards.
What to do about it
-
Do not mix weight classes on one order
This is the whole workaround and it is more practical than it sounds. If the heavy goods and the light goods are on separate purchase orders, each order's freight is apportioned across items that are broadly comparable, and value or quantity becomes an acceptable proxy. Split the order, not the invoice.
-
Where you must mix, split the freight bill yourself
Attach two freight costs to the order — your own arithmetic — rather than one, and record the split in the note on each. The engine will spread each one exactly. You are supplying the basis it does not have.
-
Choose quantity, not value, for homogeneous consignments
Where everything in the container is the same kind of thing, quantity is closer to weight than value is. Value-based apportionment is the right default only when your catalogue is uniform in density, which for an importer of trade goods it usually is not.
-
Track the charges the five types cannot name
Demurrage in particular. It goes into handling with everything else, and it is the one cost that tells you something about your clearing agent rather than about your goods. Keep it in the note, consistently worded, so you can find it later.
Our position
The engine is exact and the basis is limited, and those are different criticisms. Split orders by weight class so the available bases are adequate, split the freight bill by hand when you cannot, and prefer quantity over value on a uniform consignment. If your consignments genuinely cannot be split — one container, mixed density, every time — then a weight basis is a real requirement and worth raising as one.
What AWRA OpsHub does today
- Landed costs attached to a purchase order and apportioned across every settled receipt in proportion to what each batch holds, so the allocated total equals the bill.
- Apportionment by value or by quantity.
- Per-batch landed-cost allocation visible through the traceability view, and rolled into the batch's total unit cost.
- Five cost types — freight, customs duty, insurance, handling and local transport — as a shared controlled vocabulary, with a free-text note per attached cost.
- Weighted-average item cost that reflects the allocated landed cost, shared by the till, the ledger and margin analytics.
What it does not do
- Apportionment by weight or by volume. There is no weight or volume on an item, and no basis that could use one.
- Any additional cost type. The list of five has no create route anywhere and no organisation can add a sixth.
- A report totalling landed cost by type across shipments or suppliers, so "which supplier is expensive to clear" is not answerable.
- Re-costing of stock already sold when a cost arrives late.
- Any import of a clearing agent's charges — every cost is entered by hand.
Not ours, by choice
- The frozen cost list is deliberate rather than an oversight: a shared vocabulary is what makes figures comparable between organisations. It is still frozen at the trade profile it launched with.
- The split-order workaround is genuinely effective and it is what we would advise before any build.
- Nothing here is Rwandan. It is the arithmetic of apportioning a weight-based charge on a value basis; being landlocked simply makes that charge the biggest number on the page.
What is not built for Rwanda 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 Rwanda. 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 EBM fiscalization, 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.
EBM fiscalization
Invoice submission against RRA's approved interface, with the parts vendors gloss over — retries, a failure queue, and a daily report of sales carrying no fiscal reference.
Mobile money and bank feeds
MoMo settlement files and bank statement feeds pulled into the Payments Register, so collections match invoices without anyone re-keying a statement at month end.
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
PAYE and RSSB contribution schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet 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 integratedFour questions about any landed-cost engine
Which apportionment bases do you support?
A good answer sounds like
Value, quantity, weight, volume — named.
What it actually means
Ours is the first two. This is a schema question, not a settings one: a weight basis needs a weight on the item.
A bill arrives for an order delivered in three parts. Show me the allocation.
A good answer sounds like
The bill divided across the three by what each held, totalling the invoice.
What it actually means
This is the exact scenario that was broken here until it was found by writing a test. Ask every vendor to run it live.
What happens when the freight invoice arrives after the goods are sold?
A good answer sounds like
A restatement, or an honest "it becomes a new cost".
What it actually means
Ours is the latter. Neither answer is wrong; not knowing which one you are getting is.
Can I add a cost type?
A good answer sounds like
Yes, or a reasoned no.
What it actually means
Ours is a reasoned no — a shared vocabulary keeps figures comparable. Ask what happens to demurrage, which is the charge every importer eventually wants to see separately.
Split the orders, not the invoice
Most of the error on this page disappears when heavy and light goods stop sharing a [purchase order](/glossary/purchase-order). Bring us a recent mixed consignment and we will show you what the two bases do to it.
Work through a consignmentFrequently asked questions
Can I record an item's weight anywhere?
Not in a way the costing engine reads. Custom fields would let you store it and nothing would apportion on it, so the practical route to a weight-based split is to do the division yourself and attach two costs instead of one.
Which basis should I use by default?
Quantity, if your consignments are broadly uniform in what they contain. Value, only where the goods differ enormously in worth and not much in size — which is the reverse of most importers' reality. The default matters because it applies silently to every allocation you never think about.
Does the allocation change if I receive the rest of the order later?
Yes, and correctly. The allocation is recomputed across every settled receipt each time one is added, in proportion to what each batch holds, so the total stays equal to the bill as more of the order arrives. That behaviour is what two tests exist to protect.
