Skip to content
BLOG

How to Calculate Landed Cost Inside Your ERP

By · October 7, 2026

ERPimport

If you import inventory, the price on the supplier invoice is not what the stock cost you. By the time a carton reaches your warehouse it has also absorbed freight, duty, tariff and a set of charges that appear on documents arriving at different times from different parties.

That gap is landed cost. Getting it wrong does not look like an error. It looks like a margin that seems fine until someone asks why a profitable product is not generating cash.

What landed cost actually includes

Landed cost is the product cost plus everything required to get that product into your warehouse and available to sell. In practice that means several components, each arriving from a different source:

The supplier cost, from the purchase order. Freight, which splits further into sea or air for the main leg, inland freight to move the container from the port, and the miscellaneous charges that attach to a shipment. Duty, calculated from the item’s tariff classification. Tariff, which is a separate percentage from duty and changes on its own schedule. Harbor and port surcharges.

Each of those has its own document and its own arrival time. The supplier invoice comes with the goods. The freight invoice often comes later. Duty and tariff depend on classification, and the percentages are set by rules outside your business that can change between one shipment and the next, so treat your stored rates as current values to check rather than constants.

Why spreadsheets stop working

Almost every importer starts in a spreadsheet, and for a while it works. The failure is not that the arithmetic is hard. It is that the spreadsheet is disconnected from the system that holds the inventory.

Three things go wrong. The allocation is done once, per shipment, by one person, and nobody else can reproduce it. The result is a number that never travels back into the inventory record, so the ERP still values stock at supplier cost while the real figure lives in a file on someone’s desktop. And when a freight invoice arrives a fortnight late, the spreadsheet is usually not revisited, because the shipment has already been filed as done.

The compounding problem is reporting. If landed cost is not in the system, every margin report, every repricing decision and every answer to “is this product making money” is built on the supplier cost alone.

Calculate it at receiving

The right moment is the purchase order receipt. That is when you know what physically arrived, in what quantity, and against which purchase order, and it is the point at which a unit cost gets written to inventory.

On the system we built for a US consumer electronics brand, the ERP calculates landed cost at receiving from tariff classification, duty, tariff, harbor surcharge and freight per item. The output is a computed cost per unit, not a shipment-level total that someone has to divide up later.

Receiving is also where partial deliveries have to be handled. A container that arrives in two parts needs the allocation to follow the quantity actually received, which is the kind of thing a spreadsheet handles by being rewritten and a system handles by being designed for it.

What has to be on the item and the purchase order

For the calculation to run without anyone typing numbers, two records have to carry the inputs.

On the item: the HTS or tariff classification, the duty percentage, the tariff percentage and the harbor surcharge. These feed the calculation directly. Classification is the field worth being careful about, because it decides the duty rate and it is the one most often inherited from whoever set the product up.

On the purchase order: sea, air, inland and miscellaneous freight charges, which roll into the received unit cost rather than remaining outside inventory valuation. An ocean purchase order also needs the shipment details that let anyone answer where the stock is: ETD, bill of lading, ready date, ETA, vessel name, freight terms, and partial receipts kept attached to the order.

Those shipment fields are not part of the cost calculation, but they belong on the same record. The question “what did this cost” and the question “where is it” are asked by the same people about the same container.

Item and carton dimensions earn their keep twice

Dimensions are usually captured for outbound shipping, where they drive packaging decisions and carrier rating. They are worth having on the inbound side too, because they connect the cost of getting stock in with the cost of shipping it out.

That link matters for pricing. A product can look fine on landed cost and still be unprofitable once dimensional weight is applied to the outbound parcel. Holding both sides against the same item record is what makes that visible before it is a problem rather than after.

What changes once it is in the system

The outcome on that engagement was that landed cost is calculated automatically on imported inventory instead of in spreadsheets. The practical effect is less about the number and more about who can see it.

Margin becomes answerable per item, from the real cost. Repricing decisions start from the cost of the stock you actually hold. And when a duty or tariff rate changes, the change goes into the item record once rather than into whichever spreadsheets someone remembers to update.

It also removes a dependency on one person. Landed cost in a spreadsheet is usually understood by exactly one member of staff, and that is a risk nobody logs until they leave.

Where to start

If landed cost is currently a spreadsheet, the useful first step is not building the calculation. It is checking whether your item records carry a tariff classification and a duty rate at all, because that answers whether this is a short project or one that starts with a data exercise.

From there, calculating at receiving against the fields above gets you a real unit cost on the inventory record, and everything downstream of that improves without further work.

We build this as import and landed cost in the ERP, inside the system that already holds your purchase orders and inventory rather than beside it, as part of custom ERP development. The full multi-channel system it sits in is described in our multi-marketplace ERP case study. If you want to know whether your item data is ready for it, get in touch and tell us what your purchase orders currently record about a container: does anything on them tell you the duty rate for what is inside?

Common questions

Why calculate landed cost at receiving rather than later?

Because that is the moment the inventory exists and the costs are known. Calculate it afterwards and every report between receipt and adjustment is based on a unit cost you already know is wrong.

What if freight invoices arrive after the goods?

That is the normal case, which is why the purchase order has to hold estimates that can be replaced by actuals. The important part is that the correction updates the received unit cost rather than being booked as a separate expense.

Does this change our accounting treatment?

It changes which costs sit inside inventory valuation rather than outside it, so it is worth agreeing the approach with whoever signs off your accounts before you build it.