Finance-specific lessons from our own Workday rollout

A short note on context. This was a Workday Finance and Projects rollout for a small professional services firm with multiple entities, multi-currency revenue, and an existing Adaptive Planning footprint. The lessons below are the ones that depend on those finance specifics. The generic project lessons (discovery, capacity, governance, change) are in our consolidated go-live article; assume those still apply on top of these.

Lesson 1: The chart of accounts decision is the design choice that locks you in hardest

Of every design decision in a Workday Finance rollout, the chart of accounts and the worktag model is the one that bites longest if you get it wrong. Workday's COA is dimensional rather than concatenated, which is genuinely useful, but it tempts teams into modelling every reporting dimension as a worktag. The trap: every worktag added is a worktag that has to be entered, defaulted, validated, and reported on for the life of the tenant. We trimmed our initial worktag list by about a third in design after asking, for each one, "what report depends on this and is there no other way to get it". Spend the days on this in design that the methodology says you do not have. There is no equivalent design decision in an HCM rollout that is this expensive to revisit.

Lesson 2: Intercompany flows are where small firms underestimate themselves

If you have more than one entity, you have intercompany. Even small services firms with two or three legal entities and some cross-border recharging have more intercompany complexity than they think. The questions that matter early: which entity raises the invoice in which currency, how is the recharge calculated, which intercompany pairs need eliminations on consolidation, and how are the eliminations posted (manual journal vs delivered intercompany functionality). Pick the answers in design, not in test, because the configuration ripples through your books, your tax positions, and your Adaptive model. We thought we had a simple intercompany model. We did not. Two entities, multi-currency, one recharge stream, and we still needed three working sessions to get the flows mapped.

Lesson 3: Period close mechanics need a dry run, not just a UAT script

An HCM rollout is tested with transactions. A Finance rollout has to be tested with a close. The set of activities that happens at month-end (revenue recognition runs, accrual reversals, FX revaluation, intercompany eliminations, allocation runs, consolidation, reporting pack generation) is not adequately covered by a typical UAT script that walks one transaction at a time. We ran a mock period close end to end in the test tenant, with real opening balances, two months of transactions, and an actual close calendar. It surfaced four issues that would have hit our first live close. Build the mock close into the project plan deliberately. The Launch methodology timeline does not always carve out room for it.

Lesson 4: Adaptive integration is its own workstream

If you use Adaptive Planning (and most Workday Finance customers do), the integration between Financials and Adaptive is its own design problem, not a tail-end task. Two decisions in particular: how often actuals push to Adaptive (daily, weekly, end-of-period), and which dimensions in Workday map to which dimensions in Adaptive. Mismatched dimensionality between the two is the single most common reason Adaptive reports look subtly wrong after a Workday go-live. We had a working Adaptive instance before the Workday rollout, which made the migration of the model harder, not easier. The lesson: treat the Adaptive integration as a parallel workstream with its own design, build, and test phases, not as a config item in the last sprint.

Lesson 5: Launch methodology does not always fit a finance rollout

This is the lesson we are most willing to be specific about. Launch methodology is built around HCM rollouts where the design space is well-bounded and the templates do most of the heavy lifting. A finance rollout has more design questions per square inch (COA, worktag governance, intercompany, revenue recognition, project costing, allocations) and benefits less from a template-led approach. We saw the Launch templates work cleanly for the parts that are genuinely standard (basic AP, simple AR, a vanilla expense workflow) and start to push back on the parts that were not. The honest read: Launch is the right methodology when your finance model maps neatly onto the templates and the wrong one when it does not. Decide that in partner selection, not after the SOW is signed. If your partner's main offering is Launch and your finance model has any of the complexities above, that is a conversation to have before you sign.

Lesson 6: Finance change management is different in shape from HR change management

The generic go-live article makes the case for treating change management as a track from kick-off, and that still applies. What is different in finance is the audience and the timing. HR change management lands on employees in a wide, shallow wave. Finance change management lands on a narrow, deep audience (AP team, AR team, FP&A, controllership, audit) where each individual has a job that depends on the old system working in a specific way. The training is heavier per person, the parallel-run period matters more, and the first live close is the moment of truth in a way no single HR transaction equivalent really is. Plan a structured parallel run and a stiffened support model for the first close, not just for the first week after go-live.

What we would do differently on the next finance rollout

If we did it again, we would invest three things harder up front. A two-week design sprint dedicated specifically to the chart of accounts, worktag model, and intercompany flows, before any configuration begins. A dedicated Adaptive workstream from kick-off rather than a tail-end integration task. And a partner conversation, in writing, on methodology fit: which parts of our finance model their template-led approach covers cleanly and which parts will need a different design approach. None of those would change the price meaningfully. All of them would shorten the project.