Landed cost software: per container first, then per SKU

The phrase landed cost software covers two products that do not do the same job, and almost every page that ranks for it is about the second one.

The first collects the charges. The second allocates them. The second is what inventory and accounting vendors sell, and it is good. It also cannot start until the first has finished, and on most import desks the first is a person with a shared mailbox and a spreadsheet.

What does the ERP kind of landed cost software do?

It answers the accountant’s question: what is each unit on this container now worth?

Read the product pages and the method is the same everywhere. Blue Link describes allocating landed costs “proportionately” on “different percentages based on weight, container etc.” Finale lists the choices: subtotal, quantity, weight, volume, or equally. Aquilon says by weight, volume, value or quantity. The charges on a purchase order are spread across the SKUs on it, the average cost of each product updates, and the stock valuation and the cost of goods sold come out right.

That is allocation, and the ERP is the right place for it. The ledger needs a per-unit figure, and the rule for spreading a freight invoice across two hundred line items is a policy decision the finance team should own.

Two of these vendors add something an import desk should notice. Aquilon describes estimating the extra costs “right at the purchase order management stage” and fine-tuning them once the items land. VISCO talks about projected landed cost against actual, per shipment. Estimate first, true up later. Both are right that this is how the number should work. Neither says where the actuals come from.

Where do the actuals come from?

From six parties, by email, over about six weeks, none of whom agrees on how to name your shipment.

The goods invoice comes from the supplier at contract time. Freight comes from the forwarder, sometimes as a quote and again as the real thing. Insurance comes from the broker. Duty comes off the CHA’s working sheet after clearance. The delivery order fee arrives on a separate note from the line. Transport bills at month end. Bank charges land across four dates. And if the document pack ran late, the demurrage invoice arrives last of all.

One says the BL number. One says the invoice number. One says “your consignment”. A person on the desk reads each mail, decides which container it belongs to, checks it against the quote if there was one, and types it into a sheet. Payment tracking alone runs 10 to 15 minutes a container. Status tracking and reporting adds 20 to 30. The whole container takes about 2.2 hours of desk work, and on a 500-container desk that is roughly 1,100 hours a month before anyone buys or sells anything.

The ERP allocation module waits at the end of that. It is only as complete as the sheet that feeds it, and it has no way of knowing that the DO fee has not arrived yet or that the CHA’s reimbursement line was already invoiced by the forwarder.

That is the first kind of landed cost software, and it is the kind most import desks do not have.

Why per container has to come first

Because that is the unit the charges arrive in.

Nobody invoices per SKU. The forwarder invoices the shipment. The line raises the delivery order for the container. The CHA bills the Bill of Entry. Demurrage accrues per box per day. The container total is not an intermediate step on the way to the SKU figure. It is the only thing that can be checked against a document.

One ERP vendor’s customer story makes the point backwards. Their old system, the customer says, calculated landed costs “for an entire shipment” and they then had to apply the cost to each item by hand; the ERP fixed the second half. True, and useful. But the shipment total was still assembled by someone, from invoices, before any of that could happen.

So the sequence on a well-run desk is fixed. Collect and match per container, with evidence. Then allocate per SKU, on a rule. A desk that skips to the allocation is spreading a number it cannot defend.

What “collect and match, with evidence” means

It means the cost line and the email it came from are the same object.

An import-desk landed cost software reads the mailbox the desk already uses. When a charge lands, it matches it to the container from what it already holds: the purchase contract, the bill of lading number, the container numbers, the party masters and the way each forwarder writes your name. The charge posts against that shipment, the message stays attached to the line, and the estimate that was sitting there is replaced by the invoiced figure with the variance visible.

Six months later, when a supplier says the freight was quoted lower or an auditor asks why one container carried an extra fee, nobody searches a shared mailbox. The line opens and the mail is under it.

Where the match is not clean, the right behaviour is to say so and ask. A charge posted to the wrong container quietly corrupts two shipments. A charge in a queue for a day costs somebody thirty seconds.

The line the ERP cannot estimate

Every landed-cost component has a party, a moment it becomes known, and a treatment for customs and for accounts. The glossary entry on what goes into landed cost lays out all nine. Eight of them can be estimated at booking with reasonable accuracy.

Demurrage and detention cannot. They are unknowable at booking, arrive weeks later, and are large: a week of demurrage on one container has cost US$12,000. One missed document pack a month works out at US$12,000 to US$24,000 a year.

They are also the one line caused by paperwork. Free time starts at discharge; the document pack starts when the last party in the chain acts, and packs routinely run about eight days late. Which makes demurrage the only landed-cost line an import desk can prevent rather than record. An ERP module records it accurately, after the fact. An import-desk system that chases the pack inside free time stops it appearing.

Per container, then per SKU: the hand-off

None of this argues against the ERP. It argues for the order.

Docket does the first half: the collecting, matching and evidencing per container, with each line estimated from the purchase contract and the incoterm on day one and replaced by the actual as the invoice lands. It hands the ERP a complete, traced container total as accounting-ready expense records with the evidence attached, into SAP, QuickBooks or Xero on the Enterprise plan. The ERP does the second half: allocation per SKU on the rule the finance team chose, stock valuation, margin per product.

Docket does not allocate per SKU, does not value stock, does not pick a duty rate, and does not convert currencies at a rate it invented. Charges stay in the currency they were invoiced in; a single-currency view uses the rate you book at. The accountant still runs the ledger.

What leaves the desk is a container that can be opened, line by line, and defended.

Where to start

Open last quarter’s worst container in whatever you use today. Count how many of its cost lines you can trace to the document that produced them without leaving the screen. If the answer is fewer than all of them, the allocation module downstream is spreading a reconstruction.

Send us that container. We will show you what it looks like traced.