Lesson 1: discount tiers per customer group that are not recorded consistently anywhere
Most wholesalers work with multiple customer groups: regular buyers, project customers, large-volume accounts, occasional purchasers. Each group has its own discount agreements, and those agreements are rarely stored in the same place. One customer group lives in the ERP, another in a spreadsheet the account manager maintains, and a third in an email thread from two years ago. As soon as you want to automate sales price calculation, you run into this immediately. There is no single source of truth. The only person who knows which discount applies is the account manager. That makes automation not only technically difficult, it also makes it risky, because an error in the discount only surfaces when the customer disputes the invoice. The solution is not a smarter system, but doing the groundwork first: consolidating all discount agreements into one structured table, with customer group, product category, and volume threshold as dimensions. Only then can you build an engine that performs the calculation automatically. Anyone who skips that groundwork and jumps straight to automation is automating chaos.
Lesson 2: exchange rates that are outdated by the time the order is confirmed
Many wholesalers purchase in dollars or other currencies and sell in euros. The purchase price is converted when the item is created in the system, using the exchange rate at that moment. By the time the order actually comes in, that rate may be weeks or months old. The result: the sales price is based on a purchase price that is no longer accurate. The margin looks healthy on paper, but in reality the exchange rate has eaten into the profit. This pattern recurs among wholesalers importing from countries with volatile currencies. The technical solution is not complex: connect a currency feed to your pricing engine and recalculate the purchase price in euros at the moment an order is created, not at the moment the item was entered into the system. However, this requires an architecture in which purchase price and sales price are independent, real-time calculated values, not fixed fields on a product master record. Anyone who does not make that distinction in the data model will keep correcting exchange rates manually.
Lesson 3: the link between purchase price and sales price is not real-time
This is the most common bottleneck when automating sales price calculation in wholesale. The purchase price arrives via a supplier confirmation or a purchase order. The sales price sits in a different system, or has been manually fixed based on an old purchase price. The connection between the two is not a real-time link but a manual step: someone compares, calculates, and adjusts. That works fine when margins are wide and price changes are rare. Once margins tighten and suppliers adjust prices more frequently, sales prices structurally lag behind reality. The margin only becomes visible after the fact, at the monthly close or the quarterly report. By that point, there is nothing left to adjust on orders that have already been shipped. The solution is a pricing engine that recalculates the sales price whenever the purchase price changes, with an alert when the margin falls below a set threshold. This is not artificial intelligence; it is simply good software architecture: purchase price and margin percentage as variables, sales price as a calculated field, not a manually entered number.
When is a configurator sufficient for calculating sales prices?
Not every wholesaler needs custom development. A standard configurator or a well-configured ERP package with price list functionality can be sufficient if the discount structure is uniform (at most two or three customer groups), currency risks are limited or hedged through purchase contracts, and the purchase price is stable enough that monthly updates suffice. In that situation, it is smarter to make better use of the existing package than to build a custom system. Custom development becomes relevant when the discount structure is customer-specific and does not fit standard tiers, when currency fluctuations directly affect the margin and you want real-time visibility, or when you have multiple systems that are currently synchronized manually. In that case, you are not adding another layer on top of the problem: the smarter move is to build the pricing engine from scratch, correctly, with the right data sources as input.
How do you approach automating sales price calculation in wholesale?
Do not start with the software; start with the data model. Which variables determine the sales price? Purchase price, exchange rate, fixed margin per category, customer-specific discount, volume discount, and possibly freight costs or surcharges. Record those variables in a structured table. Verify that there is a single, unambiguous source for each of those variables. Only when that is in order does it make sense to start building. The architecture that proves most robust in practice: a central pricing engine that retrieves the purchase price in real time, applies the exchange rate, looks up the customer-specific discount, and calculates the sales price as the result. Not as a stored value, but as a calculated output at the moment of the request. This also makes it possible to display margin warnings before a quote goes out, not only at the monthly close.