How letter of credit preparation is set up in finance and ERP systems

Letter of credit preparation usually sits across several places. A purchase or sales order lives in the ERP. The facility and the application often live in a treasury module or a bank portal. Accounting entries flow back to the general ledger as memorandum and fee postings.

Where the work starts

On the import side, the trigger is normally a purchase order whose payment terms say the supplier will be paid under a letter of credit. Some ERP setups carry a specific payment term or a flag on the vendor record for this. Others rely on a buyer telling the treasury team by email. The difference matters, because a flag can drive a workflow while an email depends on someone remembering.

On the export side, the starting point is a sales order and the customer's draft or issued credit. The team checks whether the terms can actually be met before goods ship. That check is often done in a spreadsheet or a trade documentation tool, outside the core ERP.

The application itself

The applicant drafts the request to the issuing bank. The content comes from the order: goods description, amount, currency, Incoterms, shipment window, latest presentation date and the list of documents the beneficiary must provide.

Many companies keep a template per supplier or per trade lane. That cuts errors, but templates drift. A clause that suited one shipment gets copied into the next and causes a discrepancy months later.

Submission typically goes through the bank's online trade portal. Larger groups sometimes connect a treasury management system to several banks through a multibank channel, so applications and amendments travel as structured messages. In either case the bank formats the issued credit for the advising bank in the standard interbank format.

How the system holds the credit

Treasury or trade finance modules usually create a record for each credit. Typical fields include the facility it draws on, the bank, the beneficiary, expiry, tolerance, and links to the underlying orders. When this record exists, it becomes the reference for amendments, document presentations and final settlement.

Facility limits are a separate object. Each bank line has a ceiling, and every open credit consumes part of it. A good setup shows remaining headroom in real time. A weaker one leaves that view to a monthly reconciliation against bank statements.

Where no module exists, a register in a spreadsheet does the same job with far less control.

Accounting entries

An issued credit is a commitment, not yet a liability for the goods. Ledgers handle this in different ways. Some post to memorandum or contingent accounts so the exposure is visible without touching the balance sheet. Others track it only in the treasury subledger and disclose it at period end.

Cash margin deposited with the bank needs its own account, since it is restricted. Issuance commissions, amendment charges and advising fees arrive on bank debit advices and are booked as expenses or capitalised into inventory cost, depending on policy. Manual journals are common here because bank charges rarely match a purchase order line. Those journals need routing for approval like any other.

Links to cash forecasting

Expiry and expected payment dates on open credits are useful inputs to the cash forecast. Sight credits pay soon after compliant documents arrive. Usance credits create a known future outflow. When the credit record feeds the forecast automatically, treasury sees the obligation early. When it does not, large payments can surprise the cash position.

Controls that usually apply

Separation between the person who drafts the application and the person who approves it at the bank is the core control. Bank portals support dual authorisation, and it should be switched on. Amendments deserve the same scrutiny as the original, since a changed beneficiary account or extended expiry carries real risk.

Auditors tend to ask for the register of open credits, evidence of approval, and a tie between bank confirmations and ledger balances. A short process memo describing who does what saves time when those requests arrive.

Questions to ask the people who run it

Documented procedures and daily practice often part ways here. These questions tend to surface the gap:

• How does the treasury team learn that a new credit is needed? Is it a system flag, an email, or a phone call from procurement?
• Which template gets used, and when was it last reviewed against current trade terms?
• Who checks the draft against the purchase contract before submission?
• Are amendments approved by the same people as new applications, or does someone handle them alone?
• Where is the master list of open credits kept, and who updates it after settlement?
• How are bank charges matched to the right shipment and booked?
• Does anyone confirm facility headroom before applying, or is that discovered when the bank declines?
• On the export side, who reviews an incoming credit, and how quickly do they raise problems with the customer?
• What happens when documents are rejected for discrepancies? Who negotiates a waiver, and is that recorded anywhere?
• Which steps happen outside the ERP entirely, and why did the team stop using the system for them?

The answers to that last question often explain more than the process documentation does.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.