From Excel to Autonomous Treasury: A CFO Migration Playbook

Every CFO has been told the same story: a Treasury Management System will fix the Excel chaos, the late month-end, and the bank-balance scramble before each board meeting. The pitch decks promise a six-week implementation, an instant ROI, and a finance team that finally gets to do strategic work. None of that is quite true. Migrating off Excel is less about software and more about admitting which spreadsheets are quietly running the company. This is the playbook we wish we had read before the first vendor demo.

The cynical truth is that most treasury migrations stall not because the tool is wrong, but because the diagnosis was wrong. Companies pick a TMS based on a feature checklist, then discover six months later that their real problem was an undocumented intercompany loan workbook maintained by one senior accountant who is two years from retirement. This article walks through the diagnosis first, then the selection, then the implementation, and finally the part nobody puts in the proposal: the politics of taking spreadsheets away from people who built their careers on them.

When Excel actually breaks (it's not revenue)

The most common question on early treasury calls is, "At what revenue does Excel stop working?" The honest answer is that revenue is a poor proxy. A €15M single-entity SaaS company with two bank accounts and EUR-only billing can run treasury in Excel comfortably for years. A €40M industrial group with seven entities, four currencies, and a revolving credit facility will be drowning in version-control errors at half that revenue. The trigger is complexity, not turnover.

As a working rule of thumb, Excel begins to crack when any one of three thresholds is crossed: three or more legal entities, five or more bank relationships, or €20M+ revenue combined with multi-currency exposure. Cross two of those three and you are already operating on borrowed time. The symptoms appear gradually, then all at once, usually right before an audit or a refinancing.

There is a second, less obvious threshold: when more than one person needs to touch the same workbook on the same day. Excel is a single-player tool dressed up as a multi-player one. SharePoint co-authoring helps, but the moment you have a treasurer in Paris and a controller in Warsaw both updating the cash position file at 09:15, you are one cell-formula-paste-error away from a misstated forecast. That collaboration ceiling tends to hit around the same time the entity count crosses three.

Five signs you actually need a TMS

Below are the five signals we look for during a treasury health check. Any one of them in isolation is manageable. Two or more together, and the business case writes itself.

Sign 1: Data freshness measured in days, not minutes

Ask your treasurer a simple question on a Wednesday afternoon: what is our group cash position right now? If the answer involves the phrase"as of yesterday's close" or "let me refresh the file", you have a freshness problem. Modern TMS platforms with bank connectivity deliver intraday balances within 15 to 60 minutes of bank posting. Excel delivers them whenever the junior analyst finishes the morning download ritual, which is typically between 10:30 and 11:00 if nothing breaks.

The cost of stale data is not the data itself, it is the decisions made around it. A treasurer who cannot see the real position will keep defensive cash buffers of 5 to 10% of monthly opex just to avoid surprises. On €60M revenue that is somewhere between €250k and €500k of idle cash that could be earning 3.5% on a money market fund. That single line of opportunity cost often funds the entire TMS subscription.

Sign 2: An error rate you have stopped measuring

Healthy finance teams know their error rate. They know that 1.2% of payment files are returned for formatting issues, or that 0.4% of intercompany bookings are reversed within 30 days. Teams in Excel-driven environments usually do not know, because measuring it would require a system of record that does not exist. The tell is a culture of "we caught it before it went out" stories shared at the coffee machine.

Sign 3: Audit trail gaps that nobody wants to discuss

Every Excel-based treasury function has the same blind spot: who changed what, when, and why. The forecast tab from three months ago is gone, overwritten by the current version. The intercompany confirmation email lives in someone's Outlook archive. The signed-off payment list exists as a printed PDF in a binder. When the auditor asks for the approval chain on a €2.3M FX swap from October, the answer involves forensic email searches and tentative reconstructions.

SOX-equivalent controls, ISAE 3402 reports, and increasingly the EU CSRD regime all assume an immutable audit trail. Excel cannot deliver one without bolt-on tooling that costs more than the TMS would.

Sign 4: The headcount-time math no longer works

Here is the conversation that triggers most TMS projects, almost word for word: the CFO asks the head of treasury for a 13-week rolling cash forecast, weekly, by entity, by currency. The head of treasury replies that this would require another junior analyst. The CFO approves the hire. Eighteen months later, the same conversation happens again, this time about covenant reporting. By the third loop, the treasury team has doubled and the forecast is still late.

Sign 5: Board reporting cycles that consume the month

If your treasury and FP&A teams spend the last week of every month rebuilding the same board pack from scratch, you are paying senior people to do junior work. The symptom is recognisable: workbooks namedBoard_Pack_v17_FINAL_VM_edits.xlsx, frantic Slack messages at 22:00 the night before the meeting, and a CFO who cannot answer a follow-up question because "the underlying file is at the office". A TMS with a proper reporting layer collapses that week into about 90 minutes of review.

Ten questions to ask every TMS vendor

Vendor demos are theatre. The salesperson knows the script, the system engineer knows where the bugs are hidden, and the demo data is curated to avoid every edge case you actually have. The only way to cut through is to ask questions that force them off the rails. Here are ten that have never let us down.

1. Show me a live customer instance, not a sandbox. If the vendor cannot arrange a screen-share with a real client within two weeks, their reference base is thinner than they claim.
2. What is your bank connectivity model, and who pays for new banks? SWIFT service bureau, EBICS, host-to-host, or API? Each has different cost and lead-time profiles. Some vendors charge €5k to €15k per new bank connection. Get the price list in writing.
3. How do you handle intercompany netting with mismatched ERPs? If your group runs SAP, NetSuite, and a legacy Sage instance, the answer cannot be "we recommend you standardise on one ERP first". That is a non-answer.
4. What is the average implementation length for a customer of my size, measured from kickoff to go-live? Push for the median, not the average. Averages hide the disasters.
5. Can I see the data model? A vendor who will not show you the underlying schema is a vendor who plans to lock your data in. Ask for the export format and a sample extract.
6. What does year-two pricing look like? Year-one discounts are routine. Year-two and year-three uplifts are where margin is recovered. Get the renewal mechanic written into the MSA.
7. Who owns the bank format library? If your bank changes its CAMT.053 dialect, who updates the parser, and on what SLA? In-house parsing teams beat outsourced ones every time.
8. What is your customer churn rate, and where do customers go? Vendors will dodge this. Persist. Ask for named references who left, and call them.
9. How do you handle audit log immutability? The answer should involve append-only logs with cryptographic signing or equivalent. "We have a change history table" is not enough.
10. What happens if I want to leave in three years? Data export format, notice period, transition assistance, and cost. If the answer is vague, the exit is going to be expensive.

For the structured comparison, score each vendor on the criteria below. Weight by what matters in your context, not by what the vendor emphasises.

The realistic implementation timeline

Vendors will tell you six weeks. Reference customers will tell you four months. Both are right, depending on what you count. Six weeks is the time from kickoff to a working sandbox with one bank connected and one entity configured. Four months is the time from kickoff to actually decommissioning the Excel files, which is the only milestone that matters.

For a mid-market group — three to seven entities, five to ten banks, two to four currencies — plan for 14 to 18 weeks of real work, plus a parallel-run period of one full month-end. Anything faster is either oversimplified scope or post-go-live cleanup masquerading as project completion.

Change management: the part nobody puts in the proposal

Every TMS implementation deck has a slide titled Change Management. It usually contains stock photos and the words training, communication, and champions. None of that is wrong. None of it is sufficient either. The real change-management problem is political, and it lives in three places.

First, the spreadsheet authors. Every Excel-driven finance team has one or two people whose professional identity is built on the workbooks they maintain. Replacing those workbooks with a TMS feels like being replaced. They will not say this out loud. They will instead say the TMS "doesn't quite handle our specific case", which is sometimes true and sometimes a defense mechanism. You need to tell the difference.

The technical migration took four months. The cultural migration took fourteen. Two senior people left in the first year because their value to the company had been their command of a specific workbook, and once the workbook was gone, so was the leverage. We should have had that conversation with them on day one, not month nine.

Second, the ERP team. They will see the TMS as scope creep into their territory, especially around bank reconciliation and AP workflow. Get this conflict on the table early. Define the system of record for each data domain in writing, signed by the CIO and the CFO. Cash positions live in TMS. AP invoices live in ERP. Bank statements are ingested by TMS and posted to ERP via interface. Ambiguity here will cost you six weeks of integration argument later.

Third, the auditors. External auditors are creatures of habit. They have a tested set of procedures for your Excel-based process. Switching to a TMS means they need to re-scope their controls testing, which takes time and budget on their side. Brief them at least two months before go-live, and expect a higher audit fee in year one. Budget for it.

Cost justification: the math the board will ask for

At some point in the approval cycle, somebody on the board is going to ask for the business case in one slide. Resist the temptation to lead with feature benefits. Lead with the cost of doing nothing, which is almost always larger than the cost of the system.

Plug in real numbers for a representative mid-market case: a 4-person treasury team, each spending 23 hours a month on data wrangling (downloading bank statements, formatting, reconciling, rebuilding the cash position file). Loaded rate of €85 per hour. Average idle cash buffer of €450k. Opportunity cost of 3.2% on a money market alternative. Annualised error cost — late payment fees, FX mismatches, duplicate payments recovered — of €18k.

That is the run-rate cost of staying in Excel for a single mid-market group. A mid-market TMS with bank connectivity and forecasting typically lands between €45k and €75k per year all-in for a group of that size, plus a one-off implementation fee of €60k to €120k. The payback period is usually 14 to 22 months on a three-year contract. The number that matters more, however, is what the team does with the 1,100+ recovered hours per year. If even half of those go into actual analysis — covenant forecasting, working capital optimisation, FX hedging strategy — the return is multiples of the licence cost.

Final rollout checklist

Print this. Tape it to the wall of the project room. Tick items only when the evidence exists, not when somebody promises it will exist by Friday.

• Entity hierarchy and signatory matrix signed by the CFO and Group Legal.
• Chart of accounts mapping reviewed by both the controller and the auditor.
• Bank connectivity tested for every account, not just the top three by volume.
• Approval workflow matches the actual delegation of authority, not the one in the policy from 2019.
• Parallel-run month completed with documented variance analysis under €5k or 0.1% of flow, whichever is lower.
• System of record memo signed by the CFO and CIO, naming TMS, ERP, and HRIS owners by data domain.
• Audit briefing held with external auditors, with a written response on revised control testing approach.
• Excel files archived to read-only storage with retention policy, not deleted.
• Training completed for every user, with named alternates for each role (no single point of failure).
• Hypercare contact list with vendor on-call, internal escalation, and decision authority for each scenario.
• Post-go-live retrospective scheduled for week 6, not week 1.
• Year-one renewal terms reviewed by procurement before month 9, to avoid the standard 8 to 12% auto-uplift.

The migration from Excel to a real treasury platform is a multi-quarter commitment that will expose every weak process and every undocumented workaround in the finance function. That exposure is the point. The TMS does not fix bad treasury; it makes bad treasury visible and unavoidable, which then forces it to be fixed. Companies that approach the migration as a software project fail. Companies that approach it as an operating-model upgrade — with the political work done in the open and the cost-of-doing-nothing math on the table — succeed, and usually wonder why they waited so long.