What “best landed cost tracking software” actually means
Most teams say they want "landed cost software". What they actually need is software that makes one number trustworthy:
The warehouse-ready cost per shipment, and the unit cost per SKU after allocation.
If you only track product cost + freight + duty, you will still miss margin.
If you want the step-by-step method first, start here: /resources/how-to-calculate-landed-cost
The real requirement: landed cost is a shipment ledger
The mistake most tools make is treating landed cost as a static calculation.
In reality, landed cost is a ledger that accrues charges at milestones:
- booking (freight, surcharges)
- origin release (origin charges)
- arrival/discharge (destination handling)
- clearance (broker fees, duties/taxes)
- delivery (inland transport)
The best tools do not just compute. They help you close the shipment so estimates become actuals.
A buyer’s scorecard (what to check in demos)
Use this scorecard to compare tools quickly.
1) Buckets: does it match how charges appear in real invoices?
Required buckets (names can vary, but the mapping must be deterministic):
- product cost
- freight + surcharges
- origin charges
- destination charges
- duties/taxes
- broker/clearance fees
- inland delivery
- exceptions (demurrage/detention, penalties)
Red flag: the tool forces you into one “shipping cost” field.
2) Allocation: can you allocate consistently to SKUs?
If a tool can’t allocate shared costs, you can’t price SKUs correctly on mixed shipments.
Required:
- allocation by weight
- allocation by volume
- allocation by value
- ability to lock an allocation policy per lane (and audit changes)
3) Incoterms: does it model responsibility boundaries?
Incoterms are not optional decoration. They define which costs belong in your landed cost model.
Your tool should support:
- storing Incoterms + named place per shipment
- clarifying who pays which charges (at least at a workflow level)
- preventing “CIF-like quote, FOB-like execution” mismatches
Reference: Incoterms 2020 rules overview (source in frontmatter).
4) FX controls: can you keep numbers consistent?
Multi-currency is where spreadsheets die.
At minimum, the software should support:
- storing currency per cost line
- a clear FX rate/date model (invoice date vs payment date vs posting date)
- an auditable conversion to base currency
Red flag: “FX is whatever the user typed that day” without traceability.
5) Closeout: can you lock actuals and audit changes?
If the number can change forever, nobody will trust it.
Required:
- shipment closeout that locks costs
- variance view: estimate vs actual by bucket
- audit trail of edits
6) Data model: can you tie costs to the real trade chain?
Landed cost is not a standalone report. It sits in the chain:
deal -> line items -> shipment/container -> documents -> customs -> costs -> invoice/payment -> margin
If the tool cannot answer "which shipment did this charge belong to?", it will not scale.
The minimum workflow your tool should support
In a demo, make the vendor walk through this workflow:
- Create a shipment with line items and Incoterms.
- Enter freight and origin charges at booking.
- Add customs duty/tax and clearance fees at clearance.
- Add destination + inland delivery charges at delivery.
- Allocate to SKUs and show unit costs.
- Close the shipment and show estimate vs actual variance.
If any step requires exporting to a spreadsheet “for the real calculation”, it is not landed cost tracking.
Red flags in landed cost tracking software
- no allocation methods
- no closeout/locking
- no audit trail
- no Incoterms context
- destination charges are an afterthought
How Tijara fits
Tijara is designed for repeat importers and trading desks:
- shipment-level landed cost ledger
- consistent buckets and allocation
- document controls that prevent rework
- closeout discipline so margins stay real
If your current process is “we figure out landed cost at month end”, the correct next step is software that makes landed cost a daily operational control.