How customs communication is set up in finance and ERP systems

Customs communication is usually handled by a trade compliance module or a separate trade tool connected to the ERP. Product master data supplies tariff codes and origin. Shipments trigger electronic declarations, sent directly or through a broker. Duties and import taxes post to dedicated ledger accounts.

Where it sits in the system landscape

Few ERPs talk to customs authorities natively. The common pattern is a trade layer that sits between logistics and the authority's electronic gateway. Sometimes it is an add-on from the ERP vendor. Often it is a standalone product, or simply the broker's own portal.

The ERP remains the source for orders, deliveries and invoices. The trade layer pulls those documents, enriches them with classification and valuation data, and builds the declaration. Messages from customs come back the same way: acknowledgements, release notices, queries, and assessments of duty owed.

When a broker files on the company's behalf, the integration is frequently thinner than people assume. A shipping document goes out by file transfer or email. A finished entry comes back as a PDF, plus a broker invoice.

Master data that drives every declaration

Most customs problems start in the item master. Each material needs a tariff classification for every country it moves into, a country of origin, and a customs value basis. Preferential origin under trade agreements is a separate attribute, and it has to be supported by supplier declarations kept on file.

Business partner records matter too. Importer and exporter registration numbers, authorised economic operator status, and any deferment or guarantee accounts are stored against the legal entity or plant.

Ownership of this data is rarely clean. Classification may belong to a trade specialist while engineering changes the product without telling anyone.

How declarations and responses travel

On exports, a delivery or goods issue usually triggers the declaration. The system holds the shipment until a movement reference or clearance number comes back.

On imports, the trigger is often the advance shipping notice or the supplier invoice. Release from customs may update the inbound delivery status so the warehouse can receive.

Queries and holds are the weak point. Customs may ask for documents or challenge a value. Those exchanges tend to live in mailboxes and broker emails, outside any system, with no link back to the original order.

Paying duties and recording them

Duty and import VAT arrive through a few routes. A deferment account may be debited by the authority directly. A broker may pay and recharge through an invoice. A courier may collect at delivery.

Each route needs its own posting logic. Broker invoices are handled as ordinary supplier payables, matched where possible to the entry and the related purchase order, and held when they fail validation. Recoverable import VAT goes to a tax account. Non-recoverable duty is often capitalised into inventory cost through landed cost conditions, though some companies expense it.

The chart of accounts should separate duty, recoverable import tax, broker fees and penalties. Mixing them makes later reconciliation painful and hides the true landed cost.

Reconciliation and audit support

The authority's monthly statement of duty charged should be reconciled against what the ledger recorded. Differences usually trace back to amended entries, broker recharges posted to the wrong period, or duty paid twice through both a broker and a deferment account.

Auditors and customs inspectors both want the trail: declaration, commercial invoice, proof of origin, payment. Keeping those linked to the ERP document number saves weeks of hunting during a review. Findings from customs audits often lead to post-clearance amendments, which then need their own correcting entries.

Questions to ask the people who run it

What the process documentation says and what the clearance team actually does often diverge. These questions tend to surface the gap:

• Who decides the tariff code for a new item, and where is that decision recorded?
• When customs raises a query, where does the conversation happen and who keeps the reply?
• Does the broker receive data from the system, or does someone retype it?
• How are broker invoices matched to entries, and what happens when one cannot be matched?
• Which duty payments bypass purchasing entirely?
• Who checks the monthly duty statement against the ledger, and how often does that check actually get done?
• When a product changes, who tells the trade team?
• Are there spreadsheets that hold origin or valuation data the system does not?
• What workaround is used when a shipment is held at the border and the warehouse needs stock?

The spreadsheet answer is usually the most revealing.

Where setups tend to drift

Over time, trade tools and ERP master data fall out of sync. New plants get added without registration numbers. Brokers change and the old mapping stays in place. Landed cost conditions are switched off during a migration and never restored.

Anyone redesigning the process should check those integration points first. Fixing them tends to matter more than any change to the declaration workflow itself.

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.