Discrepancy — checking letter of credit paperwork

When a business buys goods from another country, its bank often promises to pay the seller once the seller hands over the right paperwork: an invoice, a bill of lading from the shipping company, and so on. That promise is called a letter of credit. Before the bank pays, someone has to check that every document agrees with the others and with the terms of the credit.

This checking is slow, specialist work, and the deadline is strict. If the documents are wrong, the bank has five banking days to refuse them, in a single notice that lists every problem. Miss the deadline and it loses the right to refuse; leave a problem off the notice and it cannot add it later. Discrepancy does the checking, drafts the notice and keeps track of the deadline.

What is finished and what is not

The checking, the refusal notice, the deadline and the record it keeps are complete and heavily tested. The part that reads the documents is a simple stand-in that only handles clean PDFs this project generated itself. So this is a working demonstration of how to build a tool like this, not something ready for real paperwork. The sections below say exactly what has and has not been shown.

What it does

It is built to help a bank's document checkers. You give it the terms of the credit and the documents that were presented, and it:

Compares the documents with each other and with the credit: the names of the buyer and the seller, the ports, the currency, the description of the goods, the shipping marks and the weight. This version covers two documents: the commercial invoice and the bill of lading (the shipping company's receipt for the goods).
Explains every problem it finds: which document, which field, what it says, what it should say, and which rule it breaks. A problem that cannot be tied to a specific rule is not reported.
Drafts the refusal notice, listing every problem at once and saying what the bank is doing with the documents, such as holding them or sending them back.
Works out the deadline, five banking days after the documents arrive, skipping bank holidays. Once a notice has gone out it will not send another, and after the deadline it will not draft one at all.
Says what it checked. Every result ends with a line naming the rules it applied, so "no problems found" is not mistaken for "everything is in order".
Hands anything it cannot read to a person. If a field cannot be read, it flags it for review and does not draft a notice, because a notice has to list every problem and it cannot yet be sure it has them all.
Keeps a record of what was presented, what the rules decided and what was sent, saved before any result is shown.

Here is a notice it drafted for one of its test cases:

NOTICE OF REFUSAL
Credit: LC-EC-002
Presentation: EC-002
Date of presentation: 2026-09-07
Date of this notice: 2026-09-09
Examination period expires: 2026-09-14 (UCP 600 art. 14(b))

We refuse to honour or negotiate.

We are holding the documents pending your further instructions. [UCP 600 art. 16(c)(iii)(a), MT734 77B/HOLD]

The discrepancies are, in full (2):
1. bill of lading, port of discharge: shows 'Singapore'; the credit requires 'Port Klang'. [UCP 600 art. 14(d)]
2. bill of lading, goods claims: shows 'colour: red'; the commercial invoice shows goods claims 'colour: green'. [UCP 600 art. 14(d)]

SCOPE OF EXAMINATION
Examined against UCP 600 art. 14(d) using rule model 0.7.0.

Exactly what the code produces for test case EC-002 after the port on the bill of lading is changed to Singapore. The references in square brackets name the rule behind each line. A test regenerates this notice on every build and checks it still matches, so the example stays true to the real output. You can produce it yourself on the demo page.

Why it is built this way

A bank has to be able to defend a refusal, sometimes in a formal dispute. So the aim was not only to get the answer right, but to make every answer easy to check.

No AI model makes the decision. The rules are written as ordinary code, so the same documents always get the same answer, and any result can be traced to the exact rule that produced it. A check takes about 7 milliseconds and makes no calls to a language model.
The deadline is enforced by the software, not left to memory. Missing it has a legal consequence, so the code will not let a late notice, or a second notice, go out.
The record is written first. What was presented, what was decided and what was sent are saved before anything is shown. Each entry is linked to the one before it by a digital fingerprint, so editing an old entry breaks the chain and shows up. That makes an edit detectable. It does not stop someone who holds this code from rewriting the whole record and recomputing every fingerprint.
When it is unsure, it asks. A wrong refusal is costly, and so is waving through documents that should have been refused, so it does not guess at a field it cannot read.

Why letters of credit

Many demos of software that reads documents pick a task with no clear right answer, which makes them hard to test. Letters of credit (also called documentary credits) have unusually solid ground truth:

The rulebook is published. UCP 600 is the international rulebook for letters of credit, published by the International Chamber of Commerce (ICC), and every problem can be tied to a numbered article in it.
The deadline is fixed: five banking days, with a clear consequence for missing it.
Real disputes are published. The ICC's Banking Commission issues opinions on disputed cases, and its DOCDEX service publishes decisions by expert panels. The test cases are built from these.

How well it works

It was tested on 20 cases, each based on a published dispute, using made-up documents. The table covers the fourteen used during development; the other six were held back as a separate test.

What it read	Cases right	Problems found	Score if it found nothing
The case data, read directly	14 / 14	7 / 7	7 / 14
A generated PDF, labels above values	13 / 14	6 / 7	7 / 14
A generated PDF, label and value on one line	13 / 14	6 / 7	7 / 14
A generated PDF, a printed form with no labels	7 / 14	0 / 7	7 / 14

Half of the fourteen cases have nothing wrong with them, so a checker that found nothing at all would still get 7 right. That is the last column, and it is why the problems-found column matters more. Reading the case data directly, it finds all 7 problems. Reading the generated PDFs, it finds 6: the one it misses is a changed model number, printed under a heading the reader does not recognise.

On the printed form with no labels, it cannot tell which value is which. It places no fields, flags the documents for a person to review, and does not report them as clean. That is the right behaviour, and it scores the same as finding nothing.

What the PDF results do not show

The PDFs were drawn by this project, and the reader was built to recognise the labels they use. It finds each field by looking for known label words, and not one of the 20 keyword groups it uses contains a word that the generated documents do not already use. So these rows show that the reader works on clean documents of the kind it was built with. They do not show that it can read paperwork written by someone else.

What it does not do yet

It reads only clean PDFs that this project generated. It cannot handle scanned documents, stamps or photographs, and no AI model reads the page. Real paperwork would need a proper document-reading step, and test cases built from images of real documents.
It checks one rule on two documents: that details in one document must not contradict the others or the credit (UCP 600 article 14(d)), plus the deadline and notice rules (articles 14(b) and 16). Other articles are not covered yet. Its results name the rule it applied, but do not yet list every rule it did not.
One person wrote all twenty test cases, and the ones held back for a final test are no longer unseen. A fair measure of how well it works on new material needs cases written by someone else, or real documents.
The tests check that it finds the same problems the experts found. They do not check whether an experienced checker would accept its reasoning. That second kind of test has been designed but not built.
Reading PDFs, it falls short of the project's own pass mark, and that is reported as a failure rather than adjusted to pass.

How it was checked

Besides several hundred automated tests, a separate AI agent reviewed the latest changes eight times during the build and tried to find what was wrong. Between them, the eight reviewer passes found 97 defects, all in code that was passing its tests at the time. The counts per pass were 11, 12, 8, 11, 13, 5, 8 and 29. The last of them reviewed this website and the demo before they went live.

What is real and what is made up

Real: the rules, cited by article number from UCP 600, and the published disputes the test cases are based on.
Made up: every document, company, bank, credit number and banking calendar. The demo turns away the names of real banks, shipping lines and traders on its blocklist.
No text from UCP 600 or its companion guide, ISBP, is reproduced anywhere in this project, only article numbers and short paraphrases, and a build check enforces that. Both are ICC copyright.

Try it

The demo page runs the real checker. Pick a test case, change a value on one of the documents so it no longer matches the credit, and press Check documents. You can also have it read a generated PDF instead of the raw data, give it the form with no labels and watch it hand the case to a person, move the notice date past the deadline, or alter one entry in the record and watch the check catch it.

If you do this work for a living and something here is wrong, I would like to know which part.