Last reviewed: 28 October 2026. Accounting standards and software import requirements change; verify the current standard and your accounting software’s documentation before relying on any specific treatment. This guide is general information, not accounting advice.
A supplier invoice lands in USD. The bank debits INR. The accounting system expects a transaction-date rate, but the bank used its own rate two days later. Three numbers, three dates, and the bookkeeper is reconciling a difference that could be a fee, a timing gap, or an exchange loss.
That gap between what the bank statement reports and what the accounting record needs is where multi-currency bookkeeping breaks down. The workflow that closes it is consistent: identify every currency in play, preserve the original transaction data before anything is converted, capture the bank’s actual movements and any separately disclosed fees, apply the exchange rate the accounting policy requires rather than only the rate the bank shows, and validate the prepared data before it reaches the accounting software. This guide walks through that process step by step.
On this page
What Is Multi-Currency Bank Statement Processing?
Multi-currency bank statement processing is the workflow of extracting transaction data from bank statements that involve more than one currency, preserving the original currency context alongside dates, descriptions, and amounts, and preparing that data for accounting software so it supports accurate measurement, review, and reconciliation under the applicable accounting framework.
This is different from converting a PDF to a spreadsheet. A generic extraction might pull dates and amounts but silently drop the currency code, merge the foreign amount with the account-currency debit, or lose the separately stated fee. Multi-currency processing treats the currency detail as data that must survive extraction, not formatting to be discarded.
Four currency concepts every bookkeeper should understand
| Term | Meaning | Why it matters |
|---|---|---|
| Transaction currency | The currency in which a transaction is denominated | Preserves the original transaction context |
| Bank-account currency | The currency in which the bank account is maintained | Explains the actual account movement |
| Functional currency | The currency of the entity’s primary economic environment, as defined by the applicable framework | Determines accounting measurement |
| Presentation currency | The currency used to present the financial statements | Relevant when the statements use a different currency |
These are distinct concepts, not necessarily four different currencies. A UK company with a GBP functional currency, a GBP bank account, and a USD supplier payment has two currencies in play, not four.
Step 1: Identify the Currencies and Extract the Original Transaction Data
Before working with any converted value, identify what the statement actually tells you.
Identify the statement and account currency
Record the financial institution, the statement period, and the account currency, holding any account identifier inside the firm’s secure workflow rather than publishing or sharing it unnecessarily. The account currency matters more than it seems: a USD-reporting company can hold EUR, GBP, or INR bank accounts, and each requires separate foreign-currency balances in the ledger. Treating the company’s base currency as the bank account’s currency is one of the most common setup errors in multi-currency bookkeeping.
Preserve the original transaction amount
If the statement shows a foreign-currency amount and currency code, keep both. Do not overwrite the foreign amount with a converted value during extraction. That original figure is the only direct evidence of what the transaction was denominated in, and it is needed for rate verification later.
Capture the actual debit or credit
A statement might show USD 100.00 as the transaction but debit INR 8,450 from the account. The INR debit is what the bank actually moved, reflecting the bank’s own conversion, which may include a spread. These two numbers serve different purposes and should remain separate in the extracted data; the bank movement is not necessarily identical to a separately calculated accounting amount.
Check dates, decimal separators, and negative values
European-format CSVs use commas as decimal separators. Some banks show debits as negative values; others use separate columns. Transaction dates and posting dates can differ by days, and currency symbols can be ambiguous. One format mismatch here can make an amount appear 100 times too large or small, so confirm date formats, debit and credit signs, and decimal precision before trusting any figure.
A sample extraction preserves each of these fields side by side:
| Description | Txn date | Currency | Foreign amount | Account debit | Disclosed fee | Source ref |
|---|---|---|---|---|---|---|
| Supplier ABC, wire | 2026-03-15 | USD | 100.00 | INR 8,450 | INR 50 | Stmt pg 2, line 4 |
Step 2: Determine the Appropriate Exchange Rate for Accounting
The bank’s displayed rate is evidence of the bank’s conversion. It is not automatic proof that the same rate is correct for every accounting purpose.
Initial recognition of a foreign-currency transaction
Under IAS 21, The Effects of Changes in Foreign Exchange Rates (para 21), a foreign-currency transaction is recorded on initial recognition by applying the spot exchange rate at the date of the transaction. Para 22 defines that date as when the transaction first qualifies for recognition, and permits a rate that approximates the actual rate, such as an average for the period, when exchange rates do not fluctuate significantly. Ind AS 21 applies the same principle. The transaction date may not be the date the bank processes settlement.
What changes between transaction and settlement dates?
If a USD payable is recorded on 10 March using that day’s rate, but the bank settles it on 15 March at a different rate, the settlement amount in the functional currency will differ from the amount initially recognised. That difference is an exchange difference on settlement, not a data-entry error.
Realised and unrealised exchange differences
A realised exchange difference arises when a foreign-currency monetary item is settled at a rate different from the rate at which it was initially recognised or last remeasured. An unrealised exchange difference arises when an outstanding foreign-currency monetary item is remeasured at the period-end closing rate (IAS 21, para 23). These are different events with different entries. IAS 21, para 28 requires exchange differences on the settlement of monetary items, and on remeasuring them at the closing rate, to be recognised in profit or loss in the period they arise. The terms realised and unrealised are practitioner shorthand; the standard’s test is the event, settlement or period-end remeasurement, not the label.
What rate should a bookkeeper use?
A practical decision sequence, with exceptions referred upward rather than guessed:
1
2
3
4
5
The bank’s settlement rate is useful evidence of what left the account, but it does not automatically answer the accounting question of what rate should have been used for initial recognition.
Step 3: Account for Foreign Transaction Fees and Bank Charges
Separately disclosed international transfer fees, card fees, and bank charges should remain identifiable in the extracted data. Do not bury them inside the transaction amount.
Take the hypothetical from Step 1: the bank debits INR 8,500 in total for a USD 100 payment, and the statement separately shows INR 50 as a wire-transfer fee. The actual conversion debit is INR 8,450, and the fee is INR 50. Recording INR 8,500 as the payment to the supplier would overstate the payable settlement and hide a bank charge.
The accounting classification of that fee depends on its nature and the client’s accounting policy: an international wire fee might go to bank charges, while a card surcharge might sit elsewhere. The classification cannot be made correctly if the extraction already merged the fee with the transaction amount, and a fee should not be inferred merely because two amounts differ. A quick check closes the step: compare the statement’s description and any separately disclosed fee against the line items in the prepared data, and investigate a mismatch before importing.
Step 4: Categorise Foreign-Currency Transactions Correctly
Knowing a transaction was in USD does not tell you which ledger account it belongs to; currency identification alone does not establish the correct classification.
Match transactions to the chart of accounts
A USD debit could be a supplier payment, a software subscription, a refund reversal, or an intercompany transfer, and the correct account depends on the underlying transaction and the supporting documents, not the currency. The most expensive errors in multi-currency work are classification errors: bank fees posted as exchange losses, foreign-currency customer receipts matched to the wrong invoice, transfers treated as income. For the general extraction and categorisation workflow that feeds this step, see the checks to run before importing converted statement data.
Preserve the information needed for review
Retain the original description, dates, amounts, currency codes, and a reference to the source statement. When a reviewer questions an entry six months later, that trail is the difference between a five-minute check and a two-hour investigation.
Flag uncertain transactions
If the description is ambiguous or the transaction is unfamiliar, flag it for review rather than assigning an account by guesswork. Guessing a code to keep the import moving creates a problem that compounds every month it goes unreviewed. The same discipline that decides when a bank transaction should be flagged for review applies here, with the added currency dimension.
Worked Example: Processing a USD Transaction in an INR Bank Account
All figures below are hypothetical and are not a current exchange rate or a real bank transaction.
| Field | Example value |
|---|---|
| Supplier transaction | USD 100 |
| Actual bank-account debit | INR 8,450 |
| Separately disclosed bank fee | INR 50 |
Within this example, the statement tells you the bank converted USD 100 and debited INR 8,450 for the supplier payment, plus INR 50 for the fee, an implied bank rate of about 84.50 INR per USD. Those are statement facts in the example.
What the statement does not settle is the accounting measurement. Suppose the payable was initially recognised on 10 March at an illustrative rate of 84.20 (a reference rate that day, under the client’s policy) and the bank settled on 15 March. The difference between INR 8,420 at initial recognition and INR 8,450 at settlement is INR 30, which could be an exchange difference on settlement, or could partly reflect the bank’s spread. Without the initial-recognition details, the split cannot be determined from the statement alone, so no definitive exchange gain or loss should be booked from the statement by itself.
| What the statement tells you | What the bookkeeper still needs to establish |
|---|---|
| USD transaction amount | The date and rate of initial recognition |
| INR debit (the bank’s converted amount) | The applicable rate source and accounting policy |
| Separately disclosed fee | The correct account classification for the fee |
| Transaction and posting dates | Whether the payable was already recorded |
| Implied bank conversion rate | Whether the difference is timing, spread, or both |
Step 5: Validate Multi-Currency Data Before Import
This validation is specific to the risks that arise when currency context is lost or altered, rather than a repeat of the general reconciliation routine.
Verify original amounts and currency codes
Spot-check a sample of extracted values against the source statement. A missing currency code can cause the accounting system to default to the base currency, which silently converts every amount at 1:1.
Check the account-currency movements
Confirm that debits, credits, fees, and signs were interpreted correctly. A European CSV where 1.234,56 is read as 1234.56 or 1.23456 will throw off every balance.
Review dates and duplicate transactions
Watch for date shifts, overlapping statement periods, and repeated imports. If two statements both include transactions from 28 to 31 March, the overlap will double those entries on import.
Confirm the destination’s requirements
Check the accounting software’s current official documentation for supported fields, currency handling, and import formats, since a format that worked last quarter may have changed. The bank statement intake checklist is a useful companion for standardising what you confirm before each import.
| Issue | What to inspect first |
|---|---|
| Foreign amount differs from the account debit | Currency context, bank conversion details, and disclosed fees |
| Amount appears 100 times too large or small | Decimal separator and number formatting |
| Currency code is missing | The original statement and account information |
| Transaction appears twice | Source period, transaction reference, and prior import history |
| Import is rejected | Destination format and required fields |
A closing-balance match confirms the arithmetic of the extraction. It does not confirm that the accounting treatment, classification, or exchange rates are correct.
How Bank2Ledger Fits into the Workflow
Pre-accounting is the step of preparing transaction data from statements before it moves into the firm’s accounting workflow. Bank2Ledger sits in that layer: it extracts each transaction’s date, description, and amount from statement PDFs, including scanned statements, checks that the opening balance plus the lines equals the closing balance, categorises transactions against each client’s chart of accounts with firm-specific rules, holds low-confidence lines in a review queue, and exports the prepared data in formats ready for accounting software, with each entry linked back to its line in the source PDF.
That is the boundary worth being clear about. Preparing and reviewing statement data is different from deciding the accounting exchange rate or the foreign-exchange treatment: Bank2Ledger does not select the accounting rate, calculate realised or unrealised exchange differences, or perform foreign-currency revaluation, which are accounting decisions that belong downstream. For firms processing statements from multiple banks and clients, that division keeps the extraction clean so the team’s time goes to the accounting judgment.
Spend your time on the accounting, not the extraction
Bank2Ledger prepares, verifies, and categorises bank statement data with an audit trail back to the source line, so bookkeepers and accounting firms can focus on rate selection, classification, and review. Explore it for your statement-preparation needs.
Multi-Currency Bank Statement Processing Checklist
A concise checklist to use during routine processing:
- Confirm the account currency and statement period.
- Preserve original amounts and currency codes.
- Capture the bank’s actual debits and credits.
- Retain relevant dates and conversion information.
- Identify separately disclosed fees.
- Confirm the applicable exchange-rate policy.
- Review categorisation exceptions.
- Check for missing or duplicated transactions.
- Verify the target import format.
- Review the prepared data before finalising the accounting entries.
Frequently Asked Questions
What is multi-currency bank statement processing?
It is the workflow of extracting, preserving, and preparing transaction data from bank statements that involve foreign currencies, so currency codes, original amounts, and conversion details survive into the accounting record. Without that, the ledger loses the information needed to verify rates, classify fees, and explain reconciliation differences.
Should I keep the original foreign-currency amount after conversion?
Yes. The original amount and currency code are the audit trail back to the source transaction. Overwriting them with a converted value removes the only direct evidence of what was denominated in the foreign currency, which makes rate verification and period-end review much harder.
Which exchange rate should be used for bookkeeping?
It depends on the applicable framework, the transaction and recognition dates, and the client’s accounting policy. Under IAS 21 and Ind AS 21, foreign-currency transactions are initially recognised at the transaction-date spot rate. The bank’s settlement rate is evidence of what was paid, but it may not be the rate required for initial recognition.
How should foreign transaction fees be handled?
Identify them separately during extraction. A wire-transfer fee or card surcharge merged into the transaction amount will overstate the payable and hide an expense. Classify the fee according to its nature and the client’s chart of accounts, and do not infer a fee merely because two amounts differ.
What is the difference between a realised and an unrealised exchange difference?
A realised difference arises on settlement, when the rate at settlement differs from the rate at initial recognition. An unrealised difference arises at period-end when an outstanding foreign-currency balance is remeasured at the closing rate. Both are recognised in profit or loss under IAS 21, but they are triggered by different events.
Can bank statement conversion software handle all multi-currency accounting?
No. Extraction software prepares the data. Accounting decisions, such as rate selection, revaluation, gain or loss recognition, and classification, require professional judgment and the applicable framework. Treating extraction as the finish line is how unexplained exchange differences accumulate.
Conclusion
Accurate multi-currency bookkeeping depends on preserving source data, distinguishing the bank’s actual movements from accounting measurements, and applying the relevant accounting policy consistently. The statement is the starting point, not the answer. If the extraction step is still consuming hours every month, that is the first bottleneck worth fixing, so the team’s attention can move to the judgment that only an accountant can apply.
