Financial Operations · Readiness
Close Readiness Scoring: Knowing on Day One How the Close Will Go
Every controller knows by day three whether the close will be late. Readiness scoring is how you know on day one — while there is still time to do something about it.
The short answer
Close readiness scoring assigns each close prerequisite one of five states, weights it by consequence, identifies a named blocker for anything blocked, and computes which blockers sit on the critical path — producing a single figure per entity per day that predicts whether the close will finish on time and shows precisely what to fix first. The score itself matters less than two things it produces: a named blocker for every stuck item, and an ordering of what to unblock first.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸Three states are not enough. Blocked and superseded are the two that explain lateness, and most trackers have neither.
- ▸Weight by consequence and by dependency count. A blocked intercompany confirmation that gates eleven items is not equal to an unstarted immaterial reconciliation.
- ▸Every blocked item needs a named blocker and an owner. ‘Blocked’ without those is a status nobody can act on.
- ▸Supersession detection is the highest-value check and nobody does it manually: completed work invalidated by a later source change.
- ▸Read the shape, not the number. A 72% score with three critical-path blockers is worse than a 61% score with none.
Source: Mark Alex, Real Biz Digital — Close Readiness Scoring: Knowing on Day One How the Close Will Go (https://realbizdigital.net/insights/close-readiness-scoring/). Reproduce with attribution.
Key takeaways
- 01Enumerate every prerequisite once. The list is the asset; the score is derived from it.
- 02Define the five states precisely and enforce them. Ambiguous states produce a score nobody trusts.
- 03Attribute every blocker to a person or an external party, with an expected resolution date.
- 04Compute the critical path daily. Priorities that follow dependency counts beat priorities that follow escalation volume.
- 05Trend the day-one score across closes. It is the single best measure of whether the close is structurally improving.
- 06Publish at the same time every day. A readiness report at an unpredictable hour gets read once.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is close readiness scoring?
- Assigning every close prerequisite a state, weighting it by consequence and dependency, naming a blocker for anything blocked, and computing a single readiness figure plus a critical path.
- Why are five states needed?
- Because blocked and superseded explain lateness, and trackers with only not-started, in-progress and complete cannot represent either.
- What is supersession?
- Completed work invalidated by a later change in its source — a reconciliation finished before the sub-ledger changed. It is the most common cause of close rework.
- How should items be weighted?
- By consequence — materiality and regulatory exposure — and by how many other items depend on them.
- What is the critical path here?
- The blocked items whose resolution would unblock the most downstream work, which is what should be worked on first.
- What does a good day-one score look like?
- It varies by organisation, but the trend matters more than the level. Rising day-one readiness across closes means the process is structurally improving.
- Who owns a blocker?
- A named person or an identified external party, always, with an expected resolution date. Unowned blockers do not get resolved.
Five states, defined precisely
Ambiguous state definitions produce a score nobody trusts. These five are mutually exclusive and jointly exhaustive.
Key facts
- ▸Most close trackers implement three of these five, which is why they can report progress but not predict lateness.
- ▸The Blocked-versus-Not-started distinction is the single most valuable definitional discipline available. It converts ‘we are 60% done’ into an actionable list.
- ▸Superseded items are invisible in every manual tracker we have seen, and they are a large share of the rework that makes closes feel chaotic.
- Not started
- No work has begun, and nothing prevents it beginning. This is capacity, not a problem. If something prevents it, the item is Blocked, not Not started — and conflating the two is the most common defect in close trackers.
- In progress
- Work has begun and can continue. Should carry an owner and an expected completion. An item in progress for three days with no movement is a blocker in disguise.
- Complete
- The work is done, reviewed if review is required, and its evidence is attached. Complete without evidence is a weaker state and should be tracked separately if your process permits it.
- Blocked
- Work cannot proceed until a specific named dependency resolves. Requires a blocker type, an owner and an expected resolution date. This is the state that explains lateness.
- Superseded
- Previously complete, but the source data has since changed, so the work must be redone. Detected automatically by comparing completion timestamps against source change timestamps.
Enforce the definitions with validation. An item cannot be Blocked without a blocker type and an owner, and cannot be Complete without evidence where evidence is required.
Weighting by consequence and dependency
An unweighted percentage is misleading, because it treats a blocked bank reconciliation as equal to an unstarted immaterial accrual.
| Factor | Range | Rationale |
|---|---|---|
| Materiality factor | 0.5–3.0 | A material account matters more than an immaterial one; use your own thresholds |
| Dependency count | 0–20+ | Each dependent item adds weight, because blocking it blocks others |
| Regulatory factor | 1.0–2.0 | Items with SOX or statutory significance carry additional weight |
| Prior-period difficulty | 1.0–1.5 | Items that were late last close are more likely to be late again |
Readiness score
score = Σ(weight_i × state_value_i) / Σ(weight_i) weight = materiality_factor × (1 + dependency_count × 0.15) × regulatory_factor state_value: complete 1.0, in progress 0.5, not started 0.2, blocked 0.0, superseded 0.0
Not started scores 0.2 rather than 0 because unstarted work with capacity available is materially better than blocked work. Blocked and superseded both score zero, because neither can progress today.
Weights should be set once with the controller and then left alone. Weights adjusted mid-close to make the score look better are the fastest way to make the whole exercise worthless.
A six-type blocker taxonomy
Classifying blockers is what makes them actionable, because each type has a different owner and a different resolution path.
- 01External data blockers dominate in most closes and are the least controllable. The mitigation is a standing cut-off policy rather than daily chasing.
- 02Upstream close blockers are usually self-inflicted sequencing errors. Work started before its prerequisite becomes superseded work later.
- 03Approval blockers should be handled like any other approval: expiry, escalation, named alternative.
- 04System blockers are almost entirely preventable with pre-flight checks in the days before the close begins.
- 05Information blockers are the most frustrating and the cheapest to fix, because someone knows the answer and nobody asked them directly.
- 06Track blocker type distribution across closes. A shift in the mix tells you where to invest structurally.
| Type | Example | Owner | Typical resolution |
|---|---|---|---|
| External data | Bank statement, custodian valuation, supplier confirmation | External party | Chase; escalate to relationship owner |
| Intercompany | Counterparty confirmation or balance agreement | Other entity’s finance team | Escalate to group; use a standing cut-off |
| Upstream close | Sub-ledger not yet closed | Sub-ledger owner | Sequence properly; do not start dependent work early |
| Approval | Awaiting a review or sign-off | Named approver | Expiry and escalation, as with any approval |
| Information | A question unanswered by anyone | Whoever knows | Route to a person, not to a queue |
| System | Integration failure, report unavailable, access problem | IT or platform | Pre-flight checks before the close begins |
The distribution of blocker types is more useful than any individual blocker. If forty percent are external data, the fix is a cut-off policy conversation, not a better tracker.
Critical path and what to fix first
Not all blockers are equal. The critical path is the ordering that unblocks the most work fastest, and it is frequently not the ordering that intuition suggests.
Build the dependency graph
Which items require which others to be complete. Most of this is stable across closes and needs building once.
Compute transitive blocked count
For each blocked item, how many items are blocked by it directly or indirectly. This is the number that should drive priority.
Weight by downstream materiality
Blocking eleven immaterial items matters less than blocking two material ones. Combine count with weight.
Order and publish daily
A short ordered list — usually three to six items — that will unblock the most work. Short enough to act on before lunch.
Track resolution velocity
How long items on the critical path take to resolve. A critical path that does not move is a management problem, not a data problem.
Intuition would prioritise the bank statement, because bank reconciliations feel urgent and material. The graph says the intercompany confirmation unblocks nearly twice as much work, and the bank statement will arrive on its own schedule regardless of chasing.
The pattern generalises: the highest-value blocker is frequently the one that feels least urgent, because urgency correlates with visibility rather than with dependency count.
Supersession detection
The check nobody performs manually, and the one that most reduces the sense that a close is chaotic.
- 01Compare completion time against every source the item depends on, not just the primary one.
- 02Notify the preparer and the reviewer, not a queue. Supersession creates rework for specific named people who need to know immediately.
- 03Record the delta where possible. ‘The sub-ledger balance changed by £4,200 after you reconciled’ is far more useful than ‘this needs redoing’.
- 04Distinguish material from immaterial supersession. A one-penny change should not trigger a full re-performance, and your materiality threshold should govern.
- 05Count supersession events per close and trend them. A high count is a sequencing problem: work is starting before its prerequisites are stable.
- 06Feed the count back into sequencing. If the same item is superseded every close, it is being started too early by design.
The supersession test
for each item where state == complete: if source_last_modified > item_completed_at: state := superseded notify(preparer, reviewer) record(reason, source, delta)
It is a timestamp comparison. The difficulty is not the logic; it is having reliable source modification timestamps, which is a data-access problem worth solving once.
Supersession count is one of the best proxies for close process maturity. It falls when sequencing improves and it cannot be gamed.
How to read the score
- ›High score, several critical-path blockers — progress on easy items while the hard ones wait
- ›Rising score, rising supersession — rework being counted as progress
- ›High score, low evidence completeness — work done but not supportable
- ›Flat blocker count, high resolution velocity — new blockers arriving as fast as old ones clear
- ›Low day-one score, zero critical-path blockers — lots of work to do, nothing preventing it
- ›Score dip on day two — usually supersession detection working correctly
- ›High blocked count, all external — a cut-off policy issue, not an execution issue
- ›Slow score rise with falling post-close adjustments — a more careful close
- 01Report the score, the critical path and the supersession count together. Any one alone is misleading.
- 02Trend day-one readiness across closes. It is the only figure that shows structural improvement rather than effort.
- 03Publish at the same time daily. Predictability is what turns a report into a routine.
- 04Show the blocker owner list, not just the count. Names create movement in a way that percentages do not.
- 05Never adjust weights mid-close. The score’s only value is comparability.
- 06Pair the score with post-close adjustments after the fact. A close that scored well and produced adjustments was fast rather than good.
The score is a management instrument, not a grade. Its purpose is to change what people work on this morning.
Next step
A readiness score against your real close, read-only
Barzel FinOps Atlas computes close readiness, detects blockers and identifies evidence gaps as callable tools — free sandbox tier, no writes to anything.
What the score does not tell you
Two limits.
- 01It measures readiness, not quality. A close can score 100% and still contain a material error, which is why post-close adjustments remain the quality measure.
- 02It depends entirely on the prerequisite list being complete. An item nobody enumerated is invisible to the score, and the first two closes always reveal missing items.
Frequently asked questions
What is close readiness scoring?
Assigning each close prerequisite one of five states, weighting it by materiality and dependency count, naming a blocker for anything blocked, and computing a single readiness figure per entity per day alongside a critical path of what to unblock first.
Why do close trackers need five states rather than three?
Because blocked and superseded are the two states that explain lateness. A tracker with only not-started, in-progress and complete can report progress but cannot distinguish work waiting on a bank statement from work nobody has picked up.
What is the difference between blocked and not started?
Not started means nothing prevents the work beginning — it is available capacity. Blocked means a specific named dependency must resolve first. Conflating them is the most common defect in close tracking and it hides the entire actionable picture.
What is supersession in a close context?
Previously completed work invalidated by a subsequent change in its source data, such as a reconciliation finished before the sub-ledger changed. It is detected by comparing the item’s completion timestamp against source modification timestamps.
How should close items be weighted?
By a materiality factor, a dependency multiplier reflecting how many other items depend on this one, a regulatory factor for statutory or SOX significance, and optionally a prior-period difficulty factor for items that were late last close.
Why does not-started score above zero?
Because unstarted work with available capacity is materially better than blocked work. Scoring not-started at 0.2 and blocked at zero reflects that a blocked item cannot progress today regardless of effort.
What are the six blocker types?
External data, intercompany confirmation, upstream close, approval, information, and system. Each has a different owner and resolution path, which is what makes classification worth doing rather than simply flagging items as stuck.
How is the close critical path computed?
Build the dependency graph, compute for each blocked item how many items it blocks directly or indirectly, weight by downstream materiality, and publish a short ordered list of three to six items that would unblock the most work.
Why is the critical path often counter-intuitive?
Because urgency correlates with visibility rather than dependency count. A bank reconciliation feels urgent and material; an intercompany confirmation that blocks eleven downstream items rarely feels urgent, and unblocking it releases nearly twice as much work.
What does a good readiness score look like?
The level matters less than the shape. A 72% score with three critical-path blockers is worse than 61% with none, and a rising score alongside rising supersession means rework is being counted as progress.
Should weights be adjusted during a close?
Never. The score’s entire value is comparability across days and across closes, and weights adjusted mid-cycle to improve the number destroy that value immediately.
What does readiness scoring not measure?
Quality. A close can score 100% and still contain a material error, which is why post-close adjustments remain the quality metric and why a close that scored well but produced adjustments was fast rather than good.
Glossary
- Close readiness score
- A weighted measure of completion across all close prerequisites for an entity and period.
- Item state
- One of five mutually exclusive statuses: not started, in progress, complete, blocked, superseded.
- Blocker type
- A classification of what prevents an item progressing, determining its owner and resolution path.
- Dependency graph
- The recorded relationships determining which close items require which others.
- Transitive blocked count
- How many items a given blocker prevents, directly or indirectly.
- Supersession detection
- Automatic identification of completed work invalidated by source change.
- Materiality factor
- A weighting reflecting the financial significance of a close item.
- Day-one readiness
- The readiness score at the start of the close, the best predictor of on-time completion.
- Resolution velocity
- How quickly critical-path blockers are resolved once identified.
- Prerequisite list
- The enumerated set of all work required to close a period for an entity.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · COSOCOSO Internal Control — Integrated Framework ↗The control framework auditors map financial process evidence against.
- 02 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 03 · PCAOBPCAOB AS 1105 — Audit Evidence ↗The standard defining sufficiency, appropriateness, relevance and reliability of audit evidence.
- 04 · BlackLineBlackLine — Agentic Financial Operations ↗Market reference: the phrase ‘Agentic Financial Operations’ and the governance framing around it.
- 05 · TrintechTrintech — AI agents for financial close ↗Market reference: variance and flux agents with reviewer signoff and traceable evidence.
- 06 · AxelosITIL 4 — change enablement ↗Established change-management vocabulary this article borrows for MCP estates.
- 07 · IFRS FoundationIAS 7 — Statement of Cash Flows ↗The reporting standard cash-position and cash-variance work ultimately serves.
- 08 · WikipediaLittle’s Law and queueing fundamentals ↗Arrival rate, concurrency and latency — the arithmetic behind capacity planning.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). Close Readiness Scoring: Knowing on Day One How the Close Will Go. Real Biz Digital. https://realbizdigital.net/insights/close-readiness-scoring/
Try the mechanics on a live server
To watch an MCP server answer a structured request before you let one read your ledger — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel FinOps Atlas is this assurance layer, sold as a running product
Thirty tools covering close readiness and blocker detection, cash position, cash variance and cash-flow risk, transaction risk scoring, policy exception detection, control risk, finance approvals, and the evidence surface — evidence-to-control mapping, evidence graphs, evidence tracing, chain verification, missing-evidence detection, auditor request answering and audit packet generation. A free sandbox tier means the first readiness report costs nothing.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Free Sandbox | Free | 500 calls/mo · close readiness, blockers, evidence checks | Testing readiness scoring against one real close |
| Starter | $29/mo | 1,000 calls/mo · evidence mapping, cash position, approvals | A single entity running one governed close cycle |
| Growth | $99/mo | 5,000 calls/mo · evidence graph, audit packets, control risk | A controller’s team with an external audit each year |
| Business | $249/mo | 15,000 calls/mo · the full 30-tool surface | Multi-entity close with SOX obligations and continuous audit readiness |
| Enterprise | $799/mo | 50,000 calls/mo · everything in Business, scaled | Group-wide finance operations across many entities |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.