HS Code Classification for Multinational ERP Integrations: Jurisdictional Coverage and Integration Controls

Introduction

A guide for trade compliance and IT teams on classifying products across the US, UK and Brazil, preparing for HS 2028, and controlling how approved codes reach ERP and customs systems.

Date

October 28, 2026

UPDATED

October 29, 2026

Author

Jonny Smith

Type

Guide

Ripple supports customs classification workflows that combine jurisdiction-specific tariff codes, supporting evidence, specialist review and integration with operational systems. For freight forwarders, customs brokers and multinational operators managing movements across the US, UK and Brazil, the practical task is to keep classification decisions usable and controlled across product catalogues, shipment documents and downstream systems. Coverage, output fields and integration scope are agreed for each deployment.

The core challenge for multinational operations: the Harmonized System provides a common six-digit foundation used by more than 200 countries and economies, but each jurisdiction extends those six digits differently. The US uses 10-digit HTS numbers for imports. The UK uses 10-digit commodity codes for imports under its own tariff. Brazil uses eight-digit NCM codes, including on domestic fiscal documents. A single product moving through all three needs three distinct classification outputs, each governed by different rules, updated on different schedules and used in different customs systems. Treating them as one classification task creates avoidable inconsistencies once codes flow into connected ERP and customs systems.

The timing matters. HS 2028, the next edition of the Harmonized System, enters into force on 1 January 2028, and every national tariff built on it will change. Organisations with classifications spread across several systems will need a controlled way to identify affected products, validate new codes and update their records.

This guide is written for trade compliance leads and IT teams evaluating classification and integration requirements. It explains the jurisdictional context, the operational questions buyers commonly raise, and the controls to agree before approved classifications enter connected systems.

General information only, current as of 28 October 2026. Ripple is a technology company, not a licensed customs broker. Nothing in this guide is customs, legal or tax advice.

Book a call with Ripple

How the HS Code Structure Differs by Jurisdiction

The World Customs Organization maintains the six-digit HS nomenclature, normally revised on a five-year cycle. The review leading to HS 2028 was exceptionally extended to six years. Every country uses this six-digit base. What changes is what comes after it, and the rules that govern how those additional digits are assigned.

National extensions keep moving independently of the WCO schedule. The UAE, for example, is moving from eight-digit to 12-digit HS codes in line with the GCC Integrated Customs Tariff, with some trade flows remaining on eight digits during the phased transition. Our guide to UAE customs automation and free zones covers that change in detail. The same principle applies everywhere: a code that is correct for one jurisdiction, movement type and date may not be correct for another.

Understanding the digit structure for each jurisdiction is the prerequisite for understanding why a single classification engine cannot apply the same logic to every shipment.

United States: 10-digit HTS and Schedule B

The Harmonized Tariff Schedule of the United States (HTSUS) extends the six-digit HS code to 10 digits. Digits seven and eight set the US tariff subheading; digits nine and 10 are statistical suffixes. The schedule is maintained by the US International Trade Commission. Schedule B numbers for exports are maintained separately by the US Census Bureau.

For imports, the 10-digit HTS number determines or informs:

The general (Normal Trade Relations) duty rate
Additional duties under Section 301, Section 232, and antidumping or countervailing duty orders, where they apply
Eligibility for preferential rates under USMCA and other trade agreements
Chapter 99 provisions and other applicable tariff measures

For exports, Electronic Export Information (EEI) filed through the Automated Export System (AES) requires a Schedule B number or, for most goods, the corresponding HTS number. Schedule B shares the six-digit HS root but its final four digits are maintained separately and can differ from the HTS.

An operational point: import HTS numbers and export Schedule B numbers share a root but are separately administered. Where a workflow needs both, the deployment should specify which code is required for each filing and how the two are kept consistent.

Duty treatment behind a valid HTS number can change while the number itself stays the same. Confirm the current requirements for the shipment, route and entry procedure when defining a workflow.

United Kingdom: 10-digit Commodity Codes

Since leaving the EU, the UK has maintained its own tariff, the UK Global Tariff, administered by HMRC. Import declarations use 10-digit commodity codes. The UK's eight-digit codes largely mirror the EU Combined Nomenclature, though the two have diverged since 2021. The final two digits identify UK-specific duties and measures, so the full 10-digit code is needed to determine the treatment that applies.

Key differences from the US system:

The UK commodity code is administered by HMRC, not the USITC
Duty rates reflect UK-specific trade agreements, including the UK-EU Trade and Cooperation Agreement and bilateral FTAs negotiated since Brexit
The UK's Customs Declaration Service (CDS) requires the full 10-digit commodity code on import declarations
UK-specific measures, including UK trade remedies and safeguards, apply at commodity code level

UK export declarations generally use the eight-digit UK commodity code. For UK classification, the deployment should specify the declaration types in scope, how the output maps to the CDS format used by the client's declaration software, and whether duty and measure information is included. Any duty figures should be dated and checked against the current UK tariff.

Brazil: Eight-digit NCM

Brazil and its Mercosul partners use the Nomenclatura Comum do Mercosul (NCM), an eight-digit system. The first six digits follow the international HS code; the final two define Mercosul-specific subdivisions.

The NCM is used for:

Brazilian import declarations in Siscomex, including the DUIMP
Nota Fiscal Eletrônica (NF-e) domestic fiscal documents
Import duty (II) and the indirect taxes calculated on imports

Brazil's indirect tax structure is changing materially. Under the consumption tax reform, 2026 is a transitional year in which fiscal documents report new CBS and IBS amounts for information. From 2027, CBS replaces PIS and COFINS on imports, and IPI rates fall to zero for most products. IBS replaces ICMS gradually between 2029 and 2033. Import duty continues to be driven by NCM classification throughout.

Brazilian classification therefore needs to be scoped alongside the tax and fiscal workflow. An NCM code is an essential input, but the deployment must also establish which taxes apply in the relevant period, which transaction attributes are required and which destination-system fields must be populated. Any tax calculation should be confirmed as an explicit part of the scope.

What Gets Assigned Per Line Item

Ripple's classification workflow produces line-item classification outputs, supporting reasoning and review in a structured format. The exact code types, duty information and downstream destinations depend on the jurisdiction and agreed deployment scope.

The classification output and acceptance criteria should specify:

The national tariff code for each jurisdiction in scope (10-digit HTS for US imports, 10-digit commodity code for UK imports, eight-digit NCM for Brazil)
Schedule B number for US export filings, where required alongside the import HTS number
ECCN (Export Control Classification Number) under the US Export Administration Regulations, where export control classification is in scope
Duty rates and applicable tariff measures, with calculation coverage, required transaction data and effective date agreed for each jurisdiction
Confidence score indicating classification certainty, with items below an agreed threshold routed for specialist review
Decision audit trail recording the classification rationale, the data used and the time of the decision

Export Control Classification and Review

Ripple's classification work can include HTS, ECCN and Schedule B outputs with supporting reasoning. The required code types should be agreed for each use case. Export control classification and licence determination are separate requirements and should be scoped separately.

Product characteristics can materially change an export control assessment. Energy-sector buyers, for example, have challenged proposed classifications for sensors and other components with possible dual-use characteristics, and asked to see the supporting reasoning and any relevant rulings. Where the available description does not resolve the relevant technical distinction, specialist review is needed before a classification is used.

The export control workflow should establish:

Which product attributes and technical evidence support the proposed ECCN
Whether destination, end-user and end-use screening are included in the agreed scope
Which unresolved questions require specialist review before release
Who owns the final classification and licensing decision, and how their approval is recorded

For energy services, offshore drilling, oil and gas, and other operators handling potentially controlled equipment, these responsibilities should be explicit before classifications are used operationally.

Confidence Scoring and Exception Routing

Not every line item can be classified with certainty from the available product data. Confidence scoring makes that uncertainty visible rather than masking it with a best-guess code.

Review thresholds and routing should be agreed for situations such as:

The product description is not specific enough for a defensible national-level decision (for example, "50mm tape" with no material specification, where the correct code depends on whether the tape is aluminium or fabric)
The confidence score falls below the agreed threshold for the deployment
The item falls within a category subject to tariff measures where the applicable rule requires human confirmation
An export control question or screening flag requires compliance sign-off

The reviewer receives the item with the suggested classification, the confidence score, the rationale and the specific data gap or ambiguity that triggered the escalation. The reviewer works from a structured recommendation, not a blank referral.

A confidence score should be accompanied by evidence the reviewer can inspect: the relevant product characteristics, supporting manufacturer information, classification reasoning and any rulings relied on. The unresolved question should be explicit so the reviewer knows what must be checked before approval.

First-pass classification rate, classification accuracy and the proportion of items requiring escalation are separate measures. A deployment should define and measure each against an agreed sample and review process.

ERP Integration Architecture

Classification output needs to reach the systems used for purchasing, order management and customs entry preparation. Integration scope should therefore describe the complete path from source documents to approved data in the receiving system.

The integration method depends on the receiving environment. API connections, structured messages and controlled file exchange should be evaluated against available interfaces, field mappings and acceptance requirements. Each direction of data flow should be specified separately.

Integration acceptance requires more than a correctly formatted output. Each deployment should confirm that the receiving system accepts the data, maps it to the intended records, handles rejected items and preserves review status. Testing and production approval should be separate milestones.

CargoWise Integration

Ripple connects to CargoWise as a system-to-system workflow integration, scoped by workflow and direction of data flow. On the inbound side, CargoWise can send a document pack to Ripple for a job, removing manual download and email preparation. The return path for prepared data needs its own agreed field mapping and acceptance tests.

The integration scope should specify:

Inbound document packs and their relationship to the relevant job or declaration
Outbound classification and duty fields, where included in the agreed scope
The treatment of exceptions, rejected messages and items awaiting review
Where source evidence, decision history and reviewer approvals are held

Writing data into customs entry records and updating the CargoWise product master are separate requirements. Each should be confirmed for the intended deployment.

ERP Platform Integration

For manufacturers, energy operators and 3PLs, the integration design should identify whether approved results belong in an ERP item master, trade compliance module, equipment register or another system of record.

The integration scope should establish:

The interfaces available in the specific ERP instance, including authentication, permissions and supported endpoints
The agreed exchange format and import schema where a controlled file-based route is required
The approval and correction process for writing new or revised classifications into existing records

Commercial invoices, purchase orders and other operational documents can provide classification input alongside structured product data. Where neither source provides enough technical detail, the workflow needs a defined clarification and review path before a classification is confirmed.

The Multi-ERP Challenge in Multinational Organisations

Classification data can be held across ERP platforms, TMS, broker databases, sourcing systems and landed cost models. A change can leave these records inconsistent unless the organisation defines which record is authoritative and how approved changes reach the others.

This is particularly acute for organisations that have grown through acquisition. Each acquired entity brings its own ERP, product data structure and classification history. Without a shared classification layer above those systems, the same product can carry different codes in different business units, creating filing discrepancies and audit exposure.

An entity-specific classification catalogue associates an approved decision with the importer or business unit it applies to. Matching needs to account for product identity, jurisdiction and the evidence behind the decision, rather than relying on a similar description alone.

For organisations with multiple ERP instances, a shared governance layer can coordinate approved classifications across connected systems. Which systems receive updates, and whether those updates are automatic or reviewed, must be agreed within the integration scope.

Classification governance also matters when equipment moves between jurisdictions. A code retained against an asset can become stale or unsuitable for a later movement. Operators of rigs, vessels and other mobile assets often hold equipment data in asset management systems, so the integration scope should identify which product or equipment record receives the approved classification, which jurisdiction it applies to and who owns subsequent corrections.

Catalogue Governance and Keeping Classifications Current

Classification accuracy at the point of first assignment is one part of the problem. Keeping a catalogue of thousands or hundreds of thousands of products current as codes, duties and trade policy change is the other.

A common failure mode is that classifications are updated in one system but not others. Compliance teams revise tariff data while procurement records, ERP item masters and broker databases keep operating with outdated codes. The inconsistency compounds over time and surfaces as filing discrepancies, inaccurate landed cost calculations and audit exposure.

A governed catalogue reduces that drift by making each approved decision traceable and its distribution controlled.

How the Catalogue Works

The catalogue should retain the approved classification and enough context to decide whether it can be reused. Relevant fields include:

The classification output (tariff code, ECCN and Schedule B where applicable, duty information with its effective date)
The jurisdiction the classification applies to
The confidence score and decision rationale at the time of classification
The date of classification and any subsequent updates
The operator or reviewer who confirmed the decision

When a known product reappears, its approved catalogue record can reduce repeated lookup work. Reuse still depends on matching the correct product, entity and jurisdiction, and on checking whether product characteristics or applicable rules have changed. A known product may need reclassification when those conditions change.

Controlled Updates When Codes or Policy Change

Tariff and policy changes need a controlled update process. The deployment scope should specify how affected records are identified, who reviews proposed changes and when approved revisions reach connected systems.

The change process should account for:

HTSUS revisions, including Chapter 99 updates and changes to tariff measures
UK commodity code updates following tariff amendments
NCM revisions under Mercosul schedule updates
Duty rate changes from new or amended trade agreements, tariff measures or regulatory actions

Each change should retain the previous decision, the reason for revision, its effective date and the person or process that approved it. Where a change affects related code types or downstream records, those dependencies should be reviewed before the update is released.

Correction ownership matters as much as initial approval. Buyers commonly ask how validated results return to their own systems, and how a catalogue change might affect related codes. A proposed update should show which related records may change and how an authorised reviewer can challenge or reverse it.

Bulk Classification for Large Product Catalogues

Bulk catalogue onboarding and shipment-document classification are distinct workflows. A catalogue project should define the input format, required jurisdictions, evidence standards and approval process before results enter operational use. A typical scope includes:

Ingestion of an agreed structured catalogue format, such as a spreadsheet or ERP export
Classification of each item to the national code length for each required jurisdiction
Confidence scoring and a decision audit trail for every item, so the compliance team can sign off before any code enters the live catalogue
Identification of items requiring human review, with a suggested classification and supporting rationale for each

The access model matters too. Some organisations want their own trade compliance team to submit catalogue work directly, rather than routing it through a forwarding partner. The workflow should identify who uploads the catalogue, who resolves missing data and who approves the results, separately from day-to-day shipment processing.

After initial classification, the catalogue needs an ongoing review and correction process. Automatic identification of affected items, approval of changes and distribution to connected systems should each be confirmed separately within the deployment scope.

HS 2028 preparation: organisations should plan how affected catalogue items will be identified, how proposed mappings from the WCO correlation tables will be validated against each national tariff, and how approved changes will reach connected systems. National tariffs will not all adopt the same deeper splits at the same pace, so the transition should preserve decision history and route ambiguous mappings to specialist review.

Document Ingestion

The classification workflow begins with document ingestion. To classify a line item, Ripple needs to extract product data from the documents the operator receives. Document formats vary widely in live logistics operations, and template-based extraction breaks when formats change.

Ripple's ingestion does not depend on a fixed template for each document layout. Typical inputs include:

Commercial invoices as PDFs, scanned images, spreadsheets or email attachments
Packing lists and bill of lading data
Purchase orders and pro forma invoices
Email content where product descriptions are embedded in the message text
Spreadsheets and CSV exports from procurement or ERP systems

When a document lacks technical detail, the workflow should surface the specific gap and route a clarification request to an agreed owner. Whether requests are sent automatically or approved by an operator should be defined during configuration.

For example, a description such as "stainless steel fittings" may need further technical evidence before a sufficiently specific code can be confirmed. The review should record what is missing, who can supply it and whether the classification is blocked pending clarification.

The information needed for a US HTS number may differ from that required for a UK commodity code or a Brazilian NCM. Data requirements and review rules should be defined for each jurisdiction in scope.

Deployment and Human Review Controls

Enterprise classification deployments require more than accurate AI output. They require defined controls over who can confirm a classification, what happens when a code is challenged and how the audit record is maintained for customs authority review.

The deployment should agree review permissions, escalation rules and evidence retention for each client and jurisdiction.

Role-Based Review Permissions

Classification decisions above a certain value, within a specified tariff chapter or flagged by export control screening can be configured to require sign-off from a designated reviewer before the code is confirmed and sent to downstream systems.

The review queue sits within the client's Ripple user interface, showing each pending item with:

The suggested classification and confidence score
The classification rationale and the data used to reach it
The specific reason the item was escalated (data gap, low confidence, tariff flag, export control flag)
The relevant tariff schedule entry and any applicable trade measure notes

The reviewer approves, modifies or rejects the suggestion. Each action is recorded in the audit trail with the reviewer's identity and a timestamp.

Audit Trail and Reasonable Care

US Customs and Border Protection expects importers to exercise "reasonable care" in classification. If CBP raises a query, the importer needs to show how each classification decision was reached and reviewed, not simply that it was accepted from an automated system.

The audit trail is designed to support that record. For each line item, it can show:

The product description and source document
The classification reasoning applied
The confidence score at the time of decision
Whether the item was confirmed automatically or reviewed by a designated reviewer
The identity of any human reviewer and the time of review
Any subsequent updates to the classification and the reason for the change

Evidence requirements should be assessed for each jurisdiction and use case. An audit trail supports review and accountability; it does not by itself establish that a classification or filing meets every applicable obligation. Responsibility for the classification declared remains with the importer or declarant.

Deployment Timeline

Deployment timing depends on source data, integration access, review configuration, testing and enterprise approval.

Integration stages often carry their own conditions. Message-format feasibility and validation by the client's IT team, for example, may need to be complete before testing can progress. A prepared interface should be distinguished from an accepted interface and an approved production workflow.

For multinational deployments, agree each entity's catalogue, jurisdictional rules, receiving-system connections, acceptance owner and go-live criteria. Ripple and the client team should agree their implementation responsibilities before committing to a schedule.

Frequently Asked Questions

Which jurisdictions does Ripple support for HS code classification?

Ripple supports classification for the United States (10-digit HTS for imports, Schedule B for exports where required), the United Kingdom (10-digit commodity codes under the UK Global Tariff) and Brazil (eight-digit NCM). Each jurisdiction is configured as a separate classification context within a deployment. Other jurisdictions can be scoped on request, subject to the data and rules each one requires.

Can Ripple assign ECCNs alongside the tariff code?

Yes, where export control classification is in scope. Ripple can propose an ECCN under the US Export Administration Regulations alongside the tariff code, with supporting reasoning for specialist review. Licence determination, and destination, end-user and end-use screening, are separate requirements that are scoped and owned explicitly. The final export control decision rests with the client's designated compliance owner.

How does Ripple integrate with CargoWise?

Ripple connects to CargoWise as a system-to-system workflow integration, scoped by workflow and direction of data flow. Inbound, CargoWise can send document packs to Ripple for a job. Outbound, the classification, duty and line-item fields returned to CargoWise, and the records they update, are agreed and acceptance-tested for each deployment. Items awaiting review remain in the Ripple user interface until a reviewer approves them.

How does Ripple handle products that ship to multiple jurisdictions?

Each jurisdiction is maintained as a separate classification context. A product shipped to the US, UK and Brazil has three separate classification records: a 10-digit HTS number, a 10-digit UK commodity code and an eight-digit NCM code. Each is classified under that jurisdiction's rules and stored with its own duty information, audit trail and update history.

How should organisations prepare for HS 2028?

HS 2028 enters into force on 1 January 2028. Each country will transpose the new six-digit codes into its own tariff, and the deeper national splits may differ. Ripple can help identify catalogue items affected by the change, propose mappings using the WCO correlation tables and route ambiguous items for specialist review. How approved changes reach connected ERP and customs systems, and whether those updates are automatic or reviewed, is agreed within the integration scope.

What audit documentation does Ripple produce?

For each classified line item, Ripple can retain the source document, the classification reasoning, the confidence score, the identity of any human reviewer, the time of review and a record of later updates. This documentation supports an importer's own evidence of reasonable care and compliance review. It does not replace the importer's or declarant's responsibility for the classification declared.

How quickly can a multinational deployment go live?

Timelines depend on source data, integration access, review configuration, testing and enterprise approval. Because Ripple's document ingestion does not rely on a fixed template for each document layout, setting up extraction is usually a smaller part of the work than integration and acceptance testing. Multinational deployments are scoped by jurisdiction and entity, with each entity's catalogue, review rules and system connections agreed in advance. Ripple and the client team agree their respective implementation responsibilities before committing to a schedule.

Talk to Ripple about HS code classification

If your team manages classification across the US, UK or Brazil, or needs approved codes to reach CargoWise, ERP or asset management systems under clear review controls, Ripple can scope a classification workflow around your catalogue, jurisdictions and systems.