Prompt-Built vs. Purpose-Built: The Execution Model a Close Actually Requires

Most finance organizations now have at least one person who can wire a frontier model to a GL extract and get a defensible reconciliation out the other side. In the teams we work with, that person is increasingly the controller rather than someone from data engineering. Treat that capability as table stakes. It is not what this piece is about.

‍

The useful question is narrower and structural. A close is a few hundred tasks arranged in a dependency graph, executed against state that arrives late, out of order, and occasionally wrong, under control invariants that have to hold at every node: who prepared this, against which source records, who approved it, and can any figure be traced back without being re-derived. Model quality determines how well each node executes. It determines almost nothing about the graph.

‍

That distinction is worth stating plainly because it predicts the empirical pattern. The organizations with the strongest access to frontier models, including the labs themselves, have not moved their own close onto a chat interface. They run conventional ERPs and they are hiring accountants, not replacing them. That is not a statement about model quality. It is a statement about which layer the models operate on.

The execution surface

Over the past year we have gone through roughly fifty close walkthroughs with controllers, CAOs and finance leads, asking them to describe the previous month rather than describe their pain. The numbers are worth reading as a profile of where hours accumulate:

‍

• A payments business reconciling roughly three hundred bank accounts against millions of daily transactions described bank reconciliation as a twenty day process. Twenty days of work per cycle, not twenty days of the month.
• A listed manufacturer runs a six hundred to seven hundred line accrual process, then spends about two days per period on flux.
• An ecommerce controller was closing April on the twenty-first of May.
• A lender's controller described recurring journals that are byte-identical month over month except the posting date, at fifteen to twenty minutes each.
• A consulting group closing across ten regional teams described its template situation as ten people, ten approaches.

‍

Sort those by what they actually demand and almost none of it is reasoning-bound. It decomposes into three categories: data acquisition and normalization from systems that were never designed to hand data to each other, orchestration across tasks with real dependencies between them, and evidence assembly. Across the enterprise teams we work with, that envelope is 70 to 80 percent of the cycle.

‍

It is also the part that close platforms have historically declined to touch, which is a design choice rather than an oversight. Checklist and workflow systems model the graph and track its state. They do not execute the nodes.

Human latency sits on the critical path

The most consistent finding was not computational. It was that the binding constraint on close duration is usually a person who has not responded yet.

‍

One energy manufacturer walked us through its PO accrual flow: requesters receive a link, decide line by line, and if a requester does not respond the accrual is approved by default. That default is a control designed around an empirical fact about response rates. A lender's FP&A team locates non-recurring accruals by emailing colleagues and waiting. A subscription food business described its accrual process as inbox-based. A staffing group reconciles intercompany across dozens of entities by matching on invoice number in pivot tables.

‍

This matters for the build-versus-buy question more than any capability comparison, because chase-and-wait is the one category of close work that no amount of inference removes. You cannot prompt your way to a reply from a procurement manager in another time zone. You can only own the follow-up loop, with escalation and a default path, as a durable process rather than as something a person remembers to do on day two.

The orchestration layer is you

The execution model of a chat interface is a single node with a human scheduler.

‍

You extract. You load. You prompt. You evaluate the output. You decide whether it is right. You carry the result forward. You prompt the next step. You handle the response that came back shaped differently than the last one. The model performs the transformation at each node; you perform every edge in the graph.

‍

For a single analysis this is efficient and often optimal. For a close it does not compose, because the edges are the dominant cost. An interface that requires a human at every edge has not touched the 70 to 80 percent. It has reduced per-node latency while leaving the orchestration, the retries and the state tracking exactly where they were, which is on a person during the narrowest window of the month.

‍

Purpose-built execution inverts the scheduler. Within a single close task, specialized agents hold the edges: one resolves trigger events and open POs against the ERP, one owns the follow-up loop with the owners who have not replied, one computes against logic the controllers have already approved, one assembles the entry and stages its supporting evidence. The handoffs are the product. What surfaces to a reviewer is a prepared work product with its lineage attached, and the remaining decision is the judgment call that required a qualified human in the first place.

What in-house builds converge on

The most useful evidence here does not come from vendors. It comes from teams that are technically capable, built it, and derived the requirements the hard way. Several of them reached conclusions worth borrowing whether or not you ever buy anything.

‍

A staffing group built its own accrual engine for timesheet expenses, runs Claude, Gemini and the OpenAI API against its own keys, and holds ISO 42001 for AI management. Their conclusion was precise and correct: human-in-the-loop has to be structurally enforced rather than procedurally promised, because a certification auditor will ask you to evidence it, not describe it. That is a sharper articulation of the control requirement than most vendors manage.

‍

An outsourced accounting firm scoped building agents directly on Claude for client work and identified the three durable costs before committing: ownership of maintenance as ERP APIs and model versions move underneath you, consistency guarantees across clients and periods, and extraction of an audit trail that was not designed in from the start. Their read was that auditors will eventually ask for proof the agents operated inside controls, and that proof is extremely expensive to retrofit. They chose not to build. The analysis stands on its own regardless of the decision.

‍

A medtech controller with more than a hundred entities runs close automation built entirely in-house by the accounting team, with no third-party close platform, and it works. A broadcaster prototyped on Power Apps and Power Automate and found the ongoing engineering load higher than the initial build suggested, which is the normal shape of this cost curve.

‍

The pattern across all of them is encouraging rather than cautionary. The reasoning layer is genuinely solved, and these teams proved it quickly, which is exactly what a good prototype is for. What the exercise surfaces is that the durable engineering sits in orchestration, state management and evidence, and that those are the components with real operating cost attached. Whether you then build or buy that layer is a legitimate engineering decision with defensible answers on both sides. It is just a different decision than the one people think they are making when they start.

Partitioning the deterministic from the probabilistic

The sharpest question we get from technical buyers is some version of: which parts of this are the model, and which parts are rules?

‍

It is the right question, and the honest answer is that both are present and the boundary between them is the design.

‍

One class of close work is irreducibly probabilistic. Whether a bank narration corresponds to a given AP invoice, which of forty variances carries signal, what the likely driver behind a movement is. Frontier models outperform the rules engines that preceded them here by a wide margin, and this is where the capability gain is real.

‍

The other class is arithmetic with a single correct answer. Whether the subledger ties to the control account. Whether the schedule foots. Whether the accrual reverses correctly. These operations need to be deterministic and idempotent: re-running a period must reproduce the prior result exactly, or you cannot replay, you cannot backfill, and you cannot answer an auditor who asks why the number moved.

‍

A generative system is non-deterministic by construction. That property is desirable nearly everywhere else and disqualifying here. So the calculation layer runs first and deterministically, the model operates on its structured output rather than on raw source data, and the boundary is explicit enough that a reviewer can tell which side any given figure came from. A medtech controller asked the same question from the other direction: is the commentary computed or generated? He wanted confirmation that metrics are calculated first and narrative is derived from them, rather than a model producing a plausible explanation unconstrained by the arithmetic. Another finance lead told us their existing copilot produced exactly that unconstrained output, which is why it had changed nothing.

Control properties are system properties

The controls a close requires are not behaviors you can prompt for. They are invariants that have to be enforced by the system that holds the state.

‍

Provenance. Not a saved transcript. An append-only record bound to each entry, capturing which source records produced it, under which policy version, and when. A finance systems lead relayed her auditor's position on agentic AI almost verbatim: genuinely exciting, and it has to be documented appropriately. A broker-dealer running a formal RFP specified, as a floor, the ability to mark an item manually reconciled and bind the underlying statement to it as proof.

‍

Segregation of duties. This is an access control property, not a procedural one. Preparer and approver must be structurally incapable of being the same principal. In a chat session they are the same principal by construction.

‍

Approval as a gate, not a record. Tracking approvals in email tells you one occurred somewhere. It does not prevent unapproved state from advancing, which is the only property that matters under test.

‍

Lineage without re-derivation. A reviewer must be able to traverse from any figure to the transactions underneath it. Generating a supporting schedule is easy. Making every number in it addressable is a separate engineering problem, and if it is unsolved the cost lands on a person reconstructing workpapers.

‍

Policy stability across periods. Prompt libraries drift. Model versions move. The person who encoded the tacit knowledge changes teams. One instrument maker told us they have no documented processes, several twenty year tenures, and had just lost their second employee. Another flagged turnover concentrated in precisely the regional layer that executes its close. Two quarters later nobody can explain why Q1 was treated differently from Q3, which is the question that actually gets asked.

‍

None of these are capabilities that arrive with a better model, because none of them are model properties. Three years of substantial capability gains have moved none of them.

‍

Coordination layer, execution layer

One structural observation, because it reframes build-versus-buy.

‍

Most teams we spoke to already own a close platform. Very few described it as executing anything.

‍

A subscription ecommerce controller described her tooling as workflow management with no automation beyond task state, with every reconciliation and schedule still prepared by hand. A finance systems lead at a food business described a reconciliation platform that operated only at GL level, could not reach subledger data, and whose promised ERP connector never shipped, leaving the team exporting and re-uploading spreadsheets. A brewing group reported intercompany reconciliation still running on manual effort with the platform in place. An industrial distributor, after a competitor demo, said plainly that they were more interested in an execution layer than in workflow management.

‍

That is not a defect. Coordination systems coordinate, and the good ones are good at it. But if the checklist emits "prepare the accrual workings," something still has to prepare the accrual workings, and today that something is usually a person with a spreadsheet. Whether it could instead be a chat window is the question this whole piece is about, and it resolves to the properties above: edges, determinism, lineage and policy stability.

‍

Where general-purpose inference is the right tool

The conclusion is not to stop using these systems. The boundary is just drawable with some precision.

‍

General-purpose models are the correct tool for researching a technical treatment before committing to it, drafting a memo or policy note, interrogating an unfamiliar calculation, and exploring a dataset before the question is well formed. They are also the fastest way to develop institutional judgment about what this technology does and does not do, and teams that have built something themselves evaluate close software far more rigorously than teams that have not.

‍

The line is operational: if the output enters the books or is presented to an auditor, it requires an execution layer with enforced controls. If it does not, use whatever is fastest.

‍

Three execution models

Most finance functions are running one of three.

‍

Manual. State lives in spreadsheets and email. Throughput is bounded by how long people will stay awake.

‍

Assisted. Per-node latency drops through copilots and chat. Real gains, but they accrue to individuals rather than to the process, they leave with the individual, and a human still holds every edge. The graph is unchanged.

‍

Executed. Agents hold the edges and run the work on a schedule without being invoked, handing results forward until the task closes. Every output arrives as a draft with its lineage, and a named preparer and approver clear it before state advances.

‍

What the third model does not remove is the judgment. It removes the 70 to 80 percent, which is where the hours sit and where no qualified person's expertise is being used.

‍

Nine questions before you scale a prototype

If you built something at a workshop, or your team keeps sending you impressive demos, these are worth asking before it touches a live close. Most of them came from finance leaders, not from us:

‍

1. Where does the data come from, and who maintains that connection when the API changes?

2. Who owns the handoffs between steps, the system or a person?

3. Is your source data clean enough for any of this to be reliable, and who finds out when it is not?

4. If you ask the same question twice, do you get the same number twice?

5. Where is the AI actually doing work, as opposed to applying deterministic rules?

6. Can a reviewer trace any figure to the underlying transaction without re-deriving it?

7. Can the preparer also approve? If yes, you do not have segregation of duties.

8. What happens to your output when the model version changes underneath you?

9. When the person who built this changes roles, who owns it?

‍

A prototype that fails several of these is not a failure. It is a well-scoped requirements document for what you actually need to buy or build properly.

‍

This is the layer we build at consarc. We changed one letter of our name for the reason above: an ark stores what is already there, an arc closes. Noa agents execute close work across accruals, prepaids, variance analysis, leases, borrowings, revenue validation and intercompany, over a data fabric that connects and normalizes ERP and subledger sources, with policy, approvals and an append-only audit trail enforced by the system rather than by discipline. Noa agents hold the edges within a task, so what reaches a reviewer is a prepared close with its lineage attached rather than an empty schedule. Journals are prepared with full coding and evidence, routed for review and approval, then exported ERP-ready for import. Today that runs at a global marketing and communications group with revenues around $17 billion closing across more than 150 countries, at a listed engineering and technology services group, at a global chemicals manufacturer, and at a fast-scaling multi-site skincare brand. That range is the point: the handoffs, the evidence and the controls are the same problem at both ends. The outputs hold up under Big 4 review. It was built by professional accountants who code, which is mostly a way of saying the people who specified it have closed books and remember what it cost.

‍

Keep the chat window. Just do not ask it to sign.

‍