Key Takeaways
- Transformance runs entities on different ERPs, such as SAP, NetSuite and Dynamics 365, in one environment with one worklist and one forecast; a proof of value takes 4-5 weeks on one entity (Transformance customer data, 2026).
- Buy-and-build keeps adding ERPs: add-ons made up 57.7% of European private equity deal count in the first half of 2026, a decade high (PitchBook, 2026).
- CIO.com reports that a cloud ERP migration can take 18 to 36 months, and an acquisitive group may face several (CIO.com, 2026).
- The integrations hub reaches each system by the route it offers: API, OData, RFC/BAPI, the ERP’s own MCP server, files, database, mailbox, an outbound-only on-premise agent or RPA.
- Each ERP stays the system of record; approved postings go back through its own interfaces, and when an entity migrates, only its connection changes.
In This Article
- Key Takeaways
- How do you automate finance across several ERPs without consolidating first?
- Why do fragmented ERP landscapes stay fragmented for years?
- What does waiting for one ERP cost finance?
- How does Transformance connect to any ERP?
- What runs in the shared layer, and what stays in each ERP?
- How do you plug in a newly acquired company?
- What happens when an entity finally migrates to a new ERP?
- Which finance processes should a multi-ERP group automate first?
- What does buy-and-build change for the finance team?
How do you automate finance across several ERPs without consolidating first?
Keep every ERP as the system of record and let Transformance run one order-to-cash process and one cash forecast above all of them, connected to each ERP separately.
Three ways to automate finance in a multi-ERP group
Time figure: Transformance customer data, 2026.
A multi-ERP finance layer is one environment that reads from every entity’s ERP, runs order-to-cash and cash forecasting for all entities, and writes approved results back to each ERP. “Finance” on this page means that scope.
The first two rows are the right answer in their own cases: if the last entities move to the target ERP next quarter, automate once, on the new system; if two ERPs share few customers, each ERP’s own AR features may be enough. The third row fits groups where several ERPs are the normal state. The table is our guidance, not a benchmark.
Every deal can add a system. In Europe, add-ons, where a company already owned by a private equity investor buys another company, made up 57.7% of all private equity deal count in the first half of 2026, a decade high (PitchBook, Q2 2026 European PE Breakdown, 2026).
The object-by-object split is in how to run one AR process across SAP, Oracle and NetSuite.
Takeaway: choose by how many ERPs you will run over the next three years, not by the target picture.
Why do fragmented ERP landscapes stay fragmented for years?
Because each consolidation is a multi-year program that competes with running the business, and in buy-and-build the next acquisition arrives before the last one is migrated.
CIO.com reports that completing a cloud ERP migration “can take 18 to 36 months, not to mention millions of dollars” (CIO.com, September 2026). That is one migration, and the same people also run the month-end close.
Illustrative example (fictional group): the parent runs SAP S/4HANA, one acquisition brought NetSuite, and two add-ons run Dynamics 365 Business Central. Before the second entity is live on the target ERP, a fifth company with its own ERP has been signed.
Each of these ERPs does its job well for the entity that runs it. The issue is time and change, not the systems.
Takeaway: treat several ERPs as the standing condition of an acquisitive group, and automate on that basis.
What does waiting for one ERP cost finance?
Years of manual cash application, AR collections and forecasting across systems: slower cash, no group view of customers and open items, and a forecast stitched together by hand.
Cash application. Every entity applies cash in its own ERP, from its own bank accounts, with its own rules. The Hackett Group found “a surprising number of organizations” taking “up to three days to post payments” and “carrying up to 6% of unapplied cash” (The Hackett Group, 2025). A payment sent to the wrong entity adds an intercompany step on top.
AR collections. A customer that buys from three entities gets three sets of reminders, and nobody sees its total exposure. Manual teams action 30-40% of overdue invoices within 24 hours; CollectPulse actions 100% (Transformance customer data, 2026).
Cash forecasting. Each entity sends a spreadsheet with its own cut-off date, and treasury consolidates by hand.
Every day of DSO is cash earned but not received (what one day of DSO costs); with Transformance, DSO comes down 8-12 days on average (Transformance customer data, 2026).
Takeaway: the cost of waiting is paid in cash and staff time every month of the migration program.
How does Transformance connect to any ERP?
Through its integrations hub, by the route each system offers: API and OData, RFC/BAPI, the ERP’s own MCP server, files, database, mailbox, an outbound-only on-premise agent or RPA.
If a system has an API, a database, a file drop or a mailbox, it can be connected.
How the integrations hub reaches each system
See which ERPs have an MCP server.
One standard process. Every connection runs the same steps: discover, map, build, test, schedule, monitor. Integration agents run them today: they read the system documentation and your setup answers, propose field mappings, draft workflows, run the test plan and report, and draft plain-language explanations when something fails. A person approves every change that reaches your system or production (what an agent-run integration platform is).
Who does what. Transformance builds, runs, monitors and fixes the connections; you approve access and production changes. A connection typically takes 2-3 days for a production ERP such as SAP S/4HANA, SAP ECC, NetSuite, Dynamics 365 or Odoo (Transformance customer data, 2026), and your IT team may be involved. Custom systems are agreed after a feasibility check (how custom and older systems are connected).
Write-back. Approved postings go through the ERP’s own interfaces (API, OData, BAPI or MCP); direct database writes happen only where you explicitly agree. The ERP list is in which ERP systems Transformance integrates with.
Takeaway: the route follows the system; the process, the approvals and the team that runs the connection stay the same.
What runs in the shared layer, and what stays in each ERP?
Each ERP keeps the ledger, invoices and postings; the shared layer holds the work: matching, AR collections worklists, deduction cases, the customer view and the forecast.
Entities on different ERPs, for example SAP S/4HANA, NetSuite and Dynamics 365, run in one Transformance environment with one worklist and one forecast, across all four modules:
- Cash application. DocSense reads remittances with over 97% extraction accuracy (Transformance platform data, 2026); ClearMatch reaches a 95% auto-match rate (Transformance customer data, 2026).
- Deductions. ClaimIQ identifies deductions with 97% accuracy (Transformance platform data, 2026) and sorts them into six categories, whichever ERP the invoice sits in.
- AR collections. One worklist across entities; Vero handles 60-80% of routine touches (Transformance customer data, 2026).
- Cash forecasting. CashPulse forecasts with 90-95% accuracy out to 90 days (Transformance platform data, 2026), with 20+ countries on one model.
Vero, Transformance’s AI agent, works on Customer 360, one graph per customer. For an unmatched payment, Vero investigates from Customer 360, fetches internal and external information to find more matches, and proposes with the evidence; a person approves.
The layer does not hold the ledger. Clearing postings, journal entries and ERP updates, including reversals, go to the entity’s own ERP after approval (what AR automation reads and writes). Nothing posts without human sign-off, within a 4-level approval model (read, recommend, execute, post) and thresholds by amount, entity and customer (approval thresholds for AI agents).
Takeaway: the ERPs keep the books; the layer keeps the work, the evidence and the approvals.
How do you plug in a newly acquired company?
Connect its ERP and bank statements, map its customers and rules to the group rulebook, prove it on that entity, then switch it on: weeks, not a migration project.
Adding an entity in four steps:
- Connect. The integrations hub connects the entity’s ERP by its route and reads its bank statements and remittances; your IT team grants access.
- Map. Your master data team links the entity’s customer numbers to the group cross-reference; its reason codes, tolerances and approval thresholds map to the group rulebook.
- Prove. The entity runs on the layer with a person approving every proposal, and its KPIs are compared with its own baseline.
- Switch on. The entity joins the group worklist and the group forecast; its controller signs off the thresholds.
A proof of value takes 4-5 weeks on one entity, and a full rollout takes up to 4-8 weeks (Transformance customer data, 2026). The plan after a single deal is in how to unify order-to-cash after an acquisition; what drives the timeline is in how long AR automation implementation takes.
Takeaway: a new entity is a connection and a mapping, not a migration.
What happens when an entity finally migrates to a new ERP?
The layer keeps running: the old connection is replaced by a new one, while the rules, history and process stay, so the automation is not lost in the migration.
What carries over: the group rulebook (reason codes, tolerances, approval thresholds), the customer cross-reference, the Customer 360 history and the forecast history. What changes: the connection to the new ERP and the mapping of codes and fields to it. Plan the switch date with the migration team, so open items are read from the system where they are booked.
The effort of the ERP migration itself sits with the migration program. For SAP groups, see whether to automate AR before or after the S/4HANA migration and what brownfield and greenfield mean for AR.
Takeaway: automate before you migrate; the migration swaps a connection, not the process.
Which finance processes should a multi-ERP group automate first?
Start where the systems split the work most: cash application across bank accounts and ERPs, then AR collections with one customer view, then a consolidated cash forecast.
Cash application first. It touches every bank account and every ERP every day, and an unapplied payment makes the aging wrong and the forecast late (intercompany and multi-currency cash application, ClearMatch).
AR collections next. With open items from all ERPs in one customer view, one team works one worklist with one cadence and one record of promises to pay (multi-entity order-to-cash across legal entities, CollectPulse). Deductions can run alongside from the start (ClaimIQ).
Then the group cash forecast. CashPulse forecasts across entities on horizons from 7 to 365 days, including 13 weeks, and feeds your existing treasury system or ERP. The first 13-week forecast is ready in 2-4 weeks (Transformance customer data, 2026). See multi-entity cash flow forecasting and CashPulse.
Takeaway: cash application, then AR collections, then the forecast; each step makes the next one more accurate.
What does buy-and-build change for the finance team?
Every add-on brings another ERP, bank set-up and customer base, so finance must absorb new entities again and again; a layer that adds an entity in weeks makes that repeatable.
In buy-and-build, an investor buys a platform company and then adds smaller companies in the same field. Each add-on repeats the same finance tasks, and a standing finance layer turns them into a routine:
- One playbook. Each add-on follows the four steps above, with the same rulebook and approval model.
- Shared customers seen once. Add-ons in the same field can sell to the same customers; one view shows total exposure.
- One set of numbers. DSO, unapplied cash and the forecast use one definition from the month the add-on is switched on.
If an add-on runs a mid-market ERP, see how AI agents work with Business Central, Sage Intacct, Acumatica, Odoo and SAP Business One.
Takeaway: in buy-and-build, the finance model has to absorb the next deal as well as the last one.
Who Transformance is for
- ERPs: SAP S/4HANA and SAP ECC, NetSuite, Microsoft Dynamics 365 Finance & Operations and Business Central, and Odoo in production with customers; Oracle and Infor supported; connects to the ERP each entity runs through its integrations hub, including older, on-premise and mid-market ERPs.
- Size: mid-market to large enterprise, 250 to 2,000+ employees, including groups with several entities and shared service centers.
- Payment volume: from under 1,000 to over 100,000 payments a month.
- Industries: manufacturing, consumer goods and food and beverage, logistics, e-commerce, agriculture, energy and professional services.
- Scope: cash application alone, or the full order-to-cash (cash application, deductions, AR collections, cash forecasting).
Conclusion: automate now, consolidate when it pays
A group with several ERPs does not have to wait for one. Each ERP keeps the books, Transformance runs order-to-cash and cash forecasting for every entity in one environment, and each acquisition becomes a connection and a mapping. Transformance works with customers such as Syngenta, Eberspächer and PwC, across Europe, the United States and Australasia. Book a Call to scope your first entity.
Key terms
- Order-to-cash: the process from customer order to cash received and applied.
- Cash application: matching incoming payments to the open invoices they pay.
- Sub-ledger: the customer ledger in each ERP, where open items sit.
- Master data management: keeping customer records consistent across systems.
- Deduction management: identifying and resolving amounts customers deduct from payments.
- Cash flow forecasting: projecting cash in and out over set horizons.
Related guides
- Which ERP systems does Transformance integrate with?
- How do you run one AR process across SAP, Oracle and NetSuite?
- How do you unify order-to-cash after an acquisition?
- Which ERPs have an MCP server?
- How do multi-entity groups forecast cash across ERPs?
- What is an agent-run integration platform for finance?
- How do you connect AR automation to a custom or older ERP?
Frequently Asked Questions
Do we need one ERP before we can automate order-to-cash?
No. Each ERP stays the system of record, and entities on different ERPs run in one Transformance environment with one worklist and one forecast.
Which ERPs can Transformance connect to?
Transformance connects to the ERP each entity runs through its integrations hub, with SAP S/4HANA and ECC, NetSuite, Dynamics 365 Finance & Operations and Business Central and Odoo in production with customers, and Oracle and Infor supported.
How does Transformance connect to older or on-premise ERPs?
By API (including OData), RFC/BAPI, files, database, mailbox, an outbound-only on-premise agent or RPA, whichever the system offers. The on-premise agent needs no inbound firewall change and no VPN.
What happens to the automation when an entity migrates to a new ERP?
Only the connection changes. The rules, the customer history and the process in the finance layer stay.
How quickly can a newly acquired company be added?
A proof of value on one entity takes 4-5 weeks and a full rollout up to 4-8 weeks (Transformance customer data, 2026). The ERP connection typically takes 2-3 days for a production ERP (Transformance customer data, 2026), and your IT team may be involved; custom systems are agreed after a feasibility check.
Is this only for private equity buy-and-build groups?
No. It fits any group running several ERPs, from acquisitions, regional set-ups or a migration in progress, with 250 to 2,000+ employees and from under 1,000 to over 100,000 payments a month.
What does it cost to automate order-to-cash across several ERPs?
It depends on scope and the number of entities, from cash application alone to the full order-to-cash with cash forecasting. Book a Call and we scope it with you.
SAP, SAP S/4HANA, Microsoft, Dynamics 365, Business Central, Oracle, NetSuite, Odoo, Infor, SAP Business One, Sage, Sage Intacct and Acumatica are trademarks of their respective owners (SAP SE, Microsoft Corporation, Oracle Corporation, Odoo S.A., Infor, The Sage Group plc, Acumatica, Inc.). Transformance is not affiliated with or endorsed by them.
