Aggregate Shipment and Trade Data Before Your Reporting Window Closes

Because a supply chain is only as consistent as the records describing it, and those records live in systems that were never built to agree. The same movement recorded in a transportation management system, a warehouse management system, and a carrier's own feed will carry different keys and different field names, so any consolidated view has to reconcile them before it can be trusted. The scale of that problem is on public record: the US Department of Transportation's Bureau of Transportation Statistics built a Freight Data Dictionary of over 6,300 data elements and 13,300 glossary terms purely to reconcile inconsistent definitions across freight data sources (US Department of Transportation, Bureau of Transportation Statistics). Integration is what turns those separate records into one dataset that operational reporting, planning, and customs filing can all read from.

Supply chain visibility is the ability to see the current state and the history of goods, orders, and shipments across every system and partner involved, rather than one system at a time. It matters because the gaps between systems are where delays, duplicate records, and disputed numbers hide. The World Bank found that on average 44 days pass between a container entering the exporting country's port and leaving the destination port, accounting for 60% of total international goods-trade transit time (World Bank, Logistics Performance Index, 2023) — a long stretch in which shipment records, carrier updates, and customs documents can drift out of agreement. In practice, visibility is a data-integration outcome: it exists when the underlying records are consolidated and refreshed on a known schedule, and it stops existing the moment they are not.

A transportation management system is the software a shipper, carrier, or logistics provider uses to plan, execute, and track the movement of freight — rating and routing shipments, tendering loads to carriers, handling documentation, and recording what happened to each movement. It usually sits alongside a warehouse management system, which records what physically entered and left the facility, and the two hold overlapping records of the same shipment under different keys and different field names. Integrating a TMS with a WMS is a separate job from running either one: it means reading both as source systems, aligning the field definitions that differ between them, and producing one dataset that reflects the transport view and the warehouse view of the same event. Neither system has to be replaced or migrated for that to work.

Electronic Data Interchange is the exchange of structured business documents between trading partners in an agreed machine-readable format, rather than as email attachments or PDFs. In logistics it carries the documents freight actually moves on — despatch advices, invoices, shipment status updates, and customs declarations — between shippers, carriers, brokers, and border authorities. The international syntax behind much of it is UN/EDIFACT, maintained by UN/CEFACT under UNECE and standardized as ISO 9735, with message types such as DESADV for despatch advice and CUSDEC for customs declarations. For a data team the practical issue is that an EDI message is a document rather than a table, so it has to be parsed and standardized before it can be joined to anything else.

EDI works by fixing the structure of a document in advance so two systems can exchange it without a person reading it. The sending system maps its internal fields into a standard message format — UN/EDIFACT and ANSI X12 are the two common families — and transmits it over an agreed channel such as AS2, SFTP, or a value-added network. The receiving system parses that message back into its own fields and returns an acknowledgement, so both sides know the document arrived and was readable. Almost everything difficult about EDI in practice lives in the mapping: two partners using the same standard can still populate optional segments differently, which is why each new partner usually needs its own mapping rules rather than a shared one.

In trucking, EDI is how load tenders, tender responses, status updates, and freight invoices move between shippers, brokers, and carriers without phone calls or re-keying. It is still in active use in 2026 rather than a retired technology: APIs have grown alongside it for real-time quoting and status, but the document-of-record exchange with large shippers and retailers is commonly still EDI, and many partners require it as a condition of being tendered freight. The practical position for most carriers is that both matter — EDI for the partners who mandate it, APIs where a partner offers one, and one integration layer underneath so the data lands in the same place regardless of how it arrived.

It refers to the EDI requirements a retailer or a border authority imposes as a condition of trading with them: specified document types, specified data elements, specified timing, and penalties when a document is late or malformed. On the retail side that usually means advance ship notices, purchase order acknowledgements, and invoices in an agreed format, with chargebacks attached to non-conformance. On the customs side the equivalent is a structured declaration such as a UN/EDIFACT CUSDEC filed into a national system like the US Automated Commercial Environment single window or the EU Single Window Environment for Customs. Meeting either is a data-quality problem before it is a transmission problem — the message has to be complete and internally consistent before it is worth sending.

Carrier integration is the work of connecting each carrier's data channel — EDI, an API, or a scheduled file drop over FTP or SFTP — into your own systems, so rates, tenders, tracking events, and invoices arrive in one consistent structure. The difficulty is rarely the connection itself. It is that every carrier names and formats the same information differently, so each one needs its own mapping rules before its data can be compared with any other carrier's. Handling that mapping inside a pipeline rather than per report means adding a carrier becomes a configuration change on something that already runs, and the carriers already connected keep running while the new one is added.

Trade compliance is the practice of meeting the legal requirements attached to moving goods and their data across borders — correct classification and valuation, accurate declarations filed into the right national system, screening obligations, and record-keeping. Two separate obligations usually apply to the same shipment record at once. The first is the customs and trade-document shape: the WCO SAFE Framework and WCO Data Model, UN/EDIFACT message types, and national filing systems such as the US Automated Commercial Environment and International Trade Data System, or the EU Single Window Environment for Customs under Regulation (EU) 2022/2399. The second applies when consignee or shipper personal data crosses a border, which brings in GDPR Chapter V as interpreted by EDPB Guidelines 05/2021 and, for US sensitive personal data, the Department of Justice Data Security Program that took effect in April 2025 — which is also why where the data is stored, and who can reach it, becomes part of the compliance question rather than a separate IT decision.