Journal reversals in RTR: an ERP plan is not proof of posting
A reversal date is set, the job has finished and the team marks the task complete. That still does not prove that the correct reversal entry reached the ledger.
In Record to Report, intent can be mistaken for an outcome. Setting up a reversal, creating its journal and posting it can be separate stages. If the client and outsourcing team use one status called “done”, a missing stage may only become apparent during balance analysis.
This guide covers execution checks for reversals that have already been agreed. It does not decide whether a particular event requires reversal or which accounting period should apply. Those decisions follow the client's accounting policy and the authority assigned to specific people.
1. Start with the source entry identifier
The control list should identify the entity, ledger, source journal identifier, period, amount, currency and approved purpose of the reversal. Include the accounts and dimensions relevant to the check. A description such as “expense accrual” is insufficient when dozens of similar entries exist.
For each item, record the expected reversal period, execution method and exception decision owner. Do not automatically copy the previous month's date. The list should reflect agreed instructions rather than introduce a new accounting rule chosen by the processing team.
2. Separate scheduling, creation and posting
Oracle Financials distinguishes automatic reversal from automatic reversal with posting. The operational implication is that automation settings alone are not evidence of a ledger posting. Inspect the correct resulting journal.
A working register can use separate states: scheduled, created and awaiting posting, posted and checked, and exception. These are proposed process labels, not universal ERP field names. Assign required evidence to each state so both parties understand it consistently.
3. Confirm the outcome for each item
Link the source identifier to the reversal identifier and check the ledger, period, amount, currency and required accounts and dimensions. Confirm the posted status in the system. An agreed batch total does not replace document linkage: a missing item and a different error can conceal each other.
Microsoft identifies batch job history as a place to check unsuccessful reversals. Keep the relevant job result and error list alongside the journal status. A process completion message should not close unresolved items in the control register.
4. Reconcile expected reversals with checked outcomes
Editorial example: an agreed list contains five source entries. Three reversals are posted and checked, one is created but unposted, and one has an error. The result is “3 checked + 1 pending + 1 exception”, not “batch complete”. Every one of the five items has an explicit state.
Also agree separate totals for each currency and ledger, and how to assess signs and accounts under the selected reversal method. Do not reduce the check to a single net value. After an approved correction, refresh the register and inspect the affected journal; an earlier export cannot confirm a later posting.
5. Check the current state before retrying
An absent journal in an old report does not prove that no reversal was created. Before making a manual correction, check the source's current state, the resulting journal, the job execution and any process still in progress. This reduces the risk of two teams handling the same item simultaneously.
For each exception, record its cause, missing evidence, owner and next action. A closed period, missing permission or unmet rule requires a decision from the appropriate person. Do not change a date or account merely to clear an error message. Once authorised, perform the agreed action and repeat the outcome check.
6. Hand over a result that can be traced
A useful completion report identifies the list's scope, check date, counts and values by state, and references to journals and evidence. Clearly identify open exceptions and decision deadlines. The recipient should be able to trace a report row to its source and the correct reversal.
BackOffice Outsourcing lists Record to Report, manual journals and control documentation within its finance and accounting processes. When handing over such work, agree the outcome definition and supporting evidence. Describe your process to the team to establish responsibilities and access. A separate guide explains the month-end close calendar.
Sources and scope
Oracle Financials 26D and Microsoft Dynamics 365 Finance documentation checked on 21 October 2026. The state register, five-entry example and handover format are editorial recommendations. Feature names and behaviour depend on the system and configuration; describing these products does not imply that BackOffice Outsourcing uses them.
FAQ
Does a reversal date mean the journal has posted?
No. It describes a plan or parameter. Confirmation requires checking the correct resulting journal and its status in the ledger.
Is a completed job enough to close the control?
Not on its own. Check individual outcomes, errors and the required journal links. Unresolved exceptions should remain visible.
What if the report contains no reversal?
Refresh the data and inspect the source's current state, resulting journal and job. Establish the actual state before agreeing a retry or manual correction.
Who decides the reversal period and method?
An authorised person under the client's accounting policy. The processing team acts within its agreed scope and should not change those rules merely to close an exception.
