Know your landed cost before you commit

Most classification happens too late to be useful for the decision it most affects. The code is often finalised near the point of import, once suppliers are chosen, quantities are set and prices are published. But the duty rate that code determines is a direct input to landed cost, and landed cost is what tells you whether a product's margin is real. Leaving classification until the end means committing to prices before you know the number that decides whether those prices work. The fix is to classify earlier, during development, and to do it fast enough that it never becomes the thing everyone is waiting on.

The short version

Duty is part of landed cost, and landed cost decides margin. If you classify late, you price before you know your true cost. Classifying during development, from the product data you already hold, means the duty rate is a known input while pricing decisions are still open, not a surprise that arrives after the goods clear customs. Speed is what makes this possible, because a classification you wait days for cannot inform a decision being made today.

The problem with classifying late

The familiar sequence goes like this. A collection is designed, suppliers quote, landed costs are estimated, margins look acceptable, prices are set. Then the goods ship, clear customs, and the actual duty turns out higher than the estimate, because the code used for the estimate was a guess or a placeholder. The margin that justified the price was never the real margin. This bites hardest on a first shipment into a new market, where the duty rate is unfamiliar and the pricing is being set from scratch. By the time the correct duty is known, the price is already in the market and the cost cannot be unwound.

This is not a rare accident, it is the predictable result of treating classification as an import-time formality rather than a development-time input. The code was always going to determine the duty; the only question was whether you knew it while you could still act on it, or after you no longer could.

The waiting problem

The reason classification slips to the end is usually speed. When the code has to come from a broker or a specialist queue, it arrives on someone else's timetable: you submit the product, you wait, and the answer comes back days later. A buying decision does not wait days. So the team proceeds on an assumed rate, promises itself it will confirm later, and the assumption hardens into a price. The bottleneck is not that classification is impossible early, it is that the usual routes are too slow to fit inside the window where the decision is actually made.

Remove the wait and the sequence changes. If a code and its duty rate are available in the moment a product is being costed, classification moves to where it belongs, alongside the supplier quote and the freight estimate, as one of the inputs to the margin calculation rather than a check performed after the fact.

Classifying during development

Classifying early does not require more information than classifying late. The attributes a code depends on, material, construction, composition, gender, end use, are defined during development, which is precisely when the product is being specified. So the data exists early; what has been missing is a way to turn it into a code quickly enough to matter.

When classification runs from that development data at speed, a product team can see the landed cost implications of a design decision while the decision is still open. A choice between two fabrics is also a choice between two duty rates. A decision to add a performance treatment might move a garment into a different code. Knowing this during development, rather than discovering it at the border, turns duty from a cost that happens to you into a variable you can design around.

Speed compounds

Fast classification pays off more than once. Because a code can be produced quickly and cheaply, you are not limited to classifying the final range once; you can re-run as the range evolves, as fabrics are substituted, as new styles are added, and keep the landed-cost picture current through development rather than freezing an early guess. And because each code arrives with a confidence figure and the reasoning behind it, speed does not come at the cost of a defensible decision: a fast answer is still an explained answer, and where a product is genuinely ambiguous the system says so and offers the options rather than rushing to a wrong code.

The goal is simple to state and, until recently, hard to achieve: know the right code, and the duty it carries, while you can still use the information. Classify during development, at speed, and margin stops being something you confirm after the goods arrive and becomes something you decide before you commit.