How to Scope a Finance Technology Advisory Project

Technology advisory projects become difficult when the software decision is made before the business requirements are understood. A useful scope should define the problem, the finance processes affected, the systems involved and what a successful implementation needs to deliver.

This article was originally published around our Digital Accountancy Show 2025 session on scoping tech advisory. The event has passed, but the underlying scoping principles remain useful.

Start with the business problem, not the app

“We need a new accounting system” is not yet a scope. Identify what is driving the project: reporting limitations, manual processing, disconnected systems, multi-entity complexity, poor visibility, an unsupported platform or a finance structure that no longer fits the business.

Those problems become the basis for evaluating software and deciding what the implementation actually needs to change.

Map the current finance process

Document how information moves today: sales, purchasing, approvals, expenses, payroll, stock, banking, reporting and month-end. Note where data is re-keyed, exported to spreadsheets or passed between systems manually.

This gives the project team a baseline. Without it, there is a risk of recreating the same inefficient process in newer software.

Separate requirements into must-have and nice-to-have

Not every feature has equal importance. Identify the requirements that are essential for control, compliance or day-to-day operations, then separate the improvements that would be useful but are not critical to go-live.

This is particularly important when moving from a larger or customised ERP to a simpler cloud accounting environment, because some functionality may need an app, a redesigned process or a conscious decision not to replicate it.

Scope the data migration at the same time

Implementation and migration should not be treated as unrelated workstreams. The destination Chart of Accounts, tracking structure, contacts and reporting design determine how historical data needs to be mapped.

Agree the source system, entities, cut-off date, years of history, transaction volume, currencies, attachments and reconciliation requirements early. If the project is opening-balances only, make that an explicit decision before go-live.

Identify integrations and ownership

List every system that sends information into or receives information from the accounting platform. For each integration, establish what data moves, how frequently, who owns it and what happens during cut-over.

A technically successful accounting implementation can still create operational problems if connected workflows are discovered too late.

Define acceptance criteria before delivery starts

Decide how the team will know the project is ready to go live. Acceptance criteria might cover configured workflows, user access, integrations, reporting, training and migration reconciliation.

For the accounting data itself, define the source reports that will be used as evidence and the destination reports they will be compared against.

Plan for the first month after go-live

Support requirements are often highest after the system begins being used in real processes. Build in ownership for questions, first reconciliations, reporting checks and any tax-return or period-end validation that is relevant to the project.

A good scope therefore ends after operational validation, not at the moment the software is switched on.

Keep the scope understandable

The best project scopes are detailed enough to prevent ambiguity but clear enough for finance, implementation and migration teams to use. State what is included, what is excluded, what assumptions have been made and which decisions still need to be resolved.

That clarity is more useful than a long list of software features because it gives everyone the same definition of what the project is trying to achieve.