What Finance Workflow Should CFOs Automate First After ERP Go-Live?
AP is the default first workflow to automate. It isn't always right. The correct first choice is whichever workflow is stable enough to govern.
You want automation that actually sticks. One workflow that gets faster, more controlled, and stays that way, proof that the ERP investment can deliver what the vendor deck promised. Not another pilot that runs well for a quarter and then quietly breaks in the middle of a close.
The generic starting point everyone recommends is AP invoice processing. It is recurring, document-heavy, rules-based, and connected to visible inputs. Most finance automation guidance starts there, and for good reason.
But "AP is usually the right starting point" is not the same as "AP is your right starting point." The right first workflow is the one that is clear enough to route, review, approve, and document without weakening control, and that may or may not be AP. For some businesses, a close-pack bridge, a reconciliation exception queue, or an accrual request workflow will be better prepared for automation support than AP is.
The question is not which workflow sounds most automatable. It is which workflow is actually ready. That is where CFO workflow services become useful: the workflow gets assessed before anything is built around it.
In Short
- AP invoice processing is the common default starting point, but treat it as a candidate, not an answer.
- The right first workflow is the one where source data, ownership, handoffs, exceptions, approvals, and evidence are already visible and stable.
- A workflow that fails on any of those dimensions is not ready for automation. It is ready for inspection.
- The first decision after inspecting a workflow is explicit: build, defer, or look at a different workflow first.
Who This Is For
This article is for CFOs, controllers, FP&A leaders, and finance teams whose ERP is live and who are now deciding which finance workflow to build automation support around first. It is especially relevant for teams who have been told "automate AP" without a clear explanation of how to know whether AP, or anything else, is actually ready.
Why ERP Go-Live Does Not Answer the Automation Question
ERP implementation makes the system of record live. It does not decide which workflows are ready for automation support. Those are two different questions.
After go-live, a finance team may still have open questions about which export or report starts a given workflow, who owns the input, where the data leaves the ERP, which exceptions need judgment, who approves the output, and where the evidence sits once the number is released. When those questions are unanswered, automation does not help. It moves the confusion faster, adds another layer on top of an unstable foundation, and produces the same fragile output, just more quickly.
Oracle NetSuite's CFO automation guidance makes the point in the other direction: it lists AP processing, financial reporting, close and consolidation, cash flow management, and FP&A as finance automation use cases, but also notes that finance leaders should map high-volume, burdensome, expensive, or risk-prone processes before choosing where to focus (Oracle NetSuite, CFO automation guide). That mapping step is the one most teams skip. They read the use case list and pick a workflow based on what sounds right. The workflow breaks in the first cycle because the source data was unclear, or the exception logic was never agreed, or the approval path was assumed rather than designed.
The mapping has to come first. For a full explanation of how to make your finance workflow visible before automating any part of it, see Why Finance Is Still Manual After ERP Go-Live.
The Wrong Way to Choose
There are three common traps, and all three lead to the same place: a workflow that has been automated before it was understood.
The first trap is starting with the noisiest workflow. The workflow that generates the most complaints may be a real bottleneck, but noise is not readiness. A workflow can be genuinely painful and still be too unstable to automate safely.
The second trap is starting with the workflow that looks easiest. An easy automation often means a low-stakes workflow. A neat demonstration is not the same as a meaningful result.
The third trap is starting with whatever the tool already supports. That makes the tool the strategy instead of the finance decision. Tools should support a workflow the finance team has chosen and understood. They should not determine which workflow gets chosen.
The better question is narrower: which recurring workflow is both important enough to matter and stable enough to support?
What "Ready" Actually Means
A workflow is ready for automation support when seven conditions are met.
The workflow repeats on a defined cycle: monthly, weekly, or every forecast cycle. The source data is visible and accessible, not manually reconstructed or disputed each period. The owners are named: preparers, reviewers, exception owners, approvers, and the person who releases the final output. The handoffs are repeatable, not different every cycle depending on who is available.
The exceptions are known and routable, not a fresh category of problem each period. The approval points are named human approvals that can be captured and preserved. And the evidence (support files, comments, version history, final output) can be kept alongside the workflow rather than scattered across inboxes.
A workflow that fails on source data, ownership, or approval points should not be automated. It should be inspected and stabilised first. Automating a workflow with unclear ownership does not make ownership clearer. It makes it invisible.
McKinsey's 2024 CFO survey found that nearly all surveyed finance functions had invested in digitisation and automation, and that many were still early in realising value, with workload, capability gaps, and resource constraints as the primary barriers (McKinsey, CFO perspectives on the future of finance). The pattern behind that finding is consistent with what I've seen in practice: investment without readiness assessment produces activity, not improvement.
The Candidate Workflows
These are the finance workflows most commonly worth inspecting first after ERP go-live. None of them should be automated by default.
| Workflow | Build when | Defer when | Keep human |
|---|---|---|---|
| AP invoice processing and approval routing | Invoice sources, PO or receipt matching, approval owners, exception types, and payment-status handoffs are clear | Vendor data, PO rules, receiving records, or approval authority are disputed | Exception judgment, payment release decisions, and material approvals |
| Close-pack bridge | Actuals source, workbook logic, owners, and approval path are repeatable | The close pack changes every cycle or definitions are still being redesigned | Final release, judgment-heavy adjustments, and commentary |
| Reconciliation exception queue | Exception types are known and reviewers are named | Exceptions are poorly classified or source data is disputed | Material exception approval |
| Forecast actuals refresh | Actuals source, timing, and mapping are stable | Forecast model logic changes constantly | Forecast judgment, scenario interpretation, and final ownership |
| Accrual request workflow | Inputs, owners, due dates, and support files are repeatable | Business owners do not agree on what should be submitted | Accrual judgment and final posting approval |
| Billing exception review | Exception categories and approval path are clear | Root cause is upstream policy, pricing, or contract ambiguity | Customer-sensitive decisions and material approvals |
| Cash view update | Sources and timing are stable | Bank, ERP, and forecast inputs do not reconcile consistently | Liquidity interpretation and management messaging |
| Board-pack input | Inputs are finalised and ownership is clear | The pack is being redesigned or commentary ownership is unclear | Final narrative, judgment, and CFO sign-off |
The best first workflow is the one where manual control is visible, repeated, and worth preserving. Not the one with the largest spreadsheet or the loudest complaint.
Build, Defer, or Inspect Next
Here is the shortcut, if you need one before running the full test on every candidate: check source data and named ownership first. Of the seven readiness conditions, those two break the most workflows, and they break every later step with them. An unclear owner makes handoffs unrepeatable. Disputed source data makes the evidence trail worthless before it is built. Rank your candidates by those two variables alone, and you will usually find your starting workflow before you finish testing the rest.
That is a sequencing heuristic from repeated diagnostic work, not a scored model, and it should sharpen further as more engagement data accumulates. It tells you where to look first. It does not replace the full test below.
Once a workflow has been assessed, the decision should be made explicitly rather than assumed.
Build when the workflow is recurring, source data is accessible, owners are named, handoffs are repeatable, exceptions are understood, human approvals can be preserved, and the evidence trail can stay visible. These conditions mean the workflow is ready to support, and that support will make it faster and more controlled simultaneously.
Defer when source data is disputed, ownership depends on institutional memory, exception logic changes every cycle, or the process is being actively redesigned. Automating an unstable process does not stabilise it.
Inspect next when this workflow is not the real bottleneck. Sometimes the AP process is slow because the purchase order data is wrong, or the close-pack bridge is slow because the accrual inputs arrive late. When the selected workflow is downstream of the real problem, the better move is to inspect a different workflow before building anything.
This sequence prevents the most common automation mistake: building a fast, expensive layer around a process the finance team already knows is fragile.
What Should Stay Human
Automation should support finance judgment, not replace it. Whatever workflow is automated first, the following should remain with named people: source data stays visible to the finance team; exceptions route to named reviewers rather than disappearing into a queue; material approvals remain with named humans; final release decisions stay with finance leadership; and the evidence trail remains accessible after the workflow completes.
The goal is not to remove finance from the workflow. It is to remove the assembly work that gets in the way of the decisions finance should be focused on making.
FAQs
What finance workflow should CFOs automate first after ERP go-live?
The recurring workflow where source data, ownership, handoffs, exceptions, approvals, and evidence are already visible and stable enough to govern. That may be AP, a close-pack bridge, reconciliation exceptions, forecast actuals, accrual requests, billing exceptions, or board-pack inputs, whichever passes the readiness test.
Should finance automate AP first?
AP is a common and often appropriate starting point because it is recurring, document-heavy, and approval-driven. But it is not automatically the right first workflow. Test AP against the same readiness conditions as any other candidate before committing to it.
Why should CFOs avoid automating broken finance processes?
Automation moves a broken process faster without making it more controlled. If source data is disputed, ownership is unclear, exceptions change every cycle, or approvals are informal, automation locks in the instability and makes it harder to diagnose later.
What is the Manual Finance Control Layer?
The set of spreadsheets, exports, review steps, exception checks, email approvals, reconciliation routines, and sign-off decisions that finance performs outside the ERP before it trusts and releases a number. See Why Finance Is Still Manual After ERP Go-Live for the full diagnostic.
What should always stay human in finance automation?
Material judgment and sign-off. Automation can support data movement, task routing, exception visibility, review preparation, and evidence capture, but named humans should remain accountable for material approvals and final release decisions.
What It Looks Like When You've Got It Right
Your AP lead runs the exception queue on Monday morning. Three items need human review. She resolves two before lunch. The third routes to the controller with a deadline attached. By Thursday close, the queue is clear. The audit trail is there. You did not touch it.
That is one workflow, chosen because it was ready: the source data was clean, the ownership was named, and the exceptions were known before anyone built anything. Your team is not managing the process anymore. They are reviewing the outputs of it.
Everything after that first workflow gets easier. Not because the method is clever, but because you have a result your team can point to, proof that the ERP investment can deliver what it always should have, once the workflow around it was made visible first.
Start with One Workflow
The first step is not choosing what to automate. It is choosing what to inspect.
A Finance Workflow Diagnostic examines one recurring finance workflow across source data, ownership, handoffs, exceptions, approval points, and evidence trail, then returns a single clear recommendation: build, defer, or inspect a different workflow first. It typically runs 2–3 weeks and produces a workflow map, control-gap analysis, and prioritised improvement plan before any commitment to a larger build.