By the time a finance technology decision reaches a shortlist, the important choice has usually already been made — silently, and without anyone recording that it was a choice at all. The moment the question becomes "which product?", the question "a product?" has been answered in the affirmative by default.
This matters because the default is frequently wrong, and because the decision that was skipped is the one with the largest financial consequence. A wrong product selection is expensive and recoverable. A decision to buy when the correct answer was to extend, fix or wait produces a permanent cost line, an integration surface, and an implementation whose value was structurally capped before the vendor was chosen.
The four paths
Four options are always available. They are not a maturity ladder — none is more advanced than another, and the right answer moves with circumstance.
| Path | What it means | Selected when | Chief risk |
|---|---|---|---|
| Extend | Deepen use of the ERP or platform you already own | Native functionality plausibly covers the need; the gap is configuration or adoption, not capability | Sunk-cost blindness — defending the incumbent past the point it can carry the load |
| Buy | Adopt a purpose-built third-party platform | The process is standardized, and volume, entity complexity or audit pressure exceeds what the incumbent carries | Buying to escape a process problem the product cannot solve |
| Build | Construct it internally | The requirement is genuinely idiosyncratic and durable, and you can staff it for a decade | Underestimating maintenance; finance teams rarely price the second five years |
| Wait | Defer deliberately, capture the gains that need no spend | A hard constraint is active, or a prerequisite is unmet, or the market is mid-reshaping | Drift — "wait" decaying into "never" because nobody owns the re-decision date |
The framework's first contribution is simply making all four visible at the same time. Extend and Wait are systematically under-considered, for structural rather than analytical reasons: no vendor advocates for them, no consultant is engaged to recommend them, and neither produces a project with a launch date. They are the two options with no sponsor in the room.
Test 1 — Is the incumbent genuinely exhausted?
Before evaluating anything new, establish whether the system you own can carry the requirement. The honest version of this test is harder than it sounds, because the usual answer — "we tried, it does not do it" — frequently means one of three quite different things:
- It cannot do it. A genuine functional gap. This is the only version that justifies
looking elsewhere.
- It was never configured to do it. Bought as part of a suite, never implemented,
because the original project ran out of budget at exactly this module.
- It does it badly enough that people stopped using it. Usually a data or process
problem wearing a software costume — and one that will follow you to the new platform.
The distinction is worth real effort, because only the first is solved by buying. The second and third are solved by work you will have to do anyway, and doing that work first frequently changes what you need to buy — or removes the need.
Where the existing ERP's native functionality adequately covers the need, deepening its use before adding a third-party platform is the better decision. The reason is not frugality. It is that every additional platform adds an integration surface, a data reconciliation obligation and a vendor relationship — permanent costs that are rarely priced into a business case that only counts licences and implementation.
Test 2 — Is the process ready to be bought for?
A purchase encodes the process it finds. This is the sequencing rule, and it enters this framework as a gate rather than an afterthought: if the process is not standardized, the buy path is not available yet — not because buying is wrong in principle, but because buying now purchases a permanent version of the current variation.
The readiness test is the maturity spine. A capability at L1 (Manual) is not ready for a platform designed to take an organisation from L2 to L3. That is not a vendor failing; it is a level the buyer must climb themselves, because it consists of process decisions only they have authority to make.
Test 3 — Does scale actually justify a dedicated platform?
Where the process is standardized, the question becomes whether the load exceeds what the incumbent can reasonably carry. Three drivers matter, and they matter more than headcount:
- Volume — transaction counts where manual or ERP-native handling stops scaling
- Entity complexity — multiple ledgers, currencies, consolidation layers, intercompany
- Audit pressure — external scrutiny requiring evidence, traceability and reviewer
workflow that spreadsheets cannot produce credibly
Any one of these, at sufficient intensity, justifies a dedicated platform even where the ERP nominally has a module. Audit pressure in particular is frequently decisive on its own: the requirement is not the calculation but the evidence that the control operated, which is precisely what purpose-built platforms are designed to produce and general ledgers are not.
Test 4 — What does the ecosystem imply?
Once buying is genuinely selected, the existing platform should weight the shortlist heavily. Integration quality is not a tie-breaker; for finance systems it is frequently the dominant variable in realised value, because the integration is where implementations overrun and where the data-quality problems surface.
This is why our vendor research tracks ERP integration coverage as evidence rather than treating it as a checkbox. A vendor with a mature, natively-supported path to your ERP is carrying risk that a nominally stronger product with a generic connector will hand back to you during implementation.
The corollary is uncomfortable and worth stating: the best product for your organisation is often not the best product in the market. If your ledger is SAP, the field of realistic options narrows before capability is assessed — and pretending otherwise produces a shortlist that looks rigorous and implements badly.
Test 5 — Is a constraint actually binding?
Constraints do not change the right answer. They change what can be done about it this year, and confusing the two produces both bad decisions and bad morale.
A budget freeze, a headcount cap, an ERP migration already in flight, an acquisition mid-integration — each blocks the buy path without making it wrong. The correct response is not to abandon the analysis but to split it: record the decision that would be correct absent the constraint, and separately decide what to do inside it. That record is what makes the re-decision cheap when the constraint lifts, and it is almost never written down.
Under a binding constraint, the highest-return move is usually to capture the gains that require no new spend — the L1→L2 standardization work — which also improves the eventual purchase.
Putting it together
Run in order. The sequence is the framework; the individual tests are unremarkable on their own.
- Is the incumbent exhausted? No → Extend. Do the configuration and adoption work.
- Is the process standardized? No → Wait or narrow scope to the stable subset.
- Does volume, entity complexity or audit pressure exceed the incumbent? No → Extend.
- **Is the requirement idiosyncratic and durable and staffable for a decade?**
Yes → Build. This is rare in finance and should feel rare.
- Is a hard constraint binding? Yes → Wait, deliberately, with a named re-decision date.
- Otherwise → Buy, weighted heavily toward ecosystem fit.
The output is not just an answer but a defensible answer: each step names the condition that selected the path, which is what allows the decision to be explained to a board and re-examined later without re-litigating it from scratch.
The strongest objection is that this framework systematically over-weights Extend and Wait, and that in practice this produces paralysis.
There is real substance here. "Extend the ERP" can absorb years and enormous internal effort before an organisation concedes the platform was never going to carry the requirement — and those years have a cost that no business case captures, because failure to act rarely appears in one. A framework whose first two tests both point back at the incumbent can rationalise indefinite delay, particularly in organisations that find decisions uncomfortable.
Two things bound the objection. First, tests 1 and 5 are time-boxed by construction: the extend path requires a stated period and a named owner, and the wait path is invalid without a re-decision date. A wait with no date is not this framework being applied — it is this framework being used as cover. Second, tests 3 and 4 are deliberately permissive: any one of volume, entity complexity or audit pressure is sufficient to select buying, which is a low bar by design, precisely because the incumbent bias is real.
The honest residual risk: this framework is more likely to delay a good purchase than to permit a bad one. In an organisation that already decides slowly, that asymmetry is a real cost and should be corrected by tightening the time-boxes — not by skipping the tests.
- Four options, always. Build, buy, extend, wait. Extend and Wait have no advocate in
the room, which is exactly why they need to be named explicitly at the start.
- The gate is process readiness, not product quality. An unstandardized process makes
the buy path unavailable this year, regardless of how good the shortlist looks.
- A constraint changes what you can do, not what is right. Record both — that record
is what makes the re-decision cheap when the constraint lifts.
Where this leaves you. Run the six steps against the one technology decision currently in front of you, and write down which condition selected the path. If no condition selects it, you have a preference rather than a decision — which is worth knowing before the business case is written.