Automating Month-End Close Across Multiple Entities

The short answer

Multi-entity close automation works by putting a system between your ledgers and your reporting pack: it pulls each entity's trial balance on a schedule, matches intercompany balances automatically, applies eliminations and allocations as versioned rules rather than as monthly spreadsheet work, and escalates only the exceptions to a human. The ERP stays. What changes is that the assembly work stops being manual, and every figure in the pack stays traceable to its source entry.

The delay is in the handoffs, not the ledger

Ask a controller where the close time goes and you will rarely hear “posting entries”. You will hear waiting for entity three, chasing a difference of four hundred dollars between two intercompany accounts, rebuilding the elimination tab because someone inserted a row, and re-cutting the pack because the CEO wants margin by location and the file only has it by legal entity.

Those are integration problems dressed up as accounting problems. Each one is a place where data leaves a system, gets handled, and goes back in. Every handoff adds delay, adds a second version of the truth, and adds a person whose absence stops the close.

A close-automation system targets the handoffs specifically. It does not post your journals for you and it does not replace judgment. It removes the carrying.

The four layers worth automating

Collection

Each entity's trial balance arrives on a schedule instead of on request — pulled through the accounting system's API, or from an exported file dropped in a watched location for entities on systems that do not expose one. The moment collection is scheduled rather than requested, the slowest entity stops setting the pace for everyone.

Intercompany matching

Balances between entities are matched automatically on amount, date window and reference, with tolerance rules you set. What matches, closes silently. What does not becomes a named exception with both sides of the entry attached, routed to whoever owns it. The work shrinks from reconciling everything to resolving what genuinely disagrees.

Eliminations, allocations and FX

These are rules, not monthly labour. Written once, versioned, applied identically every period, with the version used for each close recorded. Treating them as rules is what makes a restatement explainable six months later — you can show exactly which logic produced the number.

Reporting assembly

The pack composes itself from the consolidated result. Entity, location, department and division are dimensions on the same data rather than four different spreadsheets. When the CEO asks for a cut that was not in the pack, the answer takes a minute rather than a re-cut.

What it looks like running

The design discipline is the same one behind every production system DBAI ships:

Parallel running is not optional and it is not a formality. A close system earns trust by producing the same numbers your team produced by hand, for at least one period, with the differences reconciled item by item. Anyone who offers to skip that step is selling you a demo.

Where the model actually belongs

Language models are poor at arithmetic and excellent at explanation, so they sit at the edges of the close rather than inside it. Matching, netting and consolidation are deterministic code — they must produce the same answer every time, and be provable. The model does three other jobs well:

It reads unstructured inputs, so an intercompany invoice as a PDF becomes structured data rather than a manual keying job. It drafts variance commentary against the actual movement, so the controller edits a first draft instead of writing from a blank page. And it answers questions about the closed period in plain language, grounded in the consolidated data — which is exactly the pattern behind the knowledge systems we build, where answers cite your business rather than the open internet.

Anything the model produces is labelled as model-produced and reviewed before it reaches a board pack. Deterministic where it must be, generative where it helps, and never the other way round.

The trade-offs, stated plainly

This is a data-quality project wearing a close-automation badge. If your chart of accounts differs across entities and no one owns the mapping, that gets fixed first, and it is the least enjoyable part of the work. Budget for it.

The second cost is discipline. Automated eliminations only stay correct if someone owns the rules when the business changes — a new entity, a new intercompany arrangement, a restructure. The system does not remove the need for a controller. It changes what the controller spends the month doing.

The third is sequencing. Automating a close before the underlying process is agreed just makes a contested process faster. Where two people disagree about how something should be treated, the system will force that argument into the open. That is a feature, but it lands in week two, not week ten.

What to do before you engage anyone

Time your last three closes by step, not in total. Count the handoffs — every point where a number leaves a system, gets touched, and goes back. List the reports that get rebuilt every month rather than refreshed. Write down which steps stop entirely when one named person is on holiday.

That list is the actual scope of the project. It also tells you, before you spend anything, whether the problem is worth solving: if the total is four days, buy your controller better coffee. If it is eleven, and three of those days are one person moving files between systems, you have a system to build.