When a stale exchange rate slips into currency conversion

The most common failure is a stale exchange rate. A rate feed fails or arrives late, the system silently reuses its last stored rate, and foreign currency entries post at the wrong value. Reconciliation breaks reveal it. The fix is reloading rates, reconverting affected items and checking every future load.

How it starts

Currency conversion depends on a rate table that someone, or something, refreshes on a schedule. Usually an automated job pulls rates from a market data provider or a central bank source. Sometimes a treasury analyst keys them in by hand.

The trouble begins when that refresh does not happen. The provider changes a file format. A credential expires. A holiday in one market means no rate is published, and the job treats the empty file as a success. Whatever the cause, the table keeps yesterday's figures.

Most finance systems are built to keep working when a rate is missing. They look back to the most recent rate on file and use it. That design choice prevents transactions from stalling, which is helpful. It also means nothing stops, nothing errors and nobody gets told.

A second version of the same failure involves the wrong rate type. A spot rate gets applied where a contract or budget rate was required, or the reverse. The number exists and is current, but it belongs to a different purpose.

Why it goes unnoticed

For a while, the difference is small. Currencies that move slowly hide the problem almost completely. Supplier invoices convert, customer receipts convert, payment runs go out. Each document looks normal on its own.

The people approving payments see amounts in the transaction currency and trust the system's functional currency value. Few of them have any reason to check the rate behind it.

How it is spotted

Detection rarely comes from the conversion step itself. It shows up downstream, where converted values meet an independent source.

Bank reconciliation is often first. A foreign currency payment settles at the bank's actual rate, and the gap against the booked amount is larger than usual. One odd item gets written off as a realized difference. A cluster of them on the same dates should not be.

Revenue reconciliation catches it from the other side. Receipts in a foreign currency fail to clear open receivables cleanly, leaving residual balances that look like short payments from customers.

At period end, revaluation of open balances produces unrealized gains or losses that swing sharply, then reverse. That pattern points to entries booked at a rate that was already out of date.

The firmest signal comes when preparing foreign currency reports and statements of accountability. Those reports have to trace to general ledger balances. If the subledger, the ledger and the report each tell a slightly different story, a rate problem is a strong suspect. Checking the rate table for repeated values across consecutive dates usually confirms it within minutes.

How it is fixed

Start by establishing the window. Find the last date a genuine rate loaded and the date it was restored. Every transaction dated inside that gap is a candidate.

Load the correct historical rates for the missing dates from an authoritative source. Keep evidence of where they came from, since auditors will ask.

Next, decide how to correct each affected item. Open documents can often be reconverted in place. Posted and settled items need adjusting entries, booked to the gain and loss accounts the policy specifies. Payments already disbursed cannot be recalled for a rate error, so the correction lives entirely in the books.

Rerun revaluation for the affected period once the rates are right. Then reconcile again, against the bank, the receivables ledger and the reports owed to oversight bodies. If any reports were already submitted, a revised submission may be required.

Prevention matters more than the cleanup. Put a completeness check on the rate load that fails loudly when a currency is missing or unchanged from the prior date. Add a tolerance check that flags any rate moving outside an expected band. Route both alerts to a named person, not a shared inbox. Include a rate validation step in the quality assurance done before payment schedules are certified.

Questions to ask the people who run it

What the procedure manual says and what happens on a busy morning are often different. These questions tend to expose the gap:

• When the rate feed fails, who finds out, and how?
• What does the system do when no rate exists for a date? Has anyone tested it?
• Are rates ever typed in by hand? Who checks those entries?
• Which rate types exist, and who decides which one a transaction uses?
• How are market holidays handled for each currency?
• When a bank difference appears on a foreign payment, what happens to it in practice?
• Has a rate correction ever been needed? How long did it take to find the affected transactions, and what made it hard?
• Can the foreign currency report be traced to ledger balances without manual workarounds?
• If the person who maintains the rate table is away, who covers?

Listen for workarounds people describe casually. A spreadsheet used to double check rates, or a habit of reviewing the table first thing after a long weekend, is a control that exists only in someone's routine. Any redesign should either formalize it or replace it with something that does not depend on memory.

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.