> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Accrual Reversals (last close), Oracle ERP Cloud > Accrual Reversals (last close) counts the accrual journals reversed in the last GL period close. A high count can signal over-accrual or estimation-quality issues in the close process. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Accrual journals reversed in the last close. A high count points at over-accrual or shaky estimates. ## At a glance > Accrual Reversals counts the accrual journals that were reversed as part of the last GL period close. Accruals are estimates booked at period-end for activity that has occurred but not yet been invoiced or recorded (unbilled revenue, goods received not invoiced, expenses incurred but not yet billed), and they are normally reversed at the start of the next period when the actual transaction lands. A modest, stable count is the healthy rhythm of accrual accounting. A high or rising count is the signal worth investigating: it can mean the team over-accrues, that estimates are consistently off, or that the same items are being accrued and reversed repeatedly because an underlying process is not capturing the actual cost in time. It is an estimation-quality lens on the close. | | | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The number of accrual reversal journals processed in the last completed period close. In Oracle Fusion these are typically auto-reversal journals generated from accruals flagged for reversal, plus any manually reversed accrual journals, across the Business Units and Ledgers the connected role can see. | | **Why it matters** | The volume and trend of accrual reversals is a proxy for estimation quality. Healthy accrual accounting reverses what it accrued in an orderly way; a swelling count suggests the estimates are noisy, the accruals are too large, or actuals are arriving late and forcing repeated re-accrual. | | **What a healthy pattern looks like** | A roughly stable count period over period, tracking the genuine population of unbilled and uninvoiced items the business carries. Predictable is good. | | **What a worrying pattern looks like** | A rising count, large swings, or a cluster of high-value reversals, especially if paired with a high [Manual JEs](/nerve-centre/kpi-cards/oracle-erp/manual-jes-as-of-total) ratio, which suggests accruals are being booked and unwound by hand. | | **Business Unit scope** | Respects the dashboard's selected Business Unit and Ledger filter. By default rolls up every Business Unit and primary Ledger the connected role can see. | | **Time window** | `30D` (the last close period) | | **Alert trigger** | `>10` - more than ten accrual reversals in a single close warrants a controller's review | | **Roles** | owner, finance | ## Calculation Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A large-enterprise wholesaler runs Oracle ERP Cloud and closes monthly. The controller reviews accrual reversals across two consecutive closes: the February close (period ended 28 Feb 26) and the March close (period ended 31 Mar 26). | Close period | Accrual reversals | Status | Read | | -------------------------- | ----------------- | ------------------- | --------------------- | | February (ended 28 Feb 26) | 7 | No alert | Normal accrual rhythm | | March (ended 31 Mar 26) | 19 | Alert fired (`>10`) | Investigate | Four things to notice: 1. **The March count nearly tripled and crossed the alert line.** Seven reversals in February was a normal close. Nineteen in March is a clear elevation that the controller should explain before signing off the close pack. 2. **The cause was a goods-received-not-invoiced backlog.** A procurement integration delay meant supplier invoices were arriving late, so the team accrued for received goods at month-end, then reversed and re-accrued repeatedly as actuals trickled in. The reversals were the symptom; the late-arriving invoices were the cause. 3. **The fix is process, not journal hygiene.** Speeding up the supplier-invoice capture (or tightening the receipt-accrual matching) reduces the need to accrue and reverse the same items. Simply reversing more carefully does not address why the estimates keep needing correction. 4. **Read it with the manual ratio.** In March the [Manual JEs as % of Total](/nerve-centre/kpi-cards/oracle-erp/manual-jes-as-of-total) card also ticked up, because the accruals and reversals were being keyed by hand. The two cards together told a single story: a procurement-to-pay gap was forcing manual estimation churn at close. ## Sibling cards merchants should reference together Accrual Reversals is an estimation-quality lens on the close. Read it alongside the other close-discipline and journal-health cards. | Card | Why pair it with Accrual Reversals | | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [Manual JEs as % of Total](/nerve-centre/kpi-cards/oracle-erp/manual-jes-as-of-total) | High accrual reversals plus a high manual ratio point at estimation churn being done by hand. | | [Period Close On-Time Rate (12mo)](/nerve-centre/kpi-cards/oracle-erp/period-close-on-time-rate-12mo) | Excessive accrual reversals slow the close and can pull the on-time rate down. | | [GL Period Close Status](/nerve-centre/kpi-cards/oracle-erp/gl-period-close-status) | Accrual reversals are part of the close workflow; watch the close status as they process. | | [Journals by Source (JeSource)](/nerve-centre/kpi-cards/oracle-erp/journals-by-source-jesource) | Shows whether the reversals are automated or manual, which changes how you read the count. | | [Open (Unposted) Journals](/nerve-centre/kpi-cards/oracle-erp/open-unposted-journals) | Reversals that have not yet posted add to the close backlog. | | [GL Period Close Past Deadline](/nerve-centre/kpi-cards/oracle-erp/gl-period-close-past-deadline) | When reversal churn delays the close, this card catches the missed deadline. | ## Reconciling against Oracle ERP Cloud **Where to look in Oracle ERP Cloud:** The closest native equivalents in the Oracle Fusion UI are: > **Navigator → General Accounting → Journals → Manage Journals** (filter to reversal journals for the last close period) > **Navigator → General Accounting → Period Close → Close Status** (the close workflow including reversals) > **Reports and Analytics → OTBI → Financials → General Ledger - Journals Real Time** (reversal-flagged journals as a dimension) Oracle Fusion can auto-generate reversal journals from accruals flagged for reversal, and the close process surfaces them. Counting the reversal journals tied to the last close period in Manage Journals, scoped to the same Business Units and Ledgers, should match this card. Common mistakes when comparing against Oracle's own reports: * **Counting all reversals, not just accrual reversals.** Journals can be reversed for many reasons (corrections, error fixes). This card focuses on accrual reversals tied to the close. Make sure your Oracle query isolates accrual-type reversals. * **Period boundary confusion.** A reversal generated at the start of the next period to unwind a prior-period accrual can be attributed to either period. Confirm which period the card and your report assign it to. * **Counting lines vs headers.** A single reversal journal can have many lines. The card counts journals (headers), not lines. **Why our number may legitimately differ from Oracle's reports:** | Reason | Direction | Why | | -------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Reversal type scope** | Either | The card focuses on accrual reversals; an Oracle query counting all reversal journals (including corrections) shows more. | | **Period attribution** | Either | A next-period reversal of a prior-period accrual can be attributed to either period; the card and an Oracle report may assign it differently. | | **Headers vs lines** | Either | Counting reversal lines rather than headers changes the number. The card counts headers. | | **Business Unit / Ledger scope** | Either | The card rolls up every Business Unit and Ledger the role can see; a scoped Oracle query shows fewer. | ## Known limitations / merchant FAQs **Are accrual reversals bad?** No, reversals are a normal and necessary part of accrual accounting. You accrue an estimate at period-end and reverse it next period when the actual transaction lands, so you are not double-counting. The card does not flag reversals as wrong; it watches the volume and trend, because an unusually high or rising count is a clue that the estimates themselves may be off or that a process upstream is forcing repeated re-accrual. **What does a high count actually signal?** Usually one of three things: over-accrual (the team books larger estimates than needed, then reverses the excess), poor estimation quality (the accruals are consistently far from actuals), or a timing problem upstream (actuals arrive late, so the same items get accrued and reversed across several periods). All three are addressable, but the fix is in the underlying process, not in the reversal mechanics. **Why is the window the last close rather than a rolling period?** Because accrual reversals are a close-cycle event. They cluster at and just after period-end, tied to a specific close. Bounding the card to the last close gives a clean, comparable read period over period (this close versus the previous one) rather than a rolling average that would blur the close-cycle pattern. **Should I read this with the manual JE ratio?** Yes, it is one of the most useful pairings. If accrual reversals are high and the [Manual JEs as % of Total](/nerve-centre/kpi-cards/oracle-erp/manual-jes-as-of-total) ratio is also high, it usually means accruals are being booked and unwound by hand rather than through automated recurring journals or allocation rules. That is both an efficiency drain and an estimation-quality risk, and it is exactly the combination auditors probe. **Can I reduce accrual reversals?** Often, yes, by addressing the upstream cause. Faster supplier-invoice capture reduces goods-received-not-invoiced accruals; better unbilled-revenue tracking reduces revenue accruals; and converting standing manual accruals into automated recurring journals or allocation definitions in Oracle makes the rhythm predictable. The goal is not zero reversals (that is unrealistic) but a stable, explainable count. **Does this card respect the period close workflow?** Yes. It reads the reversals tied to the last completed close, in step with how Oracle Fusion processes auto-reversals and how the close workflow surfaces them. Reading it with [GL Period Close Status](/nerve-centre/kpi-cards/oracle-erp/gl-period-close-status) and [Period Close On-Time Rate (12mo)](/nerve-centre/kpi-cards/oracle-erp/period-close-on-time-rate-12mo) gives the controller a full view of how reversal churn is affecting close discipline. *** ### Tracked live in Vortex IQ Nerve Centre *Accrual Reversals (last close)* is one of hundreds of KPI pulses Vortex IQ tracks across Oracle ERP Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.