How currency conversion is usually set up in finance and ERP systems

Most ERP systems convert currency using a central rate table, a set of rate types and fixed rules about which rate applies to which transaction. Each company has a functional currency. Entries are converted when posted, open balances are revalued at period end, and group results are translated during consolidation.

Currencies carried on every entry

A typical ledger line stores more than one amount. It keeps the transaction currency, meaning what the invoice or payment actually said. It keeps the functional currency of the legal entity, which drives statutory books. Many systems add a group or reporting currency so consolidation can run without rework.

These currencies are set on the company code or ledger during implementation. Changing them later is painful. A new reporting currency usually means a conversion project with historical data loads, not a configuration tweak.

The rate table and rate types

Exchange rates live in a single table keyed by currency pair, date and rate type. Rate types separate the purposes a rate serves. A spot or daily type handles ordinary postings. An average type often feeds income statement translation. A closing type supports revaluation and balance sheet translation. Some organisations keep a budget or planning type so forecasts stay stable while actuals move.

Rates normally arrive through an automated feed from a bank or market data provider. A scheduled job loads them, and a treasury or accounting owner reviews exceptions. Manual entry still happens for thinly traded currencies or when the feed fails. That manual path is where errors creep in, so it deserves its own approval step.

The system also needs a rule for missing dates. Most look back to the latest available rate. A few block posting entirely. Knowing which behaviour is configured explains a surprising number of odd postings.

Conversion at posting

When a user or interface posts a document, the system picks the rate for the document date or posting date, depending on configuration. It converts the amount and stores both values. Users can sometimes override the rate. Where that is allowed, a tolerance check should compare the entered rate to the table and warn or stop when the gap is too wide.

Rounding differences go to a dedicated account. They look trivial, yet a growing balance there often points to a broken interface or a misconfigured decimal setting.

Settlement and realized differences

An invoice booked at one rate is rarely paid at the same rate. When the payment clears the open item, the system calculates the difference and posts it to a realized gain or loss account. Payment runs in foreign currency follow the same logic. The bank charges the functional currency equivalent, and the clearing entry absorbs the gap.

Bank statements complicate this. If the bank applies its own rate and the system applies the table rate, a small residual appears on every foreign payment. Some teams accept the bank rate on import to avoid that noise.

Period-end revaluation

At close, a revaluation program restates open receivables, payables and foreign currency bank balances at the closing rate. The result posts to unrealized gain or loss accounts. In most setups that posting reverses on the first day of the next period, so the eventual settlement can calculate the true realized figure.

Which accounts get revalued is a configuration choice. Missing a balance sheet account here is a common reason foreign currency reports fail to tie back to the general ledger.

Translation for group reporting

Consolidation translates each subsidiary from its functional currency into the group currency. Balance sheet items generally use the closing rate. Income and expense items use an average rate. Equity often stays at historical rates. The difference lands in a translation reserve within equity, not in profit.

Some groups run translation inside the ERP. Others push trial balances into a separate consolidation tool with its own rate table. Two rate tables that are meant to match but are maintained by different people will drift apart sooner or later.

Controls that tend to matter

Restricting who can change rates matters more than most approval workflows. So does reconciling the gain and loss accounts each period and asking whether the movements make sense against what the currencies actually did. A short report tracing revaluation results to ledger balances catches configuration gaps early.

Questions to ask the people who run the process

Written procedures describe the intended setup. Daily practice drifts. These questions tend to surface the gap:

• Where do the rates come from, and what happens on the morning the feed does not arrive?
• Who can change a rate after it is loaded, and is that change logged anywhere anyone reads?
• Do users override rates on documents, and why?
• Which rate does the bank use on foreign payments, and how is the difference cleared?
• Is revaluation run by a scheduled job or by a person remembering to run it?
• Are any balance sheet accounts deliberately excluded from revaluation?
• Does the consolidation tool use the same rates as the ERP, and who checks?
• What gets adjusted by journal after close because the system result looked wrong?
• Which currencies cause trouble repeatedly, and what workaround exists for them?

The answer to that last question usually reveals the most.

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.