Excel is used for corporate treasury at the overwhelming majority of mid-market companies. AFP survey data from recent years has consistently found that spreadsheets remain the primary treasury tool for companies below the large-enterprise threshold — somewhere between 60-75% of organizations with revenues under $500M rely on Excel for cash forecasting, cash positioning, or both. That's not a finding that surprises anyone who has worked in a mid-market finance function. Excel is available, flexible, and understood by every finance professional. It requires no IT project, no procurement cycle, and no implementation partner.
This post isn't an argument that Excel is bad. It's an honest accounting of what Excel costs you in operational terms — not the license fee, but the downstream consequences of running treasury on a manual spreadsheet infrastructure at certain levels of complexity.
The Manual Aggregation Time Tax
The most visible cost of Excel-based treasury is time. A treasury analyst or director at a company with 8 bank portals, 6 legal entities, and a daily cash position requirement spends meaningful time each morning collecting data that shouldn't require human labor. Log into portal 1, export yesterday's transactions, log into portal 2, notice it requires two-factor auth this morning, wait for the token, export. Repeat 8 times. Paste into the master workbook. Run the macro that normalizes column headers because three banks use different formats. Reconcile the total. Forward the position to the CFO.
AFP benchmarking puts this at 1.5-3 hours per day for treasury teams managing this level of complexity manually. That's not labor that improves the quality of the position — it's pure data collection overhead. Across a 250-day working year, it represents 375-750 hours of analyst time per year performing a task that could be automated.
The time tax is only part of the problem. The other part is what doesn't happen during those 1.5-3 hours: proactive analysis, covenant monitoring, investment policy review, interco loan documentation, counterparty risk assessment. The work that treasury should be doing gets deferred by the work of building the spreadsheet.
Formula Risk and Version Control
A treasury workbook maintained over months and years accumulates complexity. A formula that worked correctly in Q1 references a cell range that was restructured in Q3 when a new entity was added. A lookup table uses hardcoded values that haven't been updated since a banking relationship changed. A macro that automates the BAI2 import broke when the bank changed its file delimiter without notice.
The research literature on spreadsheet error rates — including studies published by the European Spreadsheet Risks Interest Group (EuSpRIG) — consistently finds material error rates in complex spreadsheets used in financial decision-making. Errors in treasury spreadsheets are particularly consequential because the outputs drive cash movement decisions: a wrong sweep amount, a miscalculated debt covenant ratio, an understated cash position that delays a necessary wire.
Version control in Excel is file-based rather than change-based. Treasury-Cash-Position-v3-FINAL-v2-JAN15.xlsx is a familiar sight in mid-market finance. When two analysts are updating different versions, or when a formula change is made without documentation, the audit trail for how a number was derived is absent. For companies with SOX controls or audit requirements on treasury operations, this is a compliance exposure as well as an operational one.
Concurrent Access and Workflow Gaps
Treasury operations are rarely a solo function. The cash position worksheet is opened by the treasury analyst, used by the treasurer, reviewed by the CFO, and sometimes updated by the controller with AR aging adjustments. Excel's concurrent access model — file locking, or worse, "read-only mode" while someone else has the file open — is fundamentally at odds with a collaborative, time-sensitive workflow.
The workflow gap extends to approvals. An interco sweep decision in Excel looks like: analyst identifies a sweep need, emails the treasurer, treasurer approves via email, analyst initiates the wire. The approval chain is in the email thread. The wire initiation is in the bank portal. The GL booking is in the ERP. Three separate systems, zero integration. Reconstructing the decision trail for a question six months later requires finding the right email thread and cross-referencing it with bank statements and GL entries.
The Scaling Problem
The inflection point where Excel fails isn't always obvious while you're still on the right side of it. A treasury team managing 4 entities and 6 bank accounts has a workbook they understand, maintain, and trust. Add an acquisition in year two that brings 3 new entities, 4 new bank relationships, and a Canadian currency requirement, and that workbook's complexity increases non-linearly. What took 90 minutes daily now takes 3 hours. What was a manageable set of tabs is now 40 tabs that only one person fully understands.
The risk isn't that the workbook is wrong today. It's that it becomes wrong in a way that isn't immediately visible, because the person who built the formulas left, or because a structural change to the entity chart wasn't fully propagated through every tab. At 8 entities and 14 bank accounts, the workbook's complexity has typically exceeded the point where confident reliance on its outputs is justified.
What Replacing Excel Actually Means
We're not saying Excel has no role in treasury. Cash flow analysis, debt modeling, investment policy scenario planning — these are legitimate Excel use cases where its flexibility is genuinely valuable. The argument is narrower: using Excel as the primary production system for daily cash positioning and 13-week forecasting at multi-entity complexity creates quantifiable operational costs that eventually exceed the switching cost of purpose-built treasury software.
The switching cost for a mid-market company is primarily time: bank connectivity setup, ERP integration, user onboarding, and forecast model migration. For a 6-entity company, that implementation timeline is typically 30-60 days with a focused effort. The ongoing cost savings — analyst time recovered, error rate reduction, audit trail improvement — tend to exceed the platform cost at the Professional tier of current treasury software pricing within the first year of operation.
The honest question for treasury teams still on Excel is not whether to replace it, but when the complexity threshold has been crossed where the replacement cost is justified by the operational improvement. For most teams reading this, the honest answer is: probably already.