Solution Design and Blueprint for Finance Systems

Solution design is where a finance-systems project decides how the solution will actually work — and the blueprint is where that decision gets written down and signed before anyone builds it. Requirements told you what the business needs. Fit-gap analysis told you where the standard system covers it and where the gaps are. Design is the next step: it takes those answers and turns them into a concrete, agreed target that build and test can both work from. Skip it, or do it badly, and you don't save the time — you just move it to UAT and pay interest on it.

Where design sits

By the time you get here, two things should be settled. You know what is needed, because you wrote the requirements properly. And you know where the standard falls short, because fit-gap classified every requirement as fit, gap, or change-the-process. What you don't yet have is the how.

Design is the how. It's the stage that decides, concretely:

• The target process design — how the future-state process will actually run, end to end, once the system is live. Not "we do month-end close," but the specific sequence of steps, who does what, and where the system fits into it.
• The configuration design — how the standard system will be set up to meet the fits: the settings, the structures, the rules.
• The integration and interface design — what data flows in and out, from and to which systems, in what shape, on what trigger, and what happens when a flow fails.
• The data and reporting design — the data model, the master data, and the reports, extracts and controls the business will actually rely on.

All of it lands in one place: a design document, or blueprint. That document is the deliverable of this stage — not a working system, a described one.

Every decision has to trace both ways

The discipline that makes a design worth signing is traceability. Every design decision should trace backward to a requirement — so you can point at any configured behaviour and say which agreed need it exists to satisfy. And every requirement should trace forward into the design and then into test cases — so you can prove nothing agreed got quietly dropped.

That two-way trace protects you from the two failure modes that cost the most. Without the backward trace, you build things no one asked for. Without the forward trace, you miss things people did ask for, because they fell between two workstreams and no one noticed until go-live. A design that traces both ways is boring in the best way: nothing surprising is in it, and nothing agreed is missing from it.

Design is also where the config-versus-custom calls get made concrete. Fit-gap decided whether a gap warrants building; design decides how — and that's the moment to be honest about configuration versus customization, because the design is where a "small custom tweak" either gets scoped properly or gets waved through to haunt you later.

Design is where decisions get made — and signed

Here's the part teams under-weight. The blueprint isn't documentation you produce after deciding. It's the artefact you decide through. The act of writing the target process design forces the business and the delivery team to agree how it will actually work — before a single setting is configured or a line of code is written.

"

A signed design is the cheapest scope freeze you'll ever get. Everything after it — build, test, cutover — is more expensive to change. So the design review is where you want the arguments to happen, not UAT.

Sign-off is not a formality, it's the mechanism. When the business reviews and signs the design, three things become true at once: scope is frozen against an agreed reference, build has a stable specification, and test has something concrete to verify against. Without sign-off, you have opinions each stakeholder still holds privately, and they'll surface — one at a time, as change requests — at the worst possible moment.

The finance-specific texture

Finance is where a vague design gets expensive fastest, because finance systems post. A loose requirement in some domains produces an ugly screen. A loose design in finance produces a wrong number in a ledger, and then a very tense conversation that starts with "why did it post that?"

So the design has to get specific about the things finance actually runs on:

• The month-end close — the actual sequence of the close, the dependencies, the timing, and where the system automates versus where a person still checks. Design the process, not just the feature that supports it.
• The chart of accounts and ledger design — the account structure, the hierarchy, how the ledger is organised. Get this wrong and every report downstream is wrong, and it's brutal to unwind after go-live.
• Reconciliation and control points — where the design builds in the checks: what reconciles against what, where the controls sit, and who owns the exception.
• The postings — which transactions post where, with what accounting treatment. This is the "why did it post that?" surface. Every posting rule that's vague in the design is a defect waiting to be found in test — at ten times the cost of pinning it down now.

None of this is glamorous. All of it is the difference between a close that runs and a close that doesn't.

Docs versus reality

Here's what actually happens without the discipline. Design gets skipped, or it gets "done" inside the configuration tool by whoever's building — the target is whatever they typed, and it lives in the system, not in a document anyone reviewed. There's no agreed, reviewable blueprint. There's just a build that reflects one person's reading of the requirements.

Then UAT arrives, and it becomes the design review that should have happened months earlier. The business sees the solution for the first time, doesn't recognise it, and the "design" gets discovered as a pile of change requests — every one now a change to something built, configured and tested, the most expensive place in the project to be making design decisions.

I've watched this pattern more times than I can count, and the lesson is always the same: the design didn't cost less because you skipped it. You paid for it later, in a currency called re-test. A document costs a review. A built-and-tested configuration costs a rebuild, a re-test, a re-migration of data, and the credibility you spend explaining the slip. A signed design is cheaper than a re-test — every time.

Get the design right and signed, and build becomes execution against a spec instead of interpretation, and test becomes verification instead of discovery. That's the whole point of the blueprint: to move the hard conversations to the cheapest place to have them.

Part of the Finance Systems Delivery guide. See also fit-gap analysis and testing strategy for finance systems. The newsletter sends one finance-systems pattern every two weeks.