How trade preference processing is set up in finance and ERP systems

Trade preference processing usually sits in a global trade module linked to the ERP. Master data holds product classifications and agreement rules. Supplier origin declarations are collected and stored. A calculation checks each finished item against the rules of origin, and the result feeds sales documents and import claims.

Where it lives in the system landscape

Most companies run preference logic outside the core ledger. A dedicated trade compliance application, or a trade module bolted onto the ERP, does the heavy lifting. The ERP remains the source for materials, bills of materials, vendors, customers and transactions. The trade system replicates what it needs, performs the origin work and writes results back.

Finance cares because preference status changes landed cost and duty expense. It also creates a liability if a claim turns out to be wrong. That is why the process often reports into finance even when a customs or supply chain team does the daily work.

The master data underneath

Nothing works without clean product data. Each item needs a tariff classification for the relevant customs territories. Agreements are set up as objects in their own right, each carrying its rules of origin by tariff heading. Those rules might require a change of tariff classification, a minimum regional value content, a specific manufacturing step, or some mix.

Bills of materials matter here, but not always the production version. Many teams maintain a separate costing or origin view of the BOM, because the engineering structure includes phantom items and alternates that confuse the calculation. Cost values come from the costing run in the ERP, and the trade system needs to know which cost basis an agreement accepts.

Plants, vendors and customers carry country attributes that decide which agreements can apply at all.

Collecting supplier declarations

Purchased components only count as originating if the supplier says so in writing. The system usually generates solicitation requests to vendors, either by email or through a supplier portal. Responses are recorded against the vendor and material combination, with the agreement and validity window attached.

Missing or expired declarations are the most common reason a product fails. Good setups treat an unanswered request as non-originating by default and flag it for follow up. Where one material comes from several vendors, the system has to decide how to aggregate. The cautious approach is to treat the material as originating only when every active source has declared it.

Running the origin determination

The calculation walks down the BOM, checks each component's status and applies the agreement rule for the finished good's tariff heading. Value rules compare non-originating content against the price or cost. Tariff shift rules check whether each foreign input changes classification enough.

This usually runs as a scheduled batch, with ad hoc runs when a BOM or sourcing change happens. Results are stored per product, plant and agreement, along with the evidence used. Some companies also issue their own long-term declarations to customers from these results.

Using the result on both sides of the border

On exports, the preference result flows to billing or delivery documents. The system prints the origin statement on the invoice, or prepares the certificate the customs authority or chamber requires. Customs brokers receive the status through the export declaration interface.

On imports, the logic is reversed. The purchasing or inbound team needs the supplier's proof of origin before the goods clear, so the broker can claim the reduced rate. The trade system holds those documents and matches them to the import entry. Finance then sees the lower duty in landed cost and in the duty accounts.

Controls and audit trail

Customs authorities can verify origin claims well after the shipment. The system must keep the BOM version, cost data, supplier declarations and calculation output exactly as they stood on the date of the claim. Overwriting history is the classic failure.

Typical controls include approval before a product's status flips to originating, periodic review of declaration coverage, and a reconciliation of claimed preference on import entries against documents actually held. Some teams add a duty savings report, which helps justify the effort but should not be confused with proof of compliance.

Questions to ask the people who run it

• When a supplier never replies, what actually happens to the product's status?
• Which BOM does the calculation read, and who keeps it aligned with what the plant builds?
• Are origin statements ever typed onto invoices by hand outside the system?
• How do brokers learn that an import qualifies for a lower rate, and what do they do when the proof is late?
• Who reruns the determination after a sourcing change, and how do they hear about it?
• If a customs audit asked for the evidence behind an old shipment, where would it come from?
• Are any agreements claimed that are not configured in the trade system at all?
• Who owns the tariff classifications, and are they reviewed when the customs tariff changes?
• Has a claim ever been corrected or repaid, and how was it booked?

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.