The problem
The group was a textbook case of fragmentation. The accounting platform knew the balances. A separate job system knew the projects. A shared mailbox held the invoices. A spreadsheet held the cost codes. Institutional memory held everything else, including which of the entities a given supplier normally billed and which costs were recoverable from a tenant or a related party.
Every one of those systems worked. None of them could answer the only question that mattered when an invoice arrived, which is: whose is this, what is it for, is it right, and who signs it. Assembling that answer took a person opening four things and remembering a fifth, on every invoice, all day.
The consequences were the predictable ones. Costs that should have been on-charged were not, because nobody caught them at the time. Invoices addressed to entities the group did not run were quietly coded and paid. Jobs were coded from memory to numbers that did not exist in the receiving entity’s own ledger, which meant job costing was wrong in a way nobody could see. And the whole thing depended on one person who could not take leave.
The brief
Stop the coding being a manual job. Get every invoice onto the right entity and the right job without someone holding the map in their head. Catch the ones that are wrong before they are paid rather than after. Make the on-charge recovery happen automatically instead of when someone remembers. Keep the existing accounting platform, and make the whole thing auditable.
What we built
- One dictionary for the group. Every entity and every real job in one place, pulled from the source systems rather than typed, so the map stopped living in one person’s head and started living in the system.
- Coding that cannot invent. Nothing is ever coded to an entity or a job the group does not actually have, and a bill addressed to an entity they do not run is escalated rather than paid.
- Accurate from the first invoice. The system arrived already knowing how the group codes, so the team was not correcting it for a month before it earned its place.
- Verification before payment. Layered checks against the group’s own knowledge base, against external sources, and against everything each supplier had done with them previously. Layers agree and it moves; any disagrees and a person is told what did not line up.
- Approval with a real audit trail. Through the group’s own reviewers and approvers, with who signed off and when recorded against every decision.
- On-charge recovery closing the loop. The recovery decision made when the bill was coded becomes the invoice that recovers it, so recoverable cost stopped sitting in a spreadsheet waiting to be noticed.
What it delivers
The first pass stopped being a manual job and became a short exception queue. Instead of a full inbox of raw PDFs, the team opens a list of the ones that genuinely need judgement, each with the reason attached.
Invoices that do not belong to the group are caught rather than paid. Jobs are only ever coded to numbers that actually exist in the receiving entity’s ledger, so job costing is right by construction rather than by diligence. A supplier announcing a change of bank account is held for a human instead of paid, which is the single moment where a normal accounts process loses real money.
And the map is no longer in one person’s head. It is in the registry, it is versioned, and someone can take leave.
The approach
We did not replace anything that was working. The accounting platform stayed. The job system stayed. What was missing was the layer above them that could hold the context and apply the group’s own rules, so that is what we built, against the group’s real invoices rather than a sample, tuning the confidence thresholds and the flags until the coding held up on the mail that actually arrives.
The human approval step was designed in from the start rather than added afterwards. The system proposes; a person disposes. That is a deliberate constraint, not a limitation we are working to remove.
The stack
Document intelligence over the incoming PDFs and scans, a reasoning layer constrained by the group’s own registries so it cannot invent a value that does not exist, a verification layer drawing on external and official sources, an approval and notification layer over the group’s existing channels, and an API integration into the accounting platform that receives the finished, approved transaction. Hosted in Australian infrastructure the client controls.
What this engagement says about how Bedstone works
The instinct in a fragmented business is to consolidate the applications. We did the opposite: we left the applications alone and built the context layer above them, because the applications were not the problem. Nothing sitting above them was.
It also shows where we draw the line. The system does not approve payments and does not update a supplier’s bank details on the strength of a letter. Where confidence is low or something looks wrong it stops and asks. Removing the assembly work while keeping the judgement is the whole design, and in anything touching money it is the only defensible one.
Want a reference call?
We can arrange a conversation with the operator behind this build, subject to their agreement. Start a brief and ask.