The forward capital register: what it is and why it matters

At a glance

• A forward capital register is a live list of the company’s material deployed dollars, each scored against current context, with a defender named and a re-decide date attached.
• It is not a budget. A budget records intent, once a year. The register defends deployment, every month, and it can answer the one question a chart of accounts never can: which dollars are deployed against a context that has died.
• The first version gets built inside the first 14 days of a Diagnostic, then feeds the monthly Decision Review and the board packet from then on.

A forward capital register is a live register of the company’s material deployed dollars, each one scored against the current context, with a defender named and a re-decide date attached. That is the whole definition. The rest of this piece is what goes in it, how it differs from the budget you already have, and how it gets built and used.

Why isn’t the chart of accounts enough?

Most companies in the $1M to $8M ARR band run their capital thinking off the chart of accounts. The CoA is necessary and it is backward-facing by design: it explains what happened, classified correctly, for reporting. Ask it what last quarter’s cloud spend was and it answers precisely. Ask it which of those dollars should still be deployed next quarter and it has nothing to say. It was never built to.

The forward capital register asks a different question of every recurring dollar in the company: what is the next move on this dollar, who defends it, and does the premise it was deployed against still exist? A vendor contract signed against a growth plan from the last raise, a headcount block built for a channel that has since repriced, a lease scaled for a hiring curve that flattened. Each of those dollars made sense once. The decisions weren’t wrong. They were right for a context that no longer exists. The register is the instrument that notices when the context dies, while the dollar is still recoverable.

A company with a current register can answer the most useful question a board can ask: which dollars are deployed against a context that has died. The CoA cannot answer it. The budget cannot either, for reasons covered below.

What does the register contain?

At its simplest, the register is three columns: the dollar, the next move, and the defender. That stripped version is enough to start with, and it is the version worth sketching this week if you have nothing. The working version we install carries six fields per row.

1. The dollar. The vendor line, the headcount block, the lease, the committed contract, with its monthly amount. One row per material deployed dollar; most companies set the materiality line between $2K and $5K of monthly recurring spend, plus every multi-year commitment regardless of size.
2. The original context. One sentence on the premise the dollar was deployed against. “Signed for a 40-person eng org by Q4.” “Priced against last year’s usage curve.” This field is what makes drift visible later.
3. The context score. Defendable, dead, or under review. Scored against today’s plan, not the plan the dollar was hired into. This is the field the board cares about.
4. The next move. What happens to this dollar in the next 90 days: renewed, renegotiated, cut, restructured, or held. “Held” is a legitimate answer; an unexamined renewal is not.
5. The defender. The person whose name sits next to the next move. Without a defender, the dollar moves by default, which in practice means it renews.
6. The re-decide date. The date the row comes back up for scoring, regardless of contract terms. Renewal dates belong to the vendor’s calendar; re-decide dates belong to yours.

Six fields, one row per dollar, one page when summarized. A register that needs a tutorial to read is a model, not a register.

How is the register different from a budget?

A budget records intent. It is built once, negotiated hard, approved in December, and then it ages. By March it describes a company that no longer quite exists, and by September the variance commentary is doing archaeology against it. None of that is a flaw in budgeting; it is what a planning document is.

The register defends deployment. It is live, it is re-scored every month against the close, and every row carries a name and a date. The budget asks “what did we agree to spend?” The register asks “should this dollar still be deployed, given what we now know?” The two documents disagree somewhere every single month, and the disagreement is the signal. A dollar can be exactly on budget and deployed against a dead context, and the budget will never flag it. The register exists to flag precisely that.

The other difference is ownership. A budget is owned by finance and defended by nobody in particular once approved. Every register row is defended by a named person, which means the question “why is this dollar still deployed?” always has an addressee.

How does the register get built in the first 14 days?

The first version is roughly half the work of a Diagnostic, and it follows the same arc as the first 14 days of an operational scan.

Days 1 to 3 are inventory: pull the GL detail, the vendor list, the payroll register, and the contracts folder, and reduce them to one row per material deployed dollar. Days 4 to 8 are context interviews: for each row, find the person who knows why the dollar was deployed and write the original premise in one sentence. This is where the dead contexts surface, usually a dozen of them, usually without anyone having decided anything. Days 9 to 14 are assignment: score every row, attach a defender, set the re-decide dates, and rank the dead-context rows by recoverable dollars.

The build is not a technology project. It lives in a spreadsheet for the first six months and loses nothing for it. The discipline is the cadence, not the tooling.

How does the register feed the Decision Review and the board packet?

The register is upstream of both. The rows scored dead or under review become the decision queue: each material one gets a three-path model (Keep, Kill, Restructure, dollars under each) and a slot in the monthly Decision Review. The review does not hunt for decisions; the register has already named them, with the math half built.

For the board, the register summary becomes one page in the packet: total deployed dollars, the split between defendable and dead, the quarter’s re-decide calendar, and the three rows the board is being asked to weigh in on, each rendered as a one-page decision slide. Boards read it faster than any variance section, because it answers the question they actually came with: is this company still deciding, or just spending?

What is the Decisive Finance role in this?

Building the first forward capital register is half the work of the 14-day Decision Diagnostic. We inventory the deployed dollars, score them against current context, name the defenders, and hand back the register with the dead-context rows ranked by recoverable value. Guaranteed 3x your Diagnostic fee in recoverable value, in 14 days. Typical 5x to 10x. We don’t audit the past. We justify each next call.

Where to go from here

If your company runs on a chart of accounts and a budget but no register, the three-column version is startable this week, and the full version is 14 days of work.

Read the guarantee Book the call

The register shows up first inside the Diagnostic. Preview the Trapped Value Report to see how the five categories and effort tiers are laid out.

Related reading:

• The first 14 days: what an operational scan covers
• The first Decision Review meeting
• The one-page decision slide every board should see
• The second Tuesday of the close: what it should actually produce