Mercura CPQ + Oracle NetSuite
Configure complex products, calculate the right price and create order-ready quotes while Oracle NetSuite remains your ERP system.
Mercura adds a dedicated product configuration and quoting layer for manufacturers selling configurable, make-to-order and engineer-to-order products. Keep NetSuite as the operational system of record while Mercura handles the product and sales complexity required before a clean order can be created.
Sales quotation
What is CPQ for NetSuite?
CPQ stands for Configure, Price, Quote. A NetSuite CPQ process connects the decisions required to sell a configurable product with the commercial and operational processes managed in Oracle NetSuite. Instead of expecting a salesperson to manually determine the correct product, options, dimensions, components and price, a CPQ system guides them through the configuration and validates each decision. The resulting configuration can then become a structured NetSuite estimate, sales order or manufacturing input without somebody recreating the order manually.
The buyer or salesperson describes what needs to be achieved.
Determine the valid product, options, dimensions and accessories.
Combine ERP pricing with configuration-specific formulas, additions, discounts or commercial rules.
Generate a customer-ready proposal containing the correct commercial and technical information.
Transfer the approved result into the agreed NetSuite sales and manufacturing process.
NetSuite continues to run the ERP process. Mercura handles the product and sales complexity required before a clean order can be created.
Native NetSuite CPQ
Yes. And that matters when choosing your architecture.
Oracle offers NetSuite CPQ, a native CPQ solution for NetSuite. It includes product configuration, rules-based pricing, proposals, guided selling, visualization, ecommerce integration and manufacturing capabilities. Oracle also provides NetSuite CPQ Manufacturing and a NetSuite CPQ AI Assistant.
Not the question
Can NetSuite do CPQ?
The better question
Which CPQ architecture is right for the way we sell our products?
For some companies, native NetSuite CPQ is the natural choice. For others, it makes more sense to keep NetSuite as the ERP platform while using a dedicated, composable CPQ platform for configuration, visualization and digital sales experiences. That is where Mercura fits.
Architecture choice
There is no universal answer. The right choice depends on your product complexity, sales channels, user experience requirements and system architecture.
Put ERP responsibilities in NetSuite. Put configuration responsibilities in the system best suited to managing product complexity.
System responsibility
The exact ownership of each data object is defined during implementation. A good CPQ integration does not duplicate business logic unnecessarily.
ERP and master data
Configure · Price · Quote
Commercial and operational execution
Oracle SuiteTalk REST Web Services documentation →
Yes. Mercura consumes the agreed ERP master data and returns the approved commercial result into the agreed NetSuite transaction structure.
Yes. Mercura can power internal sales tools, dealer portals, customer self-service and custom applications while NetSuite remains the ERP backend.
Yes. Oracle recommends SuiteTalk REST Web Services with OAuth 2.0 for new integrations. SOAP is being phased out for new integrations from NetSuite 2027.1.
What Mercura adds
Turn engineering knowledge, compatibility requirements and commercial logic into reusable configuration rules. Instead of salespeople remembering which components fit together, Mercura evaluates the configuration while the user works.
A customer may know the problem they need to solve without knowing your item numbers. Mercura can start with requirements rather than ERP fields.
What are you trying to achieve?
Show users what they are configuring rather than asking them to interpret item codes. The visualization reacts to the same configuration logic used to validate and price the product.
Sales channels
A major architectural decision is where users should configure the product. Mercura can power multiple routes to market while the resulting order continues into NetSuite.
Give salespeople a structured process for turning requirements into a valid configuration and quote.
Expose the relevant assortment, configuration rules and commercial logic to external sales channels.
Allow customers to explore and configure products directly through your website or portal.
Use Mercura APIs and frontend capabilities to place configuration inside an existing digital experience.
One configuration model can therefore support multiple routes to market while the resulting order continues into NetSuite.
Mercura product experience
Mercura can power an internal sales tool, dealer portal or customer-facing configurator. The interface carries your brand; the configuration model keeps every choice valid; NetSuite remains the operational system behind the sale.
Shown: a live Mercura-powered configurator. This demonstrates the buyer experience, not a claim that this customer uses the NetSuite integration.
Proposal generation
A technically correct configuration is only part of the sales process. The same structured data can be used to generate professional sales documents containing the information relevant to the customer.
NetSuite handoff
Once a configuration has been approved, Mercura maps the result into the agreed NetSuite transaction structure. The mapping depends on your NetSuite account, enabled modules, custom records, SuiteApps and manufacturing model.
From configuration to commitment
Use the same structured configuration to create branded proposal documents — then map the approved result to Oracle NetSuite.
REST-first integration
NetSuite provides SuiteTalk REST Web Services for external applications to work with NetSuite records through REST APIs. REST services support record operations, and SuiteQL can be used when more advanced querying is required.
Oracle recommends REST Web Services and OAuth 2.0 for new NetSuite integrations. Oracle has also announced the phase-out of SOAP Web Services, with new SOAP integrations no longer supported from NetSuite 2027.1 and final SOAP removal planned for 2028.2. For that reason, new Mercura implementations should be designed REST-first rather than building new dependencies on SuiteTalk SOAP.
Oracle SuiteTalk REST Web Services documentation →Technical evaluation
A typical integration architecture may include the following exchange patterns. This is not a fixed template — a NetSuite implementation often contains custom fields, custom records, workflows, SuiteApps and company-specific transaction structures.
| Data | Direction | Purpose |
|---|---|---|
| Items | NetSuite → Mercura | Reuse ERP item master data |
| Customers | NetSuite → Mercura | Customer-specific configuration and quoting |
| Units of measure | NetSuite → Mercura | Keep quantities consistent |
| Subsidiaries | NetSuite → Mercura | Support multi-company structures |
| Currencies | NetSuite → Mercura | Commercial context |
| Pricing inputs | NetSuite → Mercura | Use ERP pricing as an input to CPQ |
| Inventory information | NetSuite → Mercura | Show relevant availability where required |
| Custom records / fields | NetSuite → Mercura | Reuse company-specific ERP data |
| Configuration reference | Mercura → NetSuite | Trace configuration back to CPQ |
| Configured line items | Mercura → NetSuite | Create clean transactional lines |
| Estimate | Mercura → NetSuite | Continue the quotation process in ERP |
| Sales order | Mercura → NetSuite | Continue the order-to-cash process |
| Technical values | Mercura → NetSuite | Preserve configuration-specific attributes |
| Component information | Mercura → NetSuite | Support configure-to-order processes where appropriate |
Pricing ownership
There is no reason to rebuild commercial logic in CPQ simply because a CPQ system has a pricing engine. The correct architecture depends on where your prices are maintained today.
NetSuite remains the pricing source and Mercura retrieves the relevant commercial result during the configuration process.
Best when
NetSuite already calculates the final price required by the sales process and CPQ mainly solves product configuration.
NetSuite supplies relevant item, customer or base pricing. Mercura then calculates configuration-dependent additions — for example base machine plus selected size, material factor, motor option, control package and accessories.
Best when
Commercial master data belongs in ERP but the final price depends on selections, dimensions, formulas or calculated properties.
The complete pricing model is calculated in Mercura and the resulting line price is transferred to NetSuite.
Best when
Pricing is inseparable from the configuration model and depends heavily on technical parameters, calculations and product relationships.
NetSuite itself has significant pricing functionality, and native NetSuite CPQ can extend standard NetSuite pricing with configuration-dependent rules. If Mercura is used as the CPQ layer, each pricing rule should have a clear home. ERP pricing where ERP is best. Configuration pricing where configuration context is required.
Manufacturing handoff
For manufacturers, quotation is not the end of the process. Production needs to understand exactly what was sold. NetSuite's own CPQ Manufacturing functionality can generate work orders based on configured materials and routing steps. When Mercura is used instead, we first determine how your existing NetSuite manufacturing model should receive the configuration rather than imposing one universal BOM architecture.
Mercura determines which existing NetSuite item corresponds to the selected configuration.
Best when: The range of manufacturable variants is already represented by items in NetSuite.
A base item represents the product family while Mercura supplies additional configuration-specific parameters.
Best when: You do not want a separate ERP item for every theoretical product combination.
Mercura calculates required components and quantities from the product configuration and sends the agreed structure into the downstream process.
Best when: The manufacturing structure genuinely changes based on customer selections.
Mercura automates the repeatable commercial configuration and sends structured parameters to CAD, engineering or another technical system before the resulting structure continues into NetSuite.
Best when: Each order still requires engineering work, but a significant part of that work can be standardized before engineering becomes involved.
The right architecture depends on your manufacturing process. We do not assume every manufacturer should generate BOMs in exactly the same way.
Three-way comparison
| Capability | NetSuite ERP | Native NetSuite CPQ | Mercura + NetSuite |
|---|---|---|---|
| ERP and financials | Core responsibility | Uses NetSuite | NetSuite remains responsible |
| Items and customers | Core responsibility | Native access | Integrated from NetSuite |
| Product configuration | Limited without CPQ | Yes | Yes |
| Rules-based pricing | ERP pricing | Yes | Yes |
| Guided selling | Not the core ERP purpose | Yes | Yes |
| Product visualization | Not the core ERP purpose | 2D capabilities | 2D and interactive 3D |
| Proposal generation | ERP sales documents | Yes | Yes |
| SuiteCommerce | Native NetSuite ecosystem | Native integration available | Can integrate into external digital experiences |
| Custom dealer/customer UX | Requires additional solution | Depends on chosen NetSuite architecture | Core Mercura use case |
| Headless/custom frontend architecture | Not an ERP objective | Requires NetSuite-specific architecture | Core Mercura architecture |
| Manufacturing handoff | Core execution platform | CPQ Manufacturing available | Integrates configured output with NetSuite |
| Best fit | Standard ERP execution | Companies wanting CPQ inside the NetSuite ecosystem | Companies wanting a dedicated CPQ layer across NetSuite and external sales channels |
Oracle CPQ vs NetSuite CPQ
Oracle CPQ and NetSuite CPQ are not the same product. The Oracle product portfolio contains more than one CPQ offering.
NetSuite CPQ is a CPQ solution specifically within the NetSuite ecosystem.
Oracle CPQ is Oracle's broader enterprise Configure, Price, Quote application within its CX portfolio — a cloud application for configuring products and services and creating accurate quotes.
This page is specifically about Mercura CPQ + Oracle NetSuite ERP.
When CPQ earns its place
You probably do not need another CPQ system if a salesperson mainly selects standard items, enters quantities and applies an existing NetSuite price. A dedicated CPQ layer becomes more valuable when creating the correct order requires knowledge or calculations that go beyond standard item selection.
Products
Sales process
The goal is not to add another application to your stack. It is to remove complexity from the quote-to-order process where that complexity actually exists.
Landscape qualification
There is no credible one-click integration promise for a heavily customized ERP environment. Before defining the integration, we identify:
Delivery path
The integration is one workstream. The bigger win comes from making product, pricing and sales knowledge explicit enough to automate.
Capture options, dependencies, formulas, pricing inputs and the expected NetSuite transaction output.
Output: validated pilot model
Identify items, customers, pricing, custom records, estimate or order fields, REST coverage and error handling.
Output: field-level interface map
Design the guided flow, permissions, visual feedback and customer document around real users and channels.
Output: testable end-to-end workflow
Compare Mercura output with NetSuite, train a focused user group and expand product by product.
Output: governed rollout
Decision support
Yes. Oracle offers a native NetSuite CPQ solution with product configuration, dynamic pricing, quote and proposal functionality, guided selling, ecommerce capabilities and manufacturing extensions. Mercura is relevant for organizations that want NetSuite to remain the ERP while using a separate CPQ platform for product configuration and digital sales experiences.
No. Mercura does not replace NetSuite as the ERP. NetSuite continues to manage the operational and financial processes that belong in ERP. Mercura adds configuration, guided selling, visualization, configuration-specific calculations and quote automation around the sales process.
Yes. Mercura can be used as a dedicated CPQ layer alongside NetSuite ERP instead of using native NetSuite CPQ. The better architecture depends on your product complexity, sales channels, frontend requirements and how tightly you want configuration logic coupled to NetSuite.
They are separate Oracle products. NetSuite CPQ is the CPQ offering within the NetSuite ecosystem. Oracle CPQ is Oracle's enterprise CPQ application in its broader CX portfolio. Mercura can be evaluated as an independent CPQ layer connected to NetSuite ERP.
New implementations should normally use NetSuite SuiteTalk REST Web Services with OAuth 2.0 authentication. SuiteQL can be used for more advanced queries, while RESTlets or other NetSuite customizations can be introduced where standard REST records are not sufficient.
Oracle SuiteTalk REST Web Services documentation →Existing integrations may still use SOAP, but we would not recommend SOAP as the foundation for a new NetSuite integration. Oracle recommends REST Web Services for new integrations and has announced the eventual removal of SOAP Web Services.
Yes. NetSuite can calculate pricing, provide pricing inputs to Mercura, or receive a configured price calculated by Mercura. The correct model depends on where your pricing logic is maintained and whether final price depends on configuration-specific calculations.
The approved configuration can be mapped into the agreed NetSuite sales transaction flow, including configured lines and relevant commercial and configuration information. The exact transaction design depends on your NetSuite setup and required approval process.
Yes, relevant inventory or availability information can be incorporated where it adds value to the configuration process. NetSuite should remain the source for inventory data rather than duplicating inventory management inside CPQ.
A multi-subsidiary architecture can be supported by mapping the relevant company, subsidiary, assortment, currency, customer and integration context. The exact design should be validated against the customer's NetSuite OneWorld setup.
Yes, Mercura can calculate configuration-dependent component information. Whether that should become an existing assembly, configuration parameters, a component structure, a work order input or an engineering handoff depends on the manufacturing architecture used in NetSuite.
Yes. A common architecture is CRM → Mercura CPQ → NetSuite. The CRM owns the opportunity and customer-facing sales activity, Mercura owns the configuration process, and NetSuite handles ERP execution. Mercura can also be embedded into a custom portal or sales application.
Yes. Mercura can provide dedicated internal, distributor, dealer or customer-facing configuration experiences while NetSuite remains the backend ERP. This is one of the main reasons to use a dedicated CPQ layer rather than requiring every configuration interaction to happen inside the ERP interface.
Official technical resources
Technical content last reviewed August 2026. Validate assumptions against your NetSuite edition, release and enabled modules.
Explore the capability stack
See it on your process
Configure in Mercura. Execute in NetSuite.
Oracle NetSuite is already capable of running the operational side of a sophisticated manufacturing business. The question is whether your product configuration process should live there too. Bring a sample product, NetSuite item structure or existing quotation process and we can map how configuration, pricing and order data should move between the systems.