Importer: A Landed-Cost Calculation That Separates Currency, Freight, Duty and Allocation

Landed cost is not supplier price times exchange rate. It is a sum of components that each arrive in a different currency, on a different document, on a different date, and several of which belong to the shipment rather than to any product. The only practical question is how the shared components are split between products, and what changes when the basis changes.

What a landed cost is made of, component by component

This article is about a calculation and an allocation method. It does not cover tax rates, goods classification or accounting treatment, and every figure in it is a worked example.

Components split into two kinds, and that distinction is the whole design:

• Line-direct components. The supplier price for the item, from the supplier invoice, in the supplier currency.
• Shipment-shared components. International freight, insurance, broker fees, inland transport from port to warehouse, storage, and any statutory charge received as an assessment. Each arrives as one amount for the whole shipment and therefore needs an allocation basis.
• Components that surface late. A service-provider invoice arriving two weeks after the goods were released. If the shipment is already closed, this component needs a destination decided in advance: recost the shipment, or take it as a period expense.

Every component is stored with seven fields: component_type, amount, currency, fx_rate, fx_rate_date, source_doc, allocation_basis. The field most often skipped is fx_rate_date, and it is precisely the one needed when somebody asks why the same product came out at two different costs on two shipments.

The worked shipment: three products, one container

Shipment SHP-2026-0417, three SKUs, supplier invoice in euro:

Shipment-shared costs, all in shekels: international freight 2,400, insurance 300, inland transport and handling 900. Total to allocate: 3,600.

The rate stored on the shipment header in this example is 4.0500 per euro. From it the goods value in shekels follows: A-100 at 19,440, B-220 at 24,300 and C-330 at 4,860, for 48,600 in total. Where that rate comes from and how it is captured is covered in Bank of Israel rates for automated pricing, and this article does not repeat it.

Where do the same 3,600 shekels land by weight against by value?

Value allocation divides the 3,600 in proportion to line value. Weight allocation divides it in proportion to line weight. Both add back to exactly 3,600, and the per-unit result is not the same:

Unit cost then follows, computed as goods value in shekels plus the allocation, divided by units:

C-330 is the cheap, light item, but it occupies a quarter of the weight and only a tenth of the value. The weight basis therefore loads it with more than double what the value basis does, and the swing falls on exactly the product whose unit cost is small and where every agora is visible in the margin percentage.

Why does the allocation basis change which product looks profitable?

Because it moves cost between products without changing the total, so it moves margin too. If C-330 sells at 6.90 per unit, its gross margin is 1.68 on the value basis and 1.14 on the weight basis - 24.3% against 16.5%. Same goods, same selling price, same shipment.

Three practical rules follow:

1. The basis should reflect what actually drives the cost. Ocean freight billed by volume or weight is allocated by weight or volume, not by value.
2. Several bases can coexist in one shipment. Insurance charged as a percentage of value is allocated by value even while freight is allocated by weight.
3. The basis is recorded per component, not as a global system setting. The record is what lets the calculation be reconstructed, rather than the memory of whoever ran it.

Once unit cost is fixed it becomes the floor under every customer pricing decision. The next link in that chain is covered in customer price lists and price-override approval for a wholesaler.

Freezing the exchange rate: what the document must store

The rate is read once, at a defined moment, and stored. Three fields, not one: fx_rate, fx_rate_date, fx_source.

A short exercise on the same shipment: had the stored rate been 4.1500 instead of 4.0500, the goods value of A-100 would be 19,920, while its value-based allocation stays 1,440 because that amount is already in shekels. Unit cost rises from 52.20 to 53.40, a 2.3% move. Ten agorot on the rate moved product cost by more than two percent, which is exactly why the rate must never be a live lookup performed each time the report is opened.

• The capture moment is decided in advance: supplier invoice date, release date, or goods-receipt date. One of them, written down.
• A day with no published rate is handled by an explicit rule: the last publication preceding the date, with the date actually used recorded on the document.
• Differences between the invoiced rate and the rate at which payment actually settled are not part of product cost in this model. They enter a separate reconciliation queue, alongside invoices that arrived late, as described in supplier invoice approval through to a Masav file.

What actually breaks

• A shekel amount and nothing else. 19,440 stored without the rate or the date, and there is no way to reconstruct how it was reached.
• Allocating by unit count instead of value or weight. A SKU arriving as thousands of small units absorbs most of the freight even when it occupies one percent of the volume.
• Switching basis without flagging it. The quarter-on-quarter comparison then measures the change in method rather than the change in the business.
• Rounding at every step. Rounding each line allocation to the shekel produces a set that no longer adds to 3,600, and the difference quietly settles on the last line.
• A late invoice absorbed across all stock. One shipment's expense is smeared over other shipments, and every earlier unit cost changes retroactively.
• Returns that are not allocated. A returned unit re-enters stock at a standard cost rather than at the landed cost calculated for it.

What to have ready before building it

• A closed list of components, and a decision per component on whether it is line-direct or shipment-shared.
• A default allocation basis per component type, with a shipment-level override and a record of who overrode it.
• A decision on the rate-capture moment, and on what happens on a non-publication day.
• One rule for a late invoice: recost the shipment or take a period expense, decided in advance rather than case by case.
• A formula-version field on every shipment, so old reports stay readable after the method changes.

Sources

• WTO - Customs valuation
• World Customs Organization - Valuation
• ICC - Incoterms 2020 rules