UN/LOCODE: structure, function codes, status flags

UN/LOCODE, the United Nations Code for Trade and Transport Locations, is a five-character location identifier maintained by the United Nations Economic Commission for Europe (UNECE). First published in 1981 under Recommendation 16, it is the de-facto vocabulary used by customs authorities, shipping lines, freight forwarders, port community systems, and EDIFACT messages worldwide. As of release 2024-2 the directory contains ~116,000 entries across 271 countries and territories, of which roughly 12,000 are active maritime ports. UNECE refreshes the directory twice a year (typically in June or July, then again in December), and individual administrations can request mid-cycle additions or status changes through their national facilitation bodies.

This article is the canonical reference for the code’s anatomy, the eight-position function code system, the twelve-flag approval status taxonomy, the coordinate format and its conversion to decimal degrees, and the role UN/LOCODE plays across the maritime documentation chain (bills of lading, customs declarations, port community systems, AIS, EDIFACT). Anyone working with port automation, freight documentation, vessel scheduling, customs filing, or chartering encounters UN/LOCODE within the first day of any maritime project; understanding the code structure and its limitations saves hours of debugging when a manifest is rejected or a port-call notice routes to the wrong terminal.

For interactive lookup, the UN/LOCODE Decoder calculator lets you paste any code, country code, or location name and returns the full breakdown including function code, status, coordinates, IATA equivalent, and subdivision. The decoder is refreshed monthly against the UNECE master and ships with the maritime subset of approximately 30,000 port, ICD, and fixed-transport entries; the full directory of 116,000 entries (every airport, road junction, postal exchange) is available at unlocode.unece.org/directory.

Historical context and governance

UN/LOCODE traces its origin to the late 1970s when international trade documentation was migrating from paper-and-telex to first-generation electronic data interchange. The pre-existing port codes were vendor-specific: Lloyd’s Maritime Atlas had its own list, IATA covered airports only, individual customs authorities each maintained national tables. The lack of a single canonical port vocabulary meant that an EDI message routed from a forwarder in Hamburg to a customs agent in Yokohama might use three different codes for the same Singaporean terminal.

UNECE convened the first Working Party on Facilitation of International Trade Procedures (now part of UN/CEFACT, the United Nations Centre for Trade Facilitation and Electronic Business) in the mid-1970s to address the gap. Recommendation 16, “UN/LOCODE Code for Ports and other Locations”, was first issued in 1981 and has been revised periodically since; the most recent substantial revision is the 2020 update which clarified the eighth function-code position (border crossing) and aligned subdivision references with ISO 3166-2.

Governance today is split. The structure of the code (the 5-character format, the function-code positional convention, the status-flag taxonomy) is fixed by Recommendation 16 and changes rarely. The content of the directory (which actual locations exist, what their codes are, what functions they support) is updated on a rolling basis by national facilitation bodies who submit additions, modifications, and deletions to UNECE. Each member state nominates a focal point, typically housed in the customs authority or the ministry of transport. Submissions go through review by the UN/CEFACT Bureau before being incorporated into the next biannual release.

This split governance model has implications. The 5-character format is universal: every code worldwide uses the same shape and the same parser handles it. But the data itself reflects the submission discipline of national authorities, which varies. Some countries (Netherlands, Germany, Singapore, Japan) maintain near-perfect coverage of every active port, terminal, and inland waterway location, with fast turnaround on additions. Others lag by years, leaving operational ports that are widely used in industry without a UN/LOCODE entry. The decoder marks these gaps as “no entry” rather than “rejected” because UN/LOCODE absence does not mean the location is illegitimate; it means UNECE has not yet recorded it.

Code structure

A UN/LOCODE is exactly 5 alphanumeric characters, structured as a 2-character country prefix followed by a 3-character location suffix:

SG   SIN
└┬┘  └─┬─┘
country  location

• First two characters: the ISO 3166-1 alpha-2 country code. SG is Singapore, US is the United States, GB is the United Kingdom, IN is India, CN is China, BR is Brazil, RU is the Russian Federation, ZA is South Africa, AE is the United Arab Emirates, KR is the Republic of Korea. The country code uses the ISO 3166-1 alpha-2 standard exactly; UN/LOCODE does not invent new country codes.
• Last three characters: the location code, typically a mnemonic abbreviation of the place name. SIN for Singapore, NYC for New York, LON for London, BOM for Mumbai (the historical “Bombay” abbreviation has been retained by UN/LOCODE despite the city name change), RTM for Rotterdam, HAM for Hamburg, LAX for Los Angeles. When a city has multiple distinct UN/LOCODE entries (a port, an airport, a postal exchange, a rail terminal), each gets its own 3-character location code.

Together: SGSIN (Singapore port-and-airport hub), USNYC (New York / New Jersey port complex), GBLON (London port and airport), INBOM (Mumbai), NLRTM (Rotterdam), DEHAM (Hamburg). The decoder tolerates whitespace, dashes, and case (sg sin, SG-SIN, sgsin all resolve to SGSIN), but the canonical form is always uppercase, no separators.

Country prefix exceptions and special codes

A handful of country prefixes are not standard ISO 3166-1 codes:

• XZ: international waters (used for incidents at sea where no national jurisdiction applies)
• IB: International Baltic (rare; used for Baltic-wide aggregations)
• OY, OT, ED, OI, ZO: legacy or transitional codes for specific historical or edge-case scenarios; many freight forwarders never encounter these

These exceptions are documented in the UNECE country-and-territory code list and are inherited by the decoder.

Location code uniqueness

The 3-character location code is unique within a country but not across the globe. LON is London in the United Kingdom (GBLON) but LON could in principle exist as a Brazilian inland location with a different meaning. The 5-character compound (country plus location) is what guarantees global uniqueness.

When UN/LOCODE adds a new entry, the convention is to derive the 3-character code from the most distinctive consonants and vowels of the place name, with disambiguation suffixes when the obvious code is already taken. Singapore got SIN because SIN was free; a hypothetical second port at “Sintra” (Portugal) might get SNT instead. The historical naming patterns vary: some are the IATA airport code (JFK, LAX), some are local-language abbreviations (Mumbai’s BOM from “Bombay”), some are administrative shorthand (London’s LON from “London”).

Function codes

Each location carries an 8-position function code describing what facilities exist there. The code uses a positional convention where each digit marks one function:

A digit, dash, or zero in a position means “function not applicable”. Position 8 uses the letter B rather than the digit 8 because the original 1981 specification reserved single-digit positions for transport-mode functions and used a letter to mark the legal-status function.

Function-string examples

Some illustrative function strings encountered in practice:

• 1-------: pure port (e.g. Bukit Pasir, MYBKP, a Malaysian river port without rail, road, airport or postal facilities of UN/LOCODE significance)
• 1--45---: port plus airport plus postal exchange (Singapore, SGSIN: the city is all three)
• 12345---: port plus rail plus road plus airport plus postal (a major port-city hub)
• 1----6--: port plus ICD (a coastal port that also functions as an inland clearance depot for a hinterland region)
• ------7-: fixed transport only (an offshore oil platform such as a North Sea rig, with no port, rail, or road access)
• -------B: pure border crossing (a road or rail boundary between two countries, with no port or other functions)
• 0-3-----: road terminal only (an inland trucking depot, no port, no rail in UN/LOCODE)
• 1-3-4---: port plus road plus airport (a coastal city with port, trucking depot, and airport)

Reading function codes operationally

For a charterer or freight forwarder, the function code is the first thing checked after the country prefix. A 5-character code with a function string starting 1 is a port and the code can be used in a maritime bill of lading. A function string with 4 in position 4 indicates the location is also an airport, which matters when an inter-modal shipment routes through that point. A function string with 6 in position 6 indicates the location is an ICD; this matters because customs clearance can happen at the ICD rather than at the port of discharge, and the bill of lading load-port and discharge-port fields are populated accordingly.

The decoder rendering shows each active function as a labelled pill so the operational role is immediately clear without parsing the position string by eye.

Status flags

Every entry has a 2-character status flag indicating the level of authority that approved it:

For maritime-grade confidence (customs declarations, bill-of-lading load-port and discharge-port fields), prefer entries with AA, AC, AS, or AI. RL-status entries are valid for informal use but lack national-authority endorsement; they are useful for cross-reference but should not be cited as the primary identifier in a regulated document.

Status-flag drift

A subtle pitfall is that an entry can sit at AA for years even when the underlying authority status has changed. UNECE’s policy is that the flag is updated only when a national authority requests a change; passive drift (the authority no longer endorses the location, or the authority itself has been reorganised) is not automatically detected. The QQ flag exists precisely for this case: when UNECE notices that an entry has not been re-validated for a long time but cannot reach the national contact, it downgrades the entry to QQ (“original entry, not verified since date indicated”) rather than dropping it.

For mission-critical documentation, especially for politically sensitive routes (sanctioned countries, contested waterways, ports under change of administration), cross-check the current national customs authority website rather than relying solely on the UN/LOCODE flag.

Status-flag use in industry

Different downstream systems treat status flags differently. Most port community systems accept any flag from the A* family. Customs authorities are stricter: many EU national customs systems accept only AA, AC, or AI for the load-port and discharge-port fields of an export declaration. Some shipping lines maintain internal allowlists derived from the UN/LOCODE flag plus their own operational verification.

Subdivision codes

The optional Subdivision field aligns with ISO 3166-2 region codes. For example, the entry IDBTM (Batam, Indonesia) carries subdivision 13, which under ISO 3166-2 corresponds to “Riau Islands” province (ID-KR in newer notation, but UN/LOCODE retained the older numeric subdivision codes from the 1990s ISO 3166-2 vintage).

The subdivision code helps disambiguate locations with similar names in large countries. The United States has USPOR for Portland, Oregon and could in principle have a separate USPOR collision in another state; the subdivision field (OR for Oregon, ME for Maine) eliminates ambiguity. In practice UNECE assigns distinct location codes when the city name is shared, but the subdivision field still captures the administrative parent.

Coordinate system and conversion to decimal degrees

UN/LOCODE coordinates use a packed degrees-and-minutes format with hemisphere indicators: DDMM[N|S] DDDMM[E|W]. For Singapore (SGSIN) the entry shows 0117N 10350E which decodes to 1 degree 17 minutes North, 103 degrees 50 minutes East.

Formula, assumptions, and limits

Formula

To convert UN/LOCODE coordinates to decimal degrees:

where:

• $\phi_{\text{dec}}$ is the latitude in decimal degrees (positive North, negative South)
• $\lambda_{\text{dec}}$ is the longitude in decimal degrees (positive East, negative West)
• $D_\phi$ is the integer degrees component of latitude (parsed from the first 2 characters of the latitude block)
• $M_\phi$ is the integer minutes component of latitude (next 2 characters)
• $D_\lambda$ is the integer degrees component of longitude (parsed from the first 3 characters of the longitude block)
• $M_\lambda$ is the integer minutes component of longitude (next 2 characters)
• $\text{sign}_{\phi}$ is $+1$ for N, $-1$ for S
• $\text{sign}_{\lambda}$ is $+1$ for E, $-1$ for W

Derivation

The packed format DDMM[NS] DDDMM[EW] is a fixed-width string where each component occupies a known number of character positions. Latitude is always 2 digits of degrees plus 2 digits of minutes plus a hemisphere letter; longitude is 3 digits of degrees plus 2 digits of minutes plus a hemisphere letter. The conversion is a direct application of the standard sexagesimal-to-decimal conversion: 60 minutes per degree, with the hemisphere flipping the sign.

Assumptions

• The packed string is well-formed: exactly 5 characters of latitude (DDMM plus hemisphere letter) followed by exactly 6 characters of longitude (DDDMM plus hemisphere letter), separated by a single space.
• Hemisphere letters are uppercase ASCII (N, S, E, W). Mixed case or non-ASCII variants must be normalised before parsing.
• Minutes are integer (no fractional minutes). UN/LOCODE precision stops at the minute, so any sub-minute claim (seconds, decimal minutes) is outside the format.
• The result is in WGS-84 datum, the global default for maritime navigation since 1984. UNECE does not document the datum explicitly, but practical use in EDIFACT, customs declarations, and AIS messaging treats UN/LOCODE coordinates as WGS-84.

Worked example

For Singapore (SGSIN), the coordinate string is 0117N 10350E.

Latitude: $D_\phi = 01$, $M_\phi = 17$, hemisphere N, so $\text{sign}_{\phi} = +1$.

Longitude: $D_\lambda = 103$, $M_\lambda = 50$, hemisphere E, so $\text{sign}_{\lambda} = +1$.

Final: Singapore at 1.2833 degrees North, 103.8333 degrees East.

Edge cases and limits

• Equator and prime meridian: a location exactly on the equator has $\phi = 0$ and either hemisphere letter is acceptable; UN/LOCODE convention is N for any zero-or-positive latitude. Similar rule for the prime meridian: $\lambda = 0$ uses E. The dateline (180 East = 180 West) is conventionally encoded as E regardless of which side; downstream systems that need disambiguation should fall back to mapping APIs.
• Polar regions: latitude up to 90 degrees North or South is supported, but practical UN/LOCODE entries within 80-90 degrees are rare (a few research stations).
• Missing coordinates: many older entries, especially RL-flagged informal locations, have no coordinate field. The decoder treats this as null rather than 0.0 to avoid spurious “Gulf of Guinea” mappings.
• Precision limit: minute-level precision corresponds to roughly 1.85 km at the equator (one minute of latitude). For port-call routing this is sufficient; for berth-level navigation use port-authority hydrographic data instead.

Regulatory basis

• UNECE Recommendation 16, paragraph 4.5 (coordinate format specification)
• WGS-84 datum, ICAO Annex 4 (international standard for coordinate datum in transport applications)
• ISO 6709:2008, Standard representation of geographic point location by coordinates (the broader international standard for geographic-coordinate encoding)

Common errors

• Confusing latitude width with longitude width. Latitude is always 4 digits of DDMM. Longitude is 5 digits of DDDMM. A parser that assumes both are 4 digits truncates the longitude degrees and produces a coordinate at the wrong meridian.
• Forgetting the hemisphere sign. Buenos Aires at 3436S 05822W becomes -34.6 South / -58.37 West, not +34.6 North / +58.37 East. Sign convention errors place the port in the Mediterranean rather than the South Atlantic.
• Treating UN/LOCODE coordinates as WGS-84 when the operational system expects another datum. Modern systems are uniformly WGS-84; a few legacy customs systems expect the older Bessel 1841 or Krasovsky 1940 datums. The conversion factor is a fraction of a kilometre but matters for berth-level work.
• Reporting “Gulf of Guinea” coordinates (latitude 0, longitude 0) for locations that have no coordinate field. The Gulf of Guinea sits at the intersection of the equator and prime meridian; defaulting null to zero produces a misleading “all unmapped ports cluster off West Africa” result. Use null and a marker like a missing-coordinate flag.

Precision and accuracy

UN/LOCODE coordinates are intentionally low-precision: degrees and minutes only, no seconds and no fractional minutes. This gives a precision of roughly 1.85 km at the equator (one minute of latitude) and slightly less at high latitudes. For port-call routing, vessel-scheduling, and bill-of-lading documentation, this is more than sufficient: a port complex spans kilometres, and the UN/LOCODE coordinate identifies the centroid to within a kilometre or two.

For higher-precision navigational use (specific berth, anchorage, terminal entrance), supplement UN/LOCODE coordinates with port-authority hydrographic data or ENC charts. UN/LOCODE is a directory, not a chart.

IATA airport equivalent

When a UN/LOCODE entry is also an airport in the IATA airport-code register, the IATA 3-letter equivalent is recorded in the IATA field. New York’s USNYC corresponds to multiple IATA airports (JFK, LGA, EWR, HPN); the city carries multiple airport codes which UN/LOCODE references where applicable. When a UN/LOCODE entry is for an airport-only function (not a port), the IATA code is typically the location’s primary identifier in industry use.

Update cadence and release history

UNECE issues two releases per year. A release version is encoded as YYHC where YY is the two-digit year and H is the half number (1 = January through June submissions; 2 = July through December submissions, plus end-of-year corrections). The current release as of writing is 2024-2 (loc242csv.zip), which contains 116,018 entries.

Recent release sizes:

• 2023-1: ~115,200 entries
• 2023-2: ~115,500 entries
• 2024-1: ~115,683 entries
• 2024-2: ~116,018 entries

Half-on-half delta typically averages 100 to 500 entries: new ports added by national facilitation bodies, status updates from RQ to AA after national approval, occasional entry deletions of locations that have closed or merged. Major step-changes occur rarely, usually associated with a new member state’s first comprehensive submission or with a structural revision (the 2020 revision adjusted dozens of subdivision codes simultaneously).

ShipCalculators.com refreshes its UN/LOCODE dataset monthly via an automated workflow that fetches the latest UNECE archive and diffs against the prior version. When a new release is detected (delta greater than 0.5 percent), an issue opens for editorial review and the dataset commits to main. Tripwire: if the delta exceeds 10 percent, the workflow assumes upstream data corruption and opens a high-priority issue for inspection.

Mid-cycle changes

UNECE does not publish mid-cycle micro-updates. If a port opens in March and the half-1 release was already published in January, the new port waits until the July release. National authorities sometimes publish their own interim lists; freight forwarders learn the new code from the carrier or directly from the port authority. The biannual release cycle is the trade-off UNECE accepts to maintain dataset stability and predictable update windows for downstream systems.

Role in maritime trade documentation

UN/LOCODE is mandatory or strongly recommended in:

• EDIFACT messages: IFTSTA (in-transit goods), IFTMIN (in-vehicle inventory), CUSDEC (customs declaration), COPRAR (container preadvice), BAPLIE (bay plan in load-discharge sequence). The LOC+9+SGSIN segment is universal for “load port: SGSIN” or related load/discharge declarations.
• Customs declarations: most national customs authorities accept UN/LOCODE in load-port and discharge-port fields. EU Single Window initiatives and AEO programmes treat UN/LOCODE as the canonical port identifier.
• Bills of lading and waybills: maritime BL forms (FIATA Multimodal BL, conline BL, Combiconbill) reference UN/LOCODE in load-port and discharge-port fields. Freight forwarders’ house BLs typically inherit the master BL’s UN/LOCODE entries.
• Cargo manifests: FAL forms, APIS-type pre-arrival cargo data submissions, and the EU ICS2 Pre-Loading Advance Cargo Information all reference UN/LOCODE.
• Port community systems (PCS): Rotterdam (Portbase), Antwerp (NxtPort), Singapore (PortNet), Hamburg (DAKOSY), and Felixstowe (DCT) all use UN/LOCODE as the master port taxonomy.
• Vessel scheduling and AIS: every commercial vessel-tracker (MarineTraffic, VesselsValue, Spire, FleetMon, Windward, Kpler) tags port calls with UN/LOCODE. The AIS Type-5 message’s “Destination” field is in practice populated with UN/LOCODE plus optional terminal suffix (e.g. SGSIN or SGSIN-PSA to indicate Singapore PSA terminal specifically).

Per-EDIFACT segment use

In an EDIFACT IFTSTA message reporting an in-transit shipment, a typical UN/LOCODE-bearing segment is:

LOC+9+SGSIN'

where LOC is the location segment qualifier, 9 indicates “load port”, and SGSIN is the UN/LOCODE. Discharge port uses LOC+11+..., place of receipt uses LOC+88+..., and place of delivery uses LOC+7+.... The complete EDIFACT mapping is documented in the UN/EDIFACT directory; the salient point is that UN/LOCODE is the value side of every port-related location segment in the standard message types.

EU AEO and Single Window

The European Union’s Authorized Economic Operator (AEO) programme requires customs declarations to use UN/LOCODE for load and discharge ports. The EU Single Window (CSW-CERTEX, the unified customs-and-trade declaration platform) inherits UN/LOCODE as the canonical port reference. This means a German exporter declaring goods leaving Hamburg is compelled by both the AEO discipline and the Single Window data model to populate the load-port field with DEHAM. Mistakes (typos, wrong country prefix, dropped or doubled characters) cause the declaration to reject at the validation stage; the cost of getting the code wrong is delayed customs clearance and frequently a financial penalty.

Customs across non-EU jurisdictions

The United States Customs Border Protection (CBP) accepts UN/LOCODE in the Automated Manifest System (AMS) for arrival and departure declarations; the Canadian Border Services Agency (CBSA) does the same in ACI and ACE; Singapore Customs in TradeNet; Hong Kong in CRT (Cargo Reporting and Tracking); UK HMRC in CHIEF and now CDS. Each authority publishes its own version of the UN/LOCODE list (typically with a national subset) but all align with UNECE on the format and values.

Port community systems integration

A port community system (PCS) is the platform-level integration of all the parties that interact with a port: the port authority, the terminal operators, the shipping lines, the freight forwarders, the inland transport providers, and the customs authority. PCSes use UN/LOCODE to identify ports across all integrated parties.

• Portbase (Rotterdam): launched in 2009 as a merger of two predecessor systems, Portbase coordinates approximately 14,000 maritime, road, rail, and inland waterway transport operations per day at the Port of Rotterdam. Internal references use UN/LOCODE for port identification across all message types.
• NxtPort (Antwerp): the Antwerp port community system, operational since 2017, manages approximately 11,000 declarations per day. Inter-port routing references UN/LOCODE; intra-port references use SMDG terminal codes (which sit at a granularity finer than UN/LOCODE: per-terminal rather than per-port).
• PortNet (Singapore): operated by PSA Corporation, PortNet is the world’s most-trafficked PCS by volume, handling approximately 25,000 transactions per day. UN/LOCODE is the master port taxonomy.
• DAKOSY (Hamburg): operating since 1982, DAKOSY is one of the longest-running PCSes worldwide. UN/LOCODE is canonical.
• DCT (Felixstowe and other UK ports): similar integration pattern.

SMDG Terminal Codes: the per-terminal layer above UN/LOCODE

UN/LOCODE granularity stops at the city or port level. A port like Rotterdam contains multiple terminals (APM Terminals Rotterdam, Euromax, Rotterdam World Gateway, Hutchison Ports, etc.); a port like Singapore contains PSA terminals at Pasir Panjang, Tuas, Brani, and Keppel. UN/LOCODE has one code per port, not one per terminal.

SMDG Terminal Codes fill this gap. SMDG (Shipping Information Service for the maritime container industry) maintains a list of terminal codes that pair the UN/LOCODE with a per-terminal suffix. For example, NLRTM ECT indicates Rotterdam’s Europe Container Terminals, and SGSIN PSA indicates Singapore’s PSA terminals. Industry uses the combination when terminal granularity matters (vessel scheduling, terminal-side cargo handling) and uses bare UN/LOCODE when port granularity is sufficient (customs declarations, bills of lading).

Classification societies and port-state control records

Each IACS member maintains a port directory linked to UN/LOCODE for vessel inspection records, port-state-control deficiency tracking, and casualty-investigation reporting. ABS, BV, ClassNK, DNV, LR, RINA, KR, ClassNK, CCS, IRClass, PRS, and CRS all use UN/LOCODE as the port identifier in their public registries.

The Paris Memorandum of Understanding (Paris MoU) and the Tokyo MoU, the two main port-state control regimes, also use UN/LOCODE in their inspection databases. When a vessel is inspected at Felixstowe under Paris MoU, the inspection record is keyed to GBFXT, the UN/LOCODE for Felixstowe. This allows trend analysis: which ports have the highest deficiency rates by vessel type, which inspection regimes have detected which patterns over time.

UN/LOCODE thus appears across the regulatory chain from customs declaration through port community system to classification society inspection record to flag state casualty investigation. A single 5-character code, used consistently across all of these layers, is a substantial coordination win compared to the pre-1981 era of national port-list fragmentation.

Vessel scheduling and AIS port-of-destination

AIS Type-5 messages (Static and Voyage Related Data) contain a 20-character free-text “Destination” field set by the master or the bridge officer. In practice, ship masters set this field to the UN/LOCODE of the next port of call, sometimes followed by the SMDG terminal suffix. Examples:

• SGSIN: bound for Singapore (any terminal)
• NLRTM ECT: bound for Rotterdam, Europe Container Terminals
• USNYC: bound for New York (any terminal in the New York / New Jersey complex)
• USNYC APMT: bound for New York, APM Terminal Newark

Vessel-tracker platforms (MarineTraffic, FleetMon, VesselsValue, Spire, Kpler, Windward) parse the Destination field, look up the UN/LOCODE in their internal port directory, and present the human-readable port name. Variations in Destination format (free-text, sometimes mis-typed, sometimes with non-standard separators) make this parsing non-trivial; the first parser layer is normalisation, similar to the UN/LOCODE Decoder calculator’s input-tolerance design.

The Destination field is not always reliable: ships sometimes set it once at start of voyage and forget to update it on routing changes; some flags do not enforce update discipline; pirate-risk areas sometimes prompt masters to obfuscate the actual destination. Practical use of AIS Destination requires cross-reference against actual AIS position track to confirm the declared destination matches the ship’s heading and pace.

Adoption by jurisdiction

UN/LOCODE is universally referenced but the depth of national-authority engagement varies:

• European Union member states: comprehensive coverage, active national facilitation bodies, fast turnaround on additions. The EU customs authorities (TAXUD) coordinate UN/LOCODE submissions through national focal points, and most member states have completed digitisation of their port directories with UN/LOCODE as canonical.
• United States: comprehensive coverage of ports and airports; the US national focal point sits with the US Department of Transportation. US Customs Border Protection accepts UN/LOCODE in AMS, ACE, and CBP One.
• Singapore: compulsory for all maritime documentation; the Singapore Maritime and Port Authority (MPA) and Singapore Customs both maintain national lists derived from UN/LOCODE.
• China: comprehensive coverage of ports; the State Council’s Ministry of Transport coordinates submissions. CCS (the Chinese classification society) uses UN/LOCODE in its port directory.
• India: increasing coverage as the directorate general of shipping has digitised port directories; some smaller minor ports lag.
• Japan: comprehensive coverage; fast turnaround.
• Korea: comprehensive coverage; KR (Korean Register of Shipping) cross-references UN/LOCODE.
• Russia: comprehensive coverage of major ports; smaller inland-waterway points sometimes lag.
• Brazil: comprehensive coverage of major maritime ports; some inland river points (Amazon, Paraguay-Paraná) under-coded.
• Sub-Saharan Africa: variable. South Africa, Kenya, Nigeria have substantial coverage; some smaller West African and East African ports operationally significant for break-bulk and project cargo lack UN/LOCODE entries.

When a port lacks a UN/LOCODE entry, alternatives include the country’s national customs port code, the classification society’s internal port code, or the SMDG terminal code if the location is associated with a containerised terminal.

Relationship to other location standards

UN/LOCODE is one of several maritime-relevant location vocabularies. Practitioners encounter:

• IATA airport codes: 3-character (JFK, LHR, SIN). Cross-referenced from UN/LOCODE in the IATA field, but UN/LOCODE codes are 5-character (country plus location). For airport-only locations, the IATA code is typically primary; UN/LOCODE provides the country prefix and a unique 5-character form for cross-system reference.
• ISO 3166-1 alpha-2: the country prefix of UN/LOCODE. Always aligned.
• ISO 3166-2: subdivision codes, cross-referenced in the UN/LOCODE Subdivision field.
• GS1 Global Location Number (GLN): a 13-digit identifier from GS1 (the barcode standards body), used for unique identification of any location including specific shipping berth or warehouse rack. GLN is heavier than UN/LOCODE but per-asset-precise. Industries that need warehouse-level granularity (consumer-goods supply chains) use GLN; maritime shipping uses UN/LOCODE plus SMDG for the per-terminal layer.
• AIS port-of-destination codes: set by the master at sea via AIS Type-5 messages. In practice the UN/LOCODE plus optional terminal suffix.
• Lloyd’s Maritime Atlas codes: historically used in Lloyd’s port pages and Lloyd’s Maritime Intelligence Unit data products. Now largely aligned with UN/LOCODE; some legacy Lloyd’s codes persist in older datasets but new entries are UN/LOCODE.
• SCAC codes: Standard Carrier Alpha Code, a 4-letter code identifying ocean and intermodal carriers (MAEU for Maersk, CMA for CMA CGM). These are carrier identifiers, not location identifiers, and are orthogonal to UN/LOCODE.
• National customs port codes: each customs authority maintains its own port list. Most are subsets of UN/LOCODE with additional national codes for legacy or non-standard locations.

The general rule is that UN/LOCODE is the universal interchange format. Within a specific industry or system (intermodal logistics, FMCG supply chain, internal carrier routing), more specialised location standards may layer on top of UN/LOCODE; but the canonical form for cross-system reference is always the 5-character UN/LOCODE.

Common errors and recovery patterns

A handful of error patterns recur frequently in practical UN/LOCODE handling. Understanding them shortens debugging when a manifest, declaration, or message is rejected:

• Wrong country prefix: USRTM instead of NLRTM for Rotterdam. The location code RTM is not valid for the United States. Recovery: confirm the country prefix from the country of the port (Netherlands → NL), and the location code from the place name.
• 4-character truncation: SGSI or SGIN because the user dropped a character. Recovery: pad to 5 characters and verify against the directory.
• Typo in location code: SGSNI instead of SGSIN (transposed letters). The decoder catches these via Levenshtein fuzzy match (distance of 2 or fewer characters), but downstream systems typically reject the message rather than auto-correct.
• Use of an RR (rejected) code: a code that was once a valid request but has since been rejected. The decoder flags the status as RR so the operator knows to choose a different identifier for the location.
• Port-vs-airport confusion: CNSHA is Shanghai Hongqiao International Airport (function code 00040000, airport only, no port). The Shanghai port is CNSGH (function 12345000, port plus rail plus road plus airport plus postal). Customs declarations for sea cargo into Shanghai must use CNSGH, not CNSHA, even though both are valid UN/LOCODE entries.
• Rebrand or merger: a port that was once independent has been merged into a regional authority. UN/LOCODE typically retains the original code; recovery is to look up the historical name in the directory.
• City name change: Mumbai retains BOM from “Bombay” because the 3-character code is not regenerated when a city renames. Saint Petersburg retains LED from “Leningrad” similarly. The decoder displays the current name from the directory; the historical 3-character code is preserved for backwards compatibility with existing documentation.

When any error occurs, the practical recovery is: paste the failing code into the UN/LOCODE Decoder calculator and either get a direct match, get fuzzy suggestions, or get a clear “not found” with diagnostic detail. From there, identify the correct code and update the document.

Limitations and gaps

UN/LOCODE has known structural and operational limitations that practitioners must work around:

• Per-terminal granularity: the SMDG Terminal Codes layer above UN/LOCODE handles this. Bare UN/LOCODE is per-port, not per-terminal.
• Anchorages and Outer Port Limits (OPL): offshore ship-to-ship transfer locations and outer-port limits are inconsistently coded. Some carry their own UN/LOCODE; others do not. For transfers that occur in international waters, the only UN/LOCODE option is XZ plus a generic location code, which is rare.
• Floating units: FPSOs, FSOs, FSRUs, drillships are not always assigned UN/LOCODE entries even when they function as operational hub locations. The 7 (fixed transport) function code covers most fixed offshore installations but the entries are sparse.
• Subdivision drift: UNECE does not always reflect every administrative re-zoning in real time. Some subdivision codes lag 1 to 3 years behind ISO 3166-2 updates. For sensitive purposes, cross-check ISO 3166-2 directly.
• Status drift: as discussed, entries marked AA decades ago may have lost national-authority endorsement without UNECE updating the flag. The QQ flag exists for such cases but is applied retroactively, not prospectively.
• Mid-cycle gaps: between biannual releases, new ports operate without a UN/LOCODE for up to 6 months. Industry typically uses an interim country-plus-place-name string until the next release.
• Geopolitical sensitivity: ports under contested sovereignty (Crimea since 2014, parts of South China Sea) are coded under the country claimed by the entity submitting to UNECE. Conflicting national positions sometimes result in the same physical location being referenced by two different codes from different country prefixes, depending on the submitting jurisdiction. This is resolved at international-tribunal level rather than within UN/LOCODE; the directory presents whatever the current consensus is at the latest release.

Editorial maintenance pattern

For any reference work that depends on UN/LOCODE (a wiki article, a calculator, a generator), the maintenance discipline is:

1. Refresh the dataset on a known cadence. ShipCalculators.com runs a monthly refresh cron that fetches the latest UNECE archive and diffs against the prior version. Any delta opens an issue for editorial review.
2. Detect tripwires for upstream data corruption. If the delta exceeds 10 percent, treat as suspect upstream data and inspect before committing.
3. Document the dataset version in the rendered output. Articles and calculators reference “UN/LOCODE 2024-2” so readers can assess currency at a glance.
4. Flag deprecated entries. When an entry status changes to XX (“will be removed”), surface this in the rendered output so readers do not adopt a code that is about to disappear.
5. Cross-link the source-of-truth. Every UN/LOCODE-dependent page links to the UNECE directory directly so the reader can verify against the upstream master at any time.

This discipline is shared across the UN/LOCODE bundle: the article, the decoder calculator, and the underlying data refresh pipeline all reference the same canonical source and propagate the same version label.

See also

• UN/LOCODE Decoder: interactive lookup; paste a code, country, or location name and get the full breakdown
• Marine engine model decoder: companion calculator that decodes engine model designations the same way