Test bank-currency revaluation with a balance you can calculate independently

A currency-revaluation screen can produce a balanced journal while using the wrong bank population, rate or date. Before accepting the feature, have the accounting owner define a small example with known inputs and an expected result. The test should establish how the system calculates and records the change, not ask the software to choose the company's accounting policy.

Identify the bank account's currency, the entity's accounting currency and any separate reporting currency in scope. List the balances the company intends to revalue and the approved rate source and convention. Use explicit currency units so the implementer knows whether a rate is expressed as dollars per euro or the inverse.

Limit the first test to one reconciled hypothetical bank balance. Leave receivables, payables and other monetary items for their own configured processes. Combining several populations too early makes it harder to find out whether the bank feature itself has the correct inputs.

Ask the vendor which product version, feature settings and localization are being demonstrated. Revaluation logic can depend on those choices. The acceptance record should describe the actual proposed configuration rather than rely on a broad claim that the product supports multiple currencies.

Microsoft's bank-revaluation documentation distinguishes the date used to select the foreign-currency balance from the date used to obtain the exchange rate. It also describes previews, run history and links to resulting vouchers. These are specific product capabilities that provide a useful structure for questioning the proposed workflow.

Place one transaction before the approved cutoff and another after it. Give them recognizable amounts and inspect the population selected for the calculation. The rate date should not accidentally change which bank transactions enter that population.

Choose two deliberately different test rates on nearby dates. Run the preview with the approved date and verify the rate used in the calculation evidence. A screen that shows a date without revealing the actual rate leaves the reviewer with an important unchecked assumption.

Test a date for which the required rate is missing. Record whether the product blocks the run, uses an earlier rate or follows another rule. The company should explicitly approve any fallback. A completed calculation is not sufficient evidence that a suitable rate was available.

Use a hypothetical bank balance of EUR 10,000 with an existing USD carrying amount of $11,000. For the test only, assume the approved closing rate is $1.20 per euro. The target translated amount is $12,000, and the difference from the existing carrying amount is $1,000. These are invented demonstration rates, not current exchange rates.

Inspect the preview for the selected EUR balance, the $1.20 rate, the $11,000 prior carrying amount and the $1,000 difference. Have the accounting owner confirm the intended accounts and sign of the generated entries under the approved example. The bank's native EUR balance should remain EUR 10,000 in this no-transaction illustration.

Run the same calculation with an explicitly reversed quotation convention in a separate controlled setup. The purpose is to verify that the system and rate feed interpret units consistently. Do not let the implementer compensate for an inverted rate through an unexplained manual override.

If the company uses a reporting currency as well, require a separate explanation of that result. A correct accounting-currency adjustment does not prove that a second currency amount uses the intended rate type or convention. Keep the additional calculation visible rather than presenting one combined gain or loss.

Post the accepted test result and repeat the revaluation with unchanged inputs. Determine how the system handles the previously posted adjustment. The final carrying amount should be explainable without treating the same $1,000 movement as a fresh economic event merely because someone ran the process twice.

Then change the approved test rate to $1.22 per euro while keeping the EUR 10,000 balance unchanged. The new target is $12,200. Ask the vendor to show whether the supported process posts an additional $200, reverses and replaces a prior result or follows another documented method that reaches the approved outcome.

Inspect the run history and ledger references after the correction. The reviewer should be able to identify the original run, its status and the later calculation. A final correct balance is harder to trust if the intervening entries cannot be explained.

Demonstrate the supported reversal process where one is needed. Identify whether reversing an earlier run has restrictions after later runs exist and how the application communicates them. Do not build the operating procedure around an informal manual deletion of historical calculation records.

Ask which general ledger accounts are also eligible for a broader ledger revaluation process. The implementation should have a deliberate plan for preventing the bank amount from being adjusted twice by separate routines. The correct configuration depends on the product and the company's approved accounting design.

Test a bank account with no foreign-currency balance but a residual translated balance, if that is a relevant case supplied by the accountant. The vendor should explain the supported treatment and calculation evidence. This is a useful challenge because a rule that simply multiplies the native balance may not explain the historical residual on its own.

Inspect dimensions on the generated entries. If the bank transactions carry departments or other reporting attributes, ask how the revaluation distributes or summarizes them. A correct entity total may still require an adjustment to the intended departmental presentation.

Include an account or entity outside the user's authorized scope. Confirm the ordinary operator can select only the intended population and that the review output clearly identifies the selected entity and bank account. Shared group access should not make a run's scope ambiguous.

Have the intended preparer obtain the approved rate, run the preview and assemble the review evidence without the consultant taking over. The controller should be able to reproduce the small example with a calculator and trace the resulting posting to the selected bank balance.

Document the order of bank reconciliation, rate approval, revaluation and review in the company's close process. Include who investigates a missing rate, a changed population or a failed run. The procedure should specify the supported recovery action before an operator is tempted to repeat an uncertain process.

Accept the feature when the calculation, posting and correction history all agree with the approved examples. Keep the initial demonstration and selected settings as a focused retest after relevant upgrades. The useful capability is a revaluation result finance can explain, including how the system treated work already performed.