## TL;DR
A crashed revaluation leaves half-written journals that contaminate the next entries. First establish whether the multi-currency journal itself balances in each currency at full precision, then inspect the failed batch's partial postings in the same accounts. Roll back or complete the batch per its own log before touching the journal; most such journals balance once the revaluation debris is removed, and the rest reveal a per-line rounding residual to post properly.

```text
"multi-currency journal out of balance" error after the revaluation batch failed
```

## Use this when
- The journal error appeared immediately after a revaluation batch failed or crashed.
- Accounts in the journal also appear in the revaluation scope.
- The batch status shows partial, failed, or in-progress with posted journals attached.

## Not for this skill when
- No revaluation ran in the window. Treat the journal as a standalone multi-currency balancing problem.
- The journal balances in no currency even after isolating batch effects. The source entry is wrong and must be rebuilt.

## Steps
1. Open the failed revaluation batch record and list the journals it did post, with accounts and amounts. Verify: the batch's posted footprint is fully enumerated
2. Recompute the problem journal alone, per currency, at full precision, excluding all batch journals. Verify: you know the journal's standalone difference per currency
3. Decide the batch disposition from its log: complete the remaining postings under supervision or reverse the posted part in full. Verify: the disposition leaves no partial batch state
4. Execute the batch disposition and recheck the journal difference. Verify: any remaining difference is the journal's own, stated per currency
5. Clear the remaining journal difference through the rounding or FX account per its size and cause, then confirm the trial balance per currency. Verify: every currency side balances and the base trial balance foots

## Variant phrasings
### multi currency journal unbalanced after revaluation failed
The post-crash phrasing.
### revaluation batch partial posting journals contaminated
When clearing batch debris first.

Compatibility: Revaluation batch processing in SAP, NetSuite, Dynamics 365, and Oracle period-end FX.

## Why it happens
Batch revaluation writes many journals as one job but commits them in groups, so a crash is a partial state, not a clean failure. Later validations then read accounts polluted by half a revaluation, and a journal tested against those accounts appears unbalanced for reasons outside itself. Restoring a known batch state, fully posted or fully reversed, is a prerequisite for diagnosing anything downstream; otherwise every subsequent fix chases debris.

## Edge cases / pitfalls
- Never complete a failed batch by rerunning it blindly; without idempotency checks the rerun double-posts the committed groups.
- Revaluation batches should carry a batch id on every journal. If yours do not, request the change; untagged batch journals make this diagnosis manual.
- A batch that fails twice on the same account usually points to a locked account or a missing rate for one currency in scope.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BQL6hJHxCl4Q4t1L2gX32g