The percentage of the last 12 GL closes finished on or before deadline. Close discipline at a glance.
At a glance
Period Close On-Time Rate measures the percentage of the last 12 monthly General Ledger period closes that were completed on or before the published close deadline. It is the controller’s headline discipline metric: a single trailing number that says whether the finance organisation is closing the books reliably or repeatedly slipping. A consistently high rate is evidence of a well-run close, clean subledger-to-GL posting, and few last-minute surprises. A falling rate is an early signal that something structural is dragging the close, whether posting backlogs, reconciliation issues, integration failures, or estimation churn. Boards, auditors, and lenders all read close timeliness as a proxy for the overall health of financial controls.
| What it counts | On-time closes / total closes over the trailing 12 monthly periods, expressed as a percentage. A close is on-time if the GL period was closed on or before the deadline the organisation publishes in its close calendar. |
| Why it matters | Close timeliness is a leading indicator of control health. Late closes delay reporting, frustrate stakeholders, and often hide an underlying problem (posting backlogs, unreconciled balances, broken integrations) that the on-time rate makes visible as a trend. |
| What a healthy rate looks like | At or near 100%. Most well-run large-enterprise finance functions target every close on time, treating a single slip as an incident to be explained. |
| What pulls it down | Posting backlogs (unposted or error journals at period-end), subledger-to-GL posting failures, slow reconciliations, accrual churn, integration outages that delay data into Fusion, and resourcing gaps in the close team. |
| Business Unit scope | Respects the dashboard’s selected Business Unit and Ledger filter. By default reflects the close calendar across the Ledgers the connected role can see. |
| Time window | 12mo (trailing 12 monthly closes) |
| Alert trigger | <90% - dropping below nine of the last twelve closes on time signals a discipline problem |
| 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 Fortune 500 retailer runs Oracle ERP Cloud and publishes a close calendar requiring each monthly GL period to be closed by business day five (BD5). The controller reviews the trailing 12 closes ending with the May 26 close (period ended 31 May 26).| Close period | Deadline | Actual close | On time? |
|---|---|---|---|
| Jun 25 to Jan 26 (8 periods) | BD5 each | On or before BD5 | Yes (all 8) |
| Feb 26 | BD5 | BD5 | Yes |
| Mar 26 | BD5 | BD7 | No - posting backlog |
| Apr 26 | BD5 | BD6 | No - reconciliation delay |
| May 26 | BD5 | BD5 | Yes |
- Ten of the last twelve closes were on time, giving an 83.3% rate. That is below the
<90%alert line, so the card flags it. A year ago the rate was 100%; the two recent slips dragged it under the threshold. - The two misses had different causes but a common theme. March slipped on a posting backlog (unposted and error journals not cleared by BD5); April slipped on a slow subledger reconciliation. Both are close-mechanics problems that show up on the journal-health cards before they show up here.
- The on-time rate is the lagging summary; the journal-health cards are the leading indicators. If the controller had watched Open (Unposted) Journals and Journals in Error climbing in the last days of March, the late close was foreseeable. This card confirms the pattern over time.
- One more slip would compound the signal. At 83.3% the trend is the story, not the absolute level. A third consecutive miss would tell the board that the close process needs structural attention (resourcing, automation, or integration reliability), not just a one-off catch-up.
Sibling cards merchants should reference together
The on-time rate is the lagging summary of close discipline. Pair it with the leading indicators that predict a slip.| Card | Why pair it with Period Close On-Time Rate |
|---|---|
| GL Period Close Status | The live status of the current close. This card is the 12-month history; that card is the now. |
| GL Period Close Past Deadline | The real-time flag that the current close has already slipped, which will pull this rate down next month. |
| Open (Unposted) Journals | A posting backlog at period-end is the most common cause of a late close. |
| Journals in Error (PostedFlag=E) | Error journals block a clean close and delay the deadline. |
| Accrual Reversals (last close) | Estimation churn slows the close and threatens the on-time rate. |
| Subledger-to-GL Posting Interface Errors (24h) | A subledger posting break near period-end is a classic close-delay trigger. |
| Oracle Fusion Health Score | The composite that close timeliness contributes to. |
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 → Period Close → Manage Accounting Periods (period statuses and close dates per ledger) Navigator → General Accounting → Period Close → Close Status (the close monitor for each period) Reports and Analytics → OTBI → Financials → General Ledger - Period Status (close dates as a history)Oracle Fusion records when each GL period status moves to Closed. Comparing those close dates against your published close calendar, period by period over the last 12 months, reproduces this card’s on-time rate. The card uses the same period-close timestamps Oracle records, measured against the deadline you configure. Common mistakes when comparing against Oracle’s own reports:
- Confusing the GL close with the subledger close. Receivables and Payables periods close before the GL period. This card measures the GL period close against its deadline, not the subledger closes. Make sure you compare the right close event.
- Using period-end date as the deadline. The deadline is a business-day target in your close calendar (for example BD5), not the calendar period-end. Comparing close date to period-end rather than to the deadline gives a different, usually flattering, rate.
- Ledger scope. Different ledgers can have different close calendars and dates. A multi-ledger organisation should match the card’s ledger scope to its query.
| Reason | Direction | Why |
|---|---|---|
| Deadline definition | Either | The on-time test depends on the published deadline (for example BD5). If your Oracle comparison uses a different deadline, the rate differs. The card uses the configured close deadline. |
| GL vs subledger close | Either | Measuring subledger close dates instead of the GL close changes which event counts as on time. |
| Ledger scope | Either | Different ledgers have different close calendars; the card and a scoped Oracle query can diverge on a multi-ledger account. |
| Reopened periods | Either | A period reopened after close for an adjustment can be treated as on time (original close) or not, depending on convention. |
Known limitations / merchant FAQs
What counts as on time? A close is on time if the GL period was closed on or before the deadline in your published close calendar, typically expressed as a business day (for example BD5). The card measures the actual GL close date against that configured deadline. It does not use the calendar period-end date as the bar, because the close always happens some days after period-end by design. Why 12 months rather than a shorter window? Close discipline is a trend, not a single event. A 12-month trailing window smooths out one-off slips and shows whether the close is reliably on track or structurally drifting. It also aligns with how boards and auditors think about the metric: over a full year, how often did finance hit its close deadline? Why is the alert at 90% rather than 100%? Most well-run finance functions target 100%, but treating a single slip in twelve months as an alert would be too noisy, since occasional one-offs happen (a system outage, a one-time complex adjustment). The<90% line means more than one miss in the trailing year, which is the point at which a pattern, rather than an isolated incident, is likely forming and deserves the controller’s attention.
The rate dropped but each individual close was nearly on time. Does a one-day slip count as a miss?
Yes. The metric is binary per close: on or before deadline is on time, anything later is a miss, regardless of by how much. A consistent pattern of one-day slips is itself a signal that the deadline is too tight or that a recurring bottleneck needs fixing. The companion GL Period Close Status and journal-health cards show how close each miss was and why.
How do I improve the on-time rate?
Address the leading indicators before period-end. Keep the Open (Unposted) Journals and Journals in Error counts low through the month so there is no posting backlog at close; fix Subledger-to-GL Posting Interface Errors the day they occur; and reduce accrual churn. The on-time rate rises as the upstream close mechanics get cleaner.
Does a reopened period count against the rate?
It depends on convention. A period that closed on time and was later reopened for a single adjustment is generally still treated as an on-time close, because the original close met the deadline. The card follows the close timestamps Oracle records; if your organisation treats reopened periods differently, confirm the convention so the rate matches your close governance.