Extracting Voyage and Vessel Information From a Shipping Manifest

A manifest header names the ship four different ways, and only one of them is a stable identifier with a checksum. Getting the extraction right is mostly a matter of knowing which one that is, and refusing to let the other three overwrite it.

Four identifiers, one ship

• Vessel name. Free text, often with a prefix such as MV or a carrier’s house prefix. Not unique, not stable, not verifiable from the document.
• IMO number. Seven digits, conventionally written with the literal prefix IMO, assigned under the International Maritime Organization’s ship identification number scheme. The seventh digit is a check digit.
• MMSI. Nine digits used by the ship’s radio equipment and by AIS. The first three digits are a Maritime Identification Digits code identifying the country of registry. There is no check digit.
• Call sign. An alphanumeric radio call sign allocated by the flag state. Format varies by country and it changes when the flag changes.

A manifest may print any subset of these, and a carrier’s own vessel code — a short internal abbreviation — frequently appears alongside them in the same field group, which is how an internal code ends up stored as a call sign.

The IMO number check digit

The scheme is simple enough to implement in one line and is the only arithmetic verification available in the whole header block.

1. Take the first six digits of the seven-digit number, left to right.
2. Multiply them by 7, 6, 5, 4, 3 and 2 respectively.
3. Add the six products.
4. The check digit is the rightmost digit of that sum — the sum modulo 10.

Worked on a synthetic number, IMO 9319466:

9 x 7 = 63
3 x 6 = 18
1 x 5 =  5
9 x 4 = 36
4 x 3 = 12
6 x 2 = 12
        ---
sum    146   ->  last digit 6  ->  check digit 6

Because the weights descend to 2 and the modulus is 10, this catches every single-digit substitution but does not catch every transposition: swapping two adjacent digits changes the sum by the difference between the digits multiplied by one, so a swap of adjacent digits differing by ten — impossible — is the only undetectable case for neighbours, while non-adjacent swaps can escape when the weight difference times the digit difference is a multiple of ten. Swapping the first and sixth digits of a number where those digits differ by two is the ordinary example: the weight difference is five, and five times two is ten. So a passing check digit means the number is well formed, not that it is the right ship.

Which identifier is a key

The IMO number is assigned to the hull and stays with it. A ship can be sold, renamed, reflagged and rechartered, and the number does not change. Every other identifier on the manifest can: the name changes with the charter, the call sign and the MMSI change with the flag, and the carrier’s vessel code changes when the carrier does.

That has a direct consequence for how you store the extraction. If your vessel table is keyed on name, two calls at the same berth eighteen months apart become two ships or, worse, one ship with a name that silently rewrote itself. Key on the IMO number, store the name as an attribute of the voyage rather than of the vessel, and you get a historical record that stays true. Where the manifest gives a name and no IMO number, record the name and the absence explicitly rather than resolving it against a register during extraction; resolution is a separate step with its own error rate and it should not be hidden inside a field that looks like it came off the page.

The voyage number and its direction suffix

Voyage numbers are carrier-specific and unstandardised, which makes them the field most likely to be extracted into the wrong slot. They are commonly a sequence number plus a single-letter direction suffix — 045E and 045W being the eastbound and westbound legs of what is, from the carrier’s point of view, the same rotation. Strip the suffix and you have merged two voyages that called at different ports on different dates.

The pairing with the vessel name is where transposition happens. “VESSEL / VOYAGE” is frequently one printed field with a slash, and it is just as frequently two adjacent labelled boxes in either order. A model reading a header block without positional anchoring will sometimes return the voyage number as the vessel name, and because both are free text, nothing downstream notices.

The defence is a shape assertion rather than a confidence threshold: a voyage number is short and almost always contains a digit; a vessel name is longer and usually does not. Assert that the voyage field matches something digit-bearing and short, assert that the vessel name does not consist solely of digits, and route violations to review. This is the same argument for structural over probabilistic validation made in the page on calibrating extraction confidence, applied to a field pair that has no checksum to fall back on.

Transpositions and near misses

• The prefix eaten. IMO9319466 with no space, IMO NO. 9319466, and a bare 9319466 are all the same field. Strip non-digits before checksumming and keep the printed form separately.
• MMSI misfiled as IMO. Nine digits in a field labelled for seven is the giveaway, and it happens because the two numbers sit next to each other in the header. A length assertion catches it for nothing.
• Feeder and mother vessel. Transhipment manifests name two ships and two voyages. A schema with one vessel object forces the extraction to choose, and it will choose the first one on the page, which is not reliably the one your consignment sailed on.
• Port codes that look like words. UN/LOCODE port codes are five characters, two of country and three of place, and they are printed alongside the port name. NLRTM beside ROTTERDAM is one port stated twice, not two fields to reconcile.
• Dates without a year. Estimated arrival is often printed as day and month only. Inferring the year from the filing date is right almost always and wrong across a December boundary, which is exactly when it matters — one for a date field validation rule.