The close that took 5 days now takes fifteen. And a number the board already saw has to be walked back.
That is how a finance ERP fails. Not with an outage, but with a slow close and a restated slide. Neither is a technology problem. They are ownership, design, and sequencing problems, and they belong to finance.
The finance modules are where an ERP program's risk concentrates. Payroll has to run. The books have to close. Auditors have to sign. Every other function can absorb a rough go-live with workarounds. Finance cannot, because the first month-end close lands on a fixed legal deadline whether the system is ready or not. So this guide walks the stack module by module: the items to get right, the places each one quietly breaks, and one concrete Workday or Oracle detail per module. The discipline is identical on SAP or anything else. The field notes are mine, anonymized.
A finance ERP is not an IT purchase with a finance user. It is a finance program with an IT component. If you treat it as the former, you inherit the 70% outcome. Own the decisions that belong to finance, prove readiness with numbers, and treat the first close as the real go-live.
1. Every extra year a large IT project runs costs real money
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 forced 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 failures traced to weak discipline in requirements, testing, and data conversion.
The sharpest exposure is not cost or time. It is your own numbers. When controls get bolted on late, the audit finds the gap, and a material weakness is public. Over the past 12 months, 61% of disclosed material weaknesses carried a technology component, and the roots behind them repeat.
Put the controller and a finance program lead on the steering committee with named accountability from day one, not as reviewers who see the design after the implementer has frozen it.
The reporting layer lies about its own size. On one program, 400 critical legacy reports collapsed to 90 once we checked them against the actual run logs. Nobody asked for the other 310 again. Finance teams routinely carry forward a reporting footprint no one has validated, then pay to convert and rebuild all of it.
2. Pick the deployment shape before you pick anything else
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 decisive variables are the number of legal entities, the number of statutory and tax regimes, and rollback feasibility. Rollback in finance is rarely a clean switch back. More often it means delaying go-live, extending dual-running, or executing a controlled contingency until you can reattempt the cutover.
Sequence your waves by business-model similarity and legacy state, and take one genuinely complex entity early so the hard lessons are cheap to reuse rather than expensive to discover at scale.
One workstream nearly took the whole date down. On a large program this year, one data conversion ran so far past its window it nearly pushed go-live and blocked the first payroll run. In a big-bang, that single slip is the whole enterprise. Scope your approach to the workstream most likely to run long.
3. Design the financial data model before you touch a module
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 of accounts 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 are worktags: cost center, spend category, revenue category, region, project. Account posting rules map worktags to the ledger account behind the scenes, so a clean worktag design is the difference between correct postings and a mess you cannot unwind.
Two constraints decide the design. You cannot 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.
Redesign the chart of accounts. Do not lift and shift the old one into the new system. Lifting it forward imports every workaround you have accumulated and wastes the one clean-slate moment you get.
The dirt is worse than discovery admits. On a recent program, 10% of the active worker records were duplicates or carried termination dates that contradicted payroll history. That is payroll-tax and compliance exposure, not a spreadsheet problem. Master data quality is a controllership issue, and it surfaces the moment you try to convert.
4. Nine modules, and four or five decisions inside each
This is the core of the scope conversation. Each finance module has four or five decisions that determine whether it works. Get those right and the rest is configuration. Miss them and you buy a permanent tax of exceptions and manual work. The map below is the one-page version. The detail follows.
General Ledger and ledger design
Beyond the chart of accounts, the decisions are the ledger and book structure and how postings are controlled. Define primary and secondary ledgers and the reporting currencies each entity needs, and decide the multi-book strategy so statutory, GAAP, IFRS, and tax views run in parallel. In Workday every transaction carries a book code, and operational transactions post to a common book, which lets you keep multiple accounting bases without duplicating data. In Oracle, the Subledger Accounting engine generates journals from Payables, Receivables, Assets, and external feeds against a rules repository, so the subledger-to-GL logic is itself a design decision. Watch for over-engineering the ledger, and for subledger-to-GL rules that no one fully owns.
Financial Close and Consolidation
Get the consolidation structure and elimination logic right, the currency translation rules by rate type with a defined cumulative translation adjustment, intercompany matching with disciplined partner-entity tagging, and close-task orchestration with owners and dependencies. Workday close delivers intercompany eliminations, non-controlling interest, equity pickup, and retained-earnings calculations in real time. Oracle's Financial Consolidation and Close lets you override translation rules per account. Watch for intercompany that never nets to zero because partner data is not captured at the source.
Accounts Payable and Procure-to-Pay
Govern the supplier master with deduplication and an approval workflow for new suppliers and bank details. Set the matching level, two-way to PO, three-way adding the receipt, four-way adding inspection, at the PO shipment and vary it by supplier or category. In Oracle, out-of-tolerance invoices take a matching hold that blocks payment until released, and bulk-loading through File-Based Data Import without validating holds can auto-create payees you did not intend. This is the module where AI is most mature, and where it is worth measuring your straight-through rate against best-in-class teams, who process invoices touchless at more than twice the rate of their peers.
Accounts Receivable and Order-to-Cash
Define transaction types by class and the accounting rules that derive the GL accounts for each. Load remit-to, tax, and derivation data before go-live: Oracle's AutoInvoice rejects any invoice where it cannot derive a remit-to address, so that setup is a hard prerequisite. Set receipt application and cash-matching rules and the collections strategy, and watch for unapplied and on-account cash piling up because the matching rules are weak.
Fixed Assets
Keep the GAAP and tax books separate, each with its own depreciation method, convention, and life. Workday Asset Books and Oracle Assets both hold a corporate book and independent tax books, and in Oracle capital-project costs collected in Project Costing transfer into Assets as asset lines. Watch for the two books drifting apart because in-service dates were set inconsistently at conversion, and for legacy assets migrated with wrong accumulated depreciation.
Cash Management and Treasury
Confirm the bank statement formats and delivery for every bank, commonly BAI2 or SWIFT MT940, and set the auto-reconciliation matching rules and rule sets per bank account. Oracle supports one-to-one, one-to-many, many-to-one, many-to-many, and zero-amount matching. Set amount and date tolerances so near-matches clear without manual review, and watch for a low auto-match rate that dumps volume onto the team.
Expenses
Decide which policy rules warn and which hard-stop. Oracle lets each expense-type policy either warn the user or block submission, with warning and error tolerances, plus receipt-requirement rules, corporate-card cash limits, and an Audit Expense Report role. Watch for policies set to warn everywhere, so nothing actually blocks, and for card-feed mapping errors that create unmatched transactions.
Tax
Decide native versus third-party. Oracle Fusion Cloud has certified integrations with Vertex, Avalara, and Thomson Reuters ONESOURCE, and Workday integrates with the same engines. If you use a partner engine, the regime-to-rate setup, the business-unit subscription, the partner registration, and the master jurisdiction data all have to be in place. Watch for missing jurisdiction data, and for partner-setup gaps that make tax silently fail to calculate at go-live.
Projects and Revenue Recognition
Set the project types so capital projects accumulate construction-in-progress and transfer to Assets while billable projects flow to billing and revenue. Configure the ASC 606 5-step model explicitly, and separate billing from revenue with standalone selling prices for multi-obligation contracts. Oracle Revenue Management creates the contracts and performance obligations and recognizes at a point in time or over time. Watch for conflating billing with revenue: you may bill four milestones of 250,000 dollars each but recognize the full million only when the obligation is satisfied.
Insist the implementer configure each module against your actual policies, not the demo defaults. The demo runs on clean data and vendor-favorable assumptions. Your tolerances, your matching levels, and your policy hard-stops are where the value and the risk live.
No owner, so the loads kept failing. On one program, finance and procurement data loads kept failing during conversion. The cause was not the software. No single person owned the validation rules across the modules, so every team assumed another had it. We named one owner, gave each item a date, and the failures stopped. The fix cost nothing.
5. Convert the data, then prove it to the dollar
Data readiness is not migration completed. It is ownership, quality thresholds, and reconciliations that work repeatedly. 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 versus what you archive. Most finance conversions load trial-balance opening balances and open subledger items, keep limited comparative history live, and retain full history in an accessible archive rather than 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, and in practice finance should target three, with the final mock landing under a 2% error rate and control totals reconciled to the dollar before the data is called go-live ready.
Set a numeric conversion gate in the plan: named reconciliation owners, a minimum tie-out success rate, and a maximum error threshold that must be met before go-live is approved. Make it a go or no-go criterion, not a status color.
6. Build the controls in, not after
All too often, controls are an afterthought in ERP design, and finance teams believe they can improve system controls later. They cannot 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, not reported after the fact. Engineer out the classic conflicts: supplier-master maintenance versus invoice entry versus 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, not the post-mortem.
Make the auditor's acceptance of the segregation-of-duties model and the evidence approach a named go-live gate. If provisioning and recertification are weak, the ERP becomes a recurring audit finding no matter how good the workflows are.
One unowned security call stalled the whole test cycle. I once watched an end-to-end testing cycle stop for a full week because one security role exposed compensation data far wider than intended. Every test script that touched pay had to pause. The build was fine. The design decision was not.
7. Rehearse the close before you trust it
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 is treated as a weekend task list owned by IT. It succeeds when it is a controlled operational event led jointly by finance and IT. 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: a daily meeting chaired by controllership. Excess manual journals in a first close are normal. Unmanaged manual journals become permanent. Hypercare should end when the operating model can absorb issues through normal support, and specifically only after the first close completes successfully, not when the calendar says the period is over.
Schedule go-live to a clean period boundary with real runway before the first close, and make "first close completed successfully" the exit criterion for hypercare rather than a fixed number of weeks.
8. What AI actually does in finance today
Separate what ships from what is announced. As of mid-2026, the strongest AI is in assistive and embedded features, not autonomous agents. 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 are roadmap: 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 must activate manually, and it recommends actions on a narrow set of exceptions rather than closing the books unattended.
The adoption data says be selective. Gartner found 59% of finance functions used AI in 2025, essentially flat from the year before, 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. It is still mostly a promise at deciding and posting unattended. Every vendor keeps a human on the approval step, and so should you.
Treat AI agents as a governed part of scope with their own access design and audit trail, and fund them on a consumption model with a cost cap. Do not put an un-shipped agent on the critical path for the close. Pilot one bounded, high-volume process, use the vendor's native capability, and measure the result before you widen.
9. Most of the fixes have nothing to do with the technology
The recurring truth across stalled programs is that most of the fixes have nothing to do with the technology. They are 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 changes cut program duration by around 30% and saved double-digit millions. No new software, no added headcount. The lesson generalizes: authority compresses schedule, and schedule is money. Recall the economics from earlier in this guide, where every extra year a large program runs adds roughly 15% to its cost overrun. Governance is the one lever that buys years back.
Put the program's reporting line into the CFO's office and give finance the authority to approve scope changes above a threshold. Authority, not enthusiasm, is what moves an ERP program.
10. After go-live: the value you actually signed up for
Go-live is the start of the value story, not the end. Many programs get trapped in hypercare forever and postpone the changes that actually deliver the case: retiring manual work, tightening controls, accelerating the close, and improving working capital. Protect the core in the first 60 to 90 days, then pursue the value levers. Reduce manual journals by removing root causes, increase 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, because if you leave the old tools available, people will use them under pressure and adoption regresses.
Attach the business case to named KPIs with a baseline, a target, and a reporting cadence: days to close, AP straight-through rate, days outstanding, and manual-journal volume. A benefit no one measures is a benefit no one delivers.
The red flags to run before every gate review
The software vendors are competent and the implementers are capable. What they cannot do is decide how your finance function should work, and that is precisely the decision that determines whether you land in the 70% that miss or the minority that get the value.
Own the decisions, not just the invoice
A finance ERP program is a sequence of decisions that belong to the CFO and the controller. Which modules, in what shape, on what data model, converted to what standard, controlled how, closed how, and measured against what. Make those calls early, prove readiness with numbers, and treat the first close as the real go-live. The rest is configuration.
Related: implementing payroll, data conversion and integrations, Workday pricing and total cost of ownership, and negotiating with your System Implementer.