Currency Conversion in Multi level / Multi Market Pricebook setup

[S0023011474]

Hi CPQ Team,
a bit of background. We are working with CPQ Quote 2.0 for a global company. For now the pricing should be maintained via pricebooks. This was fine for the first two Markets we rolled out. 
Now we have markets that are required to quote in various currencies besides the default currency. The standard currency conversion feature does only work if maintain the price books (so copies of the original one) in the Market currency. This currently leads to 100+ pricebooks that need to be maintained, and it's hard to keep track of price changes, ensure all pricebooks are consistent.
Is there a way (possibly via scripting) to change the currency on quote level and keep the Market and pricebook settings?
With that we could get down to a setup where every market would just need to maintain the pricebook in their leading currency.

Appreciate your answers!

Cheers

JD

[prithvi_reddy_cpq]

Solution 1: Market-Based Currency Segmentation

Due to SAP CPQ’s constraint that each market can be associated with only one currency, the straightforward approach is to create one market per region, each configured with its leading currency. While this setup aligns with CPQ’s standard architecture, it introduces significant overhead:

• Requires maintaining multiple pricebooks — one per market-currency combination.
• Increases complexity in managing price updates and ensuring consistency across markets.
• Becomes difficult to scale and audit as the number of markets grows.

---

Solution 2: Quote-Level Currency Selection with Custom Pricing

In a previous project involving SAP CPQ integrated with Salesforce (SFDC), we implemented a more scalable solution using custom pricing logic:

• A quote-level custom field was introduced to allow users to select the desired currency for the quote.
• Upon adding items to the quote, a quote script dynamically updated item prices based on the selected currency.
• Instead of relying on standard pricebooks, custom tables were used to store base prices and exchange rates.
• The pricing was handled entirely via custom pricing, allowing flexibility and reducing the need for multiple pricebooks.

This approach significantly reduced administrative overhead and improved maintainability, especially in multi-currency environments.

[S0023011474]

Hi prithvi_reddy_cpq,

[S0023011474]

Hi prithvi_reddy_cpq, thank you very much for your response. This very much aligns with my findings so far. It's a pity that this (in my mind standard use case) is so complex to support with pricebooks. Currently I'm looking into other options (replicating the pricebook lookup via a custom script or automatically create the pricebooks in the market foreign/non-default currencies via API)

[S0023011474]

Hi prithvi_reddy_cpq, thank you very much for your response. This very much aligns with my findings so far. It's a pity that (in my mind standard use case) is so hard to realize in the system. I'm looking into other options right now (Replicate the pricebook lookup via script in the base price of the product and then use the standard currency exchange feature, or automatically replicate the pricebooks in the non-default market currencies via API)