A finance system for a multi-entity company

01 / Why close is slow

Missing evidence makes the close slow.

The finance team worked across bank feeds, cards, invoice inboxes, purchase orders, contracts, and accounting systems. The information needed to explain a transaction usually existed, but it was scattered across systems and people.

This turned the close into reconstruction. Finance searched for receipts, asked who approved a supplier, checked which entity owned a cost, fixed duplicate invoices, and revisited coding decisions after the context had gone cold.

Models can read messy documents and suggest coding. Exact accounting checks are still needed. FinBalance, a 2026 reconciliation benchmark, found that six current models reached no more than 46% exact final balance-sheet accuracy across its 710-record split. The models could create plausible entries and still link them to the wrong evidence.

02 / The first build

We started with one kind of transaction.

The company operated several legal entities, bank accounts, card programmes, currencies, and approval policies. We started with invoice and bank-transaction reconciliation for one entity.

The first build was narrow enough to evaluate and useful enough to matter. It created the foundations needed later: source identity, evidence links, policy rules, approval routes, and a reliable audit record.

03 / How it works

Every item went through the same checks.

The accounting system stayed in place. Every proposal followed the same steps, whether it began as a clean invoice or a messy email attachment.

1. 01

   Collect

   Read the invoice inbox, bank feed, purchase orders, supplier list, and chart of accounts.

2. 02

   Link

   Store each proposal with its source, entity, supplier, period, and approval history.

3. 03

   Check

   Use fixed rules to check totals, duplicates, tax fields, account status, purchase order limits, and balanced entries.

4. 04

   Suggest

   Use the model to suggest coding, explain an unusual item, and summarise an exception.

5. 05

   Route

   Send the item to the right person based on value, risk, company rules, and missing evidence.

6. 06

   Post

   Use a restricted account to post the approved entry and record who approved it.

The evidence record became the centre of the system. We sent a proposal to review only when it had a source link, entity, rule result, and decision history.

04 / Who decides

The assistant prepares. Finance decides.

These were different jobs. The model could not approve its own suggestion. The account that read invoices could not also control payments or the ledger.

The first version removed manual searches, prepared each decision, and had permission to take very few actions.

05 / Tests

Test the errors that matter.

We built a golden set of historical transactions and their approved evidence, coding, and decisions. We held back a full period for final testing and included clean examples, missing documents, duplicates, conflicting amounts, wrong entities, and adversarial instructions hidden in source files.

The primary safety metric was false clearance: an item the system allowed through when it should have stopped. We combined code-based checks, sampled human review, model-based grading where useful, and production monitoring.

06 / Access

Each agent received its own access.

We gave each agent its own identity and limited authority. This kept every action attributable and auditable instead of hiding the system behind one shared account.

• Separate identities for reading, drafting, approving, and writing
• Access limited by entity, account, action, and environment
• Human approval for payments, bank details, tax, and unusual journals
• Sources, rule results, model version, tool calls, approvals, and writes recorded
• Immediate access revocation and traceable corrections
• Email and attached documents treated as untrusted inputs

The reviewer saw the evidence, proposed entry, checks that passed, and the reason the item reached them before making a decision.

07 / Rollout

We started read-only and added writes later.

Before the system could change the ledger, it had to assemble the right evidence and stop at the right boundary.

1. 01

   Followed one transaction

   Recorded its evidence, approval, posting, and correction steps.

2. 02

   Connected read-only

   Ingested one invoice mailbox, one bank feed, and the accounting records for one entity.

3. 03

   Added fixed checks

   Built exact matching, duplicate checks, limits, and evidence rules before adding a model.

4. 04

   Added suggestions

   Suggested coding and summarised exceptions, with a link to every source.

5. 05

   Ran without posting

   Compared suggestions with finance decisions while keeping the ledger read-only.

6. 06

   Allowed approved posts

   Gave a restricted account permission to post entries after approval.

Each expansion became a new release. A second entity, new currency, or new write action changed the risk and received its own tests.

08 / Metrics

We measured whether the books were ready.

We tracked missing evidence, accepted matches, waiting exceptions, and corrected entries throughout the month.