One wrong character can freeze a million dollars for a month.

A zero typed as the letter O. A transposed invoice digit. A vessel name spelled two ways in two documents. A single conflict can be enough to trigger a refusal, and then 30 to 45 days of delayed payment for cargo that has already shipped.

Why one character is enough

UCP 600 article 14(d) is short and unforgiving: data in a document must not conflict with data in that document, any other stipulated document, or the credit. It does not have to be identical, but it cannot conflict. The ICC Banking Commission's Technical Advisory Briefing No. 12 explains how "read in context with" is meant to be applied, and it does not rescue an identifier that differs. A vessel named "MV Oceanline" on the bill of lading and "MV Oceanliine" on the insurance certificate is a conflict. A checker cannot know which is right, and the bank is not permitted to guess.

ISBP 821E softens this slightly for typing errors that do not affect meaning. "Mashine" for "machine" passes. But a wrong digit in an invoice number, a container number or a quantity changes meaning, and a vessel name is an identifier, not a word. Most of the character-level errors that actually occur fall on the wrong side of that line.

Where the characters come from

The same data is typed into a document set four, five or six times. The vessel name goes on the bill of lading (by the carrier), the insurance certificate (by the insurer or the exporter), the packing list and the beneficiary certificate (by the exporter), and often the commercial invoice. Each is a separate keystroke by a separate person from a separate source. Every one of those is an opportunity for the letter O to become a zero.

Humans are the wrong tool for this job

An experienced checker reading a 40-page presentation for conflicts is doing a task that humans are measurably bad at: sustained, character-level comparison across documents under time pressure. Attention drifts. The eye autocorrects "Oceanliine" to what it expects. Machines, when properly built, trained and monitored, do not. They compare the string, not the impression of the string.

Loamist Validator cross-checks every field across the full document set, character by character, before anything goes to the bank. It reads the value on each document, normalises it, compares it with every other occurrence and with the credit, and reports each conflict with the two documents and the two values side by side.

Key takeaways

  • A single data conflict between documents is a refusable discrepancy under UCP 600 article 14(d).
  • Re-keying the same value into several documents is the root cause; each keystroke is a chance to introduce a conflict.
  • Character-level cross-checking is exactly the kind of task software does better than a tired examiner.

The bill of lading is where most identifier conflicts surface. Our bill of lading compliance guide covers the fields that must agree, and with what.

Frequently asked questions

Does every typo cause an LC discrepancy?

No. ISBP 821E allows a misspelling or typing error that does not affect the meaning of a word (for example 'mashine' for 'machine'). A variation that changes meaning, or makes the data conflict with another document, is a discrepancy under UCP 600 article 14(d).

Which documents are checked against each other?

All of them. UCP 600 article 14(d) requires that data in a document, read in context with the credit, the document itself and international standard banking practice, does not conflict with data in that document, any other stipulated document, or the credit.

See Validator on one of your own letters of credit

Loamist Validator reads an export L/C the day it arrives, flags the terms that cannot be met, drafts the documents from the credit, and pre-checks the full set against UCP 600, eUCP and ISBP 821E before the bank sees it.

Run a free workability check on a recent L/C, or book a demo and we will walk through a live decision trace.