The Integration Layer Is a Person

On paper the systems are connected. In practice, someone connects them.

Picture the owner of a mid-size contractor asking a simple question: which customer payments came in today, and is the cash forecast still right?

It sounds like a question that should take seconds. It goes to the person who keeps the forecast, the forecast owner, and the work behind the answer is done by hand. Their day starts with the payments that came in, and each one has to be matched to a customer. The forecast lives in a set of Excel workbooks. Every so often they rerun a report from the accounting system, only to confirm the workbooks still match the books, the official record of every transaction.

When a number is off, they hunt for the difference themselves rather than pull someone else off their work. Part of the forecast isn't written anywhere: when each customer will actually pay is something they know from experience.

As we read it, that rerun is the control. The workbooks hang off the books, and until someone checks them against the books, nobody knows whether they are still complete. What looks like one finance process is payments, a report, a set of workbooks and one person's memory, joined by hand.

Technology diagrams have a name for whatever moves information between separate systems: the integration layer. In the diagrams it is software. In some mid-size firms, the integration layer is a person: one admin who knows how the tools talk, and a lot of exports into Excel. When that person leaves, the connections can leave with them.

EY's picture assumes the information is in the systems

EY, the professional services firm formerly known as Ernst & Young, published a guide for CIOs in August 2026 on what AI does to the software companies rent by subscription, SaaS for short. Against the idea that AI agents will bypass those applications, EY draws three layers. An AI interaction layer on top takes a request and breaks it into coordinated actions. Below it sit the systems of record, where each kind of record officially lives, and EY treats them as the control layer: "AI can guide and augment, but SaaS platforms enforce and execute." At the bottom, an integration fabric with an AI-enabled API gateway, software that passes requests and data between systems, connects them.

Click to enlarge

Their example is an insurance customer who emails once: they have moved, need to report an incident and want clarity on their coverage. The customer system changes the address, the claims platform opens the case, the policy system validates coverage, and every action stays traceable to the systems of record.

Click to enlarge

Keep both rules: the systems still enforce, and every action traces back to them. What breaks is the list of sources. Every one in EY's drawing is a system: customer records, claims, policy, ERP, HR, finance, a data warehouse. No spreadsheet, no project folder, no inbox, no person. The picture assumes the information worth asking about already sits in those platforms, reachable through a working integration layer. Where EY draws a gateway, a mid-size contractor often has the admin and the Excel exports.

So the question for a mid-market firm is whether AI can read the places outside the systems of record, because that is where much of the work runs.

Where the information actually lives

Firms with an ERP, the main system for their books and operations, still do a lot of work outside it. In 2026 Dodge Construction Network research, summarized by the ERP vendor CMiC, general contractors used third-party software for 63% of the functions they handle outside their ERP, and 47% relied on spreadsheets. The connections between those tools are often manual: the 2021 JBKnowledge ConTech Report found 51.3% of construction respondents still move data by hand between apps that don't integrate, with spreadsheet imports and email among the ways they do it.

I've written before about what the spreadsheet beside the accounting system can see that the system can't, and about the knowledge already sitting in inboxes, shared drives and chat channels. For a contractor, the places look like this:

• The accounting system. The books, and the rules about what can be posted.
• The tools around it. AP, purchasing, project management, each holding its own piece of the record.
• Spreadsheets beside it. Retainage schedules can live in a spreadsheet when the accounting system doesn't flag billed retainage. Reading the system alone won't reproduce them.
• Folders. A tool can pull invoice data out of email and into accounting, and someone still has to file each PDF in the right project folder and match it to a purchase order.
• Inboxes. Where the payment notices arrive.
• People. When each customer pays. How the tools connect.

A useful question for your controller: which answers can't you get from the accounting system alone, and where do you go instead? An AI layer that can't reach those places answers from the books alone, and misses the retainage schedule, the project folder and what the forecast owner knows.

Before you remove a system, weigh it

With information spread that widely, consolidation looks like the cure: replace the old accounting platform and start clean. Forrester counted more than $1 trillion of software market value erased in seven days in early February 2026, on the bet that AI would replace software workflows. In that climate, removing a system that has run the books for decades starts to sound like cancelling a subscription.

It isn't. Faisal Hoque argues that enterprise software encodes the enterprise itself: decades of business rules, process flows, compliance requirements, data definitions and permissions. In the Dodge research, 53% of general contractors using an ERP had used it for seven years or more. Even Forrester, under a "SaaS is dead" headline, projects SaaS spending rising from $318 billion in 2025 to $576 billion in 2029 and calls the death-of-SaaS story overstated.

So look at the system before you decide. What does it do every day? How long has it been there? How much of the business lives inside it and around it? What depends on it? Then ask what it would take to rebuild all of that.

The rebuild is rarely small. Across ERP projects in general, Panorama's 2024 report found a median cost of $450,000 and a median timeline of 15.5 months, and its 2026 report found more than a quarter of organizations went over budget. Firms selling construction replacements quote shorter and are still careful. One Acumatica partner puts moving a 50-to-200-person construction firm off a long-standing construction ERP at 5 to 9 months to go-live, with year-one cost of $150K to $400K, and says firms that don't need the move shouldn't make it.

And the old system rarely goes away. StratusVue, which sells migration services, says most ERP migrations carry over ending balances only, leaving the transaction detail behind. The Acumatica partner's own plan keeps the old system as a read-only archive for prior-period questions and audits, typically for seven years or more.

Some systems do need replacing: when the vendor stops supporting it, when you can't get the data out, when the business has outgrown it. Either way, you don't have to settle it first. You can add a layer that reads across what you have while the systems keep enforcing.

What the AI layer is, and where it sits

Ask which customer payments came in today and whether the forecast still matches the books, and the answer should come back with the lines it used: the entry in the books, the row in the forecast workbook, the document in the project folder. That is the AI layer: one place to ask, which reads the accounting system, the tools around it, the spreadsheets, the folders and the inboxes, while the systems of record keep enforcing the rules and doing the posting. When a customer will actually pay sits in someone's head, and no layer reads that, which is why a person stays in the loop.

AI built into each product is useful when the work stays inside that product. AEC Magazine argued that because construction software is fragmented, AI embedded inside each product carries the fragmentation forward. A cash forecast crosses payments, the accounting system, a set of workbooks and one person's memory. No single product sees all of that.

The vendors are building layers too, each starting from its own product. Sage describes its Intacct Finance Intelligence Agent as an intelligence layer that takes plain-language questions, routes them to the right agents and data sources, and composes one answer. Procore says it is building its AI into its Helix intelligence layer. Both are announcements, not results, and the retainage spreadsheet and the project folder sit outside both.

At one construction firm we work with, the working conclusion was that any AI had to work with the accounting system rather than replace it, because every financial signal is anchored there.

Inside the layer, code does the exact work

Once the layer can read everything, the pull is to let the model do the work too. The rule I build by: code takes everything it can do exactly, the model gets what is left, and a person makes the call after that.

McKinsey's review of more than 50 agent builds says rule-based, repetitive work with structured input should go to rule-based automation, not to an agent. EY's test for AI around core systems is that decisions are explainable, processes auditable and outcomes consistent: "When operations affect money, risk, or patient safety, plausibility is not enough."

Take the forecast. Rolling the workbooks forward to the new period is text substitution, and code should do it the same way every time. Say a payment arrives with a note that names a project but no invoice. No rule can match it, because the field a rule would match on is empty. A model can read the note against the open invoices on that project and suggest one, and the forecast owner confirms it. In my own inbox system, each correction I made became a few lines of code.

Where to start

Start with one process. My test for a first project: someone can walk you through it in ten minutes, the data sits in a system you can pull a report from, one named person cares about it, and waiting a year costs something. Hold the cash forecast up against it.

Ask for read-only access, so the AI can look at the accounting system and change nothing in it. At one firm, that was the first access asked for. The agent reads and reports, and touches nothing. Every number it gives traces back to a line in the books, the same standard the forecast owner holds the workbooks to.

Before anything replaces the workbooks, inventory their formulas. Workbooks copied forward every period and never rebuilt carry rules nobody wrote down, and the forecast owner is the one who can explain them.

Keep the check. The forecast owner's tie-out against the books is, as we read it, the only completeness check the forecast has. An automated forecast needs the same tie-out, or it has no check at all.

Put the forecast owner in the checker's seat. In the first phase, the person who built the forecast reviews and approves what the system produces, so the team can see it is right, and because they know the logic nobody wrote down.

Your board will ask where the data goes. An agent can be set up to run next to the accounting system inside the firm's own environment, so the only thing leaving is the call to the model.

When this isn't the answer

The wish for one clean system is real. In an Intuit-commissioned 2025 survey of 1,000 US construction business leaders, 92% said they would like a single integrated technology stack for both projects and financial operations, and 72% said they spend too much time managing data because their stacks are disconnected. The average firm in that survey used 10 technology tools.

Where the vendor has stopped supporting the system or the business has outgrown it, that wish is the right plan.

Not every process is ready, either. An attempt to automate a forecast with a reporting tool can stall when the process is manual and unwritten. The formula inventory and the ten-minute walkthrough are there to catch that before you start.

The same morning, with the layer in place

The forecast owner still starts with the payments. Now they ask which customer each one belongs to and whether everything still matches the books, and the answer shows the lines it came from. The payment with a project name and no invoice still lands with them, as the one item to decide, not as part of a morning spent matching.