HTS Code Classification: Common Mistakes Engineers Make

Mistake 1: Treating the description as the classification

The most common mistake. An engineer builds a keyword search over HTS descriptions, finds a code whose description loosely matches their product, and uses that code. This feels like classification. It is not.

HTS classification is governed by the General Rules of Interpretation, a formal six-step framework that determines which code applies when multiple codes could plausibly fit. A product that contains the word "steel" in its description does not necessarily classify in Chapter 72. A product described as "electronic" could classify in dozens of different chapters depending on its essential character, function, and composition.

Fix: Description search is a starting point for finding candidate codes, not a classification method. The correct code is determined by applying the GRIs to the specific product, not by matching text.

Mistake 2: Storing codes without validating they exist

Applications that allow users to enter HTS codes — for product catalogs, shipment records, or classification history — often accept any 10-digit number without checking whether it exists in the current schedule. Codes that were valid two years ago may have been retired. Codes that users transcribe from paper documents may contain typos. A code that looks syntactically valid is not necessarily a real code.

Fix: Validate every entered code against the current HTS dataset at the time of entry. Return a clear error for codes that do not exist. If a previously valid code has been retired, flag it in your UI rather than silently accepting it.

Mistake 3: Using 6-digit codes for US duty rate lookups

The international HS system uses 6-digit codes. Many global trade databases, product catalogs, and ERP systems store 6-digit codes because they are internationally portable. Engineers sometimes query the US HTS with a 6-digit code and read the rate off the heading-level record. This is wrong. US duty rates are defined at the 8 or 10-digit level. The rate on a 6-digit heading record in the USITC data is either absent, a range, or a parent-level placeholder that does not represent what any specific import actually pays.

Fix: For US duty rate lookups, always use the full 10-digit code. If you only have a 6-digit code, you cannot reliably determine the US rate without further classification work. Be explicit about this limitation in your application rather than surfacing a misleading result.

Mistake 4: Ignoring Chapter 99

As covered in earlier articles on this blog, Chapter 99 is where additional duties from Section 232, Section 301, and other trade actions live. It is also where temporary duty suspensions and tariff-rate quota provisions appear. Engineers who build HTS integrations focused on Chapters 1–97 and ignore Chapter 99 are building an incomplete rate lookup. The base MFN rate from Chapter 72 on a steel product is not the effective duty rate if a Section 232 additional duty applies — and right now, it does.

Fix: Chapter 99 is not optional for production rate lookups. Your data model needs to represent it, your ingestion pipeline needs to fetch it, and your rate calculation logic needs to check for applicable Chapter 99 provisions for every code you look up.

Mistake 5: Assuming one product maps to one code

Classification is not always unambiguous. A product can have multiple plausible classifications depending on interpretation, and reasonable customs brokers sometimes disagree. Some products change classification based on how they are imported — assembled versus unassembled, with or without accessories, in sets versus individually. Applications that treat HTS classification as a deterministic lookup miss this ambiguity entirely and may give users false confidence in a classification that a CBP officer would dispute.

Fix: For ambiguous products, surface the uncertainty rather than hiding it. Return candidate codes with confidence indicators where possible. Make clear in your UI that your application assists with classification rather than making a binding legal determination. For high-value or high-risk products, recommend review by a licensed customs broker.

Mistake 6: Not accounting for country of origin

The duty rate for a given HTS code varies by country of origin. The General column reflects the MFN rate that applies to most countries. The Special column lists preferential rates under trade agreements — USMCA, various FTAs — that apply only when origin requirements are met. The Other column (Column 2) applies to a small number of countries without normal trade relations. An application that returns "the duty rate" for an HTS code without knowing the country of origin is returning an incomplete answer at best and the wrong answer at worst.

Fix: Rate lookups should always include country of origin as an input. Surface the applicable column based on origin, and flag when preferential rates require documentation — a certificate of origin, for example — that the importer may not have.

Mistake 7: Hardcoding codes in application logic

Engineers sometimes hardcode specific HTS codes into application logic — rate thresholds, product category filters, reporting queries — because the code was valid when they built the feature. Codes get retired. Codes get split. A hardcoded code that disappears from the schedule does not generate an error; it silently returns no results or incorrect results. This is a maintenance debt that grows invisibly until it causes a real problem.

Fix: Treat HTS codes in application logic the same way you treat any external reference data — as something that can change and needs to be validated. Store them in configuration or a database table rather than source code, and include them in your change detection monitoring.

Mistake 8: Confusing HTS with Schedule B

The US uses two different 10-digit classification systems: HTS codes for imports (administered by USITC and CBP) and Schedule B codes for exports (administered by Census). They share the same first 6 digits — the international HS code — but the 7th through 10th digits can differ. An engineer who builds an import classification tool using Schedule B data, or vice versa, will produce correct results for the overlapping codes and silent errors for the ones that diverge.

Fix: Be explicit in your data model and UI about whether you are dealing with import (HTS) or export (Schedule B) classification. Do not mix the two datasets. If your application handles both import and export workflows, maintain them separately.