Most catalogs have one code: the SKU. It works until your buyer's supplier uses their own codes, and your biggest customer's purchasing system expects a third code entirely, and the twenty-year-old internal ERP you're phasing out still hasn't been decommissioned.
This is the reality of distribution. Products move between systems, and every system has its own naming convention. The supplier's invoice says 'FAN-450-B'. Your warehouse labels it 'FAN450'. The customer's procurement portal expects 'FAN-450-BLACK'. And the legacy ERP — the one that's been running since 2003 and nobody dares turn off — still calls it 'ELEC-FAN-0450'. Four codes. One product. And if your quoting tool only understands one of them, you're manually translating the other three every day.
The four columns
Quotery's Product carries sku, import_code, internal_code, and export_code. Each is indexed with a GIN trigram for fast substring search. Each can be searched independently or together.
The trigram index is the unsung hero here. A standard B-tree index can answer 'does this exact string match?' but not 'does this string appear anywhere in this field?' With GIN trigram, a search for 'FAN450' matches 'FAN-450-B', 'FAN450BLK', and 'ELEC-FAN-0450' — all in milliseconds. This matters because supplier documents rarely use your exact code format. They add hyphens, drop prefixes, concatenate with colors. The trigram index absorbs that variance without requiring the user to learn regex.
Why the AI import cares When the AI importer hits a line, it checks all four columns for an exact match before it ever asks the model to reason about the product. This is the difference between an import that's 99% deterministic and one that burns tokens on problems you already solved.
Each deterministic match saves roughly 200-500 tokens and 500ms of latency. On a 20-line import, if 14 lines match deterministically, the AI step only processes 6 lines instead of 20 — a 70% reduction in cost and latency. And the deterministic matches are guaranteed correct. The AI matches are probabilistic. Every line you can resolve without the model is a line you don't have to review.
Migration friendly
A customer switching from a legacy system can dump their old codes into internal_code, stand up fresh SKUs, and let the importer bridge the gap until the old codes fade.
Migration is the highest risk phase of any system change. The old codes don't disappear overnight — suppliers keep sending them, customers keep ordering by them, and printed catalogs still reference them. By keeping old codes alive in internal_code while the new SKU system takes over, the transition is gradual and reversible. When the last supplier switches to the new code and the last customer stops using the old one, you can stop populating internal_code. But until then, the bridge stays up.