Where Cloud ERP Is Actually Headed Next

A controller at a 300-employee industrial parts distributor spent four months in 2025 testing an AI copilot bundled into her Dynamics 365 Finance instance. It drafted expense report codings, suggested GL account matches for uncategorized vendor invoices, and flagged three duplicate payments before they went out. It also, on two separate occasions, proposed posting a capital expense to an operating account because the vendor's invoice description used ambiguous language the model had not seen before. Both times a human caught it before month-end close. That gap, genuinely useful at drafting, still wrong often enough to need a reviewer, is a more accurate picture of where cloud ERP is headed than most vendor keynote decks suggest.

AI copilots are doing draft work, not judgment work

Every major cloud ERP vendor now ships some form of embedded AI assistant: SAP's Joule, Oracle's Fusion AI agents, Microsoft's Copilot for Dynamics 365, NetSuite's Text Enhance and SuiteAnalytics tools. The pattern across all of them is consistent once you look past the marketing language: these tools are good at pattern-matching against historical data, such as suggesting a GL code because 94 percent of past invoices from that vendor used it, drafting a purchase order description, or summarizing a customer's payment history into a collections note. They are unreliable at anything that requires judgment about a case the historical data does not clearly cover.

The practical implication for a finance or operations team evaluating these tools is narrow but useful: budget for a human review step on anything that touches the general ledger or triggers a payment, and treat the copilot as a drafting assistant that cuts the time to produce a first pass, not a system that removes the reviewer. Vendors are not hiding this. Microsoft's own documentation for Copilot in Dynamics 365 Finance describes suggested categorizations as requiring user confirmation, not as final postings. The gap between that fine print and how the feature gets described in a sales demo is where expectations go wrong.

The failure mode is consistent enough that it is worth watching for a specific pattern: copilots trained primarily on structured historical data perform well on repetitive, well-labeled transactions and poorly on anything novel, ambiguous, or the first instance of a new vendor relationship. The rollouts that work well tend to build an explicit confidence threshold into the workflow: an AI-suggested posting under a defined dollar amount, or one that matches a clear historical pattern, moves through with lighter review, while anything above the threshold or without a clear match routes to a human queue automatically. That kind of guardrail, not blind trust in the suggestion, is what a mature deployment looks like in 2026.

Composable ERP: the monolith is losing ground to APIs

The second real shift is architectural, not conversational. For twenty years, implementing ERP meant picking one vendor's suite and living inside its modules, its CRM, its warehouse management, its budgeting tool, even when a best-of-breed point solution did any one of those jobs better. That is changing because API surfaces have gotten good enough to make swapping in a specialized module a realistic option rather than an integration project that takes a year.

NetSuite's SuiteTalk and RESTlet APIs, SAP's Business Technology Platform, and Microsoft's Dataverse connectors all now support the kind of near-real-time, bidirectional data sync that used to require custom middleware and a six-figure integration budget. A company running core financials in NetSuite can plug in a dedicated warehouse management system like Fishbowl or a specialized planning tool like Anaplan without waiting for NetSuite's native module to catch up, and without building a brittle nightly batch sync to hold it together.

This is what "composable ERP" means in practice, and it is less about a specific product and more about a buying posture: evaluate the core ERP on its API quality and its willingness to be a system of record rather than a system that does everything, and treat best-of-breed point solutions as a normal part of the stack instead of a workaround.

Celigo and Workato have both built businesses specifically around this shift, packaging pre-built connector templates between ERP systems and the point solutions companies actually want to bolt on: a specialized e-commerce platform, a dedicated EDI gateway for retail trading partners, a niche compliance tool for a regulated industry. The pitch used to be "buy our module." Increasingly it is "connect our API," and vendors that resist making that connection easy are losing deals to ones that do not.

The pricing model is moving from seats to consumption

Per-user, per-month licensing has been the default cloud ERP pricing model since the shift away from perpetual licenses began in the mid-2010s. It is starting to fray at the edges. Oracle Fusion and several mid-market platforms now offer consumption-based tiers for specific workloads, such as transaction volume, API call volume, or storage, alongside or instead of a flat per-seat rate, mirroring the pricing model cloud infrastructure providers have used for years.

The reason this matters is not abstract. A company with 40 named ERP users but a high-volume e-commerce integration pushing thousands of order transactions a day was, under a pure per-seat model, paying for user count that badly understated its actual load on the system. Consumption pricing captures that load more accurately, which can cut either way: it is often cheaper for a low-user, high-transaction business, and more expensive for a large team with light system usage. Anyone renewing or shopping a contract in the next two years should ask the vendor directly whether a consumption-based tier exists for their workload profile and run the numbers both ways before assuming the seat-based quote is the only option. The TCO calculator is a reasonable place to model that comparison before a renewal conversation, since a shift in pricing structure changes the total cost picture more than a simple per-seat discount would.

The practical wrinkle is that consumption pricing makes cost less predictable month to month, which finance teams used to fixed per-seat billing tend to dislike even when the total is lower. Vendors offering consumption tiers have generally responded with committed-use discounts, similar to cloud infrastructure reserved instances, where committing to a baseline volume in advance locks in a lower rate while usage above that baseline is billed at a higher marginal rate. Reading the marginal rate carefully matters more than the headline discount, since a spiky business with unpredictable transaction volume can end up paying more at the margin than it saved on the baseline.

Lock-in did not disappear, it moved

On-premise ERP lock-in was about data: records lived in a database the company controlled, migrating meant a genuinely hard data extraction project, but the company was never at the mercy of a vendor's roadmap for basic functionality. SaaS ERP inverted that. Data export is usually straightforward now; most vendors will hand over a database dump or API access without much friction, partly because regulators in several jurisdictions require it. What is hard to walk away from is the surrounding ecosystem: the custom workflows built on a vendor's low-code platform, such as Power Automate flows tied to Dynamics or SuiteScript customizations in NetSuite, the reporting built on a vendor-specific BI layer, and the staff trained on a specific system's quirks rather than transferable ERP concepts.

That is a subtler form of lock-in than a data hostage situation, and it is easy to underweight during a purchase because it does not show up as a contract clause. The practical defense is architectural discipline during implementation: keep custom logic in standard, portable formats where the platform allows it, document integrations well enough that a different implementation partner could pick them up, and treat heavy investment in a vendor's proprietary low-code tooling as a cost that should factor into any future switching decision, not a free convenience.

A useful gut check during any SaaS ERP purchase is to ask how many hours of consultant time it would take to rebuild the current set of customizations and integrations in a different platform, not how many days it would take to move the underlying data. Companies that have gone through a forced SaaS-to-SaaS migration, whether from an acquisition, a vendor's end-of-life announcement, or a failed implementation, consistently report that the workflow and integration rebuild dwarfs the data migration effort.

What this means for a shortlist

None of these four shifts changes the basic ERP shortlisting exercise, but they change the questions worth asking during it. Ask a vendor for a real example of where their AI features got something wrong and how the system flagged it for review, not just a demo of the feature working correctly. Ask how much of the platform's functionality is exposed through documented, versioned APIs versus locked inside a proprietary module. Ask whether a consumption-based pricing tier exists and get a quote under both models. And ask, specifically, what proportion of a typical implementation for a company of similar size ends up depending on the vendor's own low-code or scripting layer, since that number is a reasonable proxy for how hard a future migration would be.