What exactly is centralised customs data?
Centralised customs data means that all information required for an accurate declaration is held in one place and is always up to date. This includes goods descriptions, HS tariff codes, countries of origin, invoice values, weights and packaging details. Today, most companies have this data scattered across multiple locations: the goods description in the ERP, the invoice value in a PDF from the supplier, the origin in an email from the purchasing department and the tariff code in the head of the most experienced declarant. Centralised customs data means that all these flows converge in one system that serves as the single source of truth. Not as a copy-and-paste exercise repeated every time, but structurally, linked to the source.
Which data flows need to converge for an accurate declaration?
A customs declaration is the sum of multiple data sources that almost never come from the same system. The goods description and article number are in the ERP or WMS. The invoice value and delivery condition (Incoterm) are on the commercial invoice, which arrives as a PDF or email attachment. The tariff code is derived from that description: it requires knowledge and consistency. The country of origin appears on the certificate of origin or the packing list. Freight documents (CMR, bill of lading) contain the quantities and weights. When each of these flows exists in isolation, a declarant re-enters the same data multiple times from different sources. Every re-entry step is an opportunity for error. A single incorrect figure in the statistical value or a wrong tariff code can result in a hold, a fine or a post-clearance demand.
Where does it go wrong in practice with fragmented customs data?
The most common problem is the combination of time pressure and manual look-up work. A shipment needs to move, the declaration must be ready, and the declarant is still searching three systems for the correct origin or invoice value. Under pressure, assumptions are made: the same tariff code as last time, the same value as on the packing list. That approach works until it does not. A second problem is inconsistency over time. When tariff codes are entered manually for each declaration, variations emerge for the same article. During an audit or customs inspection, that is precisely the kind of inconsistency that raises questions. A third problem arises with volume. A freight forwarder processing dozens or hundreds of shipments per day cannot keep track of this manually. The margin for error grows in proportion to volume.
Can customs declarations be automated when data is centralised?
Yes, but automation depends entirely on the quality of the underlying data. A system that prepares declarations automatically needs reliable input: a correct tariff code per article, a recorded origin, a fixed link to the invoice value. When that data is centralised and structured, software can largely compile the declaration without the declarant re-entering everything. The declarant reviews and approves, but no longer types data over manually. That is the model: human in the loop. The person decides and is responsible; the software handles the look-up and data entry. Without centralised customs data, this model cannot be built. Automation is not the problem in that case; data fragmentation is.
How does an integrated software layer solve this?
An integrated software layer connects the existing sources (ERP, WMS, TMS, document flows) and brings the relevant data together in one workflow. Incoming documents such as invoices and packing lists are read automatically and enriched with the tariff code and origin data already on record for that article. Discrepancies are flagged, not silently accepted. The declarant sees one complete screen instead of four separate systems. This is not a theoretical model: it is exactly what a well-built customs system does when it is designed around domain-specific logic. A generic ERP or standard TMS does not have this built in, because customs is a specialism with its own logic. The choice then becomes: build custom functionality on top of the existing system, or replace the core system with one that puts customs logic at the centre. Both paths are viable; the right choice depends on the degree of fragmentation and the volume.