LIGHTS OUT FINANCE
Lights Out Finance · In this paper: Agentic AI meets the ERP

The system of record learns to act

Thirty years of ERP taught the enterprise to remember. Clean core, stable APIs, and policy-as-configuration are quietly turning it into something else: a platform agents can operate. The verb is changing from record to act.

AB
Adil Bahir
Founder & Editor, Lights Out Finance · Two decades in finance transformation, quantitative finance, and enterprise AI
Interactive white paper · July 2026 · lightsoutfinance.net · 9-min read · Print / PDF
In the thesisLayer 4: the systems of record agents can safely operate.
In brief
The ERP’s verb is changing. Era one recorded, era two routed workflow; era three lets governed agents act on the ledger — goals and guardrails instead of pre-scripted paths.
Clean core is not a maintenance argument. Stable APIs, standard processes, and policy held as configuration are the preconditions for agents that can be trusted to touch the books.
Three operating surfaces — master data, transactions, period processes — and one sequencing rule: build the agent capability inside the migration, not after it.

Every enterprise system has a verb hiding in its name. The ERP’s verb, for thirty years, has been remember. It remembers what was bought, sold, paid, owed, and owned, with a discipline no human ledger ever matched. What it has never done is act. Every posting it makes was decided somewhere else — by a person, or by a rule a person wrote years ago and has been afraid to touch since. The next decade of enterprise systems is about changing the verb.

This is not a product announcement dressed as a thesis. It is an architectural observation. Having spent twenty years inside these platforms — from functional consultant on the module floor to running $100M-class transformation programs — I can locate precisely where every one of those programs stopped: at the boundary between recording what happened and deciding what happens next. That boundary is now moving, and most transformation roadmaps have not noticed.

Three eras, one verb change

The first era built the system of record: one ledger, one chart of accounts, one version of the truth, at the price of rigidity that became legendary. The second era — the one most large enterprises are still paying for — built the system of workflow: approvals routed, three-way matches automated, close checklists orchestrated. Real progress, and a ceiling. A workflow is a decision made in advance: every path an analyst could take, pre-scripted by someone who could not foresee every case. The cases the script did not foresee fall out the bottom — and land on a human queue. That queue is the modern back office.

Exhibit 1
The verb changes: record → route → act
System of record Humans decide · ERP remembers 1990s–2000s System of workflow Humans decide · ERP routes Pre-scripted paths, hard-coded rules 2000s–2020s System of action Agents operate · humans govern Goals + guardrails, not scripts Evidence as a by-product Now
Workflow automated the paths someone could script in advance. Agency handles the cases the script never anticipated — under policy, with evidence.

The third era replaces scripts with goals. An autonomous system is given an objective (“this account reconciles daily”), a policy envelope (materiality thresholds, segregation rules, escalation rights), and the tools to act — and it works the queue the way a good analyst would: investigating, resolving, documenting, and escalating only what genuinely requires judgment. The difference from workflow is not intelligence for its own sake. It is that the long tail of exceptions, which workflow structurally cannot reach, is exactly where the remaining cost and risk live.

Workflow automates the cases you predicted. The entire remaining cost of the back office lives in the cases you didn’t.

Clean core is an agent-readiness strategy

Here is the reframe that changes how a CIO should defend the modernization budget. “Clean core” — keep the ERP standard, push custom logic to the extension layer, expose everything through stable APIs and events — has been sold for a decade as a maintenance argument: cheaper upgrades, faster patches. True, and underwhelming, which is why the business kept deprioritizing it.

The real argument is different: a clean core is the precondition for agents that can be trusted to touch the ledger. An agent operating against documented, versioned APIs inherits the platform’s own controls — authorizations, validations, document flow — on every action. An agent operating against thirty years of undocumented customization inherits the archaeology. Every Z-transaction, every user exit doing silent magic, every rule that lives only in one analyst’s muscle memory is a place where an autonomous system will do confidently the wrong thing. The enterprises that treated core hygiene as deferrable are discovering it was the toll gate to the entire autonomous era.

The same logic settles the perennial “where should logic live” debate. Business logic that expresses policy — thresholds, approval rights, accounting treatments — belongs in configuration and policy engines where it is legible, versioned, and testable. Agents then execute against policy rather than embedding it. When the policy changes, you change a document, not a fleet of prompts.

The three surfaces where agents earn their keep

Master data is the unglamorous first surface and the highest-yield one. Duplicate vendors, stale customer credit terms, materials with impossible attributes — every downstream automation failure is usually an upstream data defect wearing a disguise. Agents that continuously patrol, propose, and (within policy) apply master-data corrections raise the ceiling for everything else. This is why serious operating-model work sequences a governed data foundation before autonomy — not as a purist principle but because the economics compound in that order.

Transactions are the second surface: the unmatched invoice, the failed intercompany posting, the payment that bounced on a formatting rule. Today each of these spawns a ticket, a queue, and a person. The autonomous pattern resolves the routine tail — re-derive, re-match, re-post, document — and presents the residual to a human with the investigation already done. The measurable shift is from headcount-per-volume to exceptions-per-thousand, a metric that finally puts operations and finance on the same page.

Period processes — accruals, allocations, revaluations, the close itself — are the third surface, and the one covered at length in The Continuous Close. The point that belongs here: period processes are where the ERP’s system-of-record discipline and the agent’s system-of-action capability meet. The ledger stays authoritative; the agent operates the machinery around it. Nobody serious is proposing agents that improvise accounting entries outside the platform’s control framework — the entire design is agents inside it.

Exhibit 2 · Interactive
The exception-tail explorer
Workflow coverage decides how many cases fall out of the scripts; machine absorption decides how many of those still need a person. The residual is your back office.
Exceptions falling out of workflow / day
Reaching a human / day
Analyst seats implied
Human touches per 1,000 transactions
Analyst capacity assumed at 60 investigated items per day. Note the asymmetry: moving workflow coverage from 92% to 96% halves the tail; moving machine absorption from 0% to 80% removes four-fifths of what remains. The two levers compound — which is the argument for building them together.

Measuring the debt before it measures you

Clean core stalls in most enterprises for a governance reason, not a technical one: the debt has never been given a number, and what has no number loses every budget argument. The meter above is deliberately built from three figures any architecture team can produce this week — count of custom objects, share with living documentation and a named owner, share of core functions reachable through stable APIs. Run it honestly and two findings follow within the hour. First, the readiness score is lower than the roadmap assumed, which reprices the “agents next year” conversation. Second — the productive shock — the remediation number is smaller than folklore suggested, because for a sizable share of any custom estate — in my experience often approaching a third — the correct disposition is not documentation but decommissioning: code whose business owner left years ago and whose function the standard platform absorbed two releases back. The debt meter’s real product is that triage list.

Exhibit 3 · Interactive
The clean-core debt meter
Agent-readiness, quantified from the three numbers every architecture team already tracks and every steering committee ignores.
Agent-readiness score
Undocumented custom objects
Remediation effort (person-months)
Surfaces safe for autonomy today
Readiness weights API coverage 40%, documentation 30%, estate size 30% (scaled against a 6,000-object reference). Remediation assumes ~0.15 person-months per undocumented object to document-or-decommission — and decommission is the right answer more often than anyone admits — in my delivery experience, a substantial share of any mature custom estate no longer has a traceable business owner.

What “agent-ready” should mean in your next RFP

Every enterprise-software vendor will spend the next several years attaching the word “autonomous” to whatever it already sold. Procurement needs a sharper test than the demo, and the architecture of this paper supplies one, in four questions. Can an external agent act through your APIs with the same validations and authorizations as your own UI? (If the API path skips controls, it is a liability, not a feature.) Is every action attributable to a named principal with scoped entitlements? Can policy — thresholds, approval rights, treatments — be expressed as versioned configuration an agent reads, rather than logic buried in code? Does every state change emit an event a control plane can subscribe to? Four yeses and the platform is a surface agents can safely operate. Fewer, and you are buying the archaeology this paper opened with — freshly repainted.

The migration wedge

The standard objection: “we’ll look at agents after the S/4 migration.” This has the sequence backwards, and expensively so. Migration programs spend fortunes on data cleansing, reconciliation between old and new, test evidence, and cutover verification — work that is repetitive, rule-governed, evidence-hungry, and therefore the single best training ground for autonomous operations you will ever get. Teams that build the agent capability inside the migration inherit, on day one after go-live, both a clean core and a proven autonomous workforce. Teams that defer it pay for the migration twice: once in consulting hours, and again later to automate the operation they just rebuilt by hand.

The honest first step, as always, is not a tool selection. It is knowing — process by process, not on average — where your operation actually sits between scripted workflow and governed agency. That is what the Index below measures.

What leaders should do
Put a number on the core debt this month.

Custom-object count, documentation share, API coverage — three figures the architecture team already has; the debt meter turns them into a readiness score and a triage list.

Make agent-readiness a gating criterion in every platform RFP.

Four questions: controlled API parity, named principals, policy as configuration, events on every state change. Fewer than four yeses is repainted archaeology.

Build the agent capability inside the migration.

Data cleansing, reconciliation, and cutover evidence are the best training ground for agents you will ever get — and they are already in the migration budget.

Where does your operation sit?

The Lights Out Maturity Index: six questions, two minutes, no scales to interpret. Your anonymous result joins the inaugural Lights Out Finance Survey — the benchmark this publication reports on.

Take the Autonomy Readiness CheckTake the Maturity Index Browse all papers
Notes & references
Interactive models in this paper are the author’s analysis. Default values are illustrative; every input is exposed so you can calibrate with your own figures.
About the author
AB
Adil Bahir

Founder & Editor of Lights Out Finance. Big 4 partner in CFO Advisory & Finance Transformation with two decades across the Americas, EMEA, and APAC; DEng in AI (George Washington), MBA in Finance (Cornell), Master in Financial Engineering (Queen’s Smith); US CPA, CGMA, FRM, CQF, CTP, CDAA. Full profile →

Related papers