Reconciliation status, read cleanly

Three screens carry the status story: the Worklist for who owes what, the Overview dashboard for the open counts, and the pivot for status by preparer. This page maps them, foots a worked close week, and shows the same answer coming out of the owned model.

Note: In ARCS, Oracle's account reconciliation module, every account's reconciliation moves through a workflow each period: prepared, reviewed, closed. Status is the close manager's daily question: how many are done, and who holds the rest.

One question this page answers: on day three of close, who is holding what, and does the total foot? The whole module is mapped on the Account Reconciliation index.

RuleRead status by the four resting values, foot the total against the period population, and keep the history in a model you own so last close is still a query.

Neverhand-collect status into a spreadsheet on close day. The application knows, ARM_RECONCILIATIONS holds it, and the export runs nightly without anyone asking.

◆ Where each number lives, Worklist, Overview dashboard, and the pivot, doc-linked.

Number	Where it lives in the app
Who holds what	The Worklist: each user's open reconciliations, summarized All, Late, Due Today, Due in 7 Days, per Oracle's admin guide. It shows only tasks needing that user's action.
Open counts	The Overview dashboard: open and late reconciliations, completion by risk rating, account type, organizational unit, format, or process, per the dashboards doc.
Status by preparer	The documented pivot view. Useful live, gone when the period is history, which is the case for the owned model below.

The four resting statuses and why rejection is not one of them are defined on Profiles & formats. This page is about reading the numbers; that page is about what they mean.

◆ One Tuesday, footed, and the Wednesday morning after, the sixty-entity close week, and the reopened bank rec, in the console.

The sixty-entity group, Tuesday 18:00, day three of the June close:

Status	Count	Reading
Closed	268	Done, 247 on time and 21 late. The on-time story lives on the compliance page.
Open with Preparer	96	Being worked, including the six rejected back this period.
Open with Reviewer	45	Waiting on approval.
Pending	3	Start date not yet reached.

Totals foot: 268 + 96 + 45 + 3 = 412. Overnight, the late Chilean journal from the FCCS consolidation story changes the 1010-CL balance, the Wednesday load reopens that closed reconciliation, and the morning reads 267 closed, 97 with preparers. Same total, one moved row, and the console below says exactly which one and why.

THE SAME SCENARIO, IN THE CONSOLE

how are we doing on the close?run it live →

✓ status read from ARM_RECONCILIATIONS ✓ nightly export gated ✓ reopened items joined to the journal that moved them
answer Wednesday 07:00 · closed 267 of 412 · 97 with preparers · 45 in review · 3 pending · reopened overnight: 1010-CL, the Chilean subsidiary, balance changed by a late journal

read-only, computes nothing outside the star, writes nothing anywhere. The full console runs on irvineanalytics.ai.

THE USE CASE, SIMPLIFIED

The problem: Close-day status is collected by hand, every day of close week.

What we build: A nightly snapshot of every reconciliation's status lands footed in your warehouse.

What you get: The morning status foots to the population, and every overnight reopen arrives explained.

Close-day status still assembled by hand?

We wire the nightly status export into your warehouse, and every morning of close week starts with the footed answer instead of a collection exercise.

Talk to us

Terms on this page

Worklist: Your open items, summarized All, Late, Due Today, Due in 7 Days.
Overview dashboard: Open and late counts, sliceable by risk, type, org, format, process.
footing: The statuses must sum to the period population. If not, stop and ask why.
reopen: A changed balance sends Closed back to Open with Preparer. By design.