Build time and on the clock. It's time to provide some serious value in the form of a deliverable. To start, three check boxes.
Box one: the chat platform, where a person asks a question or approves a proposal. Box two: a small connector in the middle that only knows how to do six things. Box three: the engine that has actually been closing the books since May, untouched, still the only thing allowed to write to a ledger. Three boxes is the whole plan for the ai financial controller's new front end. Everything I am about to describe is just how carefully we get from that drawing to something a finance team can trust with real money.
I already wrote about why this is happening: a scare that turned out to be nothing taught me that I was the single point of failure on a system I am not expert enough to fully judge myself. The fix isn't a smarter model. It's getting the judgement calls to the person who actually has the expertise, without handing her anything she can't trust.
The four things that don't change
Every posting goes through the one engine that has closed this client's books since May, the same one I planned so carefully before its first go-live. Nothing else is ever allowed to write to the ledger, not the chat platform, not the connector, not me typing faster than I should. Nothing posts without a specific person's written approval, attached to their name, the entity and a timestamp, every single time. The connector only exposes a fixed, short menu of actions: check status, read the ledger, build a dry run, record an approval, post, verify. It cannot do anything outside that list, because it was never given the ability to. And the credentials that actually touch the accounting system never leave the one dedicated machine they live on today. The chat platform never holds them. Neither does the thread.
Days one to four: one question, one decision
The first thing that happens has nothing to do with code. It's a single question to the chat platform's own account team: does connector access carry a real person's identity through to every call, so an approval can actually be tied to the human who gave it, not just to "the system." I already have the exact question written out. Nothing in this build is worth doing if that answer comes back no.
Alongside that, a hosting decision: which dedicated machine, already inside the compliance rules this client's infrastructure runs under, will host the connector for this phase. Not a new server for the sake of it. The same discipline that already governs where the engine's credentials live now governs where the connector lives too.
Weeks one and two: sandbox only, read only
Nothing touches live data in the first two weeks. The connector gets built and tested entirely against sandbox entities, the same practice I used when the engine itself first went live in May: run it, compare it against numbers a human already produced by hand, find the gap, fix it, run it again. The target for the end of week two is a read only tier that actually works: someone on the finance team can ask a real question in the chat thread and get a real answer back, sourced from the ledger, with nothing approved and nothing posted yet. Boring, and exactly the point. A system that can only answer questions cannot lose anyone any money.
Weeks three and four: the dry run pack, for real
This is where it gets closer to how a month actually closes. The system parses that month's bank files, builds the proposed dry run pack, and presents it inside the same chat thread: proposed postings numbered, exceptions listed as plain questions instead of jargon. The named human-in-the-loop on the client's side replies with the numbers they are approving. Every one of those replies gets recorded against their name, the entity, the month, and a timestamp. Nothing posts yet in this window, this phase runs entirely on live reads, not live writes, but the whole approval loop gets exercised for real for the first time, in the actual language a CFO uses rather than a demo script I wrote for myself.
The same loop has to hold at any size. A full month end pack is the big test. "Approve this one line" is a pack of one, and it goes through the identical checks: a fresh read of the ledger before anything is proposed, a duplicate check, the balance verified before and after. If the small case and the large case don't behave identically, the system isn't actually finished, it just looks finished on the case I happened to test.
What this doesn't include yet
No guarded posting through the new front end in this window. That's the phase after the one I'm describing here, and it only starts once weeks one through four have held without a single surprise. I am not stepping back as the fallback operator yet either. And posting by hand, directly inside the accounting system, stays available the entire time, because some of what a finance team needs to do is UI only anyway. The point of this build was never to remove the keyboard. It was to remove me as the only person allowed to use it.
At first, I thought a slick UI with checkboxes to approve the posts was a good idea, but upon further reflection approvals should be written replies typed into the thread, not a tick box, because the chat platform doesn't yet support an interactive checklist inside a conversation. For an auditor, a written reply with a name and a timestamp attached is arguably the stronger trail anyway. And this whole calendar is an estimate. If the account team's answer on identity pass through comes back complicated, or the hosting decision takes longer than four days, the thirty days move. I would rather say that now than pretend a plan survives contact with a vendor's support queue untouched.
Thirty days from now I'll know whether a chat window can carry a real month end conversation without anyone approving something they didn't mean to, or whether the plan I just laid out in three check boxes needed to be a different plan entirely. Either way, that's the next post in this series.
Monthly Revenues $11,000 | Clients 2 | Prospects 1 (AI outbound agent now live)
Day 107 of 365.