Borderline Genius Inc.

If you're building anything around international commerce, procurement, logistics, or cross-border selling, there's a deceptively simple question that eventually becomes complicated:

"How much import duty will this product incur?"

At first, it sounds like a lookup problem.

Find the HS code.
Find the tariff rate.
Multiply the rate by the product value.

Done.

That works for a basic example. It starts breaking down when you try to do it reliably across hundreds or thousands of products.

The problem isn't really the multiplication.

It's the data behind the multiplication.

An HS code is only one input

Suppose a company imports $100,000 worth of a product.

The product has an HS classification and the tariff schedule shows an 8% duty rate.

The basic calculation is straightforward:

$100,000 × 8% = $8,000

But before treating $8,000 as the expected duty, you need to establish whether that 8% is actually the applicable rate.

You may need to know:

• Where the goods are being imported

• Country of origin

• Country of export

• Correct national tariff classification

• Customs value

• Preferential tariff eligibility

• Additional duties

• Trade-remedy measures

• ADD/CVD exposure

• Applicable quotas or restrictions

Suddenly, "calculate import duty" isn't one calculation.

It's a rules-and-data problem.

The country matters

One of the first mistakes in cross-border commerce is treating an HS code as globally equivalent beyond its harmonized level.

The first six digits provide the international HS foundation, but countries can extend the classification into their own tariff schedules.

So a supplier's tariff code isn't automatically the code you should use for the destination market.

For a U.S. import, for example, you need to work with the relevant HTS classification.

That creates a simple product-data relationship:

Product → Classification → Destination country

But we're not finished.

Origin changes the equation

The country from which the goods are shipped isn't necessarily their customs country of origin.

That distinction can affect the tariff treatment.

A product may qualify for a preferential rate because of its origin, while another product with the same classification may receive the normal rate.

That means your calculation engine potentially needs to evaluate:

Product + Classification + Destination + Origin

rather than simply:

Product + HS code

Then come the additional measures

This is where a simple tariff database can become inadequate.

Depending on the product and origin, there may be additional measures such as:

• Section 301

• Section 232

• Safeguards

• Anti-Dumping Duties

• Countervailing Duties

ADD/CVD can be especially challenging because the relevant information may involve specific products, countries, exporters, producers, case numbers, scope language, and rates.

So storing:

HS Code → 8%

is not necessarily enough.

A more realistic system might need to represent something closer to:

Product
→ Classification
→ Destination
→ Origin
→ Base tariff
→ Preference
→ Additional measures
→ Trade remedies
→ Applicable calculation

That's a fundamentally different data model.

Customs value is another layer

Even after determining the applicable rate, you still need the correct customs value.

The simplified formula is:

Import Duty = Customs Value × Applicable Duty Rate

But customs value isn't always something you can safely equate to the invoice total without checking the applicable valuation rules.

So now the calculation depends on both:

Rate intelligence

and

Valuation intelligence

This is why building reliable import-cost software isn't just about finding tariff percentages.

The scaling problem

Imagine a startup building a landed-cost calculator.

One product?

Manageable.

10 products?

Still manageable.

10,000 products across 20 destination markets, with multiple origins and changing trade measures?

Now you're dealing with a continuously changing regulatory dataset.

You need to account for:

• Tariff updates

• Classification changes

• Preference programs

• Country-specific rules

• Additional duties

• ADD/CVD changes

• Government-agency requirements

• Restrictions and quotas

• VAT/GST

• Data freshness

And you need to know when each rule applies.

That's a very different engineering problem from building a calculator with a static percentage field.

This is where tariff intelligence becomes interesting

For founders building in logistics, procurement, customs, or global commerce, there's an interesting distinction between:

A tariff lookup tool

and

A tariff intelligence layer

The first answers:

What's the rate for this code?

The second attempts to answer:

What trade requirements and duty treatment apply to this product, for this destination and origin, right now?

That distinction matters when your software needs to make decisions rather than simply display information.

I recently came across a useful breakdown of this exact calculation problem that goes through classification, destination, origin, customs value, preferential tariffs, and additional duties in more detail:

How to Calculate Import Duty from an HS Code

It's worth reading if you're building anything that needs to estimate import duty rather than just display a generic tariff rate.

One more distinction: duty vs. landed cost

Another trap is treating import duty as the complete import cost.

It isn't.

Depending on the transaction, the total landed cost can include:

• Import duty

• VAT/GST

• Freight

• Insurance

• Brokerage

• Handling

• Excise taxes

• Other statutory charges

So if you're building a landed-cost product, tariff intelligence is one layer of the calculation rather than the entire calculation.

The takeaway for founders

If you're building software around cross-border commerce, don't model import duty as:

HS Code → Duty Rate

That model is too simplistic for real-world use cases.

A more useful architecture starts thinking in terms of:

Product → Classification → Destination → Origin → Tariff Treatment → Customs Value → Additional Measures → Total Import Cost

The arithmetic is easy.

Keeping the underlying regulatory data accurate, current, and correctly connected is the hard part.

And that's probably the more interesting problem to solve.

If you're building a physical product business, there's an easy mistake to make when estimating your landed cost:

You find the HTS code, see the tariff rate, and put that number into your spreadsheet.

Done, right?

Not necessarily.

A product can have a relatively low standard U.S. tariff rate and still be subject to Antidumping (AD) or Countervailing Duties (CVD).

And those additional duties can completely change the economics of importing a product.

Why this matters for founders

Imagine you're sourcing a product from overseas.

Your spreadsheet says:

Product cost + freight + 5% import duty = landed cost

You build your pricing around that number.

Then you discover the merchandise is potentially covered by an AD/CVD order.

Now your original margin calculation may be wrong.

That's not a minor compliance detail. For a business importing significant volumes, it can affect pricing, supplier selection, sourcing strategy and cash flow.

The part that's easy to miss

The HTS code is useful for finding potential AD/CVD exposure.

But an HTS match isn't necessarily the final answer.

AD/CVD orders have written scope descriptions. Those descriptions can get very specific about things like:

• Materials

• Dimensions

• Physical characteristics

• Manufacturing processes

• Product configuration

• Country of origin

• Exclusions

So two products that appear similar at a high level may not necessarily receive the same treatment.

I recently went deeper into the practical workflow for checking this, including how to research the order, evaluate the written scope, identify case numbers and determine the applicable rate. The full AD/CVD compliance guide for importers is useful if you're dealing with U.S. imports.

The workflow I'd use

For a physical-product business, I'd think about AD/CVD roughly like this:

Product details → HTS classification → Potential AD/CVD order → Written scope → Product comparison → Case number → Applicable rate → Current CBP requirements

The key distinction is:

Classification asks: “What HTS code applies?”

Scope asks: “Is this merchandise covered by the AD/CVD order?”

Those aren't the same question.

Another thing founders should watch

Don't assume an AD/CVD rate you found six months ago is still the rate you should use today.

Commerce proceedings and administrative reviews can affect applicable rates and duty collection.

Supply-chain changes can also create new questions. Changing the supplier, manufacturing location or production process doesn't automatically eliminate trade-remedy exposure.

My takeaway

If you're building a hardware, DTC, manufacturing or importing business, I'd add AD/CVD exposure to the same early-stage checklist as freight, insurance, customs duty and other landed-cost components.

Otherwise, you can end up optimizing a business model around a landed-cost number that wasn't complete in the first place.

For anyone who wants the detailed research process rather than just the high-level concept, here's the full AD/CVD importer walkthrough.

When a startup begins importing products, customs classification usually isn't at the top of the founder's priority list.

At first, it may be just another field on an invoice.

Then the catalog grows.

Suddenly there are hundreds of SKUs, multiple suppliers, different countries, changing products, and people relying on old spreadsheets to determine how goods should be classified.

That's when a small classification mistake can become an operational problem.

The Problem Isn't Finding an HS Code

There are plenty of tools that can find possible HS codes.

The harder question is:

How do you know the code you're using is actually defensible?

A product name rarely contains everything needed for classification. You may need its material, function, technical specifications, composition, intended use, and configuration.

This creates a common startup trap.

Someone searches for the product name, finds a code that looks reasonable, adds it to the spreadsheet, and moves on.

That works until the product doesn't fit the assumptions behind the original classification.

Supplier Data Isn't Always Enough

Founders often assume that if the supplier provides an HS code, the problem is solved.

It isn't.

The supplier may be classifying the product according to the exporting country's tariff system. The importer may need a different country-specific classification.

Supplier data is useful input. It shouldn't automatically become the final answer.

The Six-Digit Code Can Be Only the Beginning

The Harmonized System provides an international six-digit structure, but countries can add additional digits for their own tariff and statistical purposes.

For a company selling or importing across several markets, this creates another layer of complexity.

A classification that works for one market isn't necessarily the complete classification required in another.

Scaling Makes the Problem Worse

Imagine a startup with 20 products.

Manual classification might be manageable.

Now imagine 2,000 products.

Then add:

• Multiple suppliers

• Product variations

• New markets

• Product updates

• Different reviewers

• Changing tariff schedules

• Customs questions

At that point, the problem isn't simply "What HS code should we use?"

It's how do we consistently classify, review, document, and maintain thousands of products?

Treat Classification Like Product Data

One useful shift is to stop treating an HS code as an isolated spreadsheet value.

Instead, maintain a record containing:

Product information → Classification analysis → Code → Supporting evidence → Reviewer → Decision history

This makes it much easier to understand why a classification was selected and revisit the decision when something changes.

I recently put together a more detailed breakdown of the common HS code classification mistakes that create customs problems if you want to go deeper into the practical side of this.

What I'd Do as a Founder

If you're building an import-heavy or international ecommerce business, I'd establish the classification process early.

At minimum:

1. Capture detailed product information.

2. Don't blindly copy supplier classifications.

3. Validate the destination country's tariff requirements.

4. Keep the reasoning behind important classifications.

5. Review high-risk or high-value products.

6. Don't assume an old classification remains correct forever.

The boring operational systems are usually the ones that become painful to build after you've scaled.

HS classification is one of them.

The goal isn't to create another spreadsheet full of tariff codes.

It's to create a classification process that remains understandable and manageable as the business grows.

One thing we've noticed while looking at global trade compliance is that the problem isn't always a lack of information.

There is plenty of information.

The harder problem is connecting the information.

A company might have its product catalog in one system, HS classifications in spreadsheets, tariff data somewhere else, landed-cost calculations with finance, and regulatory updates coming through emails or separate databases.

Each piece works.

The workflow doesn't.

The problem becomes obvious at scale

Imagine an importer managing 2,000 SKUs across several suppliers and countries.

A tariff or regulatory change happens.

Now someone has to figure out:

• Which products are affected?

• Are their classifications still appropriate?

• Does the tariff treatment change?

• What happens to landed cost?

• Which upcoming shipments are affected?

• Does procurement need to contact suppliers?

• Does finance need to update its assumptions?

None of these questions is particularly unusual.

The painful part is connecting them.

That's the product problem we're interested in.

We're thinking about compliance as a workflow

Instead of treating classification, tariffs, landed cost, and regulatory monitoring as separate activities, the model we're working toward looks more like:

Product Data → Classification → Tariffs → Landed Cost → Regulatory Monitoring → Impact → Action

The important part isn't the diagram itself.

It's what happens when information moves through it.

A change in regulatory information should ideally lead to a question about affected products, not just another notification in someone's inbox.

A classification change shouldn't exist independently from the tariff and cost implications that follow it.

And a compliance alert shouldn't stop at “something changed.”

It should help the right person understand what might need attention.

We wrote a deeper breakdown of this approach here: how a connected trade compliance workflow can work.

Where AI fits

We're also interested in where AI genuinely helps rather than where it is simply added because “AI” sounds good.

Trade compliance involves a lot of unstructured information.

Regulatory notices can be long. Product descriptions can be inconsistent. Trade measures can involve multiple conditions.

AI can potentially help with:

• Extracting relevant information

• Summarizing regulatory changes

• Identifying entities and products

• Matching changes against structured product data

• Prioritizing potentially relevant alerts

But we don't think AI should blindly make the final compliance decision.

A better model is:

AI finds and organizes → structured systems connect → compliance experts validate → business teams act

That keeps humans involved where judgment actually matters.

The product challenge

The interesting engineering/product problem isn't just building another database of regulations.

It's building the connections between:

Products

Classification

Trade rules

Costs

Regulatory changes

People

Actions

That's where a compliance platform can potentially create leverage.

At "Borderline Genius Inc.", we're working on this broader problem through our trade compliance technology ecosystem, including Genius Workspace.

The long-term idea is simple:

Less searching. Less spreadsheet reconciliation. More useful compliance intelligence.

If you're building in B2B SaaS, compliance tech, supply-chain software, or another domain where the real problem is fragmented workflows, I'd be interested in how you've approached the same problem.

If your company imports or exports products across multiple markets, one thing is easy to underestimate: HS codes change over time.

The Harmonized System is revised periodically by the World Customs Organization to keep pace with changes in global trade, new product categories, regulatory requirements, and classification challenges. The upcoming HS 2028 edition is a good example of why businesses should treat classification as an ongoing compliance process rather than a one-time setup.

For SaaS companies, manufacturers, distributors, customs teams, and global e-commerce businesses, a classification change can have practical consequences. Product databases, tariff calculations, duty estimates, customs documentation, and compliance workflows may all need to be updated when a new HS structure takes effect.

The bigger challenge is not simply knowing that HS 2028 exists. It is understanding which products are affected, what their previous and new classifications are, and when each market will implement the changes.

I put together a deeper breakdown of the HS revision process, including how WCO amendments move from proposals through review and approval to national implementation.

Read the full guide: Why the Harmonized System Changes Every Five Years and What Drives Each Revision

For companies managing international trade at scale, tracking HS revisions early can be far less painful than discovering a classification change after a shipment, declaration, or tariff calculation is already affected.