Why the Same Product Gets Two Different HTS Codes from Two Different Brokers
Send the same product to two competent customs brokers and it is entirely possible to get two different HTS codes back — both argued in good faith, both citing real GRI logic, and both wrong to disagree with each other about which one is right. That isn't a competence problem. It's a records problem. Neither broker wrote down which rule they tried first, which they ruled out and why, or which note actually decided it. Without that record, a disagreement between two classifications isn't a dispute that can be resolved on the merits — it's just two guesses, and there's no way to tell which one would survive a CBP challenge.
Two brokers can each follow "the rules" and land on different codes not because either was careless, but because the GRI traversal itself was never recorded — so there's no way to tell whose reasoning would survive a CBP challenge, only whose guess got there first.
This Isn't a Rare Event — It's Structural
The General Rules of Interpretation are a mandatory sequence, not a lookup table, and several of the rules in that sequence are explicitly judgment calls rather than mechanical tests. GRI 3(b) — essential character — is the clearest example: the tariff schedule lists six relevant factors and declines to rank them, on purpose, because the products that reach GRI 3(b) are exactly the ones a formula would get wrong. Two brokers can weigh those same six factors differently and each produce a defensible-sounding answer. That's not a flaw in the rule. It's the rule working as designed — see Why "Essential Character" Is the Most Litigated Phrase in the Tariff Schedule for how far that judgment call can actually swing on a real CBP ruling.
Multiply that by every judgment point in the six-rule sequence — where GRI 1 note-reading gets ambiguous, where GRI 2(a) essential-character-of-the-unfinished-article gets debatable, where GRI 4's "most akin" analysis has no fixed formula at all — and disagreement between two competent, good-faith classifiers isn't an edge case. It's the expected outcome whenever a product lands on a genuinely contested provision.
The Rules Are the Same. The Records Aren't.
Here's the part that actually matters: if both brokers ran the full GRI sequence faithfully — checked GRI 1 against the applicable notes, confirmed it was insufficient, moved to GRI 2, confirmed that was insufficient, and so on — there would be a real, comparable record showing exactly where their reasoning diverged. You could look at both traversals side by side and see whether one of them missed a chapter note, misapplied essential character, or jumped ahead in the sequence without justification.
In practice, that record almost never exists. What exists is a final HTS code and, if you're lucky, a paragraph of narrative justification written after the fact. The actual traversal — which rule was tried, why it failed, what the next rule found — was never captured, because most classification workflows aren't built to capture it. Without it, two different codes for the same product aren't a resolvable disagreement. They're two unfalsifiable claims. Neither broker can prove their reasoning was more rigorous than the other's, because neither wrote the reasoning down in a form that could be checked.
Why "Trust My Broker" Isn't a Classification Program
CBP's reasonable care standard, established under the Customs Modernization Act of 1993, requires importers to take positive, demonstrable steps toward classification accuracy — not simply to delegate the decision and hope. Reasonable care is proven with a record: a documented methodology, the notes actually consulted, the GRI rule that resolved the classification and why the prior rules didn't. A conclusion without that record isn't evidence of reasonable care, no matter how experienced the broker who produced it.
This is exactly the gap a Classification Support Package exists to close: a locked, timestamped record of the corpus version evaluated, every note considered, the specific GRI rule that resolved the classification, and any CROSS rulings that supported or were distinguished along the way. That record is what turns "our broker said 8504" into something CBP has to actually engage with on the merits during a protest or Focused Assessment — because the reasoning, not just the answer, is on paper.
A Binding Ruling Isn't a Universal Fix Either
The obvious answer is: get a binding ruling and make the disagreement go away. That works, as far as it goes — a binding ruling under 19 C.F.R. Part 177 is genuinely the gold standard of classification certainty, and it legally binds CBP for the requester on that specific product. But it only covers the one product it was requested for. An importer with hundreds or thousands of SKUs isn't requesting a binding ruling for each one — the volume makes that impractical, and CBP's ruling process isn't built to absorb it at that scale.
For every product that doesn't have its own binding ruling — which is most of them — the underlying question stands unanswered: if two brokers disagreed, whose traversal would actually hold up? A binding ruling settles individual, high-value disputes. It doesn't fix the structural problem that classification reasoning, across an entire product catalog, usually isn't recorded in the first place.
Why This Is a Software Problem, Not Just a Broker Problem
The reason two brokers can diverge and neither can prove they're right isn't that classification is unknowable — it's that the process producing the answer isn't deterministic in practice, even though the underlying law is a fixed, mandatory sequence. The same product, evaluated against the same GRI in the same order against the same corpus, should produce the same code every time. When it doesn't, the variable isn't the law. It's the absence of a system that actually runs the full sequence the same way twice and writes down what it found at each step, the way The General Rules of Interpretation, in Plain English lays out rule by rule.
That's the specific problem Kanon's classification engine is built to remove. The same product attributes evaluated against the same corpus version always produce the same HTS code, because the traversal is run in the legally required sequence — not reconstructed from memory after the fact — and every decision point is recorded in the Classification Support Package as it happens. Two people using Kanon on the same product don't get two different answers to compare. They get the same traversal, because the traversal was never left to individual judgment about where in the sequence to start.
Frequently Asked Questions
If two brokers both cite the GRI, doesn't that mean both classifications are defensible?
Citing the GRI is not the same as documenting the traversal. A defensible classification shows which rule resolved the classification and why every prior rule was insufficient — not just that GRI exists and was generally consulted. Two codes that both invoke "the GRI" without that record are not equally defensible; they're equally undocumented.
Does a Classification Support Package guarantee CBP won't challenge the classification?
No. It's evidence of reasonable care, not a guarantee against audit findings or penalties. What it does is give CBP a specific, checkable record to engage with — the corpus version, the notes evaluated, the GRI rule applied — rather than an unsupported conclusion, which materially affects the culpability finding if an error is found.
Why not just get a binding ruling for every product to avoid this entirely?
Binding rulings are the strongest form of certainty available, but requesting one for every SKU in a large catalog isn't practical — the volume and turnaround time don't scale. Binding rulings are best reserved for high-value, high-volume, or genuinely novel products; most of a catalog still depends on a documented, repeatable internal classification methodology.