How international rate monitoring is set up in finance and ERP systems

In most finance and ERP systems, international rates live in one central table that treasury owns. An external market feed loads them on a schedule. Each rate carries a type and an effective date. Every module that converts currency, revalues balances or translates subsidiaries for consolidation then reads from that table.

What the rate table holds

The table is simple in shape. Each row pairs a source currency with a target currency, a rate type, an effective date and a value. The rate type does most of the work. A spot type usually drives day to day postings. A period average type serves profit and loss translation. A closing type supports balance sheet revaluation. Some organisations add a budget or planning type so forecasts are not disturbed by market movement.

Interest rates often sit in a separate structure. That might be a reference rate table for benchmark curves or a set of conditions attached to loans, deposits and intercompany facilities. These are easy to overlook because they rarely sit on the same screen as currency rates.

Where the rates come from

Most setups pull rates automatically from a market data provider or a central bank publication. An interface job fetches the values, maps provider codes to internal currency codes and writes them into the table. Where no feed exists, someone in treasury keys rates by hand from an agreed source.

The weak point is usually the mapping. Provider quotes can be direct or indirect, and the system needs to know which way round a pair is stored. A pair entered upside down will post cleanly and still be wrong. Many systems also allow triangulation through a base currency, so a missing cross rate gets calculated without anyone noticing.

How the rates flow into transactions

When an invoice, payment or journal is entered in a foreign currency, the system looks up the rate for the document date and the rate type set on that transaction type. The converted amount lands in the ledger alongside the original currency amount. Both are kept.

Overrides are common. Users with the right permission can type a rate onto a document, often to match a bank confirmation or a contract. A tolerance check compares the typed rate against the table and blocks or warns when the gap is too wide. The same idea appears in commitment and obligation control, where the system checks that an expenditure stays within an agreed tolerance of the amount originally recorded. Foreign currency orders can drift outside that tolerance purely through rate movement, so the two checks interact.

Revaluation and consolidation

At period end a revaluation run restates open foreign currency balances at the closing rate. Unrealised gains and losses post to designated accounts and usually reverse at the start of the next period. Open receivables, payables, bank accounts and undelivered orders in foreign currency are the usual targets.

Consolidation sits one layer above. Each subsidiary ledger is translated into the group currency using closing rates for balance sheet items and average rates for income and expense. The difference goes to a translation reserve. Intercompany balances need both sides translated with matching rates, or eliminations will not net to zero.

Interest rates and open balances

Interest rates feed several calculations that are less visible. Late payment interest on overdue receivables is one, and it may be assessed alongside penalties and administrative fees when a debt ages. Intercompany loan interest is another, along with accruals on deposits and borrowings. When a benchmark rate changes, someone has to decide whether existing agreements pick it up automatically or only at reset dates written into the contract.

Controls that usually sit around it

Typical controls are straightforward. A treasury user approves loaded rates before they become active. A variance report flags any rate that moved beyond a threshold since the last load. Access to edit the table is restricted and logged. Missing rate checks run before revaluation so the job does not fall back to an old value.

Auditors tend to ask for evidence of the source and of the approval. Keeping the provider file or a screenshot attached to each load saves argument later.

Questions to ask the people who run it

The documented setup and the working practice often diverge. These questions tend to surface the gap:

• Which rate type does each transaction type actually use, and who last checked that configuration?
• When the feed fails, what happens? Does someone key rates by hand, and from which source?
• How often do users override rates on documents, and does anyone review those overrides?
• Are any currency pairs stored inverted, or calculated through triangulation?
• Which balances does the revaluation run include, and are any accounts left out on purpose?
• Do subsidiaries load their own local rates anywhere outside the central table?
• How are intercompany rates agreed so both sides translate the same way?
• Who updates interest rates on loans and overdue receivables when a benchmark moves?
• What gets corrected manually after consolidation, and why?
• If a wrong rate posts, how is it found, and how far back does the correction reach?

The answers to the last two usually reveal where the real effort goes.

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.