An ERP programme can meet its technical milestones and still leave Finance closing the books through spreadsheets, resolving interfaces manually and working around unclear ownership.
The software may be live. The Finance function may be substantially unchanged.
This is why Finance Transformation and ERP Transformation need to be connected without being treated as the same thing. ERP provides an important platform. Finance Transformation decides how work, accountability, controls, information and capability should change.
Finance leaders should make the decisions that shape the future function before solution design and implementation commitments narrow the available choices.
ERP is an enabler, not the transformation
A modern ERP can standardise transactions, connect data, automate controls and provide a stronger foundation for reporting. Those capabilities matter, but they do not decide how Finance should serve the organisation.
The system cannot determine which decisions belong in business units, shared services or a retained Finance team. It cannot settle who owns an end-to-end process, which management information is genuinely useful or which control evidence is proportionate. Those are business and operating-model choices.
A technology-led programme often starts with the platform, a system-integrator method and a timetable. Finance is then asked to fit its requirements into a design that is already gathering momentum. This can deliver software while preserving fragmented processes, inconsistent data ownership and unclear accountability.
ERP-enabled finance transformation starts from the opposite direction. It establishes what the Finance function needs to achieve, then uses technology to support that design.
Why the sequence of decisions matters
ERP configuration turns assumptions into system behaviour. An unresolved policy question can become a workflow. A temporary reporting request can become a permanent data field. Local process variation can be embedded before anyone has decided whether it should remain.
These choices are not impossible to revisit, but change becomes more expensive once configuration, integrations, migration mappings, testing scripts and training materials depend on them.
Finance does not need every future detail resolved before implementation starts. It does need clarity on the decisions that determine the shape of the solution and the evidence required for business acceptance.
The goal is not to complete a theoretical target operating model in isolation. It is to give the programme enough business direction to make sound design commitments.
What Finance should decide before ERP implementation
The following areas should be treated as connected decisions. Each one affects requirements, configuration, data, controls and the work that remains outside the ERP.
| Decision area | Finance should decide | ERP consequence |
|---|---|---|
| Operating model | Where work will be performed, who remains accountable and how Finance supports the business | Roles, workflow, organisational structures and service boundaries |
| Process ownership | Who owns Record-to-Report, Procure-to-Pay and Order-to-Cash across functional hand-offs | Design authority, exception routing and end-to-end acceptance |
| Financial controls | Which risks require prevention, approval, detection or review | Access, segregation of duties, approval rules and control evidence |
| Management information | Which decisions reporting must support and at what level of detail | Chart of Accounts, dimensions, data model and reporting architecture |
| Data ownership | Who owns master data, quality rules, remediation and ongoing stewardship | Migration scope, validation, interfaces and operating responsibilities |
| Integration boundaries | Which system owns each record and where business responsibility crosses systems | Interface design, reconciliation, monitoring and recovery |
| Acceptance | What must be proven before Finance accepts the service | Test scope, exit criteria, cutover gates and stabilisation measures |
On narrower screens, scroll the table horizontally to view all columns.
Set the target Finance operating model
Decide how Finance will be organised, which services will be centralised or retained locally and how the function will support operational and strategic decisions. Make accountability explicit across Finance, the wider business and any shared-service or outsourced providers.
The operating model should be detailed enough to expose consequences for roles, workflow, service levels, capability and governance. It should not be reduced to an organisation chart.
Name end-to-end process owners
Record-to-Report, Procure-to-Pay and Order-to-Cash cross organisational boundaries. AP may depend on Procurement and receiving teams. AR may depend on commercial policy, customer data and dispute resolution. Financial close may depend on operational submissions and consolidation adjustments.
Name the person accountable for the whole process, not only the Finance activity inside it. Process owners should be able to resolve design conflicts and accept the future process on behalf of the business.
Define controls before automating them
Financial controls should reflect the risk, the decision and the evidence needed. Determine where preventative controls are required, where review is appropriate and which exceptions need escalation.
Separate the authority to prepare, approve, post and release transactions. Decide how segregation of duties will work in the future organisation, including privileged access and emergency procedures. A workflow is not automatically an effective control simply because it is configured in the ERP.
Start reporting design with decisions
Management reporting requirements should describe the decisions leaders need to make, the frequency of those decisions and the level of detail required. This helps distinguish useful information from reports that are reproduced because they exist today.
The Chart of Accounts is part of this design, but it is not the whole reporting strategy. Legal, statutory, management and operational views may require dimensions, hierarchies, consolidation rules and data from outside the core ERP.
Assign data ownership and integration responsibility
Finance should know who owns suppliers, customers, products, cost centres, projects, bank details and other data that affects financial processing and reporting. Ownership includes defining quality rules, authorising change and resolving defects.
Integration boundaries also need business ownership. If Procurement creates a supplier and the ERP holds the financial record, the hand-off still belongs to an end-to-end process. The Procurement Transformation and Finance designs should agree how supplier decisions, purchase commitments, receipts, invoices and payment controls connect.
Turn Finance decisions into ERP requirements
ERP requirements should explain the business outcome, the rule that governs it and the evidence needed to show that it works. A list of desired features is not enough.
For example, a requirement for journal approval should identify who may prepare and approve different journal types, which thresholds or circumstances change the route, what supporting evidence is required and how the completed decision will be reviewed.
Requirements should also identify work that belongs outside the ERP. Consolidation, planning, treasury, tax, billing, procurement or specialist operational platforms may remain part of the landscape. The programme needs a deliberate boundary, not an assumption that every Finance activity will move into one system.
Prioritise requirements by business consequence. Statutory reporting, financial integrity and critical operational processing are different from presentation preferences. This distinction becomes important when time, cost or platform constraints force choices.
Use ERP selection to test the operating model
ERP selection should test how well each option supports the intended Finance model, not invite the product demonstration to define that model.
Use representative end-to-end scenarios. Follow a supplier change through purchase, receipt, invoice, payment and accounting. Follow a customer dispute through credit, collection, adjustment and reporting. Follow a close issue from source transaction to consolidation and management explanation.
These scenarios reveal the work performed across systems, the data needed and the exceptions that require judgement. They also show where standard capability is sufficient, where process change is needed and where customisation would create lasting complexity.
Commercial evaluation should consider the full delivery and operating model. Licensing is only one component. Integration, data, controls, support, release management and internal capability all affect the cost and risk of the decision.
Keep business design authority on the client side
A system integrator can bring platform knowledge, implementation capacity and delivery discipline. It should not become the default owner of Finance policy, operating-model decisions or business acceptance.
Client-side governance should identify who can approve designs, who resolves cross-functional issues and which decisions must return to the CFO, Finance Director or programme board. Decision logs should record the business rationale, affected processes and consequences for data, controls and readiness.
Design authority also needs independence from vendor and integrator incentives. A recommendation to adopt standard functionality may be sound, but Finance should understand which business choice it requires. A request for customisation may be justified, but the owner should understand its cost, control and upgrade implications.
This is where independent operating-model design and programme leadership can protect the connection between the target function and the configured solution.
Protect financial integrity through migration and reconciliation
Migration is not complete when data has loaded. Finance needs evidence that the opening position is complete, accurate and usable for the processes that follow.
Agree migration principles early. Decide which historical data will move, which records will remain accessible elsewhere, how open transactions will be treated and which data must be cleansed before loading. Assign owners for source extraction, transformation rules, validation and defect resolution.
Reconciliation should connect the source, transformation and target. It should explain differences rather than only confirm that totals match. Balance-sheet positions, open AP and AR, fixed assets, tax balances, commitments and other material populations may require different evidence.
Repeated rehearsal matters. Each cycle should improve data quality, timing, ownership and the quality of reconciliation evidence. Persistent manual adjustments should be visible to the readiness decision, not hidden as implementation activity.
PearsonGoldman's Finance and ERP modernisation experience connects migration and reconciliation with process, integration, UAT and business readiness across distinct enterprise-system contexts.
Make testing prove business acceptance
Technical testing can show that an interface runs or a configuration behaves as specified. Finance still needs to prove that end-to-end processes, controls and reporting operate with representative data and real organisational roles.
UAT should follow business scenarios and exceptions. Test rejected approvals, duplicate requests, incorrect master data, late adjustments, failed interfaces and period-end pressure. Confirm what evidence is produced and whether the responsible person can understand and act on it.
Business acceptance criteria should be agreed before execution. Defects need clear severity rules linked to financial or operational consequences. A high pass rate can be misleading if the unresolved failures affect close, payment, billing, reporting or statutory obligations.
Acceptance belongs to authorised business owners. The delivery partner can support evidence and resolution, but it should not accept the service on Finance's behalf.
Treat cutover as operational readiness, not an IT event
Cutover brings technology, data, people, controls and operational continuity together. Finance needs to understand what will stop, what will continue, which transactions will be restricted and how critical decisions will be made during transition.
Readiness evidence should cover trained users, access, process ownership, reconciled data, reporting, support, interfaces and outstanding defects. It should identify any manual workarounds, their control treatment, owners and planned removal.
The go-live decision should state the residual risk being accepted. A timetable or technical completion percentage is not enough. Leaders need to know whether Finance can operate, close, report, collect, pay and control the business from the first live period.
A focused Transformation Discovery can help establish the decisions and evidence required before a platform or implementation commitment is made.
Keep stabilisation and benefits in the transformation scope
Go-live is the start of the live operating model. Finance will need to resolve defects, support users, complete early close cycles and confirm that controls operate as designed.
Stabilisation should distinguish temporary transition issues from structural design gaps. Repeated journals, spreadsheet reconciliations, delayed reports or growing exception queues may show that the process, data or ownership model needs attention.
Benefit ownership should remain with named business leaders. Faster close, better working-capital information or released capacity will not arise from technical deployment alone. Each benefit should connect to a process change, adoption measure and operational outcome.
Measure the whole outcome. A faster transaction is not progress if review effort, rework or control risk increases elsewhere. Finance and ERP performance should be considered together through the early live periods.
What leaders should require before approving implementation
The approval pack should show a connected chain from Finance strategy to operating model, process, controls, information, data, requirements and delivery evidence.
Leaders should be able to see which decisions are settled, which remain open and who owns each one. They should understand where standard ERP capability supports the design, where integration is required and where the organisation is accepting complexity.
The programme should also provide credible migration, reconciliation, testing, cutover and support plans. Those plans need acceptance criteria and named business owners, not only dates and activities.
Can Finance explain how the future function will operate, and can the programme show that the proposed ERP design supports it?
If the answer is unclear, the next step is not automatically more configuration. It is to resolve the operating decision that the technology is being asked to carry.
ERP can enable Finance Transformation. It creates value when business design, financial integrity and accountable delivery remain in control of the implementation.
Editorial note
This article provides a business-transformation perspective, not accounting, legal or regulatory advice. ERP capabilities and implementation approaches vary by product, version, configuration and delivery context.