Skills / Reconciliation and close

FX Revaluation

FX revaluation fails quietly in one of two directions: a monetary account with a blank flag gets treated as nonmonetary and never revalued at all, or realized and unrealized movements get blended into one number that doesn't tie to either the income statement or the CTA rollforward. Both mistakes look like a completed close task. Neither one survives an auditor asking where the number on the CTA rollforward actually came from.

What it does

This skill revalues every GL row explicitly flagged as a monetary account at the period-end rate supplied for its currency, computing unrealized gain or loss on the difference between the new functional-currency equivalent and the amount currently recorded. Where optional settlement detail identifies an item that actually settled during the period, that item's gain or loss is classified realized instead, using its own settlement rate, and kept on a separate line from unrealized movements. The proposed revaluation entry for each account, the account itself moving to its new value, offset by FX Gain/(Loss), is self-balancing by construction, and the cumulative translation adjustment rolls forward from a supplied beginning CTA balance plus the period's computed unrealized translation adjustment.

The one rule it can't skip

It never decides which accounts are monetary, and it never sources or substitutes an FX rate on its own. Every row needs an explicit monetary flag, y or n, stated by the client; a blank is an exception, never assumed to be "no." Period-end rates come from wherever the entity already sources them, a treasury system, a bank feed, a published table, and are applied exactly as supplied; a missing rate for a flagged currency becomes a visible exception, never filled in from a nearby date or a different currency chosen automatically.

How the recomputation actually runs

Every row flagged monetary=y is revalued at its currency's period-end rate, and the difference between that new functional-currency equivalent and the amount currently recorded becomes gain or loss, unrealized by default, or realized where the optional settlement detail says the item actually settled this period at its own settlement rate. Every row flagged monetary=n is excluded from revaluation entirely and logged, not dropped, on its own tab. The proposed journal entry per account is checked to balance by construction before the workbook is produced, and the CTA rollforward adds the period's computed unrealized translation adjustment on top of the beginning CTA balance supplied.

What it won't do

It won't guess a monetary/nonmonetary classification from an account's name or type; a blank flag blocks that row as an exception rather than defaulting either way. It won't apply a rate it wasn't given, interpolate between dates, or borrow a nearby currency's rate. It won't net realized and unrealized gain or loss into a single figure, since the two typically post to different income statement lines. And it won't book the revaluation entry; it's proposed for a Controller to approve, the same discipline every tie-out skill in this family applies.

Inputs and output

InputsGL detail by currency with an explicit monetary/nonmonetary flag per row, period-end spot rates by currency, optional settlement detail for items that settled during the period, and the beginning CTA balance
OutputA revaluation workbook with proposed, self-balancing journal entries split between realized and unrealized gain or loss, a CTA rollforward, and a transparency log of every nonmonetary account excluded
Who it's forControllers at multi-currency entities who run FX revaluation every period close

Adopt's agents run this revaluation against the rate table your treasury function already maintains, log every nonmonetary account excluded instead of just skipping it, and keep realized and unrealized gain or loss on separate lines. Nothing posts until a Controller approves it. Sign up free, or book a pilot to run it against your own multi-currency close.