The decision most finance teams think they're making — which system to buy — is usually not the real decision. The real decision is what to do with the systems they already have, and how to make the whole landscape work together reliably.
Build, buy, and integrate aren't mutually exclusive options. Most finance technology decisions involve some combination of all three. The question is which combination, and in what order.
The case for integrating what you have
The strongest argument for integrating existing systems before buying new ones is that the problems that look like system problems are often process and data problems that a new system will inherit.
If invoice matching fails because supplier master data is inconsistent, a new AP automation tool will fail at invoice matching for the same reason. If financial close is slow because reconciliation is manual, a new ERP won't fix that unless the underlying data flows are redesigned. New systems are better than old ones in many ways, but they don't fix the problems that live between systems — they just move them.
An integration-first approach starts by making existing systems talk to each other reliably, which surfaces the real process and data problems that need to be solved. That diagnosis often changes the decision about what to buy, and in some cases eliminates the purchase entirely.
When buying is the right answer
Buying a new system is the right answer when the existing system is genuinely the constraint — when it lacks functionality that's required, when vendor support has ended, or when the data model is so far from what's needed that integration is more expensive than replacement.
It's also the right answer when the organisation is ready to standardise a process that's currently inconsistent. A new procurement platform that enforces a consistent PO workflow is worth buying if the organisation will actually change the workflow. If the existing process will just be recreated in the new system, the purchase cost isn't buying improvement — it's buying familiarity.
The risk in buying is underestimating integration cost. Most system purchases include an implementation budget for the system itself and underestimate the budget for connecting it to everything else. The ERP implementation that runs over budget almost always runs over because the integrations were harder than expected, not because the ERP configuration was harder than expected.
When building is the right answer
Building custom software is the right answer for the gaps that bought systems don't fill: the internal portal that finance needs to manage exceptions, the monitoring dashboard that gives visibility across systems, the custom connector between two platforms that don't have a native integration.
Building is not the right answer for problems that bought systems solve well. Custom-built AP automation, built because the commercial options were evaluated and dismissed for reasons that are no longer current, is a maintenance burden that usually doesn't justify itself. The bought system that was rejected five years ago has probably improved.
The build-vs-buy question for finance systems is often settled by asking who will maintain what gets built. Custom software requires ongoing engineering capacity to keep it working as the systems around it change. If that capacity doesn't exist or isn't sustainable, the custom build will degrade faster than a bought system.
How to sequence the decision
The most reliable sequence is:
- Understand what's actually failing now — the specific integration gaps, data quality problems, and process inconsistencies that are causing operational pain.
- Distinguish between problems that are system problems and problems that exist in the space between systems.
- Fix the integration problems first, because they affect every system in the landscape and the diagnosis often clarifies what a new system needs to do.
- Buy new capability where the existing system is genuinely the constraint and the integration layer is stable enough to support it.
- Build the specific tools that the commercial market doesn't address.
This sequence produces better decisions because each step generates information that improves the next one. It's slower than buying a new system and hoping the problems go away, but it produces landscapes that actually work.