The shipping data standards that actually exist, and what they leave out

Your container data arrives from a dozen places. There is the carrier’s website, the forwarder’s spreadsheet, an email from the terminal, a scan of the phyto from the exporter, a WhatsApp from the haulier. The natural conclusion is that shipping has no data standards. It has plenty. It has three generations of them stacked on top of each other, and each one covers one slice of the chain. Once you know which slice is which, you know where your data will be clean and where it will always be a PDF.

This guide goes through them in the order they were built. Then it puts them on one map, party by party, so you can see where the gaps are.

The one thing everyone agrees on: the container number #

Every standard in this guide refers back to one identifier, and it is older than all of them. ISO 6346 defines the container number: three letters for the owner, one letter for the kind of equipment, six digits of serial number and one check digit. MSKU, CSQU, TCLU are owner codes, registered with the Bureau International des Containers (BIC) in Paris. The fourth letter is U on every freight container you will ever import. J marks equipment attached to a container, such as a clip-on generator set, and Z marks a trailer or chassis.

The check digit is what makes the number safe to retype. Each letter is given a value, starting at A = 10 and skipping 11, 22 and 33. So A is 10, B is 12, C is 13 and U is 32. Each digit keeps its own value. The ten characters are multiplied by 1, 2, 4, 8 and so on, doubling each time, and the results are added together. Divide the total by 11 and the remainder is the check digit, with a remainder of 10 written as 0.

The results add up to 6,185. Divide by 11 and the remainder is 3, so the full number is CSQU3054383. Swap the 5 and the 4 and the check digit becomes 1. Type an 8 for the 4 and it becomes 7. Either way the number no longer checks, and any system that knows the rule rejects it before it looks anything up.

That matters more than it sounds. A booking number or a bill of lading number is whatever format the carrier chose, and nothing in it tells you it was mistyped. You find out when the lookup returns nothing, or returns somebody else’s box. The container number is the one reference in the chain that checks itself, which is why every system in this guide keys on it.

The same standard carries the size-and-type code painted beside the number. The first character is the length: 2 for 20 feet, 4 for 40 feet. The second is the height: 2 for 8'6", 5 for a 9'6" high cube. The last two are the type.

Note the trap in that table: 45 means a 40-foot box that is 9'6" high, not a 45-foot one. The outside dimensions themselves come from a companion standard, ISO 668: a width of 2,438 mm for every box, and a height of 2,896 mm for a high cube.

The first generation: EDIFACT (built in the 1980s, still running everything) #

The messages that move your container between carriers, terminals and customs were mostly designed before the people now reading them were at work. UN/EDIFACT became an ISO standard, ISO 9735, in 1987. It is the format behind what the trade calls EDI, and nearly every container movement in the world still passes through it at some point.

An EDIFACT message is a string of segments. Each segment starts with a three-letter tag and ends with an apostrophe. Inside a segment, + separates the fields and : separates the parts of a field. A simplified fragment of a status message looks like this:

UNH+1+IFTSTA:D:99B:UN'
EQD+CN+CSQU3054383+45R1'
LOC+11+NLRTM:139:6'
DTM+178:202609141030:203'
UNT+5+1'

A reader can decode it without a manual. EQD is the equipment: a container (CN), its number and its size-and-type code. LOC+11 is the place of discharge, given as a UN/LOCODE, here Rotterdam. DTM+178 is an actual arrival time. UNT closes the message and counts its segments.

This structure is why the format is fast for machines and unforgiving to people. Every character has a position. An apostrophe in a consignee’s name, as in “O'Neill Fresh”, ends the segment early unless it is escaped with a ?. A segment count that is off by one makes the receiving system reject the whole message. Nobody types EDIFACT by hand; it is generated by one system and read by another.

These are the messages your container passes through, whether or not you ever see one:

UN/CEFACT, a United Nations body, maintains the message definitions. The terminal messages (COPRAR, COARRI, CODECO and BAPLIE) have implementation guides maintained by SMDG, a group of carriers and terminals. Customs authorities increasingly publish their own XML formats instead of CUSDEC, but the shape is the same: a fixed declaration sent to a government system.

IFTSTA deserves a sentence of its own, because it is the ancestor of every tracking event you have ever seen. “Gate in”, “loaded on vessel” and “discharged” were IFTSTA status codes long before they were lines on a carrier’s website.

The point for an importer is simple. These messages work, they are not going away, and they are plumbing between carriers, terminals and customs. You are almost never a party to them. A large importer can take a direct IFTSTA feed from a carrier, but it is a project, not a setting. So what reaches you is the output of EDIFACT, turned into an email by somebody else.

The second generation: DCSA and the API layer (2019 onwards) #

EDIFACT connects companies that have agreed, one pair at a time, to send each other messages. That works between a carrier and a terminal that talk every day. It does not work for a customer who wants to ask “where is my container?” once, from their own system, without a six-month project.

The Digital Container Shipping Association (DCSA) was set up to fix that. It was announced in April 2019 and had nine carrier members within weeks: MSC, Maersk, CMA CGM, Hapag-Lloyd, ONE, Evergreen, Yang Ming, HMM and ZIM. PIL joined as a partner in 2024. DCSA is a non-profit, and it says plainly that it is not a technology platform. It publishes standards, free to anyone, and each carrier builds its own systems to meet them.

That choice was deliberate. At the time, Maersk and IBM were running TradeLens, a shared platform for shipping data. Other carriers were reluctant to put their customers’ data on a platform run by a competitor. In November 2022 Maersk announced that TradeLens would close, because full industry collaboration had not been achieved. It went offline in early 2023. DCSA’s model, a common language with no common database, is the one that survived.

DCSA standards are APIs rather than messages. An API is a published way for one computer system to ask another a question and get a structured answer, over the internet, on demand. Any customer with credentials can use one, with no project on either side. This, more than the format, is the real difference from EDIFACT.

Track & Trace: the box and the vessel, not the cargo #

Track & Trace (T&T) is the DCSA standard closest to an importer’s daily work, and the oldest. The current release is version 2.2, published in October 2021. A version 3.0 was on DCSA’s 2026 roadmap, but no public release had appeared by September 2026.

T&T reports three kinds of event:

• Shipment events follow the paperwork. Shipping instructions received, a draft bill of lading issued, a document approved, a customs hold or release.
• Transport events follow the vessel. It arrives at or departs from a port call, with a reason code when it is late.
• Equipment events follow the container. Gate-in, loaded, discharged, gate-out, stuffed, stripped, each one keyed on the container number.

Each event also carries a classifier: planned (PLN), estimated (EST) or actual (ACT). This is more useful than it sounds. A vessel arrival marked EST that keeps changing is your ETA moving. The same arrival marked ACT is a fact. A tracking page that shows you both without the label is hiding the one thing you need to know about the time.

The standard defines two ways to get events. In the pull model, your system asks the carrier for new events as often as it likes. In the push model, you subscribe once and give the carrier an address, and the carrier sends each new event to it as it happens. Push is much better for an importer: you learn about a discharge within minutes, and nobody has to ask about forty containers every hour. But the standard makes push optional. Hapag-Lloyd’s and CMA CGM’s developer portals, for example, say their T&T APIs offer pull only. A carrier can say “we support DCSA Track & Trace” and still not send you anything unless you ask.

The scope limit is the one to understand before you buy anything built on T&T. It tracks the box and the vessel, not the cargo. No event in the standard refers to a pallet, a lot, a case or a temperature in the fruit. “Discharged at Rotterdam” tells you the container came off the ship. It does not tell you what is inside or what state it is in.

The reefer extension #

This is the part of DCSA almost nobody has written about, and the part a produce importer most needs to understand.

DCSA published Reefer Commercial Events 1.0, calling it an extension to Track & Trace, as a beta in March 2023. It adds one kind of event with two types. A measured event (MEAS) reports readings from the reefer unit. An adjusted event (ADJU) records that somebody changed the setpoint. The standard defines these readings and settings:

The oxygen and CO2 fields matter for controlled atmosphere shipments, where the gas mix is part of the cargo care. A companion standard, IoT Commercial Events, also a beta from March 2023, carries events that a device on the container detects.

Three things are missing, and all three matter in a claim. The standard has one temperature field, not separate supply-air and return-air readings, which is how a reefer’s own log records it. It has no event for a power-off, which is the first thing you want to know about a warm load. And it has no alarms. What it gives you is a shared format for the data that reefer telematics already collect, not a replacement for the unit’s full download.

Two more limits. First, no carrier is certified for the reefer extension on DCSA’s conformance page. Carriers that sell live reefer data sell it as their own product, such as Hapag-Lloyd’s Live Reefer or Maersk’s Captain Peter. It comes in their own format, and often at a price. Second, even a perfect feed reports the air in the container, not the temperature inside the fruit. That is the difference between setpoint and pulp temperature, and no shipping standard closes it.

Electronic bill of lading #

The bill of lading is the one shipping document that is also a document of title: whoever holds the original controls the cargo. That is why it has stayed on paper for so long, and why it is where paper costs an importer most directly. An original that arrives late holds the container at the terminal while free time runs, and then demurrage starts.

DCSA’s Bill of Lading standard, version 3.0, was finalised at the end of 2024. In February 2023 the CEOs of all nine member carriers committed to issuing 50% of original bills of lading electronically within five years, and 100% by 2030. The starting point was 1.2% in 2021. DCSA reported nearly 5% in the first half of 2024 and about 11% in 2025.

The limit is legal, not technical. An electronic bill replaces a paper one as a document of title only where the law allows it. The UK’s Electronic Trade Documents Act came into force in September 2023. Thirteen jurisdictions have now adopted the UN model law on electronic transferable records (MLETR), including the UK, France (2024) and China (2025). The FIT Alliance, formed in 2022 by BIMCO, DCSA, FIATA, the ICC and SWIFT, exists to push that legal recognition along. And in June 2026 five eBL platforms adopted a common interoperability annex, so a bill issued on one can be passed to a party on another.

If your trade already runs on sea waybills or telex releases, as much fresh produce does, an eBL changes little for you.

If you still wait for couriered originals, it is the standard that affects your demurrage bill most.

Booking, schedules, arrival notice and port calls #

Booking (version 2.0, finalised December 2024) is the API version of IFTMBF and IFTMBC: request a booking, receive the confirmation. It matters to you only if you book direct with the carrier.

Commercial Schedules (1.0, September 2024) covers point-to-point routings, port schedules and vessel schedules. Operational Vessel Schedules (3.0, January 2024) is the carrier-to-carrier version. These are the most widely implemented DCSA standards, because a schedule is public data that every carrier already wanted to publish.

Arrival Notice (1.0, November 2025) is newer, and more relevant to you than its low profile suggests. The arrival notice is the document that tells a consignee the container is coming, where to collect it and what is owed. The standard gives each of those a field. Free time is listed per type (demurrage, detention or storage), with a duration in calendar days, working days or hours, the containers it applies to, and a last free date. Charges are itemised with a currency, a unit price, a quantity and whether they are prepaid or collect. The notice also carries pickup, return and release information, and the carrier’s bank details.

Two limits apply. Only the issue time and the bill of lading number are mandatory, so a notice can meet the standard and still say nothing about free time or charges. And on DCSA’s conformance page only HMM is certified for it so far. For almost everyone, the arrival notice still arrives as a PDF.

Port Call (2.0, December 2025) replaced the earlier Just-in-Time Port Call standard. It lets carriers, terminals and port authorities exchange arrival timestamps so that ships slow down at sea instead of waiting at anchor. It is vessel-side plumbing. You will see its effect as fewer ships at anchor, not as data.

What is coming in 2026 #

DCSA’s 2026 roadmap includes two new standards. Dangerous Goods Declaration was scheduled for an alpha in July and a beta in September. Invoicing was scheduled for an alpha in September and a beta in November. The roadmap names “layered surcharges, demurrage rules, and varying tax structures” as the problem it has to solve. Work on a Shipment Release standard also began in June. Roadmap timings slip. By 18 September 2026 neither standard had a public draft: DCSA’s API catalogue and its standards pages listed neither.

Invoicing deserves attention. Surcharges and demurrage are where importers lose money without noticing, because the invoice is a PDF with a total and the checking is done by hand. An invoice with every charge in a standard structure could be checked automatically against the contract and the container’s actual events. That standard does not exist yet even as a public draft, and carrier adoption would come years after one. Until then, disputing a demurrage invoice is manual work.

Who has actually implemented what #

DCSA publishes a conformance page showing which carriers are certified for which standard. Here it is as we read it on 18 September 2026 (the page itself carries no date):

Read it carefully. A mark means the carrier is certified, not that the service is live for customers. An empty cell means no certification is listed, not that nothing exists. MSC and Hapag-Lloyd both offer DCSA Track & Trace APIs on their developer portals without appearing in that column. Maersk’s catalogue lists a product called “Ocean Track & Trace Events Webhook [DCSA]”, and Maersk says all its APIs follow DCSA standards. The eBL column combines several modules: issuance and surrender are the ones most carriers have.

Can a small importer get direct access? #

Mostly yes, with one condition that decides everything. Every carrier we checked gives API access to its own customers, and most will register a small company. But the tracking data is for shipments where you are a named party. CMA CGM releases its private events to the booking party, shipper, consignee or notify party. Hapag-Lloyd describes its API as covering “shipments booked with Hapag-Lloyd”. If your forwarder books in its own name and issues you a house bill of lading, you do not appear on the carrier’s booking at all. Then you get the carrier’s data through your forwarder, or through a visibility provider that tracks by container number.

The standards that are not DCSA, but touch you more than DCSA does #

DCSA covers what carriers know. A good deal of what decides whether your fruit gets released is known by governments instead, and those formats carry legal weight.

ePhyto: the certificate that decides whether your fruit is released #

For fresh produce, the most important data standard is not a shipping standard at all. It is the electronic phytosanitary certificate, exchanged through the IPPC ePhyto Hub. The IPPC is the International Plant Protection Convention. Its hub opened in June 2018, and it passes certificates from the plant health authority of the exporting country to the authority of the importing one. A country without its own system can use GeNS, a free web system the IPPC released in July 2019.

The EU joined early. TRACES, the EU’s system for plant and animal health checks, connected to the hub in May 2020 and is the single entry point for all member states. An ePhyto that arrives there can be copied straight into the CHED-PP, the document your broker or you lodge for the border check. Under EU plant health rules, an electronic certificate is valid only if it comes through TRACES.

The global numbers are large. The IPPC reports 150 countries connected to the hub and 102 actively exchanging certificates, with about 3.5 million certificates exchanged in 2025. The IPPC’s own count of hub traffic from December 2024 to November 2025 shows most of the big produce origins in heavy use:

Those counts are certificates sent and received through the hub, to any destination. They do not tell you that a given origin sends ePhytos to the EU. No public list says which pairs of countries exchange electronically. The only reliable answer for your trade is to ask your exporter what their plant health authority issues for your destination. Egypt, China and Vietnam do not appear in the IPPC’s table at all.

Great Britain is the surprise. The UK’s Plant Health Portal lists the only countries that can export to GB using ePhyto, and as of June 2026 it names 23 EU member states and nothing else. Spain was added on 1 June 2026. Every non-EU origin, including Chile, Peru and South Africa, still sends paper into GB. For a UK importer of southern-hemisphere fruit, the original certificate is still a courier envelope, and a late envelope is still a held container.

Hong Kong is the opposite case. Fruit and vegetables imported for consumption need no plant import licence and no phytosanitary certificate at all, so the question does not arise.

Customs filing: fixed formats you are legally responsible for #

Customs systems are not standards in the DCSA sense. Nobody volunteers to adopt them. But each one is a fixed data format, and the importer is on the hook for what goes into it.

EU ICS2. The Import Control System 2 collects entry summary declarations (ENS), the safety and security data customs uses to decide which cargo to check before it arrives. Release 3 brought in sea freight: carriers had to connect between June and December 2024, and house-level filers, meaning forwarders and NVOCCs, by April 2025. The carrier is responsible for the ENS. But data the carrier does not hold, such as the buyer, the seller and a proper goods description, must be filed by whoever does hold it. That can be your forwarder, or you. A description like “fresh fruit” is the kind that gets a query from customs.

UK CDS. The Customs Declaration Service replaced CHIEF for imports on 30 September 2022 and for exports on 4 June 2024. Since 31 January 2025, goods imported from the EU into Great Britain also need a safety and security declaration, lodged in the S&S GB system. Plant health pre-notification for regulated produce goes separately, through IPAFFS.

US ACE and ISF. For readers who also import into the US: ACE is the single window through which all import data reaches US customs. The Importer Security Filing, known as “10+2”, makes the importer file ten data elements at least 24 hours before the container is loaded at origin. The penalty is up to $5,000 per violation.

IMO FAL and the Maritime Single Window #

Since 1 January 2024, every port state party to the IMO’s FAL Convention must run a Maritime Single Window. A ship reports its arrival, stay and departure to one electronic system instead of to each authority separately. That includes the cargo declaration, the crew list, the dangerous goods manifest and the health declaration.

You will never see any of it. It is ship-to-port reporting. It matters to you indirectly. Port authorities now hold arrival and departure data in structured form. That is one reason port data has become easier to get, and more reliable, since 2024.

FIATA eFBL: the forwarder’s bill of lading, digitised #

If a forwarder issues your bill of lading, it is often a FIATA Bill of Lading (FBL), the standard house bill of the forwarding trade. FIATA and UNECE published a data standard for its electronic version in March 2022, and FIATA launched the eFBL service two months later. Each document is registered in a central ledger, and anyone can verify it by scanning its QR code. FIATA now lists more than 70 software partners that can issue one.

The limit is legal rather than technical. An electronic bill of lading can only replace paper as a document of title where the law recognises it. FIATA itself says forwarders may still print an eFBL for that reason.

GS1: where your fruit is, rather than your container #

Every standard so far identifies a container, a vessel or a document. None of them identifies your fruit. That job belongs to GS1, the organisation behind the barcode on every retail product.

Three GS1 identifiers matter here. The GTIN identifies a product, down to the case. The GLN identifies a party or a location, such as a packhouse or a distribution centre. The SSCC is an 18-digit number with its own check digit, and it identifies one logistics unit: in fresh produce, one pallet. Many exporters already print an SSCC on the GS1 logistics label on each pallet, because their supermarket customers require it. EPCIS is the GS1 standard for sharing events about those units, such as “packed”, “shipped” and “received”.

Here is the gap. Nothing in DCSA, EDIFACT or ICS2 links a container number to the SSCCs inside it. The only document that connects “where is the container” to “where is my fruit” is the packing list, and there is no standard for that. It arrives as the exporter’s own spreadsheet or PDF, in the exporter’s own layout.

UN/CEFACT: the vocabulary underneath #

Most of these standards map back to the same reference vocabulary. UN/CEFACT, the UN body that maintains EDIFACT, also publishes the Buy-Ship-Pay reference data model: one agreed definition of each piece of trade data, from “consignee” to “gross weight”. Its multimodal transport subset is what the FIATA eFBL maps to, and DCSA publishes a mapping from its own standards to UN/CEFACT. You will never use it directly. It is the reason these standards can be translated into each other at all.

The gap map #

Put every party in a fresh produce import down one side, and ask three questions of each. Which standard governs its data? Can an importer get that data by machine? And what arrives in practice?

Count the last column. One row out of ten gives you structured data, and only if you are named on the booking. Every other row ends in an email, a PDF, a website or a phone call. This is not because anyone failed to build a standard. EDIFACT covers the terminal rows, and DCSA covers the carrier row. They were built for the parties who exchange data every day, and the importer is not one of them.

That is the argument for a layer on your side that takes in all of these formats and turns them into one record per container. Without it, the reconciling happens in somebody’s head and inbox.

What to do with this #

You cannot change which standards exist. You can change which ones your data comes through, and where you spend effort first.

• Ask your forwarder how they get carrier status. Do they take DCSA Track & Trace or EDI from the carriers, or do they check carrier websites? The answer tells you how fresh their updates can be.
• Ask each carrier whether you can subscribe yourself. Where you have a direct contract or a bill of lading number, some carriers will give you API access. Where they will not, a visibility provider holds the connections for you.
• Get the legal formats right first. The phytosanitary certificate and the customs data carry legal risk, and a mistake holds the container rather than just the spreadsheet. Know which of your origins issue ePhyto for your destination, and who files your ENS data.
• Accept that some of it will stay unstructured for years. No standard brings you terminal notices, haulier updates or chassis bills. Nothing on any published roadmap changes that.

The standards stop at the carrier, the terminal and the government. Everything between them and your own system is a layer you either build yourself or buy.

Glossary of the acronyms #

FAQ #

What is DCSA in shipping? #

The Digital Container Shipping Association, a non-profit set up by nine container carriers in 2019. It publishes free API standards for tracking, bookings, bills of lading and schedules. Each carrier builds its own systems to meet them. DCSA does not run a platform and holds no shipment data itself.

Does DCSA Track & Trace include reefer temperatures? #

Not in the core standard. A separate Reefer Commercial Events extension, still a beta from 2023, adds measured temperature, humidity, oxygen, CO2 and ventilation, and records setpoint changes. It has no supply-air and return-air split, no power-off events and no alarms, and no carrier is certified for it yet.

Can I get tracking data straight from the carrier’s API? #

Yes, if you are named on the carrier’s booking as shipper, consignee or notify party, and most carriers will register a small importer. If your forwarder booked in its own name, you are not on the booking. Then the data reaches you through the forwarder or a visibility provider.

Does the UK accept electronic phytosanitary certificates? #

Only from EU member states. As of June 2026 the UK’s list of countries that can send ePhytos to Great Britain names 23 EU states and no others. A consignment from Chile, Peru or South Africa into GB still needs the paper original.

How is a container number check digit calculated? #

Give each letter a value from A = 10 upwards, skipping 11, 22 and 33, and keep each digit as it is. Multiply the ten characters by 1, 2, 4, 8 and so on, add the results, and divide by 11. The remainder is the check digit, and a remainder of 10 becomes 0.