Close agents for a PE roll-up on QuickBooks and Sage: AI detects and explains, deterministic code computes every number

In two sentences

A private-equity-backed roll-up with four operating companies on QuickBooks and two on Sage now has agents working on its monthly close, consolidation, intercompany reconciliation and 13-week cash forecast, built by the consultancy Bolt Group, which says the language model is not allowed to calculate a single number. It is one of the most concrete public descriptions of how to put agents near figures that a board and a lender read, but it comes from the vendor, the client is anonymous and there are no measured results.

Who does it and why it is interesting

On 28 August 2026 Dean Sloves, founder of Bolt Group, an AI-implementation firm that embeds engineers in mid-market companies, published a long thread on X about one engagement. The client is a roll-up backed by a private-equity fund: four operating companies keep their books in QuickBooks, two in Sage, accounts payable runs in Bill.com and job costing in ServiceTitan. All six ledgers feed reporting to the board and to a lender.

Before the project, the VP of Finance closed the books by hand. Every month he exported six trial balances and stitched them together in Excel, and, in Sloves’s words, he called the result “a source of best guess, not a source of truth”. Anyone who has consolidated a group built by acquisition will recognise the problem: each company kept its own chart of accounts, its own habits for intercompany charges and its own idea of what “Repairs and Maintenance” means.

Two weeks later, Sloves described what looks like the same kind of project in a shorter post: multi-entity consolidation for a holding company that grew by acquisition, “6 general ledgers on two platforms, an AP system and more”, built on Bolt’s own harness rather than an off-the-shelf tool. The rule he says they never broke: consolidation, intercompany eliminations and the statements are computed in code that traces back to source, and “no LLM touches a total”.

Why it matters for this directory:

• It is about small-company ledgers, not an enterprise ERP. Most published finance-agent cases come from SAP, Oracle or NetSuite customers. Here the raw material is QuickBooks and Sage, the software that most acquired small businesses actually run.
• It draws a hard line between calculating and explaining. Instead of asking “how accurate is the model”, the design removes arithmetic from the model’s job altogether.
• It treats the finance owner as a test suite. The VP of Finance keeps rebuilding the package by hand and sends the differences back as bugs.

Keep the caveats in view from the start: Bolt sells this work, the thread is marketing as much as a case study, the client cannot be checked, and the only result offered is that agents “can now run” several processes and that the engagement was expanded twice.

Tools and architecture

From the thread, the system has five layers. The labels are ours; the substance is Bolt’s.

1. Sources. Six general ledgers (four QuickBooks, two Sage), the AP subledger in Bill.com and job costing in ServiceTitan. The thread does not say whether the QuickBooks companies use the Online or Desktop edition, nor which Sage product the other two run.
2. Canonical mapping. Before any agent ran, Bolt mapped the chart of accounts of all six ledgers into one canonical structure, “so an agent reasons from mapped facts instead of guessing which Repairs and Maintenance belongs to which entity”.
3. Fact store with lineage. Every fact row carries a source hash and a pull timestamp, so any figure on any screen can be walked back to the ledger row it came from, and closed periods reproduce exactly. Money is a decimal string end to end; floating-point numbers never enter the calculation path.
4. Deterministic engine. TypeScript code computes every number: the close, consolidation, intercompany eliminations, job costing and the 13-week cash forecast.
5. Agents. They “detect, flag, watch, and narrate” and never produce a total. Each agent follows one shape: pre-compute the facts, hand the model a scoped tool catalogue, validate its output against a schema, and let deterministic code decide what ships. Tools declare whether they read the general ledger or a subledger, so routing is “a contract instead of a paragraph of prompt text”. An agent is a configuration rather than code: its skills, data scope, schedule and who gets notified. Agents post in Teams, Slack, iMessage or email, and people can chat with them there.

Around it sit two feedback loops: an eval harness that grades tool routing with deterministic assertions before anything reaches production, run across model versions, and the VP of Finance, who rebuilds the package by hand and emails the variances.

Step by step to replicate the pattern

This is our translation of the design into steps a finance team and one developer could follow. It is not Bolt’s method, which is not public.

1. List every ledger and subledger and how you can read it. For QuickBooks Online, the Accounting API exposes a TrialBalance report by company and date range, with an accrual or cash basis. For other products, use whatever API or scheduled export they offer. Record for each source: entity, currency, basis, how often it is pulled and who owns it.
2. Build the canonical chart of accounts before anything else. One row per source account with: entity, source account code and name, canonical account, statement line, and whether it is intercompany (and with which counterparty). Every unmapped account must stop the run, not fall into “Other”. This table is the slow, valuable part; expect the business to argue about it.
3. Store facts, not spreadsheets. Each pulled balance or transaction becomes a row with entity, period, canonical account, amount as a decimal string or integer cents, source system, source identifier, pull timestamp and a hash of the raw record. Never edit a fact; re-pull and keep both versions.
4. Write the arithmetic as ordinary code with tests. Consolidated trial balance, intercompany eliminations, FX translation if needed, job-cost roll-ups and the 13-week forecast are functions over facts. Test them against a period the VP already closed by hand, to the cent.
5. Design a small, typed tool catalogue for agents. Each tool reads one thing and says so: gl_balances(entity, period), ap_open_items(entity, as_of), intercompany_pairs(period), mapping_exceptions(period). Tools return facts with their lineage; none returns a free-text answer.
6. Give each agent one job and one output schema. For example, an intercompany watcher returns a list of findings, each with type, entities, canonical accounts, the amounts as computed by the engine, the fact hashes it relied on, a suggested cause and a confidence label. Anything that fails schema validation is dropped and logged.
7. Let code decide what ships. A finding reaches people only if it passes deterministic checks: the amounts it quotes match the engine’s, the facts it cites exist, the difference is above a materiality threshold you set.
8. Write routing evals before going live. Short, deterministic assertions: a question about payables must call the AP tool, a P&L question must stay on the general ledger, a greeting must call no tool. Run them every time you change prompts or the model provider ships a new version.
9. Keep the human rebuild in parallel. Ask the finance owner to keep producing the package the old way for a few closes and send every difference. Turn each one into a fix and a regression test.
10. Post where the team already works. Findings go to the close channel in Teams or Slack, with links to the underlying facts, and an owner for every agent.

A minimal agent definition, in the spirit of “an agent is a configuration” (our illustration):

agent: intercompany-watcher
schedule: "daily at 07:00 during close; weekly otherwise"
data_scope: [gl_balances, intercompany_pairs, mapping_exceptions]
skills: [intercompany-rules-v3]
output_schema: finding_v2
ships_if:
  - quoted_amounts_match_engine
  - cited_fact_hashes_exist
  - abs(difference) >= 250.00
notify: ["#close-room", "vp-finance"]
owner: "group controller"

A concrete example (hypothetical numbers)

The figures below are invented to show the division of labour; they are not the client’s.

At the September close, the deterministic engine pairs intercompany balances. OpCo A (QuickBooks) shows a receivable from OpCo E (Sage) of 48,500.00; OpCo E shows a payable to OpCo A of 45,800.00. The engine computes the difference, 2,700.00, and blocks the elimination because it does not net to zero. That is pure code.

The intercompany agent then gets the two facts, their source rows and the last six months of postings between the two companies. Its finding, validated against the schema, says: the difference is divisible by nine, which is typical of a transposed entry (48,500 versus 45,800); OpCo E’s bill was keyed on 18 September with a reference that matches OpCo A’s invoice; suggested cause: data-entry error at OpCo E; confidence: medium. It quotes 2,700.00 because the engine gave it that number, not because it subtracted anything.

The gate checks that 2,700.00 matches the engine, that both fact hashes exist and that the amount is above the threshold, and posts the finding to the close channel. The OpCo E accountant opens the bill, corrects it in Sage, the next pull brings in a new fact, the engine re-pairs the balances and the elimination clears. At no point did the model change a ledger or produce a figure that went into the statements.

A second finding the same morning might flag that OpCo C books equipment repairs under cost of sales while the canonical mapping puts the same account under operating expenses for the other five companies: a mapping question for the controller, not a number for the model to fix.

Stated results

Everything here comes from Bolt Group’s founder:

• Eleven weeks into the engagement, agents “can now run the close, the 13-week cash forecast, forensic accounting, job costing, and the intercompany reconciliation”.
• The engagement “has been expanded twice”.
• The VP of Finance still rebuilds the package by hand and emails variances, such as a consolidated P&L difference, a missed bank balance or a missing accounts receivable section; each becomes a fix and a test.

What is missing: close duration before and after, hours saved, how many variances the VP has found and whether they are falling, what “run the close” means in practice (prepare, review or post?), the model used, and anything from the client. In his later post Sloves also claims to have automated “93% of JE’s for a large company” and offers a money-back guarantee; that refers to another client and is unverified. Shyan-Ming Perng’s LinkedIn post turns the thread into a seven-point checklist, but it is commentary on the same source, not independent confirmation.

Limitations and risks

• Vendor account, anonymous client. We cannot check the company, its auditors or its lender, and Bolt has a direct commercial interest.
• “Run the close” is ambiguous. The thread never says whether agents post journal entries. If they do, segregation of duties and approval limits matter more than any of the design rules.
• Deterministic does not mean correct. Code can compute the wrong elimination perfectly every month. The mapping table and the engine need review and tests like any financial model.
• Narration is still a model output. A controller of a 12-entity group wrote on r/Accounting that AI saved his team time on coding transactions, flux narratives and flagging reconciliations that did not tie, but that it once wrote “a beautiful explanation” for a variance that was just a misposting, and that he never lets it near accruals or cutoff. Explanations need the same scepticism as numbers.
• Data and access. A unified access layer to six ledgers, AP and job costing is a large attack surface; least-privilege, read-only tools and logs are not optional.
• Key-person risk moves, it does not disappear. The knowledge that lived in the VP’s spreadsheet now lives in the mapping table and the agent configuration; someone must own both.

Common mistakes

• Letting the model add up “just this once”. A model that sums a column correctly most of the time is the trap the thread describes: people stop checking.
• Starting with agents before mapping. Without a canonical chart of accounts, an agent reasoning about six ledgers is guessing.
• Floats for money. Binary floating point drifts in the cents; use decimal strings or integer minor units throughout.
• Prompt text as routing. “Use the AP data for payables questions” in a prompt is a hope; a tool that declares its scope, plus a test, is a contract.
• A model grading a model. Routing and amounts can be checked with deterministic assertions; keep model-based judging for tone, if at all.
• Switching off the manual rebuild too early. The VP’s parallel package is the cheapest, best test you have.

Conclusions

The interesting part of this case is not that agents are involved, but where the authors refuse to use them. Arithmetic, consolidation and the forecast sit in ordinary, testable code; the agents look for what is odd across six ledgers and explain it, and a deterministic gate decides what people see. For a group stitched together from QuickBooks and Sage companies, that is a pattern a finance team can adopt incrementally: mapping first, facts with lineage second, agents last.

The evidence, though, is thin: one vendor’s account of one anonymous client with no metrics. Treat it as a well-argued design document from a practitioner, check every claim against your own close, and keep the person who signs the numbers in the loop until the variances stop.