8,000 SKUs and a different price for each customer: the PDF price list is a margin loss

The “spoken” discount that doesn’t match the invoice

There is a scene that repeats itself in thousands of companies every day, and that no balance sheet records. The agent is at the customer’s. The customer asks: “what can you do for me on this quantity?”. The agent, to close the deal, gives a number — “let’s do 12%”. Handshake, order taken, everyone happy. Then the order arrives in administration, and there the “spoken” discount meets the ERP, which knows nothing about that 12%. Someone applies it by hand, or doesn’t apply it, or applies it wrong. The invoice goes out with a price the customer doesn’t expect. Phone call, argument, credit note. And the margin the agent thought they had defended has gone up in smoke, a piece at a time, without anyone having really decided it.

This is the core of the problem when you have a real catalog — let’s say 8,000 SKUs — and a different price for every customer. It’s not that you are missing “an e-commerce”. It’s that your pricing system lives in different places that don’t talk to each other: an Excel of the price lists, the agent’s head, the ERP, a PDF printed last year. Every order is a point where these worlds must match, and every time they don’t you lose margin, time, or a piece of trust with the customer.

This article is for those who sell with custom price lists — agents, sales reps, companies with sales networks, distributors — and feel that between the “right” price and the price that ends up on the invoice there is a leak they cannot stop. Let’s do the math on how much a price list error is really worth, even a small one, multiplied by volume. Then we look at why PDF and WhatsApp are the problem, what the agent must have in their hand when in front of the customer, and why the piece that decides everything is a pricing engine — not a chat, not AI, an engine that always gives the exact same answer.

PDF and WhatsApp: two sources, zero truth

Let’s pause for a moment on how prices circulate today in your company. Almost always in two ways: the price list PDF and the WhatsApp message. They seem harmless, but instead they are the root of the problem, because they create what in jargon is called “two sources of truth” — which is a technical way of saying “zero truth”.

The PDF is a photograph. You generate it today with today’s prices, and by tomorrow it’s old. You change a list price, update a cost, launch a promotion: the PDF in the hands of the agent and the customer doesn’t know. They keep working on a wrong photo, and when the order arrives with old prices, you either fulfill it at a loss or argue with the customer to correct it. Worse still: there are three different versions of the PDF circulating, one for every time you resent it, and nobody knows which one is the good one.

WhatsApp is even more insidious, because it’s convenient and seems trackable (“look, it’s written here”). The agent writes the price to the customer, or the office writes the authorized discount to the agent, and that number lives in a chat that no system reads. When you need to understand “but what price did we give this customer?”, you scroll through WhatsApp. It’s a source of truth that isn’t connected to anything: not to the ERP, not to the portal, not to the invoice. It’s truth only as long as someone remembers to look at it.

The result is that your prices — which are the most delicate commercial tool you have — live scattered among files, chats, and heads. There is no one place where, given a customer and a product, the right price comes out, the real one, the one that will end up on the invoice. And until that place exists, every order is a small gamble. It’s the exact same problem of numbers scattered in six software systems that I talk about for dashboards and data products: the data exists, but there isn’t a single reliable version, and so every decision is made on information that might be wrong.

The math: a 2% error on the price list, multiplied by volume

Here the numbers hurt, and it’s right that you look at them. The beauty — or ugliness — of prices is that the error multiplies by volume. It’s not a fixed cost: it’s a percentage that eats away at every single order line, all year long.

Let’s make an estimate, stated as such but conservative. Let’s say you invoice 3 million euros a year from listed products. Now imagine an average error of 2% on prices: discounts applied a bit higher than they should be, prices not updated after a supplier increase, expired promotions still active, roundings always in favor of the customer. It’s not an edge case: it’s the physiology of a system where prices circulate on PDFs and WhatsApp. 2% of 3 million makes 60,000 € a year of margin walking out the door without anyone having decided it.

Item	Estimate
Annual price list revenue	3,000,000 €
Average price erosion (spoken discounts, old lists, expired promos)	~2%
Margin lost per year	~60,000 €
“Big” errors (blatantly wrong price on invoice)	credit notes, time, trust
Admin hours to correct and reconcile	1-2 hours/day

And 2% is optimistic. In companies with very complex price lists and networks of independent agents, true erosion is often higher, because every agent has their “wiggle room” and nobody checks the total. To this you add the big errors — the blatantly wrong price generating the credit note — and the hours administration spends reconciling what the agent promised with what the ERP knows.

The important thing to understand is that this is not a cost that “sometimes happens”. It’s a structural cost, that you pay on every line of every order, every day, and that grows with revenue. The more you sell, the more you lose — which is the opposite of how it should work. And it’s invisible precisely because it’s widespread: there isn’t a moment when you see “here, I lost 60,000 euros”. You lose them two euros at a time, ten thousand times.

What the agent needs to see during the visit

Let’s flip the problem and start from the person who has to use the tool: the agent, the sales rep, the salesperson on a visit. Because an agent price list app that is not designed around how the agent actually works, ends up in the drawer — and the agent goes back to their Excel and their WhatsApp, and you’re back to square one.

The agent is at the customer’s. They have little time, often they are standing, maybe in a warehouse or a shop. What do they need, concretely, on the screen of their phone or tablet?

The right customer, with their prices. They select the customer and from that moment everything they see is tailored to them: their price list, their discounts, their conditions. They don’t have to calculate anything in their head, they don’t have to open a separate Excel. They search for a product and see the price for that customer, already net, already right.

A search that forgives. With 8,000 codes, search is everything. The agent searches by code, by trade name, by a piece of description, sometimes by what the customer calls it. The search must find it anyway, even with a typo, even if the customer calls it in a way that isn’t official.

True availability. “Do we have any?” is the second question after the price. The agent must be able to say with certainty if the product is there, and if not, when it arrives. Not “I’ll let you know”: the answer, immediately, read from the real warehouse.

Wiggle room, with boundaries. If the agent can give an extra discount, the app lets them — but within the limits you have decided, and recording what they granted. “You can go up to 15%, beyond that requires authorization”: this way the spoken discount becomes a tracked discount, which will end up on the invoice exactly as promised. No more surprises, no more “spoken”.

The order leaving clean. When the customer says yes, the agent confirms and the order leaves already complete: customer, right prices, applied discounts, verified availability. There is no one, in the office, who has to reinterpret a sheet or a chat. The order enters the ERP as it was taken in front of the customer.

Notice one thing: this app is the twin, on the agent’s side, of the portal where the customer orders on their own. They are two sides of the same engine: one is used by the customer at night, the other by the agent during the visit, but underneath is the same heart — the system that, given a customer and a product, knows the true price.

The piece that decides everything: the pricing engine (not the AI chat)

We arrive at the core. Everything we’ve said — the agent’s app, the customer’s portal, the clean order — rests on one thing only: a pricing engine that, given a customer and a product (and a quantity, and a date), returns the right price. Always the same, always exact, always explainable. If this engine is missing, or is wrong, everything else collapses.

What does a pricing engine do? It applies, in order, the true rules of your company. The base list price of the product. The customer’s price list, if they have a dedicated one. The category discount. The quantity scale (“from 10 pieces, from 50 pieces”). The active promotion in that period. The negotiated net price on certain items, which overrides everything. The possible contribution or surcharge. The engine takes these rules and applies them deterministically: same customer, same product, same quantity, same day → same price, guaranteed. And, crucially, it knows how to explain how it got there: “base price X, minus customer discount Y, minus quantity scale Z”. So when someone asks “why this price?”, the answer is there.

This is the price configurator, and it’s the part that no PDF, no Excel, no chat can do, because those systems don’t apply rules: they contain pre-calculated numbers, which age. The engine, instead, calculates on the fly, on today’s rules. You change a rule in one place only, and from that moment everyone — agent, portal, ERP — sees the new price. A source of truth, finally.

And here I must be clear on a dangerous trend: AI does not set the price. Every now and then someone comes proposing “the AI assistant that answers pricing”. It’s a mistake that can cost dearly. A language model is probabilistic: “usually” it gets it right, occasionally not. On prices, “occasionally not” means a wrong invoice, lost margin, an angry customer. Price is a domain where the deterministic exactness of an engine is needed, not the approximation of a model. AI has its place — it can help the agent search for the right product from a vague description, it can suggest related products, it can read an order arriving via email and propose a draft — but the price number must be given by the engine, always. Whoever confuses the two is selling you a risk labeled as innovation. It’s the same boundary I talk about for internal apps: automate where the rule is clear and deterministic, use intelligence where interpretation is needed — never the reverse.

The pricing cases that make ready-mades collapse

To understand why you need a real engine and not an off-the-shelf module, it’s worth looking at real pricing cases — the ones that seem like details but are actually the point where every ready-made solution gives up. If you recognize yourself in three or four of these, you have the answer as to why your margin is eroding.

The discount that adds up (or doesn’t). The customer has a 10% list discount, and plus there is a 5% promotion on the product. Is it 15%? Or 10% and then 5% on the net (which is less)? Or does the promotion replace the customer discount? Every company has its rule, and almost no ready-made handles it the way you want. If the rule is ambiguous, every agent chooses the most generous version, and the margin walks.

The quantity scale at weird thresholds. It’s not always “buy more pay less” in a linear way. There’s the product where the discount triggers only at a full pallet, the one where below a certain quantity there’s a surcharge, the one where the threshold is by value and not by pieces. These are precise rules that an engine applies without thinking and that a shared Excel gets wrong one time out of three.

The net price that overrides everything. On certain items, with certain customers, you have agreed on a fixed net price: that number, period, regardless of price lists and discounts. The engine must know that that rule wins over any other. In a PDF system, that net price lives in an agreement nobody rereads, and when the agent doesn’t remember it, they apply the normal list — either too high (angry customer) or too low (lost margin).

The promotion with an expiration date. The promo is valid until the 30th. On the first of the following month, who turns it off? In an engine, the date is a rule: on the 1st the promo simply no longer applies, everywhere, automatically. On PDF and WhatsApp, the expired promo keeps circulating for weeks, and you sell stuff on promotion that shouldn’t be anymore.

The geographical or channel constraint. Certain prices apply only to certain areas, or only to the reseller channel and not the installer. These are distinctions that defend your commercial structure, and that a single price list flattens — with the risk that the “wrong” price reaches the wrong customer.

Each of these cases, alone, seems manageable “by paying attention”. The problem is that they are all there together, multiplied by thousands of codes and hundreds of customers. No human attention can handle that volume: you need a price configurator that applies the rules automatically, always the same. It’s exactly the job that ready-mades don’t do, because they don’t know your rules — and they never will, because they are your business model, not a standard feature.

Frontend: search, availability, order

The engine is the heart, but the heart alone cannot be seen. What the agent and the customer touch is the frontend, and even the simplest frontend, if it rests on a good engine, changes life. The three things that matter are always the same: search, know if it’s there, order.

The search in an 8,000 SKU catalog must be instantaneous and tolerant. The agent doesn’t have time to browse categories: they type three letters and find it. If the product has an internal code, a supplier code and a trade name, the search knows them all. A large catalog without a real search is unmanageable, and the agent goes back to the PDF because “at least there I know where it is”.

The availability must be honest and in real time. Not “shows in stock” with a number from last Monday: the true remainder, right now. And if needed, the reorder date. This is the point where you see if the system is connected to the ERP or is a toy: a fake availability is worse than no availability, because it generates promises you can’t keep.

The order must close in a few taps, with a clear summary of applied prices and discounts, and leave straight for the ERP. The moment of confirmation is sacred: that’s where the promised price crystallizes. If between the agent’s confirmation and the invoice there is a human step reinterpreting, you have reopened the door to error. The goal is that what the agent confirms in front of the customer is exactly what will come out on the invoice. Nothing in between.

Synchronization with the ERP: without it, it’s a duplicate

I repeat the concept because it’s what makes most projects fail: if the price list system is not synchronized with the ERP, you have built a duplicate. A second place to keep prices, discounts and stock — which falls out of line with the first the very next day.

What must travel, between the ERP and the price list system? Customer master records with their assigned price lists. Products with their base list and scales. Stock levels, in real time or almost. And, in the opposite direction, taken orders re-entering. If this exchange is solid, the pricing system is always aligned with the truth of the ERP, and the agent works peacefully. If it’s weak — a manual export every now and then, a hand-loaded file — the misalignment is a matter of hours, and the agent has to verify everything again, meaning they don’t trust it, meaning they go back to the old method.

Synchronization must be designed with real cases in mind: what happens if the ERP is slow, if a product is updated while the agent is ordering, if the connection drops halfway. They are boring details, but they are exactly what distinguishes a system you trust from one that generates a discrepancy to explain every week. It’s the same modeling and hooking to real data work needed under every internal app: the unseen part is what decides if it works.

Offline: when the agent is in an area with no network

A practical detail that makes a huge difference for those with an agent network: offline mode. The agent doesn’t work sitting in an office with fiber: they are in an industrial shed where phones don’t reach, in a rural area, in an underground warehouse. If the price list app only works online, in those moments it becomes useless — precisely at the moment it’s needed, in front of the customer.

An app designed for the field keeps a local copy of the catalog and customer prices, so the agent can search, place the order and see prices even without a network. When the connection returns, the order synchronizes and leaves. The availability, offline, will be from the last update — and the app says it clearly (“availability updated at 8 this morning”), so the agent knows when to trust and when to verify.

Warning: offline isn’t for everyone. If your agents work in cities with good coverage, it’s a useless complication — and adding unneeded complexity is a cost, not a value. But if your network roams in places where the network isn’t, offline is the difference between an app they use and one they curse. It’s one of those choices that must be made on your real case, not copied from a spec sheet.

A typical case: an agent network and only one true price

A typical profile, architectural, no names. Company with a catalog of several thousand codes and a network of twenty multi-firm agents in the territory. Every agent had their pricing Excel, updated when they remembered, and agreed on discounts during visits which they communicated to the office via WhatsApp or on a paper form left at the end of the round. Administration spent mornings deciphering orders, applying discounts “as it seemed they meant”, and chasing agents for details. Credit notes for pricing errors were a constant, and nobody could say what the real margin per customer was, because the actual prices were nowhere in a clean way.

What was done. First, the uncomfortable and revealing work: bringing out and writing down the true pricing rules. It turned out that “the standard industry discount” was interpreted differently by every agent, and that some expired promotions had still been circulating for months. With rules ordered, the engine was built and tested on the previous year’s orders: the engine recalculated every order and showed, line by line, where the applied price was different from the correct one. That table, alone, convinced management: erosion was well beyond 2%.

Then the agent app, with offline mode because many customers were in industrial areas without signal. Started with three pilot agents, the most open ones. In the first two weeks edge cases emerged — the customer with two locations and two price lists, the product in pack multiples — which were fixed. Fully operational: the visiting agent gives the right price immediately, within their boundaries, and the order enters clean; administration stopped deciphering and went back to checking only exceptions; and for the first time management had the real margin per customer and per agent, because finally true prices were all in one place. It wasn’t “an extra app”: it was moving the price from heads and chats to a system. The usual honest note: a couple of veteran agents resisted (“I know my customers by heart”), then they saw they were closing faster and with zero credit notes, and became the most convinced.

Why ready-mades stop, and why a single hand is needed

As with the customer portal, the temptation is to buy a ready-made: an “agent management” module from the ERP, an industry app, an off-the-shelf configurator. And as with the portal, these tools get to 80% and then stop precisely on the part that makes your company different: your pricing rules. Because pricing rules are, literally, your codified business model — and no generic tool knows them. The ready-made offers you “standard” discounts; you have the historical customer with the special agreement, the product selling in multiples, the promotion valid only in certain provinces. That 20% the ready-made doesn’t do is exactly what defends your margin.

And here the theme of the single hand returns. A custom price list system is three things together: data (price lists, stock, master records synchronized with the ERP), the engine (the pricing rules, deterministic and explainable) and the frontend (the agent’s app, the customer’s portal). If you entrust them to different suppliers — one does the app, one the ERP connection, one “puts AI in it” — nobody owns the pricing rule entirely, and the pricing rule is where margin is lost or defended. Whoever designs the discount screen and whoever writes the discount rule must be the same head, or the screen will show a number the rule can’t explain. You need someone holding data, engine and interface together — not three suppliers who, when the invoice is wrong, blame each other while you lose the customer.

Timeline and where to start

How long does it take? The long part, again, is not technical: it’s putting order into the pricing rules. In almost all companies with complex price lists, the true rules aren’t fully written down anywhere — they live in an Excel, in a practice, in the head of the sales manager. The first job, the one nobody can skip, is bringing them out and writing them down: which price lists exist, how they are assigned, which discounts, which scales, which exceptions. It’s often revealing work, because it emerges that rules “everyone knows” are actually applied a bit differently by everyone — and that’s where erosion began.

Then the engine is built and tested on real cases: real past orders are taken and it’s verified that the engine yields exactly the right prices (or reveals the ones that were wrong). When the engine is reliable, the frontend is put on top — the agent app, the portal — and you start, as always, with a few pilot agents on real customers. They bring out the cases meetings don’t foresee, you fix them, you expand.

The first concrete step you can take yourself, this week, without spending anything: take ten recent random orders and verify, line by line, if the price on the invoice is what it should have been according to your rules. Count how many are right and by how much the others are wrong. That small check is your business case: it tells you, in real euros, how much not having a pricing engine is costing you today. And almost always the number is larger than you imagined.

The hidden gift: finally the margin per customer

There is a benefit that arrives almost stealthily, and that often is worth as much as the recovered margin: when all true prices live in a single system, for the first time you can know how much you really make on each customer and each agent. Not the estimate, not the “I think that customer pays off”: the real margin, line by line, because the applied price is no longer buried in a chat but is clean data.

This changes conversations in management. You discover the large customer who actually yields little because you give them discounts you hadn’t realized you were making. You discover the agent defending margin and the one giving it away to close quickly. You discover the product family where you are leaving margin on the table due to an overly generous discount rule. These are decisions you previously made by gut, and now you make on numbers — exactly the leap I talk about for dashboards that owners actually open. The pricing engine doesn’t just defend margin: it shows it to you, and it’s the first step to governing it instead of enduring it.

It’s for you if / it’s not for you if

It’s for you if: you have a large catalog (thousands of codes) and different prices per customer; you use a network of agents or reps who agree on discounts during visits; your prices circulate on PDFs, Excel and WhatsApp and there is no single reliable source; you realize that between the “promised” price and the one on the invoice there is a leak you can’t control; you have an ERP containing master records and price lists to start from.

It’s not for you if: you sell few products at a single or almost single price (then you don’t need an engine, a simple price list is enough); you are not willing to put your pricing rules in order — because an engine makes them explicit, and if you prefer to keep them vague “for flexibility”, the engine isn’t for you; you have a network of agents who are fine as they are and whom you don’t want to track in any way (but then the lost margin is a choice, not an accident).

Frequently asked questions

My catalog has thousands of codes: is it too big? No, it’s exactly the case where a system is needed most. The complexity of 8,000 SKUs is unmanageable on PDF and Excel, and it’s the reason you lose margin. A large catalog, with real search and a pricing engine, finally becomes manageable — for the agent and the customer.

Isn’t my ERP’s agent module enough? Sometimes yes, if your pricing rules are standard. But ready-made modules handle “normal” discounts well and exceptions poorly — which in B2B are exactly where the margin is. The criterion is how much of your pricing rules fits in that 20% the module doesn’t cover. If the heart of your way of selling fits there, the module holds you back.

Can AI manage prices? No, and beware of anyone proposing it. Pricing requires a deterministic engine that always gives the same exact answer and can explain it. An AI model is probabilistic: it makes mistakes occasionally, and on prices “occasionally” means wrong invoices and lost margin. AI helps searching for products and reading incoming orders, not making the price.

What do I do with agents who don’t want to change? By involving them and giving them a tool that makes them look better in front of the customer: right price immediately, certain availability, order closed in two taps. An agent doesn’t abandon their method for an imposition, but gladly abandons it for a tool that makes them close faster and with fewer mistakes. The pilot rollout also serves to turn some skeptical agents into testimonials for the others.

Is offline mode necessary? It depends on where your agents work. If they roam in sheds, countryside, warehouses without network, offline is essential. If they work in cities with good coverage, it’s a useless complication. It’s a choice to be made on your real case.

How much is really saved? The big item is margin erosion: even just 2% on list revenue, recovered, is tens of thousands of euros a year. Add admin hours saved on reconciliation and credit notes avoided. Do the ten-order check I mentioned: it gives you the real number for your company.

Does it connect to the ERP I have? Almost always yes. Master records, price lists and stock are read from the ERP, orders re-enter it. How and how often depends on the specific ERP, and is one of the first things to evaluate — but it’s the rule, not the exception.

Do the data and system remain mine? Yes, and they must. Pricing rules are your business model: they shouldn’t be held hostage by a supplier. Code, engine and data remain yours, without vendor lock-in.

In one line

With thousands of codes and a different price for each customer, the PDF price list and the “spoken” discount are not a detail: they are a structural margin loss, often tens of thousands of euros a year, that you pay on every order line. The solution is not another PDF or an app “with AI making prices”: it’s custom B2B price lists software built around a deterministic pricing engine, synchronized with the ERP, with an app giving the agent the right price — and its boundaries — in front of the customer. Done this way, the promised discount is what ends up on the invoice, and margin stops walking out the door.

If you want to see how much you’re losing today and what a pricing engine would look like on your price lists, look at the projects I’ve built or drop me a couple of lines: we start from your true pricing rules, not from a catalog configurator.