Skip to main content
Card class: Non-HeroCategory: Ecommerce Platform
The percentage of monthly period closes completed by the internal deadline over the trailing 12 months. Below 90% signals close-process strain.

At a glance

The proportion of monthly period closes finished on or before the internal deadline across the last 12 months. It turns the live close picture into a reliability score. One late month is noise; a rate drifting below 90% is a pattern, and patterns in close performance are early signals of under-resourcing, fragile manual processes, or an entity that needs help.
What it countsCloses completed on or before the internal deadline, divided by total closes due, over the trailing 12 months. A close “counts” for the entity / month it relates to; a month closed after its deadline counts against the rate. In Finance & Operations this draws on when each Ledger period moved to closed against the close schedule; in Business Central it infers close timing from when the period’s posting range was locked relative to the deadline.
ScopeAcross selected legal entities by default, so it is a group reliability score. Filter to one entity to see whether a single entity is dragging the group rate down.
UnitPercentage (a gauge) over a rolling 12-month window.
CurrencyNot applicable; this is a process-reliability metric, not a value metric.
Multi-CompanyAggregated across entities. A group rate of 90% can hide one entity at 60% offset by others at 100%, so always check the per-entity split.
Time window12mo (trailing 12 months)
Alert trigger<90%
Rolesowner, finance

Calculation

Calculated automatically from your Microsoft Dynamics 365 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 US-headquartered group on Finance & Operations with three legal entities, snapshot 12 Jun 26 covering the trailing 12 months (Jun 25 to May 26). The internal deadline is the 6th working day of the following month.
Legal entityCloses dueOn timeLateOn-time rate
US HoldCo12120100%
US Retail Inc1211192%
EU DTC BV127558%
Group3630683%
The group rate is 83%, below the 90% line, so the card is amber. Four things to notice:
  1. The group looks worse than two of three entities. US HoldCo and US Retail Inc are both fine. The group rate is dragged under 90% almost entirely by EU DTC BV at 58%.
  2. EU DTC BV is the whole story. Five late closes in twelve months is a structural problem at that entity, not bad luck. The fix is there, not a group-wide process change.
  3. One late month at a good entity is noise. US Retail Inc’s single miss (92%) does not warrant intervention. The 12-month window exists precisely so one bad month does not over-react.
  4. This pairs with the live status card. Ledger Period Close Status tells you who is late right now; this card tells you who is chronically late. EU DTC BV showing up on both is the signal to investigate resourcing or process at that entity.

Sibling cards merchants should reference together

Period Close On-Time Rate is the trend behind close reliability. Pair it with these to connect the pattern to its causes.
CardWhy pair
Ledger Period Close StatusThe live counterpart. This card is the 12-month trend; that one is today’s state. An entity on both is chronically and currently late.
Ledger Period Close Past DeadlineThe current breaches feeding next month’s data point in this trend.
Accrual Reversals (last close)Heavy accrual processing slows close. Noisy reversals at a low-on-time entity point at where the time goes.
Open (Not Posted) Journal EntriesA persistently large unposted queue is a leading cause of late close.
Manual Journals as % of TotalA high manual workload correlates strongly with slower, less reliable close.

Reconciling against Microsoft Dynamics 365

Where to look in Business Central / Finance & Operations:
Finance & Operations: General ledger > Period close > Financial period close workspace (task completion dates against the close schedule) Finance & Operations: General ledger > Period close > Ledger periods (when each period moved to closed) Finance & Operations: General ledger > Ledger setup > Ledger calendars (period structure underpinning the schedule) Business Central: Finance > Accounting Periods (and the historical changes to the Allow Posting range that mark each close)
To reconcile: for each of the last 12 months, compare when the period actually closed against its internal deadline, then average across months and entities. The card should match that manual tally subject to how close timing is captured. Why our number may legitimately differ:
ReasonDirectionWhy
Deadline definitionEitherThe rate uses your configured internal deadline. A native review against the statutory filing date will produce a different (usually higher) on-time rate.
Close-timing sourceEitherF&O records explicit close actions; BC infers close from when the posting range was locked. If a BC team locks the range late even though work finished on time, the inferred timing differs from reality.
Reopened periodsEitherA period closed on time then reopened for an audit adjustment may be counted differently depending on whether the reopen is treated as a new close event.
Entity weightingEitherThe group rate weights each entity-month equally. A native view that weights by revenue or transaction volume reads differently.
New entitiesCard lowerAn entity onboarded mid-year has fewer closes in the window, so its early misses carry more weight in its own rate.
This card has no commerce-side equivalent; close reliability is an ERP-only concept. Indirectly, a chronically low rate erodes confidence in month-end revenue and reconciliation, which is why a falling rate often shows up alongside slower resolution of the Revenue Gap vs Commerce.

Known limitations / merchant FAQs

Why is 90% the alert line? Roughly one missed close per year (out of twelve) is tolerable; consistently missing more than that signals a process under strain. 90% is a sensible default rather than a regulatory standard, and it is adjustable in card settings to suit your tolerance. Whose deadline does “on time” use? Your internal close deadline, configured during onboarding (for example the 6th working day). The default is intentionally the internal target, not the statutory filing date, because the internal deadline is what keeps reporting and consolidation on track. Why a 12-month window rather than this month? To separate signal from noise. One late month happens to everyone. A 12-month trailing rate reveals whether late close is the exception or the norm, which is the actionable distinction. For the live picture, use Ledger Period Close Status. The group rate looks fine, can an entity still be in trouble? Yes, and this is the most important caveat. A 92% group rate can hide one entity at 60% offset by others at 100%. Always open the per-entity split before concluding the group is healthy. How does the card know when a close actually happened? In F&O it reads when each ledger period moved to closed against the close schedule. In BC, which has no explicit close action, it infers timing from when the period’s posting range was locked. The BC inference is slightly softer, which is noted in reconciliation. Does reopening a period count against the rate? It depends on configuration, but a period that closed on time and was later reopened for an adjustment is generally not retroactively marked late, since the original close met the deadline. What is the fastest lever to improve the rate? Find the lowest-scoring entity and look at its Open (Not Posted) Journal Entries and Manual Journals as % of Total. Reducing the unposted backlog and automating routine entries is usually where the time is recovered.

Tracked live in Vortex IQ Nerve Centre

Period Close On-Time Rate (12mo) is one of hundreds of KPI pulses Vortex IQ tracks across Microsoft Dynamics 365 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 or book a demo to see this metric running on your own data.