Letter of Credit Management in ERP: Banks Deal With Documents, Not Goods

The bank does not care about your goods

The most important rule in documentary credit practice is not a technicality, it is the starting point of the whole mechanism. A credit is independent of the sales contract it supports (UCP 600 Article 4), and banks deal with documents rather than with goods or services (Article 5). Whether the cargo was sound, whether the buyer is satisfied, whether a side agreement collapsed — none of it changes the bank's position. If the documents presented conform on their face to the terms of the credit, the bank pays.

The mirror image of that principle is where the exporter's risk sits: your payment does not depend on what you shipped, it depends on what you presented. Which means letter of credit management is not about recording a payment method on a sales order. It is about completing the document-versus-terms consistency check before presentation, while the documents can still be changed.

That distinction explains why a system described as supporting letters of credit is often not enough. If the module stores an L/C number, an amount and an expiry date as fields on an order, it is maintaining a register rather than managing risk. What actually needs managing are the deadlines, because all of them are one-directional.

Three clocks that decide whether you get paid

Clock one: five banking days

After receiving a presentation, the issuing bank has a maximum of five banking days following the day of presentation to examine the documents and decide whether to honour (sub-article 14(b)). That limit is firm: a bank cannot extend it on the grounds that the documents were complex or that staff were unavailable.

The practical reading cuts both ways. For the exporter, five banking days after presentation is when funds can reasonably be expected. For the internal process, it means that once documents leave your hands there is no correction window left. The consequence for system design is direct: presentation self-checks must complete at the document preparation stage, not at the point where a discrepancy notice arrives from the bank.

Clock two: twenty-one days after shipment

A beneficiary may present up to twenty-one calendar days after the date of shipment (sub-article 14(c)), and in any event within the validity of the credit. Two clocks run at once: shipment starts the presentation window, and expiry caps it.

Nothing about this should depend on memory. When the shipment event is recorded, the system should derive the latest presentation date and back-schedule the deadlines for document preparation, booking, insurance and certificates of origin from it. A system that does not do this arithmetic is leaving the single most consequential date in the transaction to a person with a spreadsheet.

Clock three: the instalment trap

The third deadline is the one most often missed. Under Article 32, when an instalment is not drawn or shipped within the period allowed for it, the credit ceases to be available for that instalment and for any subsequent instalment. A delay on the first shipment of a staged credit does not merely affect the first shipment — it extinguishes the remainder of the credit.

For any order shipping in several lots, this means the credit has to be modelled instalment by instalment rather than as a single drawing limit. Systems that record only a total amount have no structure in which to raise the warning, which is precisely why the risk goes unnoticed until it has already materialised.

Autonomy means the credit is its own entity

Since a credit stands apart from the contract it secures, it should also stand apart in the data model rather than being a set of fields hanging off a sales order. Terms, amendments, presentations and settlements each have their own timeline and status, and one credit may cover several orders or several shipments. Only as an independent entity can the system answer the question that matters operationally: which document is still missing before this credit can be presented.

There is a related detail worth designing for. A credit can neither be amended nor cancelled without the agreement of the issuing bank, the confirming bank if any, and the beneficiary (Article 10). Amendments therefore have versions, and the system has to retain them — otherwise, when a discrepancy is disputed, there is no way to establish which terms were actually in force on the presentation date.

What the system must check, and when

Translated into requirements, the three clocks become four moments at which the L/C module has to do something.

• On receipt of the credit: parse the terms into structured data — document list, expiry, latest shipment date, latest presentation date, partial shipment and transhipment rules — and flag any required document your existing templates cannot produce.
• At scheduling and booking: validate the latest shipment date against production and vessel schedules; for staged credits, validate each instalment separately.
• At document preparation: run cross-document consistency checks, including that data does not contradict other documents or the credit itself, and that transport documents carry no adverse notation.
• Before presentation: generate the self-check list and the presentation countdown, and archive the submitted version so the as-presented set can be reconstructed later.

One rule is worth calling out because it is commonly implemented wrong. Banks accept only clean transport documents, meaning documents that do not expressly declare a defective condition of the goods or packaging (Article 27), and the word clean itself does not have to appear on the document. A system that validates for the literal string is checking the wrong thing; what it should be looking for is the presence of adverse clauses. The examination standard the bank applies is conformity on the face of the documents, so the internal check should mirror that logic rather than invent its own.

Where the letter of credit meets the rest of the export cycle

A credit is not an isolated step. Settlement feeds verification, verification feeds the rebate, and a missing document anywhere in that chain slows the rebate down. That is the argument for keeping L/C data inside the same system as settlement and rebate records, rather than having one copy in the banking portal, one in a spreadsheet and one in the ERP. The link between settlement and rebate is set out in our export tax rebate guide; the handling of settlement and exchange differences across currencies is covered in multi-currency ERP for trading companies; and if the credit covers a CIF sale, the freight and insurance have to be separated out of the rebate base, which FOB versus CIF pricing explains.

Where documents are also the trigger for customs and rebate data, the same underlying discipline applies as in customs declaration integration: the value of the integration is that a document is captured once and used downstream, not that it is typed in faster.

How to test it in a demo

• Hand over a real credit and have the vendor enter it live; watch whether the system derives the latest presentation date and back-schedules the related steps.
• Ask how instalments are modelled, whether each instalment is separately controlled, and where the Article 32 exposure is warned about.
• Ask how amendments are versioned and whether the terms in force on a given date can be reconstructed.
• Have them demonstrate a discrepancy being caught: at which step it was caught, and what the correction path looks like.
• Ask who maintains the presentation self-check list — built-in rule set, or configuration you have to author yourself.
• Check whether settlement data flows into verification automatically or has to be keyed a second time.

Why this is worth systemising at all

A credit is often described as the safest payment method available to an exporter, and in the sense that it substitutes a bank's undertaking for a buyer's willingness to pay, that is true. What the description omits is that the safety is conditional on documentary performance, and documentary performance is a project with deadlines. The three clocks are all real, all one-directional, and all knowable in advance. Treating them as configuration rather than as things to remember is the entire case for having L/C management in the system at all.