A pricing engine calculates selling prices automatically from cost, margin targets, customer groups, quantity, supplier, or other business rules - instead of a manually maintained value per product. It starts to matter once prices can no longer be reliably managed as a single hand-edited field per item: a margin change, a rounding convention, or a supplier cost update needs to propagate to every affected product without anyone editing rows by hand.
PIMSuite includes a rules-based pricing engine built for exactly that.
When does a single product price stop being enough?
A single price field per product works fine as long as nothing changes. That usually stops being true once one or more of the following apply:
- supplier costs change regularly
- multiple suppliers carry the same product at different costs
- margins differ by product family
- B2B customers get different prices than consumers
- quantity tiers need to be accounted for
- different channels need different pricing logic
- prices need automatic psychological rounding (€19.99 instead of €20.04)
- minimum margins must never be undercut
- promotional prices need a compare-at price or price history
One of these alone is often still manageable in a spreadsheet. Several of them together turn the spreadsheet into the error source - that's roughly the point where a pricing engine starts paying for itself.
How a rules-based pricing engine works
At the core, every rules-based price calculation follows the same shape:
Cost basis
↓
select the matching rule
↓
apply margin / markup
↓
rounding
↓
price type (selling, RRP, compare-at, B2B)
↓
output to shop / ERP / marketplace
Cost basis: the starting value, usually the supplier cost - with multiple suppliers, you first need to decide which cost value applies (see below).
Rule selection: where several rules could apply, the most specific one wins (see rule hierarchy).
Margin/markup: the actual formula that turns cost into a price.
Rounding: the raw calculated value gets adjusted to a sensible final digit.
Price type: the same formula can behave differently per price type - a B2B price is rarely just a flat discount off the selling price.
Worked formula examples
PIMSuite pricing rules are formulas, not free-text percentages. That keeps them readable and auditable:
| Goal | Example |
|---|---|
| 40% markup | cost * 1.4 |
| 40% margin | cost / 0.6 |
| Minimum price | max(cost / 0.7, 19.90) |
| Psychological rounding | result → nearest .99 |
| Currency markup | cost * exchange_rate * 1.35 |
Markup is not the same as margin
This is one of the most common sources of pricing errors, and the gap is bigger than it sounds.
Starting cost: €60
- 40% markup (
cost * 1.4) → selling price €84, margin ≈ 28.6% - 40% margin (
cost / 0.6) → selling price €100, margin = 40%
Mix up "40% on top" with "40% margin" and you end up pricing meaningfully too thin or too generous depending on which one you meant. Because PIMSuite rules are explicit formulas rather than a single percentage field, which one you mean is unambiguous the moment you write the rule.
Rule hierarchy and precedence
Rules apply at four levels of specificity: default (all products), family (a product type), supplier (all products from one supplier), and product (a specific SKU). The most specific matching rule wins automatically.
A worked example:
- Default: 30% margin on all products
- Family "Accessories": 45% margin
- Supplier X: minimum 35% margin
- SKU ABC123: fixed exception, €24.99
A regular product with no special rule gets the 30% default margin. If it belongs to the "Accessories" family, the 45% rule overrides the default. If it also comes from Supplier X, the supplier rule only applies where it's more specific than the family rule - otherwise the more specific family rule still wins. SKU ABC123 is always €24.99 regardless of every other rule, because product-level rules have the highest specificity.
That's what lets you set a global baseline margin and override it selectively for specific families, suppliers, or individual products, without touching every product one by one.
Multiple suppliers, multiple cost sources
When a product has more than one supplier association, you choose which cost value serves as the calculation base: preferred supplier, lowest cost across suppliers, highest cost, or average.
An example: product P is carried by three suppliers.
- Supplier A: €11.20
- Supplier B: €10.50
- Supplier C: €12.00
Preferred supplier is the most predictable choice operationally - the price only changes when that one supplier's price changes, regardless of what the others do.
Lowest cost maximizes theoretical margin, but is risky if supplier availability isn't accounted for - the cheapest supplier isn't necessarily the one actually fulfilling the order.
Highest cost prices conservatively and leaves margin on the table whenever you're actually buying cheaper.
Average smooths out cost fluctuations, but can mask a genuine cost change from a single supplier.
If Supplier A changes its price tomorrow, "preferred supplier" reflects that directly and exclusively when A is preferred; "average" reflects it only partially; "lowest cost" may not reflect it at all if A wasn't the cheapest to begin with.
Common B2B pricing models
B2B pricing is rarely a single discount percentage. Common models include:
- list price
- customer-group price
- customer-specific negotiated price
- quantity-tiered price
- contract / price-list price
- cost-plus price
- minimum-margin rule
- temporary promotional price
PIMSuite currently supports: cost-based formula rules with the specificity hierarchy described above (default/family/supplier/product), plus a standalone B2B/wholesale price per product.
Models beyond that - customer-specific contract pricing or per-customer quantity tiers, for example - usually live closer to whichever ERP or CRM owns that customer relationship. Where that's the case, we'd typically integrate with it rather than duplicate the logic (more on that below).
Rounding
Specify how calculated prices are rounded: up, down, or to nearest, with custom precision. Prices like €19.99 instead of €20.04 happen automatically as the last step of the calculation, not as a manual correction afterward.
Price history and the EU Omnibus Directive
For consumer-facing price reductions in the EU, the prior-price rules stemming from the Omnibus Directive can require showing the lowest price applied during the preceding 30 days. Exact obligations depend on the specific case and national implementation - this is a general pointer, not legal advice.
Technically, PIMSuite tracks every price change with a timestamp and calculates the 30-day lowest price alongside the current price, available via the API. Wiring that value directly into channel exports and integrations is in progress, not yet live.
What happens when data is missing or conflicting?
A production pricing system also has to handle incomplete input: a missing cost value, two equally specific rules, a calculated result that violates a minimum margin, or an unavailable currency conversion. How robustly a system handles that often decides whether a wrong price quietly reaches a storefront or gets caught in time.
PIMSuite's specificity hierarchy resolves the most common conflict - multiple matching rules - deterministically: the most specific rule always wins. For the remaining cases (missing cost, violated margin floors, missing exchange rates), we recommend reviewing calculated prices before publishing; an automated validation layer for that is the kind of thing we'd typically add as custom development where a business needs it.
Auditability
For any calculated price, it should ideally be possible to answer "why is this €124.99?" - something like:
Supplier cost: €72.00
Rule: Family "Accessories" / EU
Formula: cost / 0.58
Calculated: €124.14
Rounding rule: nearest .99
Final price: €124.99
PIMSuite stores every price change with a timestamp, and product records carry a full audit log and version history. A dedicated per-price breakdown by rule and formula - like the example above - isn't currently available as a built-in report; where that matters for a B2B team, it's a natural extension to build.
Where should pricing logic live - ERP, PIM, shop, or a dedicated engine?
This is a genuine architecture question, not one with the same answer every time.
ERP: makes sense when cost and customer contracts are authoritative there.
PIM: makes sense when pricing depends heavily on product and supplier data and needs to be distributed to multiple channels - the case PIMSuite's engine is built for.
E-commerce platform: well suited to channel-specific promotions, cart logic, coupons, and session-based rules.
Dedicated pricing engine: makes sense for highly dynamic, cross-channel pricing driven by many changing signals.
PIMSuite's engine is useful when the rules genuinely belong to the product-data layer. If your ERP is the real commercial source of truth, we'd usually integrate with it rather than duplicate that logic inside PIMSuite.
Pricing engine vs. dynamic pricing
A rules-based pricing engine calculates prices deterministically from known inputs - cost, margin, rule specificity. The same input always produces the same price.
Dynamic pricing varies prices based on changing signals such as demand, inventory, competitor prices, or time.
AI-driven pricing optimization goes further still, toward prediction and optimization, and needs considerably more governance to run safely.
PIMSuite's engine is the first category: auditable and rules-based, not competitor- or demand-driven.
Pricing engine vs. CPQ
A CPQ system (Configure, Price, Quote) configures complex, often customer-specific offers - typically sales-assisted and built for the exception case.
A pricing engine resolves prices programmatically at scale, across a full catalog rather than a single quote.
The two can overlap but aren't the same thing: a CPQ system often needs a pricing engine underneath it, but a pricing engine doesn't replace a CPQ system for complex, negotiated deals.
How PIMSuite implements this
PIMSuite tracks four distinct prices per product - selling price, RRP, compare-at price, and B2B price - each with its own currency. Pricing rules are formulas (cost * 2.4, round(cost / 0.6, 2)), readable and auditable. They apply at the four specificity levels described above, resolved automatically by specificity. With multiple suppliers, you choose the cost-source strategy. Rounding is configurable. And a rule can be applied to thousands of products in one operation - the engine recalculates and stores every affected price, with no spreadsheet formulas to maintain anywhere. The rules live centrally in PIMSuite.