Oracle "subledger journal entry is out of balance: accounted DR does not equal accounted CR" error after the payables...

TL;DR

Oracle accounts subledger transactions twice: entered amounts and accounted amounts in the ledger currency. This error means the accounted debit and credit differ, usually by a cent or two, after currency conversion or tax rounding on one invoice or payment in the transfer batch. Run the Subledger Period Close Exceptions report or the Journal Entries report filtered to the failed transfer to name the offending transaction, then inspect its distributions: a converted line rounded up while its offset rounded down is the classic pattern. Fix the distribution rounding or the SLA rounding rule, re-account that transaction only, and rerun Create Accounting. Do not force the whole batch through with a manual GL journal, because the subledger will stay out of balance with the GL.

Oracle "subledger journal entry is out of balance: accounted DR does not equal accounted CR" error after the payables transfer

Use this when

• Create Accounting or Transfer Journal Entries to GL fails for Payables with the accounted DR versus CR message.
• The ledger currency differs from the invoice currency on part of the batch.
• Most invoices transferred fine in earlier runs; the failure arrived with a specific invoice, tax line or payment.

Not for this skill when

• Transactions are simply unaccounted or stuck in draft accounting. Run draft accounting diagnostics first.
• The imbalance is in entered amounts on a single-currency invoice. That is a data entry or interface error, not accounted rounding.

Steps

1. Run the Subledger Period Close Exceptions report for Payables for the period and export the transactions flagged out of balance. Verify: the report names the specific invoices or payments blocking the transfer
2. For the first flagged transaction, open its journal entry in the subledger inquiry and compare entered versus accounted amounts line by line. Verify: the exact distribution lines carrying the rounding difference are visible
3. Check the exchange rate type, conversion date and SLA rounding rule assigned to those distributions. Verify: you know whether rounding is set per line, per entry or inherited from the ledger options
4. Correct the source: adjust the distribution, fix the tax rounding, or amend the SLA rule for that account class, per your change control. Verify: the corrected rule or distribution is saved and approved
5. Re-run Create Accounting in final mode for just that transaction, then rerun the transfer and reconcile Payables to GL. Verify: the transaction accounts balanced and the subledger-to-GL reconciliation shows no residual for it

Variant phrasings

Oracle accounted DR does not equal accounted CR payables

The verbatim accounted-balance error.

subledger period close exceptions report out of balance Oracle

The diagnostic report phrasing.

Create Accounting fails rounding accounted amounts SLA Oracle

For the SLA rule fix path.

Compatibility: Oracle E-Business Suite R12 Payables and Oracle Fusion Cloud Payables with Subledger Accounting, multi-currency ledgers and Create Accounting transfers.

Why it happens

Subledger Accounting converts each distribution to the ledger currency independently and rounds each converted line. On multi-line invoices with tax and freight, the rounded credits can sum a cent away from the rounded debits even though the entered amounts balance perfectly. The transfer protects GL integrity by refusing an unbalanced accounted entry, pushing the fix back to the rounding point instead of letting a permanent cent-level subledger-to-GL difference accumulate.

Edge cases / pitfalls

• Withholding tax and retainage lines are frequent rounding sources because they derive from percentages of other lines.
• If the same supplier invoices fail monthly, the pattern is in the interface or SLA rule, not in individual invoices; fix it once at the rule.
• Never plug the difference in the GL alone: the next subledger reconciliation will report the same transaction as a break.

Provenance

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