A company doing forty million in revenue was running its entire finance function through QuickBooks, eleven spreadsheets, and one controller who knew where everything was. It worked. It worked right up until she took a two-week holiday and nobody could produce a cash forecast.
That is the actual failure mode. Not the software, QuickBooks handles far more than people assume. The failure is that no one ever designed the system, so the system became a person.
Architecture before applications
Most finance stack conversations begin with the wrong question. “Should we move to NetSuite?” is not a starting point; it is a conclusion that requires three prior answers.
Where does the truth live? Every number has exactly one authoritative source. Revenue lives in one place. Headcount lives in one place. If two systems can both claim to hold the real number, you have guaranteed a reconciliation meeting every month for the rest of the company’s life.
How does data move? Every handoff between systems is either an integration or a human. Integrations fail loudly and get fixed. Humans fail quietly, on holiday, at quarter-end. Count your handoffs, the number is usually higher than management thinks.
What has to be true at close? Work backwards from the reporting package your board, lender, or buyer requires. That output determines the chart of accounts, the dimensions you tag transactions with, and the sequence in which the close has to run.
Answer those three and the software questions largely answer themselves.
The layers, in the order they should be built
We think about a finance stack as five layers. Building them out of order is the single most common and most expensive mistake we see.
1. The ledger. Your general ledger and chart of accounts. QuickBooks Online is sufficient for most companies below roughly fifty million in revenue, single-entity, with straightforward revenue recognition. You move to NetSuite or Intacct when you hit real multi-entity consolidation, inventory complexity, or subscription revenue that QBO cannot model, not because you crossed a revenue threshold that felt significant.
The chart of accounts is the part that actually matters here, and it is the part that gets the least attention. Design it around how you make decisions, with dimensions for entity, department, location, and channel. Redesigning a chart of accounts after three years of history is painful, expensive, and destroys comparability in exactly the periods a buyer wants to examine.
2. Transaction capture. Bill.com for payables, expense management for cards and reimbursements, the payment rails you actually use. This layer is where the labor is, and where automation pays back fastest. Intelligent document processing on inbound invoices (coding, matching, routing) removes the highest-volume, lowest-judgment work in the department.
It also builds your control environment. Approval thresholds, segregation of duties, an audit trail that exists because the system produces it rather than because someone remembered to save the email. That is what an auditor tests, and increasingly what a buyer’s diligence team tests too.
3. People and payroll. Payroll, benefits, and time, integrated so that labor cost lands in the ledger with the right dimensions attached. For most owner-led companies a PEO is the correct answer, and the integration between the PEO and the ledger is what determines whether departmental reporting is real or approximate.
4. Reporting and planning. This is where owners feel the difference. The ledger produces statements; this layer produces answers. Budget versus actual with variance explanations. Rolling forecasts. Unit economics by channel, SKU, or property. Cash visibility over a horizon long enough to act on.
Critically, this layer only works if layers one through three are clean. Building dashboards on unreliable data does not produce insight. It produces confident wrongness, distributed weekly.
5. Intelligence. Anomaly detection on spend. Automated variance commentary. Natural-language interrogation of your own numbers. This is where the interesting work is happening right now, and where we spend a growing share of our time.
But note the position: layer five. AI applied to a broken close does not fix the close. It makes the mess faster and harder to trace.
Where AI earns its place today
Some honest distinctions, because the marketing in this space is well ahead of the reality.
Working now: document extraction and coding on invoices and receipts; anomaly detection across transaction volume; first-draft variance commentary; drafting SOPs and process documentation; reconciliation matching on high-volume accounts.
Working with a human in the loop: forecast generation, cash flow scenario modeling, revenue recognition on non-standard contracts. Useful, far faster than manual, and not something to leave unreviewed.
Not there yet: anything requiring judgment about materiality, anything a regulator or auditor will hold you to without a documented human decision behind it.
The pattern that holds is straightforward. AI is very good at the high-volume, low-judgment work that consumes most of a finance team’s hours, and it is unreliable precisely where judgment is the value. Automate the first category aggressively. Keep experienced people on the second.
Sequencing a real engagement
When we take on a company with a finance function that has grown by accretion rather than design, the order is almost always the same.
Weeks one to three. Map what exists. Every system, every spreadsheet, every handoff, every person who is a single point of failure. This is usually the first time anyone has seen the whole picture on one page, and the picture itself is often the most valuable deliverable of the engagement.
Weeks four to eight. Fix the ledger and the close. Chart of accounts, accrual discipline, a close calendar with owners and dates. Nothing downstream is trustworthy until this is done, and it is the least glamorous work in the entire project.
Weeks eight to sixteen. Automate transaction capture. Payables, expenses, document processing. Highest labor saving, lowest risk, and it funds the rest of the project in headcount terms.
Months four to six. Build the reporting layer. Now that the data is reliable, dashboards mean something. This is when owners typically say the engagement paid for itself.
Ongoing. Intelligence and refinement. Anomaly detection, deeper automation, tightening the close calendar month over month.
What good actually looks like
A finance function is well-architected when a few specific things are true. Close completes in five business days or fewer. Any number in the reporting package can be traced to source without asking a person. The controller can take two weeks off. Adding an entity, a location, or a product line does not require redesigning anything. And a diligence request produces a file rather than a project.
None of that requires expensive software. All of it requires design.
The companies that struggle are not the ones with the wrong applications. They are the ones where nobody ever drew the diagram, where every system was added to solve a specific problem in a specific month, and the architecture is simply the accumulated residue of those decisions.
Draw the diagram. Then buy the software.