Currency conversion: what to automate, what to keep human, and the data it needs

Software can already fetch rates, convert transactions, post revaluation entries and flag variances. People still need to choose the rate policy, approve exceptions, judge unusual rates and sign off translated reports. None of it works until rate sources, currency codes and conversion dates are clean and agreed.

Where the work actually happens

Currency conversion rarely sits in one place. It shows up when an invoice arrives in a foreign currency. It shows up again when a payment is scheduled, again when the bank executes it, and once more at period end when open balances are revalued. Each of those moments can use a different rate. The gaps between them are where gains, losses and most of the confusion come from.

Anyone changing this process should map every point where a foreign amount becomes a functional amount. The documented flow usually shows one or two. The real flow often has more, including spreadsheets kept by treasury or a regional office.

Steps software handles well today

Rate retrieval is the easiest win. A system can pull daily rates from an agreed provider, store them with a timestamp and refuse to post anything when the rate for that date is missing. This removes the habit of someone typing a rate from a website.

Conversion of individual transactions is also safe to hand over. Once the rate type is defined for each transaction class, the arithmetic is mechanical. Spot, average and contract rates can all be applied by rule.

Period end revaluation of open receivables, payables and bank balances follows a fixed method. Software can calculate unrealised gains and losses, post them and reverse them on schedule without manual journals.

Before payments go out, automated quality checks earn their keep. A disbursement schedule can be tested against the converted invoice amount, the currency of the supplier's bank account and tolerance limits. Mismatches get held before release instead of discovered on the bank statement.

AI tools add value in narrower spots. They can read the currency from a scanned invoice, match incoming receipts that differ from the expected amount because of bank charges or rate movement, and draft a first explanation of why a realised loss looks larger than usual. Each of these produces a suggestion that someone reviews.

Steps that still need a person

Setting the rate policy is a human decision. Which provider, which time of day, when to use a booked contract rate over market rates, how to treat currencies with official and parallel rates. These choices affect reported results and sometimes tax, so a named owner must make them and record why.

Exceptions need judgement. A rate that moved sharply overnight may be correct or may be a feed error. A customer who paid in the wrong currency may need a refund, a new invoice or a written agreement. No rule covers every case well.

Reconciliation of realised differences on revenue and receipts still benefits from someone who knows the customers. Software can show that a receipt fell short. A person decides whether that shortfall is a rate effect to write off, an unauthorised deduction to chase or a pricing error to fix upstream.

Translated reports going to management, auditors or regulators should carry a human sign off. The preparer needs to confirm that foreign currency figures trace back to general ledger balances and that the rates used match the stated policy.

What the data must look like first

Currency codes must follow one standard everywhere. Free text such as "dollars" or local symbols will break any automated rule.

Every transaction needs a clear date that drives the rate: invoice date, posting date or payment date. If the business has never agreed which date counts for which document type, automation will simply apply the confusion faster.

Rate tables need a single authoritative source, held in one location, with history preserved. Overwriting yesterday's rate destroys the audit trail.

Vendor and customer master records should state the transaction currency and the bank account currency. When those differ and nobody has recorded it, payments convert twice.

Gain and loss accounts must be separated for realised and unrealised amounts, with clear mapping by entity. Without that, period end figures cannot be explained or traced.

Questions to ask the people who run it

• Which rate does the team actually use when a booked rate is missing, and where does it come from?
• Are any conversions done in a spreadsheet before entry into the ledger?
• How often does a payment amount change between scheduling and release because of rate movement?
• Who decides to write off a small difference on a customer receipt, and is there a limit?
• When the rate feed fails, what happens on that day?
• Which currencies cause the most rework, and why?
• Do any entities revalue using a method different from the group policy?
• When auditors ask how a translated balance was built, how long does it take to show them, and who has to be involved?
• Are there contracts that fix a rate the system does not know about?

The answers usually reveal workarounds that never made it into the process document. Those workarounds are what an automated design has to replace or deliberately keep.

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.