Del.ai sells ERP migrations to portfolio companies, so this article has a commercial interest in the argument it makes; weigh it accordingly.
ERP standardization for private equity portfolio companies usually starts as a mandate, not a project. An operating partner reads the board pack after the third add-on acquisition. They find three different charts of accounts and three different close calendars. A finance team spends the first two weeks of every month reconciling formats instead of reporting results. The instinct that follows is almost always the same: standardize everything onto one system.
That instinct is where most standardization mandates go wrong. "One ERP for the whole portfolio" gets read as one shared instance, one database, real-time consolidation across every entity. That is a different, much harder problem than standardization requires. This article separates the two: what standardization needs to mean to work, and what usually gets tried instead. Both come at real cost to the mandate and to the operating partner who championed it.
A roll-up thesis depends on comparable, timely financials across portfolio companies. LPs and lenders expect one reporting cadence, not five. Every add-on acquisition arrives on its own system of record. NetSuite runs one company, QuickBooks another, Sage or a spreadsheet stitched together with macros a third. For the first acquisition, this is a footnote. By the third or fourth, it is a structural problem. Operating partners now call this ERP rationalization private equity portfolios need after an add-on. It starts here: the finance team translates N charts of accounts into one board format every month. Each translation introduces the kind of errors that show up in an audit letter.
In del.ai's read, the pattern that pushes a fund from tolerating this to mandating a fix isn't abstract. It's the reconciliation tax becoming visible in the board pack, usually a year or two after the platform acquisition that started the roll-up. By then, the fund has inherited a legacy ERP decision none of its own operating partners made. We put no number on average ERP tenure — the widely circulated 8.8-year figure is not in the report it is usually attributed to — and the point does not need one. A portco's system of record was chosen under a prior owner at a prior scale, and portfolio comparability was never a design goal of that choice.
Holding periods compound the problem rather than resolving it. Bain's Global Private Equity Report 2026 puts almost 40% of portfolio companies at more than five years held, against 29% in 2019, with the average holding period at exit now running around seven years. A fund therefore owns the ERP-standardization problem for most of a hold period, not for the integration quarter after close. Every quarter the portfolio runs on incompatible systems is reconciliation cost that compounds toward exit and was avoidable. That is why the mandate to standardize ERP across portfolio companies tends to arrive as a board directive rather than an optional initiative.
ERP fragmentation becomes an urgent, board-level problem within roughly a year to eighteen months of the acquisition that pushes a portfolio past two systems of record, not at the moment of the add-on. The trigger is the reconciliation tax: a finance team translating N charts of accounts into one board format every month, at an error rate that shows up in audit letters once a third or fourth entity joins the roll-up. One documented fact compounds it. Holding periods are lengthening — Bain's Global Private Equity Report 2026 puts almost 40% of portfolio companies at more than five years held, up from 29% in 2019, with holding periods at exit now around seven years. A fund therefore owns the fragmentation problem for most of a hold period, not the integration quarter after close. There is no reliable published figure for average ERP tenure at mid-market scale, so treat the age of each portco's system as something to check rather than assume.
Source: Bain & Company, "Private Equity Outlook 2026: Gaining Traction," Global Private Equity Report 2026. ↗
No, and the gap is specific rather than general. Odoo does ship a consolidation tool: account mapping across companies, separate ledgers for consolidation adjustments, a parent-level multi-company view, and cumulative translation adjustments for multi-currency groups. What its documentation does not describe is automated intercompany elimination, a transfer-pricing engine, or jurisdiction-specific statutory consolidation logic — and del.ai does not custom-build those. That is where multi-entity ERP standardization NetSuite Odoo comparisons actually land: Odoo combines and reports, OneWorld performs regulated group accounting. A portfolio that needs one shared instance running that accounting math across jurisdictions should keep evaluating OneWorld or an SAP-class platform, and we will say so on the call rather than three weeks into discovery. What we propose instead is one clean instance per portfolio company on a shared chart-of-accounts template, so books stay legally separate while categories match across the portfolio.
Source: Odoo, "Consolidation," Odoo 19.0 accounting documentation, 2026. ↗
Say the boundary plainly, because burying it is how discovery calls go sideways three weeks in. The trap isn't that operating partners want the wrong thing. It's that "standardize" and "consolidate" get treated as one problem when they're two. Standardization means every portco reports on a comparable ontology and a comparable chart-of-accounts template. A controller in Portco A and a controller in Portco B categorize the same kind of transaction the same way. Consolidation means one shared database performs the accounting math across those entities automatically. It eliminates intercompany transactions, allocates transfer pricing, and produces a statutory filing per jurisdiction. The first is an ontology problem. The second is a tax-and-legal-entity-accounting problem. It's the one that stalls a "one ERP for the whole portfolio" project for a year before it quietly gets shelved.
They standardize the playbook, not the instance. Each portfolio company migrates to its own Odoo instance built from one canonical ontology and chart-of-accounts template, so every controller categorizes transactions the same way without merging any entity's books into a shared database. The mechanism meant to make this a repeatable post-acquisition ERP integration playbook rather than a sequence of one-off projects is mapping reuse: once a source-ERP-to-Odoo mapping exists for the system one portco runs, the next portco on that same source is a configuration-and-validation exercise against a working template rather than a build from a blank page. State the epistemic status plainly, because it is the load-bearing part of this article: that is a design property of how the work is structured and a bet on how the economics behave. It is not a measured result. del.ai has migrated no portfolio companies and has no second-entity cost curve to report.
Source: del.ai cost model, 2026 — our own modelled pricing structure, stated as a design bet rather than an observed outcome.
Two agents are written into the scope we would sign for each portco — a month-end close agent and an FP&A draft agent. Both are at demo stage today, deployed nowhere and referenced by nobody, so read them as what we are committing to build for you, not as software a portfolio company is running this quarter. The design reason we think it is feasible: the ontology is clean the moment a migration completes, and an agent built against one portco's canonical categories reads the next portco's categories the same way.
Here is why the reuse bet cuts against the usual PE-integration math. A generic Odoo systems integrator prices each engagement as its own statement of work, so mapping NetSuite to Odoo for portco #2 costs roughly what it cost for portco #1 — nothing in that pricing model rewards reuse. Our migration starts ~$50k per portco for a standard configuration, with hosting from ~$2k/mo, and complexity scales it up from there. The structural claim is that once a source-system mapping exists, the next portco on that source is configuration and validation rather than a fresh build. Whether that converts into a lower second price is a per-portco negotiation. Hold us to the figure in the scope document, not to this paragraph — and if a second portco does not come in cheaper than the first, the bet did not pay and you should say so.
No, not when each portco's migration is funded by the ERP spend that portco already pays. A company spending $120,000 or more a year on NetSuite license, Alliance Partner retainer, SuiteApps, and admin headcount is carrying a stack that, in a representative mid-market case, totals somewhere between $210,000 and $680,000 a year once every layer is counted, on del.ai's published cost model — a modeled estimate, not an independently verified benchmark. A per-portco migration starting at ~$50k, plus ~$2k/mo in hosting, is typically smaller than one year of what that stack already costs, which means the case to standardize ERP across portfolio companies doesn't route through the fund's IC as a new line item. It routes through each portco's own controller, as a decision to stop paying for what the migration deletes. No fund-level budget ask, no portfolio-wide standardization line item to defend at the next LP meeting.
Source: del.ai cost model, 2026 — our own modelled estimate of a representative mid-market stack, not an independently verified benchmark. Re-run it on your own inputs at ↗
Sum the ERP tax each portco pays separately today: license, Alliance Partner retainer, SuiteApps, BI and ETL tooling, and the internal headcount required to manage all of it. That $210,000–$680,000 range brackets a specific case: for the representative mid-market stack in del.ai's published cost model, the total lands near $429,000 a year. That is a model you can open and re-run on your own inputs, not a survey result. Multiply it by however many portfolio companies still run legacy ERP. The fund pays that tax once per add-on, for as long as standardization is deferred.
The consultant tax deletes the same way, portco by portco. Every AI pilot or reconciliation project that needed an outside consultant to work around a closed ERP disappears once that portco's schema is open and clean. The debugging question — is the model wrong or is the data wrong — stops being unanswerable on a closed system. None of this needs fund-level budget approval. Each portco's math clears on its own before an operating partner has to defend a portfolio-wide number to the investment committee.
See if the standardization math works for your portfolio
30 minutes. We walk through one portfolio company's ERP spend and show you the per-entity math before you take it to the IC. No pitch.
No, not if the migration structure keeps each legacy ERP live until the numbers reconcile. A portco's existing system stays running in parallel through the entire build, so LP and lender reporting for that period never depends on an unproven system, and cutover happens only after outputs match daily during the parallel run. A sound PE roll-up ERP consolidation strategy stages migrations one portfolio company at a time, on a fixed-price basis, so a schedule slip at one portco doesn't put reporting at risk for the rest of the portfolio. Within the scope agreed at signing, del.ai structures each engagement so cost overruns land on del.ai, not on the portco or the fund. That structure matters more across a multi-portco program than in a single migration, because the operating partner is staking credibility on a repeatable process, not one bet.
Source: del.ai migration methodology, 2026 — the engagement structure we contract for, not a record of migrations performed.
The reporting risk in a roll-up isn't about any single migration. It's whether one portco's slip cascades into the fund's board pack for that quarter. Staggering cutovers across the portfolio, rather than attempting a simultaneous multi-entity swap, isolates that risk. Portco #3 running long has no bearing on whether portco #1 or #5 report on time. Per-step rollback applies at each portco individually. If a checkpoint fails at one entity, that entity's migration pauses. It doesn't pull the rest of the program off schedule.
Concretely: say portco #3's weekly reconciliation gate fails in week six because a legacy inventory valuation method doesn't map cleanly to the new chart of accounts. That portco's migration pauses at the last confirmed checkpoint, and its legacy ERP stays the system of record until the mapping is corrected and the gate reruns clean. Portco #1, cut over two months earlier, and portco #5, scheduled for next quarter, are unaffected — each runs on its own signed scope document and its own rollback trigger. The fund's board pack for that quarter shows one portco still mid-migration and four already standardized, not a five-entity program stalled behind the slowest build. A single-portco slip costs that portco weeks, not the fund's reporting credibility for the roll-up.
Every quarter a portfolio runs without a common ontology compounds two costs: the reconciliation tax on the next add-on, and the diligence cost at exit. Buyers running quality-of-earnings work on a roll-up want comparable financials across the portfolio. A fund with one clean ontology's worth of history moves faster through that process. A fund still explaining why five portcos report the same line item five different ways does not.
Waiting for the incumbent is a plan without a date on it, and the reason is definitional rather than anything about Oracle's intentions. An ERP vendor's unit of analysis is the customer. Cross-portfolio standardization — one ontology applied across separately owned legal entities that a fund happens to hold at the same time — has its boundary drawn at the fund, which is not an entity any ERP vendor has a contract with. Nothing on a published roadmap addresses it, and a roadmap is the only thing "wait and see" is betting on.
The window is bounded by the fund's own hold period. With almost 40% of portfolio companies now past five years held and exits running around seven, every add-on acquired partway through that clock adds another entity to reconcile before the buyer's quality-of-earnings team arrives. Comparable financials across the portfolio affect how fast a QoE process moves. In del.ai's view they also affect how confidently a fund defends its multiple at sale — that one is an argument, not a measurement, and we flag it as such. The case for standardizing gets weaker the longer it is deferred, not stronger.
ERP standardization fits PE portfolio companies that each spend $120,000 or more a year on NetSuite or a comparable legacy ERP, have an active board or IC-level mandate to standardize post-acquisition, and are evaluating a repeatable per-portco migration onto one common playbook rather than a bespoke project per entity. It is not a fit for a fund that needs one shared, multi-entity instance running automated statutory consolidation and cross-entity eliminations across jurisdictions today — that remains NetSuite OneWorld or SAP-class territory, and no amount of mapping reuse changes that boundary. Trigger signals worth checking before the next board meeting: a recent or upcoming add-on acquisition, a standardization directive that has been discussed but not yet scoped, and renewal dates approaching across two or more portfolio companies at once. If two or more of those are true, the per-entity math is worth building before the next IC meeting, not after.
Source: del.ai product scope definition, 2026 — our own qualification criteria, not third-party research.
The disqualifier is worth stating once more because it is the one that ends conversations three weeks in if it is buried: if you need one shared multi-entity instance running automated statutory consolidation and cross-entity eliminations across jurisdictions today, this is not it, and no amount of mapping reuse changes that. See NetSuite OneWorld to Odoo: What Actually Transfers (and What Doesn't) for Multi-Entity Companies for the structural gap list — worth reading even if you assume it rules you out, since some portfolio companies pay for OneWorld-class depth their actual legal structure never uses.
30 minutes. Bring one portco's NetSuite bill. We build the per-entity math live and you leave with a number for the IC. If the reuse bet is the part you doubt, say so on the call — it is the part we would doubt too, and there is no case study to wave at you.