LIGHTS OUT FINANCE
Lights Out Finance · The Thesis

Finance, run by AI. Governed by design.

Lights Out Finance is the end state in which agents run the routine of finance end to end — closing, reconciling, paying, screening, reporting — under policies and controls that management defines and can evidence, routing only exceptions to people, and running through month-end, quarter-end, and Day-1 events. The distinction matters: copilots assist tasks; agents run processes. Costs stop scaling with volume, the close compresses, and audits draw on evidence produced as the work happens. This page is the framework. The papers are the argument, domain by domain.

The Definition

Why “lights out”

Manufacturing coined the term half a century ago: a lights-out factory runs so autonomously it needs no lighting — machines do the production; humans design the system, govern it, and handle what it escalates. Finance is the last major enterprise function still run as a manual production line: people keying, matching, chasing, reconciling, and assembling evidence about work they just did. The thesis of this publication is that the same transition manufacturing made is now underway in finance — and that it is primarily an operating-model problem, not a technology one.

In formal terms: a governed autonomous system — but that is architecture language, and this is an operating-model argument. “Lights out” describes the operating model, never the workforce. The functions that get this right end up with fewer, more senior people doing more consequential work — and with controls that are demonstrably stronger than the manual world’s, because evidence is generated by construction rather than reconstructed on request.

What it is not
Not RPA rebranded. Robots replay scripts on predicted paths. Lights-out operations handle the unpredicted tail — the exceptions where the actual cost and risk live — under policy, with evidence.
Not headcount zero. The volume layer becomes software; the judgment layer becomes the function. Policy owners, exception judges, model stewards, and controls attestors are the roles that remain — and grow.
Not a product you buy. It is an operating model you build — in a deliberate sequence, on a data foundation, inside a control plane — using whichever platforms and models fit. This publication is vendor-independent by principle.
Not a leap of faith. Every claim on this site ships with a model you can run on your own numbers, and a maturity instrument that tells you where you actually stand.
The Enablement Stack

How autonomy is actually built: five layers

Enterprise AI enablement, in finance, is not a model choice. It is a stack — and the layers must be built in an order the economics enforce. Select a layer.

Hyper-automation

What hyper-automation actually means

The industry uses “hyper-automation” to mean more bots. This publication uses it to mean something specific and measurable: the compounding of the stack — each layer multiplying the ones beneath it until the operation crosses from automated-with-exceptions to autonomous-with-judgment.

The compounding is concrete. A governed foundation (L1) raises the ceiling on what models (L2) can reliably read. Reliable models let agents (L3) work the exception tail that workflow never reached — census screening of every transaction, investigation of every break, resolution of the routine residual. Operable systems of record (L4) let those agents act with the platform’s own controls attached. And the control plane (L5) turns every action into evidence, which flips assurance from sampling to census — which is what finally makes the autonomy expandable, because each new process inherits a proven envelope instead of a fresh risk debate.

Workflow automates the cases you predicted. Hyper-automation is the machinery for the cases you didn’t — measured in touchless rate and exceptions-per-thousand, not bots deployed.

Hence the two numbers this publication treats as the true scoreboard of hyper-automation, in every domain: the touchless rate (share of volume completing with no human contact, evidence included) and exceptions per thousand reaching a human. Bot counts, license counts, and “automation initiatives launched” measure activity. These two measure the operating model.

The Path

Five stages — measured per process, never on average

Every finance function sits somewhere on this path — and almost never uniformly: a treasury can be intelligent on forecasting and manual on payments in the same building. That is why the assessment instruments measure process by process. Select a stage. The organizational half of the path — the roles, the broken ladder, the redesign sequence — is argued in full in The Last Org Chart.

The Method

And one delivery sequence

1

DIAGNOSE

Locate every candidate process on two axes — operating maturity and data condition — honestly, process by process. The intersection picks the wedge.

2

DESIGN

Target operating model first: roles, policy envelopes, exception rights, control plane. Before the first agent ships — or the org chart quietly rebuilds the old model inside your automation.

3

DELIVER

A 90-day wedge, end-to-end: one process taken to the target state with a hard before/after baseline. Then repetition, not persuasion.

4

EMBED

Run until the new roles — not the old habits — are what the function defends. Metrics move to touchless rate, exceptions per thousand, cost per outcome.

Now read the argument — or take the measurement

The papers page maps everything published here by theme — start with the topics closest to your remit. The flagship paper shows the full stack run end-to-end against a single asset class. And the Maturity Index tells you, in six questions, where your own operation sits on the path above.

Browse the papersRead the flagship paperAssess where you stand