Implementing finance ERP modules: a CFO and controller's guide

The economics are unforgiving. McKinsey's dataset shows every extra year a large IT project runs adds roughly 15% to its cost overrun, and 17% of large IT projects go so badly they threaten the existence of the company. McKinsey documented one bank that brought its finance department into the transformation only a few months before go-live. The late accounting-module changes that followed delayed the launch by more than 3 months, at a cost of more than $8 million.

The public sector shows the same pattern at scale. The U.S. Government Accountability Office found the Navy had largely wasted about $1 billion on four separate ERP pilot efforts, with the failures traced to weak discipline in requirements, testing and data conversion.

The sharpest exposure is your own numbers. When controls get bolted on late, the audit finds the gap, and a material weakness is public. Deloitte's count of the material weaknesses disclosed over the past 12 months shows the same three roots again and again, and a finance ERP built without controls in mind makes each one more likely.

A big-bang implementation takes all modules and units live on one date. A phased approach sets several smaller go-live dates by module, by entity or by geography. Big-bang is faster and cheaper when it works, and it removes the cost of running legacy and new systems in parallel. It also removes your safety net.

For finance the deciding variables are the number of legal entities, the number of statutory and tax regimes, and whether you can roll back. Rollback in finance is rarely a clean switch back. More often it means delaying go-live, extending dual-running, or running a controlled contingency until you can try the cutover again.

The chart of accounts is the one decision that touches every module, every report and every close for the next decade. The failure pattern is well documented. Companies expand the chart over time by encoding product, region and location into accounts, and end up with an unwieldy structure that slows the close and produces data-quality issues that can lead to misstatements. The fix is to keep the natural-account list short and push managerial detail into dimensions.

In Oracle those dimensions are chart-of-accounts segments, each with a value set and a segment label, and up to three balancing segments for legal and management views. In Workday they're worktags. Account posting rules map worktags to the ledger account behind the scenes, so a clean worktag design decides whether you get correct postings or a mess you can't unwind.

Two constraints decide the design. You can't budget below the level of your chart of accounts, so any dimension you want to control has to exist as a segment or worktag. And the design has to survive reorganizations and acquisitions, so segments need room to grow. A chart of accounts is only as good as the organization's ability to govern it, which is why the governance body should include controllership, FP&A, tax, compliance and technology.

Data readiness means ownership, quality thresholds and reconciliations that work every time you run them. A finished migration on its own proves none of that. Finance conversion objects typically include the chart of accounts and hierarchies, suppliers and customers, open AP and AR items, open orders, fixed assets, bank balances, and historical balances for comparatives.

The first real decision is what you convert and what you archive. Most finance conversions load trial-balance opening balances and open subledger items, keep limited comparative history live, and hold full history in an accessible archive instead of migrating years of transactions.

Reconciliation has to be engineered and repeatable: control totals for counts and amounts, subledger-to-GL balance tie-outs, and sampling for high-risk objects such as bank accounts, supplier bank details and customer credit data. Prove it through mock conversions with rising bars. Early mocks prove the extraction logic, middle mocks prove completeness and reconciliation, and late mocks simulate the real cutover sequence and timing.

The bar is at least two successful mock conversions. In practice finance should target three, with the final mock under a 2% error rate and control totals reconciled to the dollar before anyone calls the data ready for go-live.

All too often, controls are an afterthought in ERP design, and finance teams believe they can improve system controls later. They can't do it cheaply, and the audit finds the gap. Over the past 12 months, 61% of companies disclosing a material weakness had a technology component in it, and material weaknesses tied to IT general control failures have risen every year since 2021.

Segregation of duties has to be designed in. Reporting on it after the fact is too late. Engineer out the classic conflicts: supplier-master maintenance against invoice entry against payment release, customer credits and refunds, manual journal posting, and configuration changes. Grant least privilege and avoid broad super-user roles for convenience. Automated controls can be relied on only when the underlying IT general controls work, so bring your external auditor into the design while it can still change.

The first month-end close after go-live is the highest-risk event in a finance ERP program. It compresses every weakness into a fixed deadline. Cutover is the moment the program stops being a project and becomes the operating backbone of the business, and the safety net disappears. It fails when it's treated as a weekend task list owned by IT, and it works when finance and IT lead it jointly as a controlled operational event.

Run at least two full cutover rehearsals, one earlier to prove sequencing and one later to simulate the real timing and staffing. Add a rehearsal close: run the close calendar and produce the close pack on the new reporting architecture before go-live.

For the first close, build a calendar more detailed than your steady-state target, reconcile the close-critical accounts early, and run a close control tower, which is a daily meeting chaired by controllership. Excess manual journals in a first close are normal. Unmanaged ones become permanent. Hypercare should end when the operating model can absorb issues through normal support, and only after the first close completes successfully. The period ending on the calendar doesn't count.

Separate what ships from what's announced. As of mid-2026, the strongest AI is in assistive and embedded features, and autonomous agents are mostly still on roadmaps. Microsoft's Finance in Microsoft 365 Copilot reached general availability in October 2025 with financial reconciliation, while variance analysis remains in preview. SAP has shipped general-availability finance features such as AI-assisted payment-advice processing.

Several headline agents haven't shipped. Workday's three Illuminate for Financials agents were announced for availability in 2026, and Oracle's finance agents for payables, ledger, planning and payments are described as planned. Microsoft's own account-reconciliation agent inside Dynamics is a production-ready preview the vendor has to activate manually, and it recommends actions on a narrow set of exceptions. It doesn't close the books unattended.

The adoption data says be selective. Gartner found finance AI adoption rose from 37% in 2023 to 58% in 2024, then flattened at 59% in 2025, and named data quality and data literacy as the biggest obstacles. The most common finance use cases are knowledge management at 49%, accounts-payable automation at 37%, and error and anomaly detection at 34%.

The cautions come from the same analysts the vendors quote. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 on cost, unclear value and weak risk controls. An MIT study found that 95% of enterprise generative AI pilots delivered no measurable return, a figure Workday itself cites. AI in finance ERP is genuinely productive at reading, extracting, matching, explaining and drafting. At deciding and posting unattended it's still mostly a promise. Every vendor keeps a human on the approval step, and so should you.

Across stalled programs, the fixes keep coming back to governance, ownership and authority. The best-documented turnaround makes the point. A country CFO took over a multi-year ERP program that had spent its budget and launched a single pilot entity. The fixes were structural. The program lead was made to report directly to the group CFO, which gave the authority to move fast, and a template committee including local CFOs had to approve changes above a threshold.

Those two changes cut program duration by around 30% and saved double-digit millions, with no new software and no added headcount. Authority compresses schedule, and schedule is money. Every extra year a large program runs adds roughly 15% to its cost overrun (account 1100), so governance is the one lever that buys years back.

Go-live is where the value story starts. Many programs get trapped in hypercare and keep postponing the changes that deliver the case: retiring manual work, tightening controls, speeding up the close and improving working capital. Protect the core in the first 60 to 90 days, then go after the value levers. Reduce manual journals by removing root causes, raise straight-through processing in AP by cutting match exceptions, and improve cash-application match rates.

Decommission the legacy reports, duplicate interfaces and shadow spreadsheets on a defined timeline. If you leave the old tools available, people will use them under pressure and adoption slides back.

The number to move is days to close. APQC puts top-quartile finance teams under 5 days to close the monthly books, the median at 6.4 days and the bottom quartile at 10 days or more. A finance ERP that doesn't shorten the close hasn't paid for itself.