Our organization has complex discount scenarios that involve volume tiers, contract-based pricing, partner discounts, and promotional campaigns - often stacked together. Standard CPQ logic handles basic scenarios well, but we’re hitting limitations with discount precedence rules and the ability to apply custom business logic during price calculation. We’re evaluating whether to build a custom pricing engine that hooks into CPQ or try to extend the standard logic through configuration and scripting. The concern with custom development is maintenance burden and upgrade compatibility - every SAP CX release could potentially break our custom engine. But the standard CPQ logic seems too rigid for our needs. What approaches have others taken for complex discount scenarios, and how do you balance customization against upgrade impact?
There’s a middle ground - use CPQ’s extension points rather than replacing the engine entirely. CPQ has BAdIs and user exits specifically for custom pricing logic. You can inject your custom calculations at specific points in the pricing flow without rebuilding the whole engine. This approach is more upgrade-resilient because you’re working within SAP’s extension framework rather than replacing core functionality. We’ve used this successfully for complex partner discount calculations that standard CPQ couldn’t handle.
We went the custom engine route three years ago and honestly regretted it. Every quarterly SAP CX update required testing and often code changes. The custom pricing engine worked great initially but became a maintenance nightmare. If I were starting over, I’d push harder to fit within standard CPQ capabilities, even if it means simplifying some business rules.
Let me share insights on all three critical areas based on implementations I’ve led:
Custom Pricing Logic Considerations:
When to use standard CPQ:
- Discount stacking follows predictable precedence rules (volume → contract → promotional)
- Pricing factors are relatively static or change infrequently
- Business is willing to adapt processes slightly to fit standard capabilities
- You have fewer than 50 unique pricing condition types
- Discount approval workflows follow standard patterns
When custom logic makes sense:
- Real-time pricing based on external factors (competitor prices, inventory levels, market conditions)
- Complex conditional logic that varies by customer segment, product family, and sales channel simultaneously
- Integration with proprietary pricing algorithms or AI/ML models
- Regulatory requirements for pricing transparency that standard CPQ audit trails don’t satisfy
- Need for pricing simulation capabilities beyond CPQ’s what-if scenarios
CPQ Integration Approaches:
If you do need custom logic, integrate it properly with CPQ rather than replacing CPQ:
-
Extension Points (Recommended): Use CPQ’s BAdI framework for custom pricing steps. Implement these specific BAdIs:
- PRICING_BEFORE_CALCULATION: Add custom conditions before standard pricing
- PRICING_AFTER_CALCULATION: Adjust results after standard pricing
- DISCOUNT_VALIDATION: Custom approval logic for discount limits
-
Pricing Service Pattern: Build external pricing service that CPQ calls via REST API. Benefits:
- Decoupled from SAP CX upgrade cycle
- Can be tested independently
- Reusable across multiple systems (e-commerce, sales apps)
- Easier to scale independently
-
Hybrid Configuration: Use standard CPQ for 80% of scenarios, custom logic only for complex edge cases. Route quotes through different pricing paths based on complexity flags.
Upgrade Impact Management:
This is where most custom implementations fail. Minimize upgrade pain:
- Use SAP’s extension framework exclusively - never modify standard CPQ code
- Document all custom pricing logic with business justification (helps during upgrade decisions about whether to keep customization or adopt new standard features)
- Implement comprehensive automated testing - test every pricing scenario after each upgrade
- Version your custom pricing logic to match SAP CX versions
- Maintain a “standard CPQ configuration” sandbox to compare behavior against your customized system
- Plan for 20-40 hours of testing and potential adjustments per major SAP CX release
For your specific scenario with volume tiers, contract pricing, partner discounts, and promotions, here’s my recommendation:
Start with maximizing standard CPQ configuration:
- Use pricing procedures with proper step sequencing for discount precedence
- Leverage condition tables for volume tier and contract pricing
- Use pricing agreements for partner-specific discounts
- Configure promotional pricing with validity periods
Only add custom logic for truly unique requirements that standard CPQ can’t handle. Based on what you’ve described, I estimate 85-90% can be achieved with standard CPQ if you configure it properly. The remaining 10-15% might need custom BAdI implementation for specific edge cases.
The maintenance burden of custom pricing engine is real - budget 0.5-1 FTE ongoing just for maintenance and upgrade compatibility. Standard CPQ configuration requires less ongoing effort, maybe 0.2 FTE for adjustments and minor enhancements. Make the business case based on these realistic TCO numbers.
I’ve implemented both approaches across different clients. The decision really comes down to how far outside standard CPQ capabilities your requirements are. For most scenarios involving discount stacking, volume tiers, and contract pricing, standard CPQ with proper configuration handles it. Custom engines make sense only when you have truly unique logic like dynamic pricing based on real-time market data or AI-driven pricing recommendations.
One aspect to consider is where the pricing complexity actually lives. If your complex rules are based on external data (customer history from ERP, market pricing from third-party services), you might be better off with a custom pricing service that CPQ calls via API rather than embedding logic directly in CPQ. This way the custom logic is decoupled and easier to maintain independently of SAP CX upgrades.