How to review broker HTS classifications with public HTS data

TL;DR

• Review the importer's highest-risk product and entry lines first, rather than treating every line as equally urgent.
• Confirm that each filed code exists, then examine the hierarchy, current notes, product evidence, and any relevant CBP rulings.
• Re-run duty, Chapter 99, PGA, and AD/CVD checks to understand the consequence of the filed code. These checks do not validate the classification.
• Record the reviewer's reasoning and disposition. Escalate ambiguity and possible past-entry errors to a licensed customs professional or counsel.

Know what the review proves

A second-pass review can find stale or malformed codes, incomplete product descriptions, inconsistent treatment within a SKU family, overlooked duty layers, and entries that deserve a deeper legal review. That is valuable operational work.

It cannot prove that the first result from a search endpoint is the correct classification. Tandom's current public surface provides read-only HTS reference, duty, PGA, Chapter 99, AD/CVD, and regulatory data. The description-to-code classifier and broker-override workflow described in older versions of this guide are not public API capabilities.

Use the public tools to assemble evidence and reveal exceptions. Keep the decision with a qualified human reviewer.

Choose a sample that can actually reveal risk

Export enough entry-line detail to reconnect the filed code to the product facts: entry number and line, SKU, filed HTS code, description, origin, supplier or manufacturer, entry date, value, quantity, and unit of measure. Link supporting specifications and invoices where possible.

Prioritize:

• new products, suppliers, brokers, or source countries;
• high-value or high-volume SKU families;
• vague descriptions such as "parts" or "accessories";
• sets, composite goods, and products with multiple materials;
• lines affected by Chapter 99, PGA, Section 232, or AD/CVD signals;
• codes that changed, disappeared, or have not been reviewed recently.

Run the review in six passes

1. Normalize the filed code

Keep the original value, then create a normalized ten-digit value for matching. Do not silently pad a short code or repair a transposed digit; flag it for review.

2. Confirm that the code resolves

Use the Tandom catalog or public catalog-code operation. A not-found response is a strong exception signal. A successful response proves only that the code exists in the current dataset.

3. Read the hierarchy and notes

Compare the filed code's full description with the actual article, then read parent headings and applicable section, chapter, heading, and subheading notes. Search CBP CROSS for rulings involving materially similar facts.

4. Compare the product evidence

Check composition, function, principal or actual use, form, dimensions, capacity, and whether the article is a part, set, kit, or unfinished good. If the invoice does not contain the necessary facts, request specifications from the supplier instead of guessing.

5. Re-run consequences separately

Calculate duty for the filed code, origin, value, and entry date. Check PGA flags and Chapter 99 applicability. Screen AD/CVD using the product description, country, manufacturer, and exporter; HTS coverage alone does not establish scope.

6. Assign a disposition

Use explicit outcomes: confirmed after review, more product facts required, classification review required, trade-remedy review required, or counsel/binding-ruling escalation. Avoid labels such as "API says wrong."

Build an exact-lookup log

This minimal Node.js example checks whether filed codes resolve and preserves the raw public response for review. It does not classify the products, score broker quality, or declare a code correct.

// filed-code-lookup.mjs — Node 20+
const API_KEY = process.env.TANDOM_API_KEY;
const codes = ["7307.91.50.10", "8413.70.20.04"];

for (const filedCode of codes) {
  const endpoint =
    "https://api.tandom.ai/v1/catalog/codes/" +
    encodeURIComponent(filedCode);

  const response = await fetch(endpoint, {
    headers: { Authorization: "Bearer " + API_KEY },
  });
  const body = await response.json();

  console.log(JSON.stringify({
    filedCode,
    resolves: response.ok,
    reference: body,
    disposition: "HUMAN_REVIEW_REQUIRED",
    checkedAt: new Date().toISOString(),
  }));
}

Store the response beside the source line, but do not mistake a raw JSON log for an audit record. The reviewer's sources, reasoning, and disposition are the part that explains what the team decided.

Document the disposition and next action

A useful review row contains the filed code, product facts, sources consulted, reviewer, date, conclusion, unresolved facts, and next action. Link the result to the SKU family and supplier so corrections to master data reach future purchase orders and invoices.

When a possible historical error appears, pause the automation. Entry status, timing, materiality, and the available correction path require professional review. Consult a licensed customs broker or customs counsel before changing a filing or contacting CBP.

Common pitfalls

• Treating existence as correctness. A real code can still be wrong for the article.
• Comparing descriptions only. Classification can turn on notes and facts absent from the invoice.
• Calling AD/CVD an HTS-only check. Scope language and party facts control the analysis.
• Using an invented confidence threshold. The public reference endpoints do not return classification confidence.
• Taking corrective action from a script. Escalate the complete facts to a qualified customs professional.

FAQ