Summary 

A multi-agent system for the accounting close is a group of AI agents, each responsible for one part of a period end, coordinated so they finish the close together. In most published descriptions, one agent handles accounts payable, another accounts receivable, another reconciliation, another reporting, and an orchestrator directs them.

That design fails more often than it works for a structural reason. Reading parallelises well, because two agents reading the same ledger do not interfere with each other. Writing does not parallelise. The close is almost entirely writing: posting entries, clearing open items, applying cash, booking accruals. Agents writing at the same time make conflicting decisions that cost more to unwind than they saved, and that a reviewer cannot follow after the fact.

The reliable design runs a fixed sequence your team controls, with agents contained inside individual steps and a person authorising every posting. If you run an accounting firm rather than a single set of books, one further constraint applies. You close many clients at once, which makes isolation between engagements a harder requirement than coordination between agents.

What a Multi-Agent System for the Accounting Close Means

Five terms make the architecture easier to evaluate.

The important distinction sits underneath all five terms: who determines the path through the close?

In one architecture, the workflow determines the path. Your team defines the sequence in advance, and specialized agents are called at specific points. A reconciliation agent may investigate an unmatched balance, an evidence agent may retrieve support, and a narrative agent may draft commentary, but the order in which those capabilities are invoked is controlled by code and workflow rules.

In the second architecture, the orchestrator determines the path dynamically. It evaluates the current state, decides which agent should act next, may call several tools or agents, and chooses when the task is ready to move forward. The route through the close can therefore differ from one run to another.

Both architectures can legitimately be called multi-agent systems. They do not create the same operating risk.

A workflow-controlled system usually offers greater repeatability because the sequence, authority boundaries, and escalation points are defined before execution. A dynamically orchestrated system can handle less predictable situations, but every additional runtime decision creates another place where the firm must define what the system may decide, what evidence it must preserve, and when it must stop for a person.

That does not make dynamic orchestration inherently unsuitable for the close. It means it should be used where variability actually requires it.

There is little benefit in asking an AI orchestrator to decide how to calculate a depreciation schedule, apply a materiality threshold, verify that debits equal credits, or determine which period a fixed date belongs to. Those are deterministic problems. Runtime reasoning becomes more useful around ambiguous exceptions: deciding which evidence may explain an unmatched transaction, determining which specialist workflow should investigate a break, or assembling the information a reviewer needs.

This creates a useful purchasing rule: Keep the predictable parts of the close deterministic. Introduce agent autonomy only where the workflow genuinely cannot be specified in advance.

That rule also changes how a COO should evaluate a multi-agent vendor. A diagram showing six specialist agents around a central orchestrator tells you almost nothing about the actual level of autonomy.

The more useful questions are:

• Which decisions are fixed in workflow logic, and which are made by the orchestrator at runtime?
• Can the orchestrator change the sequence of close activities?
• Which agents can write back to the ERP or general ledger?
• What context and evidence must travel with every handoff?
• What conditions stop an agent and route the item to a person?
• Can the firm reconstruct why a particular path was taken after the close?
• Which calculations and controls remain deterministic regardless of what the agents decide?

The objective is to place it inside explicit authority boundaries.

Therefore, for the accounting close, the safest multi-agent architecture is the one where deterministic rules control what should never vary, agents handle the work that actually requires interpretation, and the orchestrator cannot silently expand its own authority between the two.

You Close Many Books, Not One

Almost everything published on this subject assumes a single company closing its own accounts However, the truth is that an accounting firm has a different problem, and the difference changes the architecture.

A client advisory practice runs dozens of closes inside the same window. The concurrency sits across engagements, which means the pressure lands on isolation instead of coordination. One client's transactions, vendor names, and adjustments must never reach the context of another client's work. Shared agent memory across a client base is a data leak, and under IRC section 7216 the exposure for a firm handling tax data is criminal rather than commercial.

Client-level variation compounds this. Chart of accounts, materiality thresholds, accrual conventions and approval limits change from one engagement to the next. An agent that generalises across your client base produces mistakes at the speed of the whole book of business, and it produces them consistently enough to look correct.

Then there is the boundary that firm-side work introduces and corporate close software does not model. Your firm prepares. Your client approves. The authorisation step sits outside your systems, inside a relationship, and often inside an email thread. Any architecture that treats posting as the natural end of the pipeline has skipped the part where your engagement letter says the client owns the numbers.

Read: How to Automate Month-End Close, How to Automate Bank Reconciliation

If you have already automated intake, reconciliation and month-end preparation as separate pieces of work, this article covers what happens when you connect them.

Why AI Agent Orchestration Breaks at the Close

The failure is predictable, and the engineering literature explains it well enough to plan around.

Reading parallelises, writing does not

Several agents can search, extract, and summarise simultaneously with little trouble because reads do not collide. Two agents can both read a bank statement, and nothing breaks. Writes behave differently. Every action an agent takes carries decisions it made implicitly. When two agents act at once on related records, those decisions conflict in ways that are difficult to reconcile afterwards. Engineers at LangChain and Cognition have both described this asymmetry from production experience, and Anthropic's published guidance recommends multi-agent designs mainly for search and retrieval work.

Now look at what a close consists of: 

• Posting journal entries
• Clearing open items
• Applying cash against invoices
• Booking and reversing accruals
• Adjusting balances. 

These are writes from beginning to end. The workflow that vendors most often illustrate with parallel specialist agents is the workflow least suited to them.

The failures come from design, not from the model

A team at UC Berkeley studied why these systems fail and published the first empirical taxonomy of it, presented at NeurIPS in 2025. They annotated execution traces across seven multi-agent frameworks and identified 14 distinct failure modes, grouped into three categories: system design issues, misalignment between agents, and inadequate verification of the result.

Their headline conclusion deserves attention from anyone comparing suppliers. The failures they catalogued came from how the systems were designed rather than from the quality of the underlying models. Upgrading the model does not fix an architecture that loses context at handoffs.

Several of their modes translate directly into close work. An agent repeats a step it already completed, so a reconciling item gets cleared twice. An agent fails to recognise that its task is finished and continues working. Two agents act on the same open item from different assumptions, and neither knows the other exists.

The cost line that scales with your client list

Anthropic's engineering team reported that multi-agent systems consume roughly 15 times the tokens of a chat interaction, with single agents at around four times. They also found that token usage alone explained about 80% of the performance variation in one of their internal evaluations, which is a blunt finding: much of what looks like clever coordination is spending.

For a corporate finance team closing one entity, that cost is absorbable. For a firm closing fifty clients every month, inference cost becomes a line item that grows with your client list rather than with your revenue per client. Ask any supplier to model this at your actual volume before you sign anything.

An honest note on the strongest argument against multi-agent design

The clearest published case against these architectures came from Cognition in June 2025, in a post titled "Don't Build Multi-Agents". Two principles carried it: share full agent traces and avoid splitting decision-making in ways that let agents conflict.

Their author revised that position publicly in April 2026, saying the team had since found multi-agent setups that work. We think both statements are useful and we cite them together. The principles remain sound as design constraints. The revision tells you that the field is moving, and that anyone quoting the 2025 position as settled has stopped reading.

What the Benchmarks Show About Multi-Agent Orchestration

Four main orchestration patterns appear in production systems:

A 2026 preprint by Kulkarni and Kulkarni benchmarked these four patterns across five models on a corpus of SEC filings. Self-correcting designs scored highest on extraction accuracy at roughly 2.3 times the cost of a sequential baseline, hierarchical designs sat closest to the best available balance of cost and accuracy, and hybrid configurations recovered most of the accuracy advantage at a small premium. We would treat the shape of that tradeoff as informative and the precise figures as provisional, since the paper carries no institutional affiliation and the authors released no code.

Set against that, a separate 2026 study found single agents matching or beating multi-agent systems on multi-step reasoning when both were given the same reasoning budget. Adding agents is not the same as adding capability.

How to Build The Architecture for the Accounting Close That Holds

Five commitments describe the design we would build and the design we would look for in someone else's proposal.

1. Keep the sequence deterministic 

The order of a close is code your team controls, not a decision a model makes at runtime. A 2026 study comparing deterministic against model-controlled orchestration found that deterministic control improved worst-case correctness and reduced the variation between runs, and run-to-run variation is the property you will struggle to defend when a reviewer asks why last month's close took a different path.

2. Contain agents inside steps

Models are good at interpretation, at matching under ambiguity, and at reasoning through exceptions. Rules are good at arithmetic, dates, thresholds and posting logic. Deterministic matching clears the straightforward majority of items cheaply, and the model earns its cost on the residue that rules cannot settle. A model asked to perform arithmetic will get it right often enough to be trusted and wrong often enough to be dangerous.

3. Hold one source of truth

Every step reads and writes through a single ledger of record. This is the mechanism that stops two components acting on the same open item, and it does more for reliability than any amount of instruction in a prompt.

4. Make authorisation an explicit boundary

Define confidence bands and what happens in each: clear automatically, route for review, escalate to a person. Set the default so ambiguity goes to a human rather than the reverse. Then tighten the bands as the system earns it against your own data.

5. Isolate per engagement

Context, memory and rules scoped to one client, enforced by the structure of the system rather than by asking a model politely. This is the requirement corporate close software does not have and your firm cannot avoid.

What the Evidence Supports, and What it Does Not

Verified production data on multi-agent closed systems is thin, and we would rather say so than pad this section.

Gartner reported in its 2026 Hype Cycle that around 17% of organisations have deployed AI agents at all, against more than 60% intending to within two years, and placed agentic AI at the peak of inflated expectations. 

Also, Gartner's published figure for the close itself is a forecast for accounting firms: embedded AI in cloud ERP applications driving a 30% faster financial close by 2028. That is a prediction about 2028, and several articles now circulate it as a measured result. On current benchmarks, the strongest models answer fewer than half of realistic financial research tasks correctly, though they work considerably faster than human experts while doing it.

Most of the impressive numbers in this market come from suppliers describing their own products, without a study behind them. We have left those out.

What we can offer is our own build. Codebridge delivered a production multi-agent system for sales pipeline automation, and although the domain is sales rather than accounting, the architectural decisions match the five commitments above closely enough to be worth reading.

A central orchestration layer coordinates specialised services while maintaining one consistent view of each record, which the team built specifically to prevent data conflicts and duplicate actions. A single database holds the source of truth, with clear separation between orchestration, model logic and persistence. 

Retrieval grounding ties every generated response to verified source material rather than to the model's recall. Two models split the work by task, with one handling high-volume analysis and another handling longer reasoning. Most relevant here, the qualification logic uses a conservative confidence threshold: when intent is ambiguous, the system defers to a person instead of deciding.

The measured results were an average response time falling from around 24 hours to under two minutes, time to first meeting compressing from one or two weeks to two or three days, a 30% increase in qualified meetings, and over 500,000 personalised messages in a single month with no spam complaints or automation flags.

Those outcomes belong to sales work and we make no claim that they transfer to a client close. The architecture is what transfers: one source of truth, bounded services, grounded outputs, and ambiguity routed to a human by default.

How Codebridge Approaches This

Codebridge builds AI implementations for mid-market professional services firms, with roots in Big 4 consulting at KPMG. We work as an engineering partner, which means the sequence, the control points, and the code belong to your firm at the end of the engagement.

Our starting position on close work is the one described above. The pipeline stays deterministic, agents stay inside steps, authorisation stays with a person, and every engagement stays isolated from every other. We would rather build something narrow that your clients' auditors can follow than something broad that nobody can explain.

Engagements begin with a fixed-fee three-week discovery, in which we build a prototype on your firm's own data and show you what the workflow looks like before you commit to a build.

Book a 30-minute call to talk through which part of your close would fit a three-week prototype.