A payback-ranked map of nine finance workflows. Two almost always work: vendor onboarding and invoice coding. Two almost never do: forecasting and revenue recognition without clean data. For Heads of Finance evaluating an automation roadmap before buying tooling.
Every finance automation roadmap we are shown has the same shape. Forecasting at the top, because the board asks about it. Revenue recognition next, because the auditors asked. Then a long tail of accounts payable, accounts receivable and reconciliation work that nobody has ranked, because everyone assumes it is easy.
The roadmap is upside down. Across the finance teams we have worked with, in companies of 50 to 5,000 people and on ledgers from Xero to SAP, the workflows at the bottom of that list pay back in months and the ones at the top pay back late or not at all. Two almost always work: vendor onboarding and supplier invoice coding. Two almost never do at the first attempt: forecasting and revenue recognition, for the same reason every time.
What follows is the map we walk a Head of Finance through before anyone buys tooling: nine workflows ranked by how quickly they pay back, one reason each. The ranking is qualitative on purpose; the order is the point.
What does the payback map look like?
Four things decide where a workflow lands. How much volume runs through it. Whether the team can write the rule down today. Whether the inputs it depends on are already trustworthy. And how quickly a wrong output gets noticed, because a workflow that surfaces its own errors improves and one that hides them is abandoned. Scored on those four, this is the order we get.
- Vendor onboarding and master data. Bounded inputs, a form the team already uses, and a mispayment cost everyone in the room has felt. Duplicates and stale vendors flagged before they cause the problem.
- Supplier invoice coding. High volume, rules the team can already recite, and a wrong code that surfaces at approval or at the close. The feedback loop is short, so trust builds quickly.
- Bank reconciliation. Rules match the routine, a model handles the ambiguous middle, a person sees only what is left. The Friday afternoon becomes an exception list by the next close.
- Collections. Reminders and statements on a cadence the team sets, in your tone, with escalation to a human when a relationship needs one. The return is cash arriving sooner, which the CFO notices first.
- Purchase order matching. Fast where purchase orders are actually raised, slow where they are not. The build is easy; the precondition is the whole story, and it belongs in the Spec.
- Customer invoicing from the system of record. Generated from the CRM, the contract or the timesheet. Pays back when the source of truth is right and generates disputes when it is not, so it sits below collections.
- Month-end close as a checklist. Accruals, prepayments and recurring journals raised from the schedule, and the close pack checked before it reaches the board. Real hours saved, but it depends on everything above it, so its payback waits.
- Forecasting. Sits on the ledger, the pipeline and the headcount plan; if any one is stale, the forecast is confidently wrong. Fails without clean data, and clean data is a consequence of the workflows above.
- Revenue recognition. Depends on contract data that lives in the CRM, in PDFs and in email between sales and legal. Automating it over those inputs produces wrong journals faster, and they go to the auditors. Fails without clean data.
The first four are where a roadmap should start; the middle three depend on something above them, which is a reason to do them in order. The last two are where most roadmaps do start, which is why so many programmes are written off before they have paid for themselves.
Why do vendor onboarding and invoice coding always work?
They have a property the rest of the map does not. A supplier form is a supplier form and an invoice is an invoice; neither depends on another system being right. The output is a vendor record with the right payment terms and tax treatment, or a line coded to an account and a cost centre. The rule already exists, in a person's head or a spreadsheet tab nobody has opened since it was written; most of the build is writing it down.
Three other things line up. The volume is high enough that the hours come back in the first month. The error cost is one everyone has felt: a duplicate vendor, a mispayment, a miscoded invoice found at the close. And the loop is short: a wrong code is caught at approval, a wrong vendor at the first payment run. Trust is built on evidence rather than on a demo.
The two workflows that always pay back share one property: nothing upstream has to be right first.
Why do forecasting and revenue recognition fail?
For the same reason every time: the inputs are not trustworthy yet, and automation multiplies whatever it sits on. A forecast is a function of the ledger, the pipeline, the contracts and the headcount plan. If the ledger closes late, the pipeline is optimistic and the contracts live in a shared drive, a model fixes none of that. It produces a confident number faster.
Revenue recognition is the harder case, because the wrong output goes to the auditors. It depends on contract start dates, performance obligations, modifications and renewals, and that data lives in the CRM, in PDFs and in email. We have watched teams automate the schedule before anyone owned the contract data, then unwind the resulting journals by hand.
The failure is also slow to surface. A miscoded invoice is caught within the month; a bad forecast is not proved wrong until the quarter it described has ended, and a revenue recognition error surfaces at audit. Nothing in that loop earns the finance team's trust.
This is a sequencing verdict, not a permanent one. Once accounts payable, receivable and reconciliation run on automation, the ledger is current, and a current ledger is exactly what forecasting needs. We get there. We do not start there.
How do you keep the auditors happy?
By making the automated entry easier to trace than the manual one it replaced. Every entry the system posts carries its source document, the rule or model that produced it, and the person who approved it, so any number can be followed back to its origin. Auditors do not object to that. They object to the spreadsheet where a formula was overwritten with a hard number in a tab called final.
Two design rules make it hold. Deterministic rules handle the routine, a model handles only the ambiguous middle, and the log records which of the two produced each entry, because an auditor will ask. And the approval thresholds stay yours: anything above them routes to a named person, and nothing posts without a human where you say one is required. The judgement stays with the finance team; the system keeps the trail.
What to do next
Pick the first workflow before you pick the tooling. It is almost always vendor onboarding or invoice coding, and the readiness test is whether you can describe it in a paragraph: the trigger, the owner, the approval path and the budget holder who can say yes. If the paragraph stalls at the approval path, settle that first; it is a conversation, not a build.
That is what the first call with us is for. A 20 or 45-minute call, no deck and no homework, and a one-page summary within 24 hours. Where the scope needs defining, the four-day Spec from €5,000 turns it into a written, vendor-neutral brief you own outright, with acceptance criteria before any build is priced. The average build ships in eight weeks and 95% reach production. Start with the workflow that pays back first. The forecasting model can wait until the ledger can carry it.