Arfiti

The Hidden Tax of Your Finance Tool Stack

If you run finance at a company with 30 to 200 employees, you already know the number: somewhere between five and eight distinct software tools sit between your bank account and your financial statements. You pay for each of them. You maintain integrations between some of them. And you employ at least one person whose unofficial job title is "the person who makes all of this work together."

That person — or more likely, that set of responsibilities distributed across your entire finance team — represents a cost that never shows up on any vendor invoice. It is the hidden tax of a fragmented finance stack, and it is almost certainly larger than every subscription fee combined.

The Typical Stack, Mapped

Walk into any growth-stage company and you will find some variation of the following:

General ledger and accounting: QuickBooks Online, Xero, or Sage
Expense management: Expensify, Brex, or Ramp
Accounts payable: Bill.com or Tipalti
Payroll: Gusto, Rippling, or ADP
FP&A and budgeting: Pigment, Mosaic, or a collection of spreadsheets
Cash flow forecasting: Float, Runway, or another collection of spreadsheets
Time tracking and billing (if services-based): Harvest, Toggl, or Clockify
The spreadsheets: Always the spreadsheets

Each tool is defensible in isolation. Expensify is genuinely better at expense reports than QuickBooks. Pigment is genuinely better at planning models than Excel. No single vendor has built a product that handles all of these jobs well, and so the rational decision at each point of need is to adopt the best-of-breed tool.

The problem is that rational individual decisions produce an irrational system.

The Human Glue Problem

Every tool in your stack produces data. Almost none of them consume data from the others without human intervention. The result is that your finance team spends a significant portion of its time acting as the integration layer — copying, reformatting, reconciling, and cross-checking information that moves between systems.

We call this "human glue" work, and it is pervasive.

A 2025 survey by Gartner estimated that finance teams at mid-market companies spend 15 to 20 hours per week on data movement and reconciliation tasks that exist solely because their tools do not share a common data model. That is roughly 40 percent of a full-time employee — not doing analysis, not doing strategy, not doing the work that finance professionals are trained for. Just moving numbers from one place to another.

Consider the lifecycle of a single vendor invoice:

The invoice arrives via email or a vendor portal.
Someone enters it into the AP system (Bill.com).
It gets coded to an expense account — but the chart of accounts in Bill.com may not perfectly match the chart of accounts in QuickBooks, so someone maintains a mapping table.
After approval and payment, the transaction syncs to QuickBooks — sometimes automatically, sometimes with errors that require manual correction.
At month-end, the AP balance in Bill.com needs to reconcile with the AP balance in QuickBooks. Discrepancies trigger a manual investigation.
The same expense data needs to flow into the budget-vs-actual report in Pigment, which pulls from QuickBooks but may require manual adjustments for timing differences.
If the expense relates to a project, someone also logs it in Harvest or updates a project tracking spreadsheet.

That is seven touch points for one invoice. Multiply by hundreds of invoices per month, and the scale of the glue work becomes clear.

Quantifying the Hidden Costs

The subscription costs are visible and measurable. A typical mid-market finance stack runs $2,000 to $5,000 per month in software fees. That is not trivial, but it is manageable and predictable.

The hidden costs are larger and harder to see:

Reconciliation time. When your bank statement, your accounting system, and your AP platform all have slightly different views of the same transactions, someone has to resolve the differences. For a company processing 500 to 1,000 transactions per month, this typically consumes 8 to 12 hours per month-end cycle. At a fully loaded cost of $75 to $100 per hour for an experienced accountant, that is $600 to $1,200 per month spent on a task that exists entirely because the systems do not agree.

Data entry duplication. Despite integrations, many data points still get entered more than once. A new vendor gets created in QuickBooks, in Bill.com, in the budgeting tool, and possibly in a master vendor spreadsheet. Each entry is a chance for error. Each error is a future reconciliation problem.

Version control failures. The budget lives in Pigment, but the board deck pulls from a Google Sheet that was exported from Pigment three weeks ago, and the CEO's version has manual adjustments that never made it back into the system of record. This is not a technology problem. It is an architecture problem. When data lives in multiple places, version divergence is inevitable.

Month-end elongation. Companies with clean, unified data close their books in 3 to 5 business days. Companies running fragmented stacks routinely take 10 to 15 business days. Those extra days are not just a matter of team bandwidth. They delay financial visibility, push back board reporting, and reduce the time available for forward-looking analysis.

Error propagation. A miscoded expense in Expensify flows through to QuickBooks, which feeds into Pigment, which informs the board deck. If the error is caught at the board deck stage, the correction has to propagate backward through three systems. If it is not caught, a flawed number becomes the basis for decisions.

Add these up across a year, and the hidden tax of a fragmented stack typically runs $50,000 to $150,000 annually for a mid-market company — measured in labor hours, delayed decisions, and error correction. That is 10 to 30 times the software subscription cost.

The Integration Tax

The natural response to tool fragmentation is integration. Connect everything with APIs. Use Zapier or Make to automate the data flows. Build custom scripts.

This works, partially, for a time.

But integrations carry their own tax. Someone has to build them. Someone has to maintain them. When QuickBooks pushes an API update, or Expensify changes its data format, or Bill.com deprecates an endpoint, someone has to fix the broken connection — usually on an urgent timeline because month-end close is in three days.

Most mid-market companies do not have dedicated integration engineers on their finance team. The maintenance falls to whoever set up the integration originally, or to an external consultant at $150 to $250 per hour.

And even well-maintained integrations are fragile. They map between different data models, which means they encode assumptions. When those assumptions break — a new expense category, a new entity, a change in the chart of accounts — the integration silently produces incorrect data until someone notices.

The integration approach treats the symptom (disconnected data) without addressing the disease (disconnected systems). You end up with a Rube Goldberg machine: technically functional, practically terrifying, and entirely dependent on institutional knowledge that walks out the door when someone leaves.

The Spreadsheet Escape Valve

Every fragmented finance stack has a pressure release valve, and it is always a spreadsheet.

When the tools do not talk to each other, when the integration breaks, when the data does not quite line up — someone opens Excel or Google Sheets and builds a bridge. The month-end reconciliation spreadsheet. The vendor master list. The budget consolidation workbook. The "source of truth" that is actually a source of one person's interpretation of the truth at one point in time.

These spreadsheets are not optional. They are structurally necessary in a fragmented stack. They fill the gaps that no vendor anticipated and no integration covers. And they are almost universally undocumented, unversioned, and maintained by a single person.

The risk here is not hypothetical. A 2024 study by FSN Research found that 72 percent of finance professionals reported at least one material spreadsheet error in the prior 12 months. Nearly a quarter reported errors that affected external reporting.

Why Best-of-Breed Became Worst-of-Breed

The best-of-breed philosophy — choose the best tool for each job — made sense when the jobs were independent. Payroll is independent of expense management is independent of FP&A. Buy the best tool for each.

But finance jobs are not independent. They are deeply interconnected. Every expense is also a cash flow event, a budget line item, a vendor relationship, a tax consideration, and a data point in next quarter's forecast. The data model is inherently unified even when the tools are not.

The best-of-breed approach optimizes each node in the network while ignoring the cost of the edges. And in a highly connected network — which is exactly what a finance function is — the edge costs dominate.

This is not a new insight. ERP systems have existed for decades precisely to solve this problem. But traditional ERPs (SAP, Oracle, NetSuite) solved it by being monolithic: one massive system that does everything, configured by consultants over 6 to 18 months, at a cost that only makes sense for companies with $50 million or more in revenue.

The mid-market has been stuck between two bad options: fragmented best-of-breed stacks with high glue costs, or enterprise ERPs with high implementation costs and low flexibility. Neither is right.

The Architecture Is the Problem

The core issue is not that any individual tool is bad. Most of them are genuinely good at their specific job. The issue is architectural: when financial data is distributed across multiple systems with different data models, reconciliation and integration become permanent, ongoing costs rather than one-time setup problems.

The question is not "which expense tool should we use?" The question is "why does our expense data live in a different system than our ledger data in the first place?"

The answer, historically, has been that building a unified system is hard, and the unified systems that do exist (traditional ERPs) are expensive and rigid. But that historical constraint is weakening. New approaches to financial infrastructure are making it possible to unify the data model without sacrificing flexibility or requiring 12 months of consultant time.

At Arfiti, we are building a finance system that starts from a single, unified data model — where every transaction, every vendor, every budget line, and every forecast lives in one place from the beginning. Not by bolting integrations onto separate tools, but by designing the architecture so that the glue work simply does not exist. The result is a system where your team spends its time on analysis and decisions rather than on moving data between systems.

The hidden tax of your finance stack is real, it is large, and it compounds every month. The solution is not better integrations between fragmented tools. It is a different architecture entirely.