Episode 17: Why Pricing Has Never Lived in a PIM

A PIM tells you what a product is. It does not tell you what it was worth yesterday, what it will be worth tomorrow, what you paid for it, or what you should be selling it for.

That gap has sat in plain sight for as long as the category has existed. Pricing turns up as a line item on PIM RFPs constantly, and it has never really been answered.

Akeneo has now acquired PricingHub, which makes this a good moment to ask why. Not why the acquisition happened, that part is obvious. Why pricing was never in there to begin with.

What do you actually mean by pricing?

Whenever a business tells us they want to store pricing in the PIM, the useful first question is what they mean by the word.

Usually the answer is cost price and sales price. Two fields. If that genuinely is the whole requirement, you can hold them almost anywhere.

But pricing as a domain is far larger than two static numbers. It carries its own processes, its own logic and its own requirements, and the moment a business moves past list and cost, the two-field answer collapses.

We would not claim to be pricing specialists. What we do see, repeatedly, is how codependent the two domains are, and three structural reasons they have stayed in separate systems.

1. Product data and pricing run on different clocks

The reason PIM vendors have largely left pricing alone is not oversight. It is that pricing demands a different set of engineering requirements from a store of relatively static data.

PIMs are built for descriptive facts. You write an attribute value or a description once, and it holds. Businesses load plenty of products and change plenty of attributes, but the underlying rhythm is stable, and the architecture of nearly every PIM reflects it: enrich, approve, publish. It was not designed for constant throughput.

Pricing is the opposite kind of workload. It is high volume and high compute. Prices are not so much stored as calculated, against customer specific rates, discounts, promotions, and whatever dynamic pricing or pricing intelligence logic sits on top of those.

Once a system is built around enrich, approve, publish, operational data of that kind is genuinely hard to bolt on afterwards. None of which is a criticism of either category. It is a statement about what each one was engineered to do.

PIMs were built for facts that hold still. Pricing does not hold still.

2. Pricing is not a content problem

The second reason is that pricing is not really about the product at all. It is about margin, cost, contracts, tax, currency, discounting, and the fact that different customers pay different amounts. That belongs in the ERP, or in a dedicated pricing setup, and it is complicated in a way product content is not.

The consequences differ too. Get product content wrong and somebody notices and complains. Get a price wrong on a live sales channel and there is an immediate financial impact, which is why the controls around pricing look nothing like the controls around a description.

Then there is ownership. Pricing tends to sit with commercial, finance and category teams. The PIM traditionally sits with digital, merchandising and ecommerce. Those groups are looking at different things from different angles, and often report into different P&Ls.

So they do not buy the same tools, and they rarely collaborate on tool selection, because neither side fully understands the other's domain. The separation is organisational long before it is technical.

3. One product does not have one price

This is where the attempt usually breaks, and it is most obvious in B2B distribution.

The PIM model assumes one record holds one value per attribute. That works beautifully for specification data. It does not survive contact with pricing.

A single SKU can carry a list price, a cost price, channel specific pricing, customer group pricing, contract prices, promotional prices, and regional and currency variants. Those are not attributes. They are a matrix governed by rules.

Location pricing makes the point plainly. The same product, in the same retailer's estate, can carry a materially different price depending on which branch you walk into, sometimes a premium in the region of twenty to thirty percent.

We have seen some genuinely horrific attempts to capture that dimensionality inside a PIM. The instinct is to add a price field, then a table behind it, then more tables. It does not work, because the PIM holds no context about customers, locations, contracts or channels to resolve the rules against.

Pricing is a matrix. You cannot shove a matrix into a text field.

Why the consolidation makes sense

Which brings us back to the acquisition, and to why we expect more of them.

The read on this one is that it is largely an AI play. Roll pricing intelligence together with product content and you get a system that can optimise against real time market data, and a product record far more likely to be recommended, and converted, by an AI agent.

It is not the only pairing happening either. A PLM vendor buying a PIM is the same logic from the other end: connect the upstream world of making products to the downstream world of taking them to market, so the end to end lifecycle stops living in disconnected domains. This acquisition sits on the commercial side of that line rather than the manufacturing side.

More pricing platforms are the obvious near term candidates, because the requirement is already proven on both sides of the table. After that we would expect compliance and sustainability platforms to follow. Regulatory data has the same profile: essential to selling the product, structurally awkward to hold in a PIM, and increasingly non-negotiable.

None of which is surprising. These domains were always codependent. What is changing is that the market has decided to stitch them together commercially, rather than leave every customer to integrate them one at a time.

What this means if you are buying

Pricing has come up in roughly 70% of the PIM projects and selections we have run over the past five years. It is one of the most consistent unmet requirements in the category, which is precisely why somebody has now bought their way into it rather than waiting to build it.

So if pricing is on your RFP, be specific about what you are actually asking for. Two static fields is a data question, and almost any system answers it. Anything involving customer groups, contracts, locations or promotions is a pricing engine question, and no quantity of extra attributes in a PIM will meet it.

Work out which one you are buying before the demos start. Vendors will happily answer either question, and it is not their job to tell you which one you asked.

Listen to the full episode

Episode 17 of Product Data Weekly is available now. For more episodes and the weekly newsletter on operational issues inside product data and ecommerce teams, visit productdataweekly.com.