Business Central price lists for retail: assigning sales prices to customers and stores
Most Business Central pricing guides are written for order desks. Retail is different: the "customer" is often a store, a price group, or whoever walks up to the till. Price lists still do the work — but only if the assignment level matches how the store actually sells.
What a price list actually is
A price list is a flexible container of prices (and, if you want, discounts) that you point at a business partner or an activity. Microsoft's documentation puts it plainly: you can set up one price list that applies to all customers, or offer special prices or discounts for each business partner. The prices you define apply automatically to sales and purchase documents — no one re-keys them at sale time.
What makes a line special is the combination it keys on. Special prices and discounts are often based on a minimum quantity, a period of time, or a certain combination of customer, item, minimum quantity, and unit of measure. One list can therefore hold everyday shelf prices alongside a quantity break and a dated seasonal price, as long as each line's combination is unambiguous.
Two setup points before you build anything. First, Microsoft expects the strategy to be defined up front: before you create price lists, define your pricing and discount strategies on the Sales & Receivables Setup and Purchase & Payables Setup pages. Second, know which discount animal you are dealing with. Business Central has line discounts (an amount on lines matching a combination of customer, item, minimum quantity, unit of measure, or dates) and invoice discounts (a percentage off the document total once the total passes a minimum). Price lists can carry prices, discounts, or both — the header's View Columns for setting only changes which columns you see; hidden prices and discounts still apply.
And when several agreements could match a sale, Business Central resolves it with its best-price calculation: the best price is the lowest price with the highest line discount allowed on a given date. The check looks at whether the customer has an agreement or belongs to a group that does, whether the item (or its item discount group) is in that agreement, whether the date falls inside the agreement's starting and ending dates — the Posting Date for invoices and credit memos, the Order Date for other documents — and whether the unit of measure matches. That logic is why overlapping lists so often surprise people: the system is doing exactly what it was told, and picking the cheapest match.
The assignment ladder: who a list can apply to
The header field that decides everything is Assign-to Type, with Assign-to No. naming the specific target where one is needed. The realistic options for a retailer, compared:
| Assign-to Type | Applies to | Best used for | Watch out for |
|---|---|---|---|
| All Customers | Every customer | The default shelf-price list every store falls back to | Every exception still needs its own list on top |
| Customer | One named customer | A single trade or account customer with negotiated prices | One list per customer does not scale |
| Customer Price Group | All customers in the group | Tiers such as trade, staff, or loyalty pricing | A customer can sit in only one customer price group |
| Customer Discount Group | All customers in the discount group | Discount structures that differ from the price tiers | Prices and discounts group separately on purpose — do not conflate them |
| Contact | A prospect or contact | Quotes before someone becomes a customer; different prices per ship-to via a contact per address | Easy to forget when the contact converts to a customer |
Two properties of the ladder matter day to day. A customer can be assigned to only one customer price group, which keeps group pricing predictable but forces you to design the tiers before you assign anyone. And prices and discounts can use separate groupings: a customer can belong to one price group where specific prices apply and a separate discount group with its own tiers, minimum quantities, and dates. Used well, that separation is a feature. Discovered by accident at the till, it is a bug report.
How LS Central retail uses price lists differently
LS Central's pricing mechanism is built on the Business Central price structure, and LS is explicit about the range that gives you: items can have multiple prices valid on different dates or times, or based on different tender types, and different stores and customers can have different prices.
The retail twist is in how the lists are organised. In the LS Central demo data company, the new sales pricing experience is enabled and Use default price lists is disabled — which means there is one sales price list per customer price group, rather than every price being poured into a single default list. The connection to the item card is direct: if you update the Unit Price field on the Retail Item card, the sales price list whose Assign-to Type is Customer Price Group and whose Assign-to is the Default Price Group on the Retail Setup card is updated accordingly (the value All in the demo data company). You can see the Item Price Overview from the FactBox, and open Sales Prices from the Prices & Discounts action bar.
Per-store pricing uses a different lever entirely. If you want to register additional item prices — different prices in different stores — LS says you must create a retail price group, assigned to the relevant store or stores, that the additional price is assigned to. Stores are not customers, and trying to fake store pricing with customer records is where retail price setups usually go wrong.
Set up a retail price list: the procedure
- Confirm the groundwork. Check that the pricing strategy is set on Sales & Receivables Setup, and confirm whether the new sales pricing experience is the one your company is using — the steps differ between the current and new experiences.
- Create the header. Open the Sales Price Lists page and choose New. Give the list a code (or let the number series assign one) and a description staff will recognise in a list of twenty.
- Set the assignment. Choose the Assign-to Type from the ladder above, and the Assign-to No. where the type needs one. Decide this before adding lines — see the traps below.
- Set the frame. Add a currency if the list should only apply to documents in that currency, and starting/ending dates if the prices are valid for a period. Validity is judged against the document date.
- Add lines. Key lines manually for a handful of items. For bulk work, use Suggest Lines with filters (for example an item category), an adjustment factor, and a rounding method — one documented run pulled a category in at item-card prices, then ran again with a minimum quantity of 10 and a factor of 0.95 to build a 5%-cheaper quantity tier. Lines can also be copied from another list, with recalculation. For changes across many lists, the Price Worksheet is the tool built for it.
- Activate. Work in Draft while building. Only Active lists are applied to sales documents — Draft and Inactive lists are ignored — so set the status to Active when the lines are checked.
- Verify at the point of sale. Sell one item from the list on a test transaction and confirm the price that comes up is the list price, not the item-card fallback.
Which level should you pick?
A short decision framework keeps the list count sane:
- Everyone pays it? It belongs on the All Customers list. This is your shelf price baseline.
- A recognisable tier pays it? Customer Price Group. Design the tiers first; remember each customer gets exactly one group for prices, however many discount groupings you layer separately.
- One account negotiated it? A Customer list — and accept that this does not scale beyond a handful of accounts.
- It depends on the store, not the shopper? That is not a Business Central customer assignment at all: use an LS Central retail price group assigned to the stores.
- It is really a promotion? Do not bury dated offers in price lists; scheduled offers are the LS Central tool for that job (see our guide to scheduling promotions in LS Central).
The two traps that stop prices reaching the till
Trap 1: editing an active list puts the line back in draft. Business Central allows updating active price lists, but when you change a line on an active list, that line shows in a different font because it is now in draft — and neither the old nor the new price will be applied to a sales document. You must run Validate Lines to activate the updated line; the action also checks for overlapping or duplicate lines and suggests which to remove. "I changed the price and nothing happened" is this trap, almost every time. Good practice is to change a list's status to draft before changing prices, then reactivate deliberately.
Trap 2: Assign-to cannot be changed afterwards. Once a list exists, you cannot change the assign-to option. If a list was built for the wrong target, the fix is to create a copy or a new list from scratch — not to hunt for an edit field that is not there. This is why step 3 of the procedure comes before any lines are added.
A smaller third warning: if an item should never be sold with a discount, leave the discount fields on the item page empty and keep the item out of every line discount setup. And remember the unit-of-measure rule: Business Central will not recalculate a price from the list if the order line uses a different unit of measure, so an item priced per piece needs an explicit line for the box of five if you sell it that way.
What success looks like
- The list status is Active, and every edited line has been through Validate Lines — no lines sitting in draft font.
- A test sale of a listed item returns the list price; a test sale of an unlisted item returns the expected fallback price.
- Each customer sits in exactly one customer price group, and you can say which list serves each store and tier without opening the system.
- Store-specific prices live on retail price groups assigned to those stores — not on customer records created to imitate stores.
FAQ
Can one price list hold both prices and discounts? Yes. The View Columns for setting controls whether you see price columns, discount columns, or both — it is a view setting only, and prices and discounts apply even when their columns are hidden.
Why did the till charge the old price after I updated the list? The usual cause is the edited line sitting in draft on an active list. Run Validate Lines, then re-test. If the price is store-specific, also check the retail price group assignment for that store.
How many price groups can a customer be in? One customer price group. Discounts are separate: the same customer can be in a different customer discount group, which is how tiered prices and tiered discounts are kept independent.
General information only, based on Microsoft and LS Retail documentation checked 2026-10-17. Field behaviour can vary by version and localisation — confirm against your own environment before changing live pricing.
IndexBack to all guides →