LC Discrepancy Checker: How AI Catches What Human Eyes Miss

---

The problem with manual LC review

A letter of credit (LC) is only as useful as the documents that support it. Banks don't pay because a deal went well — they pay because every document in the presented set matches the LC terms, the requirements of UCP 600 (Uniform Customs and Practice for Documentary Credits, the global rulebook banks apply when examining LC documents), and ISBP 821 (International Standard Banking Practice, the detailed examination standard last updated in July 2023) simultaneously.

That's three layers of requirements that every single page needs to pass. A human reviewer working under time pressure — and most document checking happens in compressed windows before shipment deadlines — is checking dozens of fields across multiple documents, each against a different clause. The error doesn't have to be large. Under UCP 600 Article 14, the standard for document examination, even a non-material inconsistency between documents gives the bank grounds to reject. A different abbreviation for the same port. A unit count that doesn't carry across from the invoice to the packing list. A goods description that is technically accurate but not worded the way the LC specifies.

These are exactly the errors human eyes normalize. Pattern recognition — the thing that makes experienced reviewers good at most tasks — is a liability when two documents say essentially the same thing in subtly different ways. The brain resolves the difference. The bank's examination system doesn't.

What an LC discrepancy checker actually needs to do

Not every tool described as an "LC discrepancy checker" works the same way. The meaningful difference is whether the system checks against the actual rules or against a generic document template.

A rule-grounded checker applies the specific examination criteria from UCP 600 and ISBP 821 to each document type. The requirements for a commercial invoice under UCP 600 Article 18 are different from the requirements for a bill of lading under Article 20, which are different again from the requirements for an insurance document under Article 28. A checker that treats all documents the same — scanning for missing fields or obvious typos — misses the structural mismatches between documents that account for a significant share of real-world discrepancies.

The second requirement is cross-document consistency checking. Most discrepancies don't exist within a single document — they exist in the relationship between documents. The invoice says one thing about the goods. The packing list says something slightly different. The bill of lading uses a third formulation. Each document, read alone, might pass examination. The set, read together, fails under UCP 600 Article 14's requirement that documents not conflict with each other.

Third — and this is the part most tools skip — the checker needs to flag issues that fall under ISBP 821's interpretation guidance, not just UCP 600's explicit rules. ISBP 821 governs how banks apply those rules in practice. A document correction that isn't authenticated correctly, a goods description that diverges from the LC in ways UCP 600 doesn't explicitly prohibit but ISBP 821 does, a bill of lading endorsement that looks right but doesn't follow the consignment structure — these are ISBP-level issues that only appear if the checker is built on that layer of rules as well.

The 5-banking-day window you probably aren't tracking

UCP 600 Article 16 gives the issuing bank a maximum of five banking days following the day of presentation to decide whether documents comply. If the bank exceeds that window without communicating a decision, it loses the right to claim discrepancy — the documents are deemed complying by default.

The 5-banking-day rule: Under UCP 600 Article 16, banks have a maximum of 5 banking days to reject documents after presentation. Miss the window, and the right to claim discrepancy is lost — documents are treated as complying.

For exporters, this creates a practical dynamic: if you catch and correct discrepancies before presentation, you control the timeline. If you present discrepant documents and the bank catches them within the five-day window, you're looking at rejection, re-presentation, amended documentation, and the fees and delays that come with each step. The cost of a pre-presentation check is a fraction of the cost of even a single rejection cycle.

Where AI changes the equation

The advantage of an AI-based LC discrepancy checker isn't speed alone — though processing a full document set in seconds versus hours matters. The more significant advantage is consistency. Human reviewers vary. An experienced examiner on a good day is different from the same examiner at the end of a document-heavy week. AI applies the same ruleset to the same set of fields every time.

The second advantage is that AI handles the cross-document matrix that makes manual review particularly error-prone. With five or six documents in a typical LC presentation — invoice, packing list, bill of lading, insurance certificate, certificate of origin, and potentially inspection certificates — the number of relationships between fields across documents grows quickly. An AI system can check all of those relationships simultaneously, against the rule that governs each specific pair of fields, without the cognitive load that causes human reviewers to normalize inconsistencies.

The critical caveat: an AI checker is only as good as the rules it's trained on. A system that learned from historical document samples without being explicitly grounded in UCP 600 and ISBP 821 will catch the discrepancies that appeared most often in training data — not the ones that matter under the current examination standard. ISBP 821 replaced ISBP 745 in July 2023. Any checker still operating on the older standard is applying rules that banks are no longer required to follow.

A practical example: what gets caught and what gets missed

Scenario: An exporter presents a set of documents for a shipment of industrial components. The invoice describes the goods as "precision-machined steel components, grade 304." The LC specifies "stainless steel machined parts, AISI 304." The packing list uses "steel parts (304 grade)."

A human reviewer reading through three documents in sequence often resolves this as "the same thing." The examiner knows that AISI 304 and grade 304 refer to the same steel specification. The bank's document examiner, applying UCP 600 Article 18's requirement that the goods description in the invoice correspond with the credit, may not extend that inference — and under ISBP 821, the examiner isn't required to. The description on the invoice needs to correspond to the LC terms, not just be factually equivalent to them.

A rule-grounded AI checker flags this as a potential discrepancy at the description-matching layer, before the documents leave the exporter's desk. The exporter can amend the invoice. The bank never sees the inconsistency. Payment proceeds on schedule.

How T flow L/C Checker is built

T FLOW is a full-stack trade operations and trade finance infrastructure platform — covering storefront, RFQ, contract, documentation, shipping, and settlement in a single system. Within that platform, T flow L/C Checker is the document verification engine, built on 53 examination rules grounded directly in UCP 600 and ISBP 821.

The architecture uses a dual-channel approach: an ontology-driven inference layer applies the rule structure of UCP 600 and ISBP 821 systematically, while an AI reasoning layer handles the interpretation cases where the rules require contextual judgment — the situations that fall between explicit rule clauses and that generate the most real-world disputes.

The system checks each document against its applicable rule set (invoice under Article 18, bill of lading under Article 20, insurance under Article 28) and then runs the cross-document consistency matrix across the full presentation set. Issues are flagged with the specific rule clause that applies, so the exporter knows not just what the problem is but why it's a problem under the examination standard the bank will use.

Check your documents before the bank does.
[Try T flow L/C Checker →] tflowx.com