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

Not specified by the original author.

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.

"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

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

Thread query: "multi-currency journal out of balance" error after the revaluation batch failed

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.

Not specified by the original author.

TL;DR

A 0.03 break after a multi-currency journal is per-line rounding: each foreign line was converted and rounded to cents, and the rounded lines no longer sum to the rounded total. Recompute the entry line by line at the booked rate, confirm the residuals sum to 0.03, and post that residual to the rounding difference account in the same entry period. Converting the total instead of each line next time prevents the repeat.

"trial balance out of balance by 0.03" after a multi-currency journal entry posted

Use this when

• The trial balance difference is a few cents and appeared with a multi-currency journal.
• The journal has several lines in one foreign currency converted at one rate.
• In the foreign currency the entry balances exactly; only the base-currency side is off.

Not for this skill when

• The base-currency difference is a round amount. Suspect a missing line, not rounding.
• The foreign-currency side also fails to balance. The source entry itself is wrong.

Steps

1. Identify the multi-currency journal and list each foreign line with its foreign amount, booked rate, and posted base amount. Verify: every line of the entry is accounted for
2. Recompute each base amount at full precision and compare with the posted rounded amount per line. Verify: the per-line residuals sum to exactly 0.03
3. Confirm the ERP rounding rule for that currency and journal type, and note whether rounding is per line or per entry. Verify: the rule explains the residual pattern you found
4. Post a 0.03 residual entry to the rounding difference account against the affected account, referencing the original journal. Verify: the trial balance now balances to zero
5. Where the ERP allows it, switch that journal template to a rounding method that posts residuals automatically. Verify: a test entry in the same currency posts balanced with a visible rounding line

Variant phrasings

multi-currency journal rounding difference cents

The per-line rounding phrasing.

trial balance out by 0.03 foreign currency entry

Searching by the exact difference.

Compatibility: Multi-currency journals in NetSuite, Dynamics 365, SAP, and Sage Intacct with per-line conversion.

Why it happens

Currencies convert at rates with more precision than cents. When each line rounds independently, the rounding errors accumulate instead of cancelling, and a six-line entry can strand up to a few cents. The foreign side balances because no conversion happened there. Systems that post an automatic residual line hide this; systems in manual mode leave the residual inside the trial balance difference.

Edge cases / pitfalls

• JPY and other zero-decimal currencies round to whole units, so residuals there are larger and more visible. Treat them with the same per-line method.
• If the residual exceeds half a cent per line, a rate was keyed wrong on one line. Check rates before posting a rounding entry.
• Month-end revaluation creates similar cents. Keep revaluation residuals in their own account so the two causes stay separable.

Provenance

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

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

Thread query: "trial balance out of balance by 0.03" after a multi-currency journal entry posted

TL;DR: A 0.03 break after a multi-currency journal is per-line rounding: each foreign line was converted and rounded to cents, and the rounded lines no longer sum to the rounded total. Recompute the entry line by line at the booked rate, confirm the residuals sum to 0.03, and post that residual to the rounding difference account in the same entry period. Converting the total instead of each line next time prevents the repeat.

Not specified by the original author.

TL;DR

A crashed revaluation posts some currency adjustments and not their offsets, so the FX account holds one-sided entries. Extract every journal the run created from its batch id, total them by currency and account, and decide: reverse the partial set and rerun clean, which is usually safer than completing a half-known calculation. After the clean rerun, the FX account balance should equal the sum of the run's reported gains and losses exactly.

"FX gain/loss account out of balance" error after the period-end revaluation crashed

Use this when

• The FX gain loss account balance does not tie to the revaluation report after a crash.
• The revaluation run status is failed, aborted, or incomplete with journals already posted.
• Some currencies revalued and others did not in the same run.

Not for this skill when

• The run completed and the balance is large. Large is not wrong; tie it to the report and investigate only a proven gap.
• Manual FX journals posted into the same account during the period. Separate manual activity before blaming the run.

Steps

1. List all journals carrying the crashed run's batch id with currency, account, and amount. Verify: the partial footprint is complete, including any offset journals
2. Total the partial postings by currency and compare with the run report's intended results per currency. Verify: you can state what fraction of the run actually posted
3. Reverse the partial postings as a set, referencing the batch id, unless the system can provably resume without duplication. Verify: the FX account returns to its pre-run balance
4. Fix the crash cause if identifiable, such as a missing rate or a locked account, before rerunning. Verify: the blocking condition is removed, not just retried past
5. Rerun revaluation for the full scope and tie the FX account movement to the new run report to the cent. Verify: run report total equals the FX account movement for the period

Variant phrasings

revaluation crashed FX gain loss account incomplete

The crashed-run phrasing.

period end revaluation partial posting reverse rerun

When reversing the partial set.

Compatibility: Period-end revaluation in SAP, NetSuite, Dynamics 365, Oracle, and Sage multi-currency closes.

Why it happens

Revaluation is a calculation with a posting phase, and the posting phase is many journals. A crash between journals leaves the ledger in a state the calculation never intended: some balance sheet accounts restated, their FX offsets missing, the FX account holding fragments. Because fragments look like real FX activity, the only reliable marker is the batch id tying them to the aborted run. Set-based reversal restores the pre-run truth so a clean rerun can replace it.

Edge cases / pitfalls

• If the crash happened during a database failover, check for journals posted but missing from the run log; reconcile by account movement, not by log alone.
• Do not let the next period's revaluation run on top of an unreversed partial run; the new run values balances that include fragments and compounds the error.
• A status dashboard for close jobs that distinguishes posted-nothing, posted-partial, and posted-complete prevents most rediscovery work.

Provenance

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

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

Thread query: "FX gain/loss account out of balance" error after the period-end revaluation crashed

TL;DR: A crashed revaluation posts some currency adjustments and not their offsets, so the FX account holds one-sided entries. Extract every journal the run created from its batch id, total them by currency and account, and decide: reverse the partial set and rerun clean, which is usually safer than completing a half-known calculation. After the clean rerun, the FX account balance should equal the sum of the run's reported gains and losses exactly.