Upload PI, PO, CI, PL, LC and B/L Together and Cross-Check Them in One Pass

Checking documents one at a time cannot find mismatches, because a mismatch only exists between two documents. What a multi-document cross-check does: one upload of the whole set, then field-by-field comparison across every document, with missing documents flagged.

Last updated: 2026-08-10 · English

The leading cause of refused payment in export trade is not a wrong calculation — it is documents that do not agree. That has an awkward implication for how most people check: reviewing one document at a time cannot possibly find the problem, because the problem does not live inside any single document. It exists between two of them. Finding it requires holding the whole set at once.

What "cross-checking the set" means in practice

You upload what you have — proforma invoice, purchase order, commercial invoice, packing list, letter of credit, bill of lading, certificate of origin, sales contract, in any combination — and the comparison runs as a matrix: field by document, not document by document. For each field that should be identical across the set, every document's value is read and compared against the rest.

The fields that carry the most risk:

• Amount and currency — including whether two figures differ because the trade terms differ, which is legitimate, or because someone made an error, which is not.
• Quantity and unit — pieces against cartons against pallets is the classic false alarm, and a checker that cannot tell the difference is worse than no checker.
• Goods description and specification — the field where strict compliance bites hardest.
• Parties — shipper, consignee, notify party, applicant, beneficiary, spelled identically.
• Trade terms and named place — the reference against which freight and insurance obligations are read.
• Ports, dates and shipping marks — loading and discharge ports, latest shipment date, presentation period.

Flagging what is absent, not only what is wrong

A set can fail because a document is missing rather than mismatched. If the credit calls for an insurance certificate under CIF and none was uploaded, listing the field comparisons is not enough — the gap itself is the finding. A useful check reports the documents it expected to see given what you did upload, and says plainly which are not present.

The reason to state this as a separate capability is that it is the failure mode people notice last. Everyone re-reads the invoice; almost nobody notices that the certificate of origin was never issued.

Suspected, not proven

The hardest part of cross-checking is not finding differences. It is deciding which differences matter. Two documents can legitimately disagree — a CIF invoice exceeds a FOB proforma because insurance and freight were added; a packing list counts cartons where an invoice counts pieces; a scan of a faxed bill of lading yields an uncertain character.

So findings are graded rather than pooled. A provable contradiction is stated plainly and pointed at. Anything resting on an uncertain reading, a unit difference or a term difference is dropped to needs review, with the reason attached. What a checker must never do is declare a document set defective on the strength of a blurry scan.

Why the split matters

Two designs exist for this work. One sends the whole set to a model and returns a summary. It reads well and cannot be audited: ask which rule produced a finding and there is no answer, and run it twice and you may get two answers.

The other splits the work. AI only reads the characters — extracting fields from PDFs, scans and photos, and reporting its own confidence. Fixed rules make the judgement — comparing those fields under written rules. The consequences are practical: same input, same result; every finding names the document, the line and the rule; low-confidence reads are quarantined as review items instead of feeding conclusions. When a buyer or a bank asks why you amended a document, you have an answer with a citation.