How to read a UN/LOCODE, and why it matters on your paperwork

The structure: two letters, then three characters

A UN/LOCODE is exactly five characters, split into two parts. The first two letters are the ISO 3166-1 alpha-2 country code: NL for the Netherlands, TH for Thailand, KE for Kenya. The remaining three characters identify a specific location inside that country. They are usually letters but can include digits, and the maintaining body (the United Nations Centre for Trade Facilitation and Electronic Business, UN/CEFACT) assigns them without a fixed pattern tied to the name, so the three characters are close to arbitrary from the outside. Rotterdam is NLRTM. Bangkok is THBKK. Mombasa is KEMBA.

Because the three-character block carries no inherent meaning, you cannot derive a code from a place name with confidence, and you cannot infer a place name from a code you don't recognise. NLRTM reads as Rotterdam because everyone in the trade has memorised it, not because the letters spell out anything. Treat every code as an opaque identifier to be looked up, not decoded.

The full standard record carries more than the code: a location name, subdivision, and function classification sit alongside it in the reference data. Most shipping documents only ask for the five characters, which is exactly why the function classification, covered next, matters so much and is so easy to skip.

A LOCODE names a location, not a seaport

This is the point that causes real damage. The UN/LOCODE system was built to identify locations used in trade and transport generally, not seaports specifically. The same five-character namespace covers seaports, airports, inland river or rail terminals, road checkpoints, and postal and inland clearance depots. Each location record carries a function code, a short classifier noting whether the location has port, airport, rail terminal, road terminal, or inland clearance depot functions, but that classifier lives in the reference dataset, not in the code string itself, and it does not appear on the document field where you type the code.

A country can have a landlocked inland container depot and a coastal seaport that share the same city name, sit in the same country, and produce codes that look equally plausible to someone scanning a list without checking the function field. If your freight forwarder or your own staff pick the wrong one when filling in the booking, the carrier's system routes the container to whichever facility the code actually identifies. An ocean booking built against a code that resolves to an inland rail terminal, rather than the seaport gate that terminal feeds, does not get silently corrected by the carrier: it either bounces the booking or, worse, gets accepted and creates a drayage leg nobody planned or paid for.

The practical rule: when you pull a code from a reference list, glance at the function classification before you use it, not just the name. A location record showing only rail or road terminal function is not a seaport, whatever the city name suggests.

Where the code appears on your paperwork, and what a mismatch costs

The code shows up in more places than exporters usually track. A freight booking carries it in the port of loading and port of discharge fields. The bill of lading repeats it, sometimes in a structured field and sometimes embedded in the free-text port name the carrier's system generates from the code. A customs declaration uses country and location codes in the consignment fields that customs risk-scoring systems read directly, and an export declaration that names one location while the actual conveyance departs from a different one creates a mismatch a customs system can flag even when the underlying shipment is entirely legitimate. A phytosanitary certificate issued by the exporting country's plant protection authority typically names the point of exit, and if that point of exit code does not match the port of loading on the bill of lading, the receiving country's inspector has grounds to question the certificate's validity on the load that actually arrives.

Consider a worked example. A packhouse in Kenya books a reefer container through Mombasa. The freight forwarder's booking system defaults to a code that resolves to an inland container depot outside the city rather than the seaport terminal itself, because both carry KE codes with similar-looking third characters and the depot code was the one saved from a prior domestic move. The booking confirmation looks fine: correct country, correct city name in the generated text. The bill of lading, generated from the same booking data, inherits the same code. Customs clearance at the border proceeds on the declared location. It is only when the phytosanitary certificate, issued separately by Kenya's plant health authority and citing the actual seaport of exit, is compared against the bill of lading by the importing country's inspector that the mismatch surfaces, at the port of arrival, after the goods have already crossed an ocean.

The cost of that kind of mismatch is rarely a formal rejection outright. More often it is a hold for document reconciliation, a request for a corrected certificate or an affidavit explaining the discrepancy, and a demurrage clock that starts running on the container while the paperwork gets sorted. For perishable agri-food cargo, the hold itself can be the loss even before any question of whether the shipment is refused.

One port, several codes: multi-terminal complexes

Large port complexes sometimes split across more than one UN/LOCODE. Where a metropolitan port area has grown to include a separate deep-water terminal, satellite port, or a distinct administrative area some distance from the historic city core, the two facilities can carry separate codes rather than sharing one. This is not universal, most port cities keep a single code covering the whole complex, but it is common enough among major container gateways that assuming one code per port name is a mistake worth pricing in.

The operational consequence is straightforward: quoting the wrong one of two valid codes for the same broad port area can point a booking at a terminal your cargo has no relationship with, with its own gate hours, its own customs post, and its own trucking access. Freight forwarders who work a lane regularly know which of the two codes matches which physical gate; exporters who book occasionally, or who inherit a code from an old template, are the ones who get caught. If a port name you're booking against has any history of terminal expansion or a second facility under a different name nearby, treat the LOCODE as terminal-specific and confirm which physical gate it points to before the booking is finalised, not after the truck arrives.

Name collisions across countries, and codes that look similar but are not

Because the three-character block is only unique within a country, not globally, the same three letters can appear after different country prefixes and mean entirely unrelated places. That's by design and rarely causes confusion on its own, since the country prefix disambiguates. The real risk is closer to home: two codes that share a country prefix and differ by one character, where an operator scanning quickly reads the country and the first letter and assumes a match.

A useful discipline is to treat the last two or three characters as the part that actually needs checking, since the country prefix is the part everyone already gets right. A code like KEMBA (Mombasa, Kenya's main seaport) and a similar-looking code for a smaller inland Kenyan location sharing the KE prefix and an overlapping first letter are exactly the kind of pair a tired data-entry pass will not catch on a visual scan. The fix is not memorising more codes, it's not trusting a visual scan for anything that goes on a legal document. Look the code up against the location name in the reference list every time, rather than pattern-matching against a code that looks about right.

How codes change, and the verification habit that prevents the error

UN/CEFACT publishes updates to the LOCODE list on a recurring cycle, adding newly requested locations, and occasionally retiring or renaming an existing entry when a location's status changes. A code that was current when your freight forwarder built a booking template two or three years ago is very likely still valid today, changes to established major ports are uncommon, but the list is not frozen, and smaller or newer locations are exactly where an update is more likely to land unnoticed. A code sitting in a saved template, a customs broker's macro, or a spreadsheet of standard shipping instructions is a static snapshot of a dataset that is not static.

The habit that closes this gap costs one lookup per new location, or per document set for a lane you haven't shipped on in a while: check the code against the current published UN/LOCODE list at the point you're building the document, rather than trusting a saved template, a previous shipment's paperwork, or memory. For a lane you ship every week, that discipline is unnecessary friction, the code isn't moving. For a first-time lane, a new customer's port, or any port complex with multiple facilities, it is the five minutes that keeps a phytosanitary certificate, a bill of lading, and a customs declaration all pointing at the same physical gate.