The Import-Duty Problem Is More Complicated Than a Tariff Lookup
One thing that surprised me about global trade software is how often “calculate the import duty” sounds like a much simpler product requirement than it actually is.
At first glance, it seems like a straightforward formula:
Product → HS code → tariff rate → duty.
But that model breaks down pretty quickly in real-world shipments.
The tariff rate is only one input.
The four variables that actually matter
An import-duty calculation generally starts with four things:
Product classification
Country of origin
Customs value
Quantity
Each can change the outcome.
Classification determines which tariff provision applies. Origin determines whether the shipment receives MFN, preferential or other treatment. Customs valuation determines the monetary base, while quantity becomes critical when duties are charged per unit, weight or volume.
So if you're building software around international trade, you're not really building a “tariff lookup.”
You're building a decision system.
Why the tariff table isn't enough
Imagine two companies importing essentially the same product.
They could have the same HS classification and the same shipment value, but receive different duty outcomes because their products have different origins.
Or the tariff rate could remain unchanged while an antidumping measure changes the final amount payable.
Or the invoice value could be correct commercially but still not represent the complete customs value.
This is why how tariff schedules actually affect import-duty calculations is a more complicated question than simply finding a percentage in a tariff database.
Where software gets interesting
This creates an interesting product challenge.
A useful trade-compliance system needs to connect several pieces of information rather than treating them as isolated records:
Product classification
→ tariff treatment
→ origin eligibility
→ customs valuation
→ additional measures
→ final duty and landed cost
And those inputs aren't static.
Tariff schedules change. Trade remedies change. Preferential programmes have eligibility requirements. Classification rules evolve. Even the same product can produce a different result at a different point in time.
That means maintaining current data can be just as important as building the calculation itself.
The product lesson
For anyone building SaaS around regulated or highly rules-based industries, there's a useful product lesson here:
The visible calculation is often the easy part. The difficult part is maintaining the decision inputs behind it.
A calculator can multiply 4.2% by $27,000 in milliseconds.
The harder question is whether 4.2% and $27,000 are actually the right inputs.
That's where domain expertise, reliable data, auditability and workflow design become important.
For anyone interested in the underlying tariff mechanics, this detailed tariff schedule guide goes deeper into MFN and preferential rates, customs valuation, additional duties and worked examples.
I'd be interested in hearing from other founders building software in regulated industries: where did you discover that the “simple calculation” was actually the smallest part of the problem?
