When the rate table goes stale: a common failure in monitoring international rates

The most common failure is a stale rate table. A scheduled rate load fails or loads the wrong rate type, the system quietly reuses old rates, and foreign currency balances are revalued and consolidated on numbers nobody approved. It shows up later as unexplained translation differences.

How it starts

Most rate tables are fed automatically from a market data provider or a central bank feed. The feed runs overnight. When it works, nobody looks at it.

The trouble begins with something small. A provider changes a file format. A credential expires. A new currency is added to the ledger but never mapped to the feed. Sometimes the load succeeds but brings in spot rates where the ledger expected period average rates, because someone edited the job during an upgrade.

In each case the accounting system does not stop. It looks for a rate on the posting date, finds none, and falls back to the most recent one it holds. That fallback is a convenience setting, often switched on years ago so that postings would never be blocked. It is the reason the failure stays hidden.

Why nobody notices at first

Transactions keep posting. Invoices in foreign currency are converted. Receivables and payables are revalued at period end. Every screen looks normal.

Currency movements are usually modest from one day to the next, so the error in any single document is too small to catch the eye. It builds quietly across many entries. Whoever owns the rate process often sits in treasury, while those who feel the effect sit in accounting and consolidation. Neither group sees the whole picture.

How it is spotted

Detection tends to come from the edges of the process, not from the rate monitoring itself.

Intercompany reconciliation is the usual first warning. Two subsidiaries record the same balance in different currencies. If one converted at a fresh rate and the other at an old one, the elimination will not net to zero, and the difference lands in a suspense or rounding account that suddenly looks too large.

Tolerance checks catch it as well. Where obligations, commitments or expenditures are recorded in foreign currency, a control usually compares the converted amounts against an allowed variance. A run of exceptions against a single currency, all leaning the same direction, points at the rate and not at the transactions.

Aged receivables reports give another clue. An old foreign currency invoice whose home currency value has not moved for several reporting periods, during a time when the market clearly moved, is a strong sign the revaluation used a frozen rate.

The most reliable test is the dullest one. Pull the rate table, sort it by effective date, and look for gaps or repeated values.

Fixing the period that went wrong

Start by establishing exactly when the feed stopped and which currencies and rate types were affected. Do this before touching any entry. Correcting one currency while another is still broken creates a second round of differences.

Load the correct rates with their proper effective dates, taken from the approved source. Do not type them in from a website, because that breaks the audit trail and the next reviewer will ask where they came from.

Then rerun revaluation for the affected period and currencies. Most ledgers will reverse the prior revaluation and post a new one. Check the result against intercompany balances again; the eliminations should now clear. Any residual difference usually belongs to a document that was converted at entry with a manual override, and those need individual review.

If the period is already closed and reported, the decision about restating or correcting in the current period belongs to the controller, guided by materiality. Record the decision and the reasoning either way.

Stopping it coming back

The single most useful change is to turn off silent fallback, or at least make it noisy. A missing rate should raise an alert to a named person, not a log entry nobody reads.

Add a daily completeness check that compares the currencies held in the ledger with those present in the latest load. A separate reasonableness check, comparing each new rate against the prior one and flagging large jumps, catches wrong rate types loaded under the right label.

Give the feed a clear owner. Treasury often maintains it while accounting depends on it, and that gap is where failures sit unnoticed. Written agreement on who watches the load and who signs off period end rates closes the gap.

Questions to ask the people who run it

What a procedure document says and what happens at the desk often differ, so ask directly.

• When a rate is missing, what does the system actually do, and who finds out?
• Has anyone ever entered rates by hand? From what source, and how often does that happen in practice?
• Which rate type does each ledger expect for revaluation, and which does consolidation expect? Are they the same?
• Who checks the rate table before period end close, and what exactly do they look at?
• When intercompany balances fail to eliminate, where does the difference go, and who clears it?
• Are new currencies added to the feed when they are added to the ledger, or later?
• If the feed stopped tomorrow, how long before someone would notice, and what would tip them off?

The answers to the last question usually reveal more than any process map.

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.