How product classification is set up in finance and ERP systems

Product classification usually lives on the item master. Each product carries a customs tariff number and, where it applies, an export control code, held separately for each country or trade region. A trade compliance team assigns these through a workflow, and orders, invoices and shipping documents pick them up automatically.

Where the codes sit

Most ERP systems split product data into a general record and a set of extended views. Classification belongs in a trade or customs view attached to the product. It is not a free text field on the description. That view holds the tariff number for import, the commodity code used for export statistics, any export control classification, and the country of origin.

The important design choice is that codes are stored by jurisdiction. A single product can have one tariff number in the importing country and a different one at the point of export. The shared international portion of the code is often identical across countries. The national extension is not, so the system needs a separate entry for each place the product crosses a border.

Larger organisations often run a dedicated global trade application next to the ERP. In that setup, the trade application owns the classification, and the ERP receives a copy. The direction of that flow matters. If both systems let people edit codes, they drift apart.

How a new product gets classified

A new item is normally created by engineering, purchasing or product management. Creation triggers a task for the classification team. Until that task is complete, the product is usually blocked for cross-border shipping, though it can still be quoted or stocked.

The classifier works from technical specifications, material composition and intended use. Some systems offer suggested codes based on similar products or keyword search of the tariff schedule. Those suggestions help, but a person still decides. For difficult items, the team may ask a customs broker for an opinion or apply to the authorities for a binding ruling, and the ruling reference is then stored against the product.

When the item is a variant of something already classified, many teams copy the existing code. This is efficient and also the most common way errors spread across a product range.

Validity, changes and history

Tariff schedules are revised by the authorities, sometimes in large batches. A well built setup loads the new schedule as content, maps old codes to new ones, and gives each assignment a valid from date. Old codes stay visible so that past declarations can be explained during an audit.

Changes to a classification should require approval and leave a record of who changed it and why. Without that history, nobody can show whether a past shipment was declared correctly at the time it left.

How the codes flow into transactions

Once assigned, the code is read at the moment a document is created. Sales orders, delivery notes, commercial invoices and customs declarations pull it from the product record. Duty calculation, preferential origin checks and export licence screening all depend on it.

Some systems copy the code onto the transaction line when the document is created. Others look it up again when the declaration is sent. The difference decides what happens when a code changes while goods are in transit, and it is worth knowing which behaviour the system follows.

Where finance comes in

Finance rarely assigns codes, but it lives with the consequences. Duty costs land in inventory valuation or cost of goods sold. Wrong classification can mean overpaid duty that is never reclaimed, or underpaid duty that returns later as an assessment with penalties. Preferential trade agreements reduce duty only when classification and origin are both right, so savings that look secure on paper may not survive a review.

Accrual for duty, reconciliation of broker invoices and the treatment of post-clearance adjustments all assume that the code on the product was correct when the goods moved.

Where the setup usually breaks

The documented process often assumes one team classifies everything. In practice, brokers frequently classify at the border and never feed their codes back. Local warehouses may override a code on a single shipment to get goods released. Purchasing may create items with a placeholder code just to clear the block. Each of these leaves the master data saying one thing while declarations say another.

Another weak point is ownership after creation. Products get redesigned, change supplier or change material, and nobody tells the classification team, so the record goes stale quietly.

Questions to ask the people who run it

• Who actually decides the code for a new product, and what do they look at?
• When a broker uses a different code from the one in the system, how does anyone find out?
• Can a shipment go out before classification is approved, and how often does that happen in practice?
• Which system is the master for classification, and can the other one be edited?
• When the tariff schedule changes, who loads it and who remaps the products?
• Are binding rulings stored against the product, or kept in someone's files?
• If engineering changes a product's material, what tells the trade team?
• Does the declaration use the code saved on the order or the one on the product today?
• Who reviews duty paid against what the classification says should have been paid?
• What workarounds exist that nobody has written down?

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.