Skip to content

Work/Finance

A shorter close, with the ledger untouched

Controllers wrote variance commentary every month that read like last month’s, because it largely was. The writing ate the days they needed for review.

Group finance4 min read

Sector, size, and function are stated. The client is not.

A group finance team room during month-end close, one person updating a close calendar on the whiteboard while others work at screens showing a ledger coding queue
Nothing touches the ledger

At a glance

Sector
Finance
Structure
Multi-entity group
Function
Group finance
Reviewed
Twenty-four months of postings
Never automated
Posting, accruals without evidence, consolidated adjustments
Engagement
Constraint design, then build, priced per phase

The short version

The close calendar shortened, and held through a year end

The cycle that tests a close calendar is the one after December. It held.

Coding queries stopped bouncing between teams

Shared services and the business units used to spend days on this. The proposals arrive with their precedent attached.

The audit trail improved as a side effect

Every coding decision now carries a recorded reason, which was not true when a person did it from experience.

Why the ledger was ruled out first

The close ran long, every month. Coding queries bounced between shared services and the business units for days at a time. Commentary drafting consumed the days controllers needed for review.

Coding, matching, and commentary are pattern-heavy and evidence-based, which suits automation.

The ledger is not. Nothing touching it was automated, and that constraint was set before any design work started.

Constraints, then twenty-four months of postings

The order is deliberate and it is the whole method.

Sessions with the group controller and each entity finance lead. Materiality thresholds for commentary were agreed early, so the system explains what matters and stays quiet about the rest. Getting that line in the right place took two cycles.

Twenty-four months of postings were reviewed to learn the coding patterns. That surfaced several places where entities coded the same transaction type differently. Those got fixed before automation, not after, which added weeks no one had planned for.

Constraints were written first: no posting without approval, no accrual proposed without supporting evidence, no adjustment to consolidated results, and a full log of every proposal with its reasoning.

Data work covered chart of accounts harmonization, vendor master deduplication, and cost center mapping across entities.

Auditor briefing, held before go-live
The design was walked through with the external auditors ahead of deployment. Their position: advisory proposals with a logged rationale improve the evidence trail rather than weakening it, provided approval remains a human act and the log is retained. That position was minuted.

bearingbridge.ai project record, phase Bearing

What was built, and how often it is wrong

None of it touches the ledger.

Three components, and every one of them advisory.

Coding assistant

Proposes account and cost center with its reasoning and the precedent transactions it relied on.

Intercompany matching

Proposes resolutions for breaks instead of only flagging them.

Commentary drafter

First-pass variance explanations from ledger movement combined with operational context: volumes, exchange rates, headcount. Every explanation cites the figures behind it.

The coding assistant: a transaction line, a proposed account and cost centre with a confidence chip, a why panel listing three precedent transactions, and a permanently disabled post-to-ledger control
The disabled control is the design, not an oversight. Posting to the ledger is not available, by construction rather than by policy.

Controllers edit and own the final text. Their name is on it, which is the point.

The coding assistant is wrong often enough to matter, mostly on transactions with no close precedent. Rejections are reviewed quarterly, because a pattern in them usually means a rule needs writing.

Where it stands after a few months

The close calendar shortened. Commentary drafting and coding queries both fell against the baseline measured over the two cycles before the build.

The audit trail improved as a side effect. Every coding decision now carries a recorded reason, which was not true when a person did it from experience.

Months later the close calendar had held its new length through a year end, the cycle that tests it.

Three things that made it work

Constraints were written before the design

The boundary was a starting condition rather than a compromise negotiated later, and it is the difference between a system finance trusts and one they work around.

Inconsistencies got fixed first

Automating three entities’ contradictory coding habits would only have scaled the contradiction, faster and with better documentation.

Auditors were briefed early

A design review in March costs a meeting. The same review in January costs the close.

Figures on this page are client-verified and published with permission. Where a figure is absent, the outcome is described in operational terms instead.

Talk to us

Talk to us about AI.

A conversation with the senior team about your markets, your data, and where AI would actually pay back for you. No slides, no obligation, and if the honest answer is that AI is not your next move, you will hear that too.