We always start with the same seductive assumption: the chaos in our current financial data is a product of the tool we are using. If we could just move to a modern platform—something cloud-native like Xero or a properly configured ERP—the discipline would follow automatically. It feels like buying a new gym membership in January. The transaction itself feels like progress.
I have sat in three different conference rooms over the last five years where we made the exact same decision. We looked at the messy spreadsheets, the invoices sent out via personal email, and the categorization errors that drove our accountant mad. We concluded that our legacy system was "too rigid" or "too outdated" to support the way we wanted to work. So we signed the contract. We committed to the migration. We promised ourselves that this time, we would build the chart of accounts correctly from day one.
The friction never starts during the demo. It starts about three weeks into the implementation, usually on a Tuesday afternoon, when someone from the sales team asks why they can't just "type in" a client name anymore.
The Friction of Enforced Order
Modern SaaS platforms are built on a logic of strict validation. That is their selling point. They don't let you enter a transaction without a category. They don't let you delete an invoice that has been reconciled. They force you to link every expense to a vendor record.
But our actual business processes were built on fluidity. We used to fix billing addresses on the fly. We used to categorize ambiguous expenses as "General" and figure it out later. When we moved to the new system, that fluidity hit a brick wall. The tool wasn't broken; it was doing exactly what we asked it to do. It was enforcing a level of discipline that our team simply didn't possess.
The result wasn't cleaner data. It was shadow IT. To avoid the "hassle" of creating a new vendor record in the system just to buy a $50 software plugin, the marketing team started putting it on a personal card and expensing it later. The system remained pristine, but it ceased to reflect reality. We traded a messy but complete ledger for a perfect but empty one.
"Why is it so hard to just get a simple report of what we spent last month?"
Because in the old system, you were looking at cash out the door. In this new system, you are looking at accruals, matched against purchase orders that haven't been closed yet. The report isn't hard to generate; the definition of "spent" has fundamentally changed, and we never actually agreed on what the new definition meant before we switched.
This is the decision misjudgment that keeps me up at night. We assumed that "better reporting" was a software feature. We thought that if we bought the tool with the best dashboard, we would get the best insights. We failed to realize that reporting is an output of process, not code. If the process of entering data is too high-friction for the person doing the actual work, the dashboard will always be three weeks out of date.
When This Approach Fails
There are specific environments where this strict, structure-first migration is almost guaranteed to fail. If your revenue model is still evolving—say, you are a consultancy that sometimes sells products, or a SaaS company that does one-off custom implementations—a rigid accounting platform can become a straitjacket.
I've seen teams spend months trying to force their "creative" billing structures into standard SKU fields, only to realize that they are spending more time managing the tool than the client relationship. In these cases, the "messy" flexibility of a spreadsheet or a simpler tool like FreshBooks might actually be the superior strategic choice, even if it looks less "professional" to the CFO.
The residual risk we are left with is significant. We now have a system that requires a dedicated administrator just to keep the lights on. We have cleaner data, yes, but we have paid for it with a permanent increase in operational overhead. We didn't just buy software; we hired a digital bureaucrat that sits between us and our work.
Looking back, the mistake wasn't the tool we chose. The mistake was believing that the tool would do the heavy lifting of changing our culture. We wanted the software to be the bad guy so we didn't have to be. But software makes a terrible manager. It just sits there, waiting for valid input, while we argue about whose job it is to provide it.