Build or buy for finance automation

Building your own finance automation used to be obviously wrong for most businesses. The cost of a developer, the time, the maintenance — the arithmetic settled it.

That has genuinely changed. Describing what you need and having it built collapses the construction cost, which means the decision now turns on things other than build effort.

Which makes it harder, not easier.

What building still costs

The construction was never the expensive part. What remains:

Ongoing maintenance. Business changes, requirements change, something breaks. There is no vendor.

The knowledge problem. Whoever built it understands it. When they leave, you have a system nobody can safely modify. This is the most common way home-built finance tools become liabilities — see when the only person who understood it resigns.

Edge cases you have not met yet. A bought system has encountered thousands of businesses' awkward cases. Yours has encountered your own, so far.

Compliance and audit trail. Producing a trail that satisfies an auditor is more work than it appears, and the requirements are specific — see evidence an auditor will accept.

Integration maintenance. Banks change formats. Platforms change APIs. Someone has to keep up.

What buying still costs

Not just the subscription:

Fitting your process to theirs. Sometimes an improvement, sometimes a permanent workaround.

Change requests. Anything outside the configuration range happens on the vendor's timetable.

Dependency. They set the direction, the pricing and the lifespan.

Migration, in and out. Underestimated in both directions, and the exit is the one nobody plans for — see record retention when records are generated.

The four questions

Is this differentiating, or is it plumbing?

Bank reconciliation is plumbing. Every business does it, correctness is defined externally, and doing it distinctively wins you nothing. Buy plumbing.

If you have a genuinely unusual process that is part of how you compete — an unusual settlement arrangement, a bespoke revenue model — that may be worth building.

Most finance automation is plumbing. The bar for "differentiating" is higher than it feels.

Who maintains it in three years?

Not who builds it. If the honest answer is "whoever is here", you are building a dependency on individuals for a system that has to keep working monthly for as long as the business exists.

This question kills more build cases than cost ever did.

Does it need to satisfy an auditor?

Anything touching the ledger does. That means a complete audit trail, rule versioning, the ability to identify every transaction processed under a given rule, and documentation an auditor can follow.

Bought systems have this because their customers demanded it. Built systems have it if someone thought to include it, and retrofitting it is genuinely difficult.

What happens when it breaks during month end?

A bought system has support. A built one has whoever is available, and if it is one person, whether they are on leave.

Finance has non-negotiable deadlines, which raises the cost of an outage above what a normal internal tool would carry.

The hybrid that usually wins

For most businesses the answer is neither pure option:

Buy the core. Ledger, reconciliation, document capture, audit trail, compliance. Standard, externally defined, and the audit trail is the hard part.

Build the edges. The specific report nobody else needs, the workflow around your unusual process, the integration with the system unique to your industry.

This works because the edges are where your specificity lives and the core is where the compliance burden sits. It fails when the boundary is not maintained — when "the edges" quietly grows until you have built a second finance system alongside the first.

The failure mode of each

Build fails by: the builder leaving, the audit trail being inadequate when it matters, and the system becoming unmaintainable while still being depended upon.

Buy fails by: a requirement the vendor will not accommodate, a change of direction you did not choose, and a migration cost that traps you.

Neither is disqualifying. Both are worth naming before deciding, because each has a mitigation — documentation and knowledge transfer for the first, exit terms and export testing for the second.

Common questions

Should I build or buy finance automation?

Buy anything that is plumbing — bank reconciliation, document capture, the ledger, the audit trail — because correctness is externally defined and doing it distinctively wins nothing. Building is worth considering only for a genuinely unusual process that is part of how you compete, and the bar for that is higher than it feels.

What makes building risky even when construction is cheap?

The construction was never the expensive part. What remains is ongoing maintenance with no vendor, the knowledge dependency when the builder leaves, edge cases you have not encountered yet, producing an audit trail that satisfies an auditor, and keeping integrations working as banks and platforms change formats.

What is the question that settles it?

Who maintains it in three years. Not who builds it — if the honest answer is whoever happens to be there, you are creating a dependency on individuals for something that must keep working every month for as long as the business exists. That question ends more build cases than cost ever did.

Is a mixed approach sensible?

For most businesses it is the right answer: buy the core where compliance and the audit trail live, and build the edges where your specificity is — the report nobody else needs, the workflow around an unusual process, an industry-specific integration. It fails when the boundary is not maintained and the edges gradually become a second finance system.

Related: AI features versus AI-native accounting · when the only person who understood it resigns · the new shadow IT