EXIMLetters of credit — for exporters presenting documents

Examine the letter of credit before the bank does.

Two-way and three-way examination between the credit, the draft credit and the proforma invoice or contract underneath it. Over two hundred configurable checks span nineteen document types and twenty-three pairings between them.

Request a pilot What it does not do yet

What it does

Built to produce a verdict, not a to-do list.

Letters of credit examined before a bank sees them.

Two-way and three-way examination between the credit, the draft credit and the underlying proforma or contract
Over two hundred configurable checks spanning nineteen document types and twenty-three pairings between them
Every finding names the field, the two documents, the expectation and the consequence

app.docinflow.ai

Trade Finance in DocInflow

What it actually does, step by step.

Each stage below is a real part of the product, not a category. The counts come from the configuration the product ships with.

209

checks in four shapes — 147 field, 26 date, 23 clause, 13 risk scanners

match types, from character-perfect to “broader, never narrower”

deadline clocks, each clearing on evidence rather than a tick

Examine the credit, tag by tag

Thirty numbered rules, each carrying its SWIFT tag — :59 beneficiary, :32B amount, :47A conditions
Nine match types, so the port of loading is tested differently from the beneficiary name
The score is recomputed in code from the field verdicts, never taken from the model
Several proforma invoices are totalled into one credit before anything is judged

Own the catalogue, do not inherit it

209 checks in four shapes: field comparisons, date logic, clause patterns, risk scanners
The document topology is data too — 22 pairings, each with its fallback ancestors
Your rows shadow the shipped defaults; the defaults themselves cannot be edited
Four editable tabs, and a prompt preview that costs no tokens to look at

Deterministic first, AI only where it earns it

Tolerances, date arithmetic and format checks decided in code, bit for bit
A strict mismatch escalates, because “Co.” against “Company” is a judgement
An ambiguous date escalates rather than being guessed at
A check that could not be judged is surfaced, never counted as a pass

Run the shipment as three stages

Nineteen document types across pre-shipment, shipment and post-shipment
A failed stage invalidates everything downstream, so nothing stands on a broken position
An accepted amendment is overlaid on the credit before any check runs, latest wins
Several files of one type merge into one logical document, with conflicts recorded

Watch four clocks at once

Credit expiry, latest shipment, the presentation window, and FEMA realisation
Each clears on evidence — an on-board date, a flight date, a realisation date
A portfolio view ranks flows worst first, banded overdue, urgent and upcoming
The presentation window defaults to 21 days and is capped at credit expiry

Draft the credit, then hand it to SAP

Every MT700 tag computed in code from your proforma and purchase order
A port allowlist, so an inland city is never promoted to a port of loading
Field 47A assembled from a condition library in three tiers you can toggle
Seventy-four mapped SAP fields; a push is refused listing exactly what is missing

Examine the credit, tag by tag

Thirty numbered rules, each carrying its SWIFT tag — :59 beneficiary, :32B amount, :47A conditions
Nine match types, so the port of loading is tested differently from the beneficiary name
The score is recomputed in code from the field verdicts, never taken from the model
Several proforma invoices are totalled into one credit before anything is judged

Own the catalogue, do not inherit it

209 checks in four shapes: field comparisons, date logic, clause patterns, risk scanners
The document topology is data too — 22 pairings, each with its fallback ancestors
Your rows shadow the shipped defaults; the defaults themselves cannot be edited
Four editable tabs, and a prompt preview that costs no tokens to look at

Deterministic first, AI only where it earns it

Tolerances, date arithmetic and format checks decided in code, bit for bit
A strict mismatch escalates, because “Co.” against “Company” is a judgement
An ambiguous date escalates rather than being guessed at
A check that could not be judged is surfaced, never counted as a pass

Run the shipment as three stages

Nineteen document types across pre-shipment, shipment and post-shipment
A failed stage invalidates everything downstream, so nothing stands on a broken position
An accepted amendment is overlaid on the credit before any check runs, latest wins
Several files of one type merge into one logical document, with conflicts recorded

Watch four clocks at once

Credit expiry, latest shipment, the presentation window, and FEMA realisation
Each clears on evidence — an on-board date, a flight date, a realisation date
A portfolio view ranks flows worst first, banded overdue, urgent and upcoming
The presentation window defaults to 21 days and is capped at credit expiry

Draft the credit, then hand it to SAP

Every MT700 tag computed in code from your proforma and purchase order
A port allowlist, so an inland city is never promoted to a port of loading
Field 47A assembled from a condition library in three tiers you can toggle
Seventy-four mapped SAP fields; a push is refused listing exactly what is missing

Scroll sideways for the rest of the flow.

The expensive discrepancy is the one your bank finds.

A refusal at presentation costs time you do not have and fees you did not budget for. The same check at your desk costs minutes.

Core capabilities

Strengthen your trade documentation end to end

Catch it here, or explain it to your bank

Thirty numbered rules run against the credit, each carrying its SWIFT tag, and nine match types decide what counts as a discrepancy — so “may be broader but never narrower” on the port of loading is a different test from character-perfect equality on the beneficiary name.

└─Real risks stand out because tolerable differences stay quiet
└─The score is recomputed in code from the field verdicts, never taken from the model
└─Several proforma invoices are totalled into one credit before anything is judged

209 checks, and every one of them is yours

209 checks ship in four distinct shapes — 147 field comparisons, 26 date-logic rules, 23 clause patterns and 13 risk scanners — cloned into your organisation at onboarding as rows you then edit. The shipped defaults cannot be altered, so a change is always yours and always reversible.

└─Retune a check your bank is strict about without forking anything
└─The document topology is data too — 22 pairings with their fallback ancestors
└─Preview the exact instruction set before spending a token on a run

The same answer every single time

Numeric tolerances, date arithmetic and format checks are decided in Python and are bit-for-bit reproducible. The model is called where an answer needs materiality — a strict mismatch on “Co.” against “Company” — and an ambiguous date escalates rather than being guessed at.

└─The same documents and settings give the same verdict every time
└─A check that could not be judged is surfaced, never counted as a pass
└─Findings are labelled in the report by which tier decided them

Four deadlines that cannot quietly slip

Credit expiry, latest shipment date, the presentation window and FEMA realisation run per flow. None of them clears on a manual tick — the bill of lading's on-board date clears the shipment clock, the e-BRC's realisation date clears FEMA.

└─A deadline cannot be marked done by someone who has not got the document
└─The presentation window defaults to 21 days and is capped at credit expiry
└─The portfolio ranks flows worst first, banded overdue, urgent and upcoming

How the check works

The documents, and what is compared between them.

What changes

The difference is where the check happens.

Typical practice

A documentation team checks the credit line by line by hand, and finds out whether they got it right when the bank responds days later.

With DocInflow

The examination runs in minutes against a catalogue of checks you own, with each finding explained and traced to the document that caused it.

Typical practice

The credit arrives already drafted around the applicant's preferences, and unworkable conditions surface at presentation.

With DocInflow

You bring your own draft credit to the conversation, built from your trade terms, with conditions no document could evidence filtered out.

Not built yet — said plainly

Documentary collection and advance-payment trade — the pre-shipment stage covers deals with no credit involved, but the later stages assume one

We publish what is not built yet because you will find it in the first ten minutes of a trial anyway — and because a vendor who tells you the boundary is the one worth believing about everything inside it.

The rest of the platform

It is one system underneath.

Same document layer, same control model, same audit trail — which is why a price agreed in a contract can be checked on an invoice and land in the ledger without leaving the product.

CLM

Contracts

The rate card becomes a control, not a filed document.

Explore

P2P

Procure-to-Pay

Order, receipt and invoice matched line by line.

Explore

O2C

Order-to-Cash

Prove you delivered exactly what was ordered.

Explore

R2R

Accounting

A real double-entry ledger, not a reporting layer.

Explore

Run it on your own documents.

A pilot runs on your paperwork, not a sample file. Send a real set — a purchase order with its invoice, or a letter of credit with its proforma invoice — and we will run the checks on it.

Request a pilot