month-end revaluation posted a 4,000.00 unrealized loss: "FX rate stale" error on the intercompany loan
Fixes a month-end revaluation posting a 4,000.00 unrealised loss flagged as FX rate stale on an intercompany loan: verify the rate date and value, reverse and rerun with the correct closing rate if stale, or evidence the loss if real. Use when the rate used was not the closing rate. Not for a loss computed at the correct rate.
TL;DR
A stale rate means the loan was revalued at an old rate, so the 4,000.00 loss may be an artifact. Identify the rate the run actually used, compare it with the authorised closing rate for the loan currency, and recompute the expected movement by hand. If the used rate is stale, reverse the revaluation, load the correct closing rate, and rerun. If the rate was right, the loss is real: document the currency movement and keep it.
month-end revaluation posted a 4,000.00 unrealized loss: "FX rate stale" error on the intercompany loanUse this when
- The revaluation journal shows a large unrealised loss on an intercompany loan, here 4,000.00.
- The run or its log flags FX rate stale, or the rate date is not the period-end date.
- The currency did not move enough in the period to explain a loss of that size at first glance.
Not for this skill when
- The rate is the correct closing rate and the currency genuinely moved. Then the loss stands and needs explanation, not reversal.
- The loan balance itself changed unexpectedly. Reconcile the loan principal first; revaluation of a wrong balance is a different fix.
Steps
- Extract from the revaluation log the exact rate, rate date, and rate type applied to the loan. Verify: the applied rate is stated from the log, not from the rate table's current value
- Get the authorised closing rate for the period end and recompute the loan's base-currency value at both rates. Verify: the recomputation shows how much of the 4,000.00 the stale rate explains
- Confirm the loan's foreign-currency principal from the loan agreement and counterparty confirmation. Verify: principal is agreed with the other entity before blaming the rate
- If the rate was stale, reverse the revaluation entry, load the correct closing rate, and rerun revaluation for that loan. Verify: the new journal's loss matches your hand recomputation
- If the rate was correct, document the currency movement and the computation in the close file and leave the loss posted. Verify: the close file explains the 4,000.00 with rate evidence
Variant phrasings
FX rate stale revaluation unrealised loss intercompany loan
The stale-rate phrasing.
revaluation used wrong rate date reverse rerun
When reversing and rerunning.
Compatibility: Intercompany loan revaluation in NetSuite OneWorld, SAP, Dynamics 365, and Oracle treasury and GL.
Why it happens
Revaluation jobs pick rates by configuration: the rate type and the as-of logic decide whether the run uses the closing rate, an average, or simply the newest rate in the table on the day someone loaded it. If the closing rate load failed or lagged, the job quietly uses the last available rate and labels nothing wrong. The stale flag, when it appears, is the difference between a real economic loss and a data timing artifact.
Edge cases / pitfalls
- Intercompany loans revalue on both sides; a stale rate on one side creates an intercompany mismatch downstream at consolidation. Fix both entities' rates together.
- Long-term intercompany loans that are in substance capital may be excluded from revaluation through profit or loss by policy. Confirm the loan's classification before rerunning.
- Rate loads should finish before revaluation is scheduled. Sequence the close checklist so the rate check gates the revaluation step.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_AAoTrk7H1gHgy7AbwedSfA