Revaluation is the step in Currency Management that most people either skip by accident or run without understanding what it's actually correcting. Before you close a financial period, if the tenant carries any foreign-currency balances — a USD bank account in a KES-functional company, an AR invoice in EUR, an intercompany payable in GBP — you need to run revaluation so the GL reflects what those balances are worth in functional currency as of the period end, not what they were worth on the day the transaction was entered.
What revaluation actually does
Every open document denominated in a foreign currency was originally posted at the exchange rate in effect on its transaction date. Rates move. By the time you get to month end, that USD invoice booked three weeks ago is worth a different amount in functional currency than it was when you recorded it — not because anything happened to the invoice, but because the currency did. Revaluation walks every open foreign-currency balance on revaluation-enabled accounts, recalculates it at the period-end rate, and posts the difference as an unrealised gain or loss.
Critically, this entry is auto-reversing. Acumatica posts the revaluation adjustment on the last day of the period, then automatically reverses it on the first day of the next period. That reversal matters more than the adjustment itself: it means next period opens clean, with the original transaction-date rate still sitting on the books, rather than starting from an already-adjusted balance that then has to be adjusted again against whatever rate is current next time. When the underlying invoice or bill actually settles, the real gain or loss is realized against the true entry, not against a moving target you patched in a prior period.
The account mapping work people underestimate
The part of this that catches first-time implementers is not running the process — it's the setup before you ever click the button. For each currency you manage, Currency Management expects you to assign a distinct set of accounts and subaccounts: realized gain, realized loss, unrealized gain, unrealized loss, translation gain/loss, revaluation gain/loss, and rounding gain/loss. That's seven mapping slots per currency, and if a client trades in three or four foreign currencies, that setup work multiplies out fast and nobody budgets time for it during the initial implementation.
Skipping or half-configuring this mapping doesn't throw an obvious error — revaluation will often still run, it just posts to whatever default or fallback account is configured, which means your unrealized FX movement quietly lands somewhere your finance team isn't looking for it. The first time someone notices is usually when the auditor asks why unrealized gain and realized gain are commingled in the same GL account.
Walk through every currency the tenant transacts in and confirm all seven gain/loss/rounding accounts are assigned deliberately, not left on a shared default. Doing this during setup takes an afternoon. Discovering it's wrong during an audit takes a lot longer, and the fix usually means reclassifying entries after the fact.
What skipping it actually costs you
If you close the period without running revaluation, the GL simply doesn't reflect current FX exposure — every open foreign-currency balance sits at its original transaction rate, understating or overstating the real functional-currency value depending on which way the rate moved. For a tenant dealing only in stable currency pairs, that drift might be immaterial for a month or two. For clients transacting in NGN, EGP, or RWF against USD — which describes a fair number of the businesses I work with across East and Southern Africa — a skipped revaluation cycle can misstate the balance sheet by a meaningful amount in a single month, because these are exactly the currency pairs that move the most.
This is why revaluation belongs in the close sequence, not as an optional cleanup step. I cover the full period-close order — sub-ledger closes, the unposted documents gate, and where revaluation sits relative to the GL503000 close itself — in the GL period-end close checklist. The short version: run revaluation after sub-ledgers are closed and before you close GL, so the unrealized gain/loss entries land in the period they belong to.
A simple mental model for the entry
You don't need to memorize the exact debit/credit mechanics to reason about revaluation correctly — the model that's actually useful is this: revaluation never touches the original transaction. It layers a temporary, self-cancelling adjustment on top, sized to the rate movement between the transaction date and the period-end date.
Period-end balance (functional currency) = Open foreign-currency balance x closing rate Revaluation adjustment = Period-end balance − balance already on the books (posted as unrealized gain/loss, auto-reverses next period)
Once that clicks, the auto-reversing behaviour stops looking like a quirk and starts looking like the only sane way to handle it — you're not trying to guess the final settlement rate, you're just marking the balance to market at each period end and undoing the mark as soon as the period turns over.
Wrapping up
Revaluation exists to keep foreign-currency balances honest at period end without permanently distorting the ledger — the auto-reversing entry marks exposure to the closing rate, then gets out of the way the moment the next period opens. The setup cost is mostly in the account mapping, which is easy to underestimate and expensive to unwind later, and the cost of skipping it entirely is a balance sheet that understates real FX exposure — a real risk for any tenant transacting in currencies as volatile as NGN, EGP, or RWF. Run it as a standing step before you close GL, not an occasional cleanup task.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.