Why procurement pricing breaks in cloud ERP migrations

Most cloud ERP migration business cases get the headline numbers right. Infrastructure savings, license consolidation, reduced IT overhead. The numbers look clean, the project gets approved, and the migration begins.

What rarely makes it into the business case is procurement pricing. Not because nobody thought about it, but because the gap doesn’t surface until after go-live when changing course isn’t really on the table anymore.

The gap nobody warned you about

Oracle EBS had a dedicated advanced pricing engine built directly into purchasing. Not an add-on—core functionality. Supplier-specific price lists, category-based pricing, qualifier-based rules tied to contract purchase agreements, formula-driven pricing for complex scenarios, modifiers for discounts and surcharges on top of base prices. When a purchase order referenced the right contract and supplier, the system pulled the correct price. Buyers didn’t have to do anything.

Oracle Fusion Cloud doesn’t have that. Not as standard configuration and not as a settings toggle. The advanced pricing engine that lived inside Oracle Purchasing in EBS simply isn’t integrated with the procurement module in Fusion Cloud. Organizations that built their procurement operations around contract-linked price lists, qualifier-based pricing rules, or formula-driven pricing find that none of those structures survive the migration natively.

This isn’t speculation. Oracle’s own customer community has documented it for years—multiple open enhancement requests on Cloud Customer Connect, companies in manufacturing, distribution, and healthcare describing the same problem. The requests are still open.

I’m not making a case against Oracle specifically. Cloud ERP platforms are built for standardization and scalability, and they do that well. The tradeoff is that organizations often lose the sophisticated pricing capabilities that mature on-premise systems handled behind the scenes. Most organizations don’t find this out until after go-live, which is the worst possible time to redesign a procurement architecture.

What actually breaks

In EBS, a buyer creating a purchase order for a raw material supplier would reference the contract purchase agreement. The system pulled the correct price—simple unit price, formula-based calculation, qualified rate specific to that supplier and agreement. The PO went out with the right number. Approvals ran automatically.

In Fusion Cloud, that mechanism doesn’t exist in standard procurement. The price doesn’t default. The buyer has to enter it manually, or the PO goes out blank and gets flagged. Either way, someone has to intervene.

That intervention goes into an approval queue. In a complex enterprise, manual review doesn’t happen in an afternoon. In organizations I’ve worked with, approval cycles for purchase orders requiring manual price validation ranged from one day to 14—depending on approver availability, urgency, and what else was ahead of it.

Fourteen days. For a purchase order that should have been auto-priced and auto-approved.

Multiply that across raw material categories, across dozens of suppliers, across a manufacturing operation that can’t hold production while waiting for materials to be ordered, approved, manufactured, and shipped. The warehouse runs out of inventory on its own schedule. It doesn’t adjust for your ERP migration timeline.

The project was sold on efficiency. The reality is procurement teams running manual workarounds that cost more in operational overhead than the migration saved in licenses.

Why it keeps getting missed

Pre-migration assessments focus on what the new system can do. Vendor demonstrations show the platform at its best. Implementation partners scope around standard functionality. The people defining migration scope—usually IT and project management—often don’t have enough visibility into how procurement actually prices things to know what to ask.

The people who do know—category managers, the procurement leads who actually negotiate supplier contracts—usually aren’t in the room when scope is being defined. By the time the gap surfaces, the project is committed and the implementation partner is already billing.

This is a process failure. The information exists. It just doesn’t get asked for at the right time.

The question to ask before you sign

One question will tell you more about your pricing risk than any vendor demonstration:

What advanced pricing functionality from our current ERP environment will not be available after migration to cloud—and what is your recommended workaround for each gap—before we sign the contract?

Press for specifics. If the answer is “it’s on our roadmap,” ask when. “We recommend a third-party solution”—ask which one, what it costs, how it integrates, and who supports it when something breaks at 2 a.m. “Most customers don’t need that functionality”—ask to speak with a customer in your industry who migrated with complex supplier pricing and came out intact.

These aren’t difficult questions. They just get asked too late, or not at all.

How organizations close the gap

When standard cloud procurement pricing falls short, there are three realistic paths.

Accepting the limitation and redesigning procurement operations around what the cloud system supports natively. This works if your pricing is simple—a unit price per item, no formula logic, no supplier-specific rate structures. It stops working the moment contracts involve qualifier-based pricing rules, tiered rates, or formula-driven calculations that vary by agreement.

Third-party integration—connecting the cloud ERP to a specialized pricing engine or contract management platform. This can close the gap, but it introduces integration complexity, additional licensing costs, and a dependency on vendor support that almost always gets underestimated. The integration also needs to survive quarterly Oracle cloud updates, which creates a recurring maintenance burden most teams don't plan for.

Custom extension architecture—building the missing functionality directly inside the cloud ERP’s extensibility framework. When designed correctly, this keeps pricing logic inside the procurement workflow, preserves the platform’s upgrade path, and eliminates the overhead of managing a third-party integration. The tradeoff is that it requires deep Oracle Fusion Cloud technical expertise to build extensions that stay functional as the platform evolves and don’t create data integrity problems downstream.

The organizations that come out the other side without a crisis are, almost without exception, the ones that treated the gap-closure architecture as a first-class project deliverable—not something to figure out after go-live.

What to do before the business case closes

Pull a sample of your top 50 purchase orders by spend. For each one, figure out how the price was determined –simple unit price from a blanket agreement, formula-based calculation, qualifier-driven rate tied to a specific contract, or a manual override someone entered because nothing else worked. How many of those pricing structures exist natively in the system you’re migrating to? That number tells you more than the vendor demo.

Get procurement in the room before the vendor is selected. Category managers and procurement leads who negotiate supplier contracts know where the complexity lives. Their input during vendor evaluation is worth considerably more than their feedback during user acceptance testing, at which point the decisions have already been made and the budget has already been committed.

Get the gap list in writing before signing. Ask the implementation partner to document every functional gap between your current system and the target platform—including pricing—and document their proposed approach for each gap. A signed statement of work that doesn’t address known limitations isn’t a plan. It’s a transfer of risk onto the business.

A final word

Moving to cloud ERP makes sense for most organizations. I believe that. The maintenance advantages, the scalability, the integration ecosystem—those benefits are real and they compound over time.

But cloud doesn’t mean complete. In procurement specifically, the gap between what a mature on-premise system handles and what a current-generation cloud platform supports can be significantly wider than the business case assumed—and significantly narrower in the vendor documentation than in practice.

The organizations that navigate this without a crisis understood what they were giving up before they signed. They went in with their eyes open. That’s not a high bar. It just requires asking the right questions at the right time.

About the author

Anil Yellepeddi is an Oracle ERP procurement architect with 18 years of experience designing procure-to-pay solutions for global enterprises and international organizations, including engagements with the World Health Organization and the International Atomic Energy Agency.

Disclosure: The author works in an enterprise IT leadership role at a large U.S. manufacturing company. Views are the author’s own.

SC
MR