The job nobody wrote down
If you watched a finance team closely for a month and tracked where the hours actually went, you would find something strange. A large share of the time is not spent on analysis, forecasting, or advising the business. It is spent connecting systems.
Pulling data out of the ERP. Exporting from the CRM. Matching a customer in billing to the same customer in the ledger, where they carry different names and different IDs. Reconciling why two systems report different numbers for the same thing. Translating a sales event into a revenue figure. Stitching a dozen sources into one coherent picture, by hand, every reporting cycle.
None of that appears in a finance job description. Nobody was hired to be a data integration team. And yet, in most growing companies, that is what a meaningful part of the finance function has quietly become. The business needed someone to connect its systems into one financial view, no one else owned the job, and it landed on finance by default.
This article is about that default, why it happens, what it costs, and why the most strategic function in the company should not be spending its time as the connective tissue between everyone else's software.
How finance became the integration layer
No one decided this on purpose. It accumulated.
In a small company, finance has two or three systems and one person who understands all of them. Connecting them is a quick, informal task. Then the company grows, and with growth comes software. Sales gets a CRM. Accounting gets an ERP. Billing moves to a subscription platform. HR gets its own system. Product, marketing, and customer success each adopt tools built for their work. Every one of these decisions is sensible on its own, and every system is good at its job.
But each system was built for its own function, and each represents the business in its own language. The CRM speaks in opportunities and stages. The billing platform speaks in invoices and plans. The ledger speaks in accounts and postings. The HR system speaks in employees and roles. None of them was designed to agree with the others, because agreeing with the others was never their job.
So when the business needs a single, coherent financial view, something has to translate all those languages into one. That something is finance. Finance sits at the intersection of every system that touches the numbers, and it is the only function positioned to see across all of them. Which means the work of connecting them falls to finance, not by mandate but by position. The company grew, the systems multiplied, and finance inherited the integration problem that growth created.
Integration is not the work finance is for
Here is the core problem with this arrangement. Connecting systems is not what finance is uniquely good at, and it is not why finance exists.
Finance exists to understand the business and to help lead it: to interpret what the numbers mean, to forecast where things are heading, to advise on decisions, and to give leadership a trustworthy account of performance. That work requires judgment, context, and financial expertise that is genuinely scarce and genuinely valuable.
Integration work requires none of that scarce judgment. Matching customer records, chasing down why two exports disagree, and reassembling the same reconciliation every month is necessary work, but it is not work that draws on what makes finance valuable. When a skilled financial professional spends the first two weeks of every month connecting systems so they can spend the last week actually analyzing, the ratio is backward. The high-value work gets whatever time is left after the plumbing is done.
That is the real cost, and it is easy to miss because the plumbing feels like part of the job. It has always been part of the job. But "we have always done it this way" is not the same as "this is the right use of the function." The integration work is a tax finance pays before it gets to do its actual work, and the tax has grown as the number of systems has grown.
What it actually costs
The cost of finance serving as the integration layer shows up in several ways, most of them larger than the hours involved.
The analysis gets squeezed. The work that finance is uniquely positioned to do, interpreting performance and advising the business, competes for time with the integration work, and the integration work usually wins because it is a prerequisite. You cannot analyze numbers you have not yet reconciled. So the strategic work is perpetually deferred to whatever time remains.
The close is slow. When producing a financial view depends on manually connecting several systems, the reporting cycle takes as long as the connecting takes. The timeline is set by the plumbing, not by the analysis, and the plumbing is unpredictable.
The knowledge is fragile. The understanding of how all these systems connect, which fields map to what, where the quirks are, and how the reconciliation actually works, tends to live in one or two people's heads and in the formulas of a spreadsheet they maintain. When they are unavailable or they leave, a critical piece of how the company understands its own finances leaves with them. This is real key-person risk, sitting quietly inside a process nobody documented because nobody designed it in the first place.
The uncertainty compounds. Because the integration is manual, it is never quite the same twice, and it is hard to fully trust. That uncertainty flows into every number built on top of it, which is why so much of finance's time goes into validating and re-checking rather than deciding. (We have written about that dynamic in why finance's real bottleneck is uncertainty, not reporting.)
None of these costs appears as a line item. All of them are real, and together they mean the company is getting less from its finance function than it is paying for, because a large part of that function's capacity is absorbed by work it was never meant to do.
Connecting systems is not the same as understanding them
It is worth being precise about a distinction that sits underneath all of this, because it explains why more integration tooling alone does not fix the problem.
Integration is about movement. Interpretation is about meaning. Those are different activities, and more pipelines or warehouses do not close the gap on their own. We cover that distinction fully in why a single source of truth on its own is not enough; the short version is that connecting and centralizing data is not the same as interpreting it. (See also why financial data needs translation, not just integration.)
What finance could do instead
Picture the finance team that is no longer the integration layer. The connecting, matching, reconciling, and translating still happens, but finance is not the one doing it by hand. What changes?
The time that went into assembling the numbers goes into understanding them. Instead of spending most of the cycle preparing data and the remainder analyzing it, finance spends the cycle on analysis, forecasting, and advising. The questions leadership cares about, why performance changed, what the forecast implies, where the risks are, and what the business should do next, get the attention they deserve rather than the attention that was left over.
The close gets faster, not because anyone worked harder, but because the slow part was the manual integration, and that is no longer finance's manual task. The knowledge stops being fragile, because how the systems connect is captured in something durable rather than in one person's memory. And the uncertainty drops, because the connecting is done consistently rather than reconstructed differently each period, which means finance spends less time validating and more time deciding.
The point is not that finance does less. It is that finance does the work that actually requires finance, and stops spending its scarcest resource, expert judgment, on work that does not require it. A finance function freed from the integration layer is not a smaller function. It is a more valuable one.
This is not about replacing finance people
It is important to be clear about what this argument is and is not. It is not an argument for automating finance away or for reducing the team. It is the opposite.
Every capability described here, connecting, translating, governing, exists to take the reconstruction work off finance's plate, not to take finance's judgment off the org chart. The reconstruction work is the manual reassembly of the same picture every cycle: the matching, the reconciling, the rebuilding of the same reconciliation from something close to scratch. That is the work worth removing, because it consumes capacity without drawing on expertise. What remains is the interpretation, the forecasting, the advising, and the judgment, which is exactly the work finance should be doing more of, not less.
So the goal is not fewer finance professionals. It is finance professionals who spend their time on the parts of the job that require a finance professional. Freeing the function from the integration layer is about raising the level at which finance operates, not shrinking the function.
The layer that should carry this instead
If finance should not be the integration layer, something else has to be. And the answer is not to push the work onto another team or to buy one more connector. It is to give the company a layer whose actual job is to do what finance has been doing by hand: connect the systems, translate their data into consistent financial meaning, govern the definitions, validate the results, and make everything traceable, so that what reaches finance is already interpreted and trustworthy rather than raw and unreconciled.
This layer sits above the systems of record without replacing them. The ERP, CRM, billing platform, and HR system remain authoritative for the jobs they were built to do. What changes is that the work of turning their combined output into one consistent financial view stops being a manual task finance performs and becomes a capability the company owns. Finance moves from operating the integration layer to operating on top of it, which is where a finance function belongs. (This is the broader idea behind what a finance operating system should be: the coordinating, interpreting layer that carries this work so finance does not have to.)
That shift is the point. Not more tools for finance to operate, but a layer that carries the connective work finance was never meant to own, so the function can spend its time understanding the business instead of assembling it.
FAQ
What does it mean that finance becomes the integration layer? It means that the work of connecting a company's separate systems into one coherent financial view falls to the finance team by default. Finance ends up pulling, matching, reconciling, and translating data across the ERP, CRM, billing, and other systems, because it sits at the intersection of all of them and no other function owns the job.
Why is this a problem? Because integration work does not draw on what makes finance valuable. Time spent connecting systems is time not spent on analysis, forecasting, and advising the business. It slows the close, concentrates critical knowledge in a few people, and increases the uncertainty that finance then has to spend more time validating.
Isn't connecting systems just part of finance's job? It has become part of the job, but that is a result of how systems accumulated as the company grew, not a reflection of what finance is for. Finance exists to interpret and advise. Manual integration is a prerequisite tax on that work, not the work itself.
Doesn't more integration software solve this? Integration tools help with moving and mapping data, and they reduce manual transfer work. But they do not interpret the data, because interpretation is a financial judgment, not a transfer function. So finance can invest heavily in connectors and still perform the interpretation by hand each period.
Does removing this work mean replacing finance people? No. The goal is to remove the manual reconstruction work, the repeated matching and reconciling, so finance professionals can spend their time on interpretation, forecasting, and advising. It raises the level at which finance operates rather than reducing the team.
What should carry the integration work instead? A layer that sits above the systems of record and does the connecting, translating, governing, and validating, so that what reaches finance is already consistent and traceable. The systems of record stay authoritative for their own domains; finance operates on top of an interpreted view rather than assembling it by hand.
Where SMPL.ai fits
SMPL.ai helps SaaS finance teams stop being the integration layer, so they can spend their time interpreting the business rather than assembling it.
The value is exactly the shift this article describes. SMPL works with the financial and operational information already in your existing systems and does not replace your ERP, CRM, billing platform, or other systems of record. It helps turn that information into consistent, governed financial meaning, using your own methodologies, so the connecting and translating that finance has been doing by hand is carried for them. Results are designed to be validated and traceable, and calculations are deterministic and repeatable, so what finance works from is already trustworthy.
The point is not another system for finance to operate. It is to take the connective work off finance's plate, so the function can spend its time on the analysis and judgment that actually require a finance team.
If you would like to see what that looks like on your own numbers, book a demo and we will walk it on data that looks like yours.