Foreign-Currency Reporting: Has the Balance Changed, or Have You Only Previewed a New Rate?

When commissioning a finance dashboard, separate a foreign-currency valuation preview from a posted accounting adjustment. Changing the exchange rate in a report should not leave staff guessing whether the accounts have changed. Specify the reporting date, rate basis, adjustment authority and reversal information before approving the integration.

This is a software brief, not an accounting policy. Your financial adviser must decide which balances require valuation, which rates and dates apply, and how adjustments should be recorded. A developer should not choose those rules merely because a report offers convenient defaults.

Preserve the two currency perspectives

An overseas bank balance and its value in the company's accounting currency answer different questions. Ask the dashboard to identify both currencies explicitly. A number labelled only “balance” is inadequate when staff need to understand whether it represents the bank's currency or the company's reporting currency.

Odoo 19's foreign-currency bank-account guide provides a concrete software example. It says transactions are recorded in the company's default currency and reports use that currency. For transactions in a foreign-currency bank account, it stores debit and credit values in both the company currency and the bank-account currency.

For a custom integration, agree which original transaction values remain available alongside a valuation. Do not replace those recorded amounts with a newly calculated display value. The question here is the reporting value of a balance, not a new customer price or evidence that money has moved.

Make a rate override visible

Odoo's Unrealized Currencies report allows a different rate to be selected through its Exchange Rates control. The guide describes a yellow banner after a manual change, with an option to reset to Odoo's rate.

Treat that distinction as a useful requirement, not a mandate to copy a particular colour. A reviewer should know whether the report uses the system rate or an override, who selected the override in your implementation, and which reporting date the view represents. If those details are unavailable from the integration, show that limitation rather than inventing an audit trail.

Agree whether users may explore alternative rates without posting anything. A planning scenario and a finance-approved reporting view should not look indistinguishable in an export sent to management. Define their labels and the inputs retained with each saved result.

A report control is not the posting decision

The same guide describes a separate Adjustment Entry action to update the balance sheet with the amount in the report's Adjustment column. Its window selects a journal, expense account and income account to process unrealized gains or losses.

For your project, identify who may inspect the calculation and who may approve or create the actual entry. If the integration is read-only, say so plainly. Do not provide a button that appears to approve an adjustment when it merely downloads a proposal.

For a posting integration, require the resulting accounting reference to be linked to the reviewed report inputs. Define how uncertain outcomes are investigated before anyone tries the action again. An absent confirmation is not proof that no entry exists. These are recommended integration controls, not claims that the documented report implements your proposed approval process.

Keep reversal separate from cash settlement

Odoo documents a report Date and a Reversal Date, with automatic reversal of the booking entry on the latter date. It also says that after posting, the Adjustment column should show zero because the unrealized gains or losses have been adjusted.

Do not translate that zero into “customer paid” or “bank account closed.” It describes the adjustment in this report. Your interface should retain the report date, posted-entry reference and intended reversal date so the financial reviewer can explain the sequence.

Have the accountant approve how the app displays a later reversal, a changed reporting period and a fresh valuation. Do not silently carry an old approval onto a different rate or date.

Demonstrate the reporting lifecycle

Use fictional balances and adviser-approved expected outcomes in the acceptance criteria. Show the original two-currency transaction, an unposted rate override, reset to the system rate, an authorised adjustment and its reversal information. Check that the source transaction remains identifiable throughout.

Review the final export as well as the dashboard. A reader should distinguish a scenario, an adjustment awaiting action and an actual posted reference without reconstructing the sequence from screenshots. Bring that lifecycle to a finance-integration discussion, rather than requesting a generic currency converter.

The source supports the named Odoo controls and behaviour. Approval design, auditability and acceptance recommendations are project guidance. No accounting compliance, tax treatment or result from a live financial system is certified here.