The month he spent building it isn't the part to copy

A finance leader at an early-stage SaaS company built a revenue recognition tool in a month, and he had no prior coding experience when he started. That's how a CFO Connect recap of one of its live sessions tells it, and that's the line people repeat. Revenue recognition "was costing 4 to 6 hours per month," according to the recap, and he got it down to "three button clicks."

I like that story a lot, but I don't think the speed is the part to copy. What I care about is what happens after the build -- the part most people skip when they show off something they made... understandably, nobody wants to demo a line-by-line comparison.

The recap calls him Alex. His tool pulls from three places -- the billing system (Tabs, through its API), closed-won deals in HubSpot, and QuickBooks as the destination where it all ends up, and in the recap's words it "posts a validated journal entry in one click." He also built a finance portal that puts multi-entity financials, SaaS metrics and investor reporting in one hosted place, with "role-based gating at the database layer" deciding who sees what, so marketing sees CAC reports, the CEO sees the board deck, and nobody but Alex sees the task list.

The detail I keep coming back to is the hosting. According to the recap, "one engineer spends one day adding Google SSO." So after a month of building by someone who doesn't write code, the one piece that needed an engineer was making sure only the right people could get in -- and that tells you where the hard parts are.

The slow part

The recap's step-by-step setup has two steps after the build that I'd tape to the wall. The first is checking the tool against history, "Run the script against every prior month," then comparing the output line by line against what's already posted in QuickBooks. When Alex did that, the check "surfaced errors the old manual process had missed." That's worth sitting with, because back-testing isn't only about catching the new tool's mistakes, it turns up the old process's mistakes too, and those only come to light if somebody goes looking.

The second step is running both methods in parallel, which the recap puts as "operate both methods simultaneously for two to three months before going fully live." Its advice for the quarter says the same: keep the manual close going, run the new tool next to it, and compare the two each time.

This is where trust comes from. A demo shows the tool works once, on the month you happened to pick, and two or three closes in parallel show it works on months you didn't pick, with the odd refund, the deal that closed on the last day, the invoice somebody fixed by hand. That gives the builder confidence, and it gives anyone who checks the books later something more to go on than "the new script said so."

Why finance can't skip it

Dell's CFO, David Kennedy, told Fortune that he has "started to deploy agents to do reconciliations, do accounting journal entries," which is the same kind of work Alex automated, at a very different scale. He made two points that fit the slow rollout. The first was "You're only as good as the data you have, so you've got to make sure that's clean." The second was "The accountability level is still there," said while pointing to his work with auditors and regulators. That second one is the whole reason for the parallel run... the tool can post the journal entry, but a person still has to answer for it when someone asks.

I also want to be honest about where the edges are. An earlier CFO Connect recap, published in March about a session on Claude for finance teams, said that "automatically updating a live model for the next quarter is not yet reliable," and told people to "expect that in six to twelve months." So some tasks are ready for a careful rollout and some aren't yet, and a parallel run is a good way to find out which kind you've got.

If you work in finance or ops and you've built something that replaces a manual task, this is the order I'd follow, mostly straight from the recap. Back-test it against every past period you have, line by line against what was actually recorded at the time. Treat every difference as a question and not a verdict, since some will be the tool's bugs and some will be the old process's. Run both methods side by side for two to three cycles before you switch over completely. Before anyone else gets access, sort out who can see what and how they're going to sign in. Then keep a person accountable for the output, someone who can explain how it was produced.

Doing the work twice for two or three months is expensive. You built the thing to get your hours back and for a whole quarter you end up with fewer of them, so I get why some teams won't have the patience. But the month of building is what makes the story fun to tell, and the months of checking are what turn the tool into something you can put in front of an auditor. The one step Alex needed an engineer for, limiting access to the people who should have it, is the gap we're trying to close at Workbricks -- but the checking is still on you, and I think that's how it should be.

Copy the checking, not the month.