Unmatched aging, the key control with no report behind it
The application computes the age of every unmatched transaction and shows it on a screen. What auditors ask for is the over-90-days list per period, trended, and no in-app route produces that. This page shows the routes, where each stops, and the owned version.
Note: Transaction Matching is the high-volume half of ARCS, Oracle's reconciliation module: it pairs transactions between two systems, bank statement and ledger for example, by rule. Whatever the rules cannot pair stays unmatched, and how long it has stayed that way is this page.
One question this page answers: what exactly is unmatched over 90 days, per period, and who is looking at it? The whole module is mapped on the Account Reconciliation index.
◆ Why the age is a control number, the live ask, the documented Age column, and the archive penalty.
Old unmatched transactions are the residue auto match could not explain, and their age is a control number: a live Customer Connect ask calls the unmatched-over-90-days-by-period report a key control in their organization, and gets pointed at workarounds. Two facts make the age hard to ignore. The application computes it, per Oracle's own doc: an Age column on Unmatched Transactions, today minus the Accounting Date. And old items carry an operational penalty: per the archive doc, a profile holding unmatched transactions older than the archive-age date is excluded from archive jobs entirely, so aged residue blocks housekeeping, not just sign-off.
◆ Three routes in the app, and where each stops, worklist, dashboard, and the per-reconciliation REST report.
| Route in the app | Where it stops |
|---|---|
| Unmatched list, Age column | A worklist, not a report. Sort oldest first and work the pile; the screen scrolls 50,000 rows at most and manual selection caps at 1,000. Nothing here trends across periods or lands in an inbox. |
| Dashboard chart | The documented chart view for unmatched by account type reads well on screen; a live thread still asks for matched and unmatched counts the balance summary report does not show. |
| Balance Report Transactions | Since the September 2025 update, a REST call generates it, one reconciliation and one accounting date per call. The key-control report needs every reconciliation, bucketed, per period. |
◆ The owned aging report, one query, every bucket, any as-of date; the map, drillable.
The owned version is one query on the nightly extract: every unmatched transaction with its age, bucketed, per period, any as-of date, trending across months. June in the sixty-entity group: 414 unmatched of 24,618 loaded, aging 198 at 0 to 30 days, 121 at 31 to 60, 58 at 61 to 90, and 37 over 90. The buckets foot: 198 + 121 + 58 + 37 = 414. The 37 is the number the auditor asks for, and in the owned report it comes with names, amounts, and how long each has been sitting.
The problem: The over-90-days list auditors ask for by name has no report behind it.
What we build: The matching transactions export nightly and the aging view buckets them by period.
What you get: The auditor's list, with names and amounts, trended month over month, every morning.
- Age
- Days since the accounting date. Computed by the app, reportable only by you.
- unmatched
- What auto match could not explain. The residue is the risk.
- bucket
- 0 to 30, 31 to 60, 61 to 90, over 90. The auditor reads the last one.
- archive age
- Old unmatched items exclude the profile from archive jobs.