Fit-Gap Analysis for Finance Systems
A fit-gap analysis compares what a standard system does against what the business needs — classifying each requirement as fit, gap, or change-the-process. How to run one, classify gaps, and avoid the customization trap that makes systems expensive forever.
A fit-gap analysis compares what a standard system does out of the box against what the business actually needs — classifying each requirement as a fit, a gap, or a case to change the process. It's how an implementation decides what to configure, what to build, and — most importantly — what to not build by adapting the business instead. Done honestly, it's the single biggest lever on the cost, timeline and long-term maintainability of a finance system. Done as a formality, it's where over-customization quietly begins.
What it is
Every packaged finance system does a great deal as standard. A fit-gap analysis is the structured comparison of that standard capability against your requirements, requirement by requirement:
- Fit — the standard meets it, typically through configuration. No build needed.
- Gap — the standard doesn't meet it as-is. You'll need to configure heavily, build something custom, adopt a workaround, or…
- Change the process — the third, most-underused option: adapt the business process to the standard instead of bending the system to the process.
The third option is the point
Most teams treat fit-gap as a binary — it fits or we build it. The valuable move is the third column: some gaps exist only because "we've always done it this way," and the honest answer is to change the way, not the software.
Every gap you close by building is a cost you pay once to create and forever to maintain. Every gap you close by changing the process is paid once. The art of fit-gap is telling those two apart.
Not every process is sacred, and standard software often encodes a better practice than the local habit it's replacing. Reserve customization for where your process is a genuine, defensible differentiator — not for where it's merely familiar.
Why it matters
Fit-gap controls three things at once:
- Scope — it turns "make it do what we need" into a concrete, decided list.
- Cost — configuration is cheap; custom build is expensive to create, test, document and maintain.
- Risk — heavy customization is what makes systems fragile, hard to upgrade, and expensive to change later.
The outcome and scope you agreed at intake are the reference point: a gap only matters to the extent it blocks the agreed outcome.
How to run one
- Start from agreed requirements. Vague requirements produce a vague fit-gap. This is why the shaping work upstream matters.
- Assess the standard. Through demos, a prototype, or deep product knowledge, establish honestly how the standard meets each requirement.
- Classify every requirement: fit, gap, or process-change.
- Decide each gap — configure, build, work around, or change the process — with the business in the room.
- Log the decision and its rationale. The output is a decision log, not a list of gaps someone will re-argue in UAT.
Classifying gaps well
Not all gaps are equal. Two axes matter:
| Must-have | Nice-to-have | |
|---|---|---|
| Cheap to close | Do it | Maybe |
| Expensive to close | Weigh hard — is a process change or workaround acceptable? | Almost always drop or defer |
A "must-have" that's expensive to build deserves the hardest scrutiny: is it truly must-have, or is it a strong preference wearing a must-have label? That conversation, held now, is worth ten times what it costs.
The customization trap
The most common way finance implementations go wrong is a thousand small "yes, we can build that." Each gap closed by custom code seems reasonable alone; together they produce a system that's expensive to run, painful to upgrade, and understood by no one. Standard-first isn't dogma — it's the recognition that custom is a permanent liability, so it should be spent deliberately, on the few gaps that genuinely warrant it.
What usually goes wrong
- Fit-gap as a formality. A spreadsheet filled in to tick a milestone, with no real decisions — so the gaps resurface, uncosted, in build and UAT.
- Everything is a gap. No appetite to change any process, so every local habit becomes a customization.
- Gaps discovered late. A weak fit-gap, so "the standard doesn't do that" is discovered in UAT — the most expensive place to learn it.
- Nice-to-haves built as must-haves. No honest must/nice classification, so cost goes where preference is loudest, not where value is highest.
Compare standard against need, use all three responses (fit, build, change the process), classify gaps by value and cost, and log the decisions — and fit-gap becomes the moment you take control of scope and cost, rather than the formality where you quietly lose it. What you decide here is what UAT will later verify actually works.
Part of the Finance Systems Delivery guide. See also writing scope in and scope out and user acceptance testing. The newsletter sends one finance-systems pattern every two weeks.