A company running two business lines out of one Business Central company came to us with a frustrating problem: the right price wouldn't fill in on their sales orders. Sometimes the system pulled the wrong division's price, sometimes it pulled zero. If you run more than one brand or price book out of a single company, this is worth understanding, because the fix is mostly about how you set the pieces up, not about custom code.
The setup: one company, two price books
This business sells the same physical items under two divisions at different prices. Rather than spin up separate companies, they use a division dimension to tell the two lines apart. Every customer carries a division code as a dimension. Every item carries a variant per division, so the same item number can exist as a variant for each line. Sales prices are held on price lists tied to the item and its variant, not scattered around.
When it works, the flow is clean. You pick the customer, the division dimension lands on the order header, you add an item, and Business Central fills in the matching variant and the price that goes with it. One item, two prices, and the order figures out which one applies from the dimension on the header.
Dimensions in Business Central are tags you attach to records and transactions (a division, a product line, a salesperson). Making one a global dimension means it flows onto documents automatically and you can filter and report by it everywhere.
Where it breaks: prices left on the item card
Here's the trap that bit this client. In their old way of working, some items carried a unit price directly on the item card. When they moved to variant-based price lists, those item-card prices didn't go away on their own. So on some items the order kept pulling the old price (which happened to be one division's number) instead of the variant price list. On other items, once someone deleted the item-card price to fix it, the order showed zero, because the variant wasn't populating and no price list matched.
The price list can be perfect, and the order will still pull the wrong number if a stale price is sitting on the item card.
Two things had to be true for this to work cleanly. First, remove the sales and purchase prices from the item cards so the price lists are the only source. Second, make sure the variant actually populates on the order line, because the price list is keyed to item plus variant. No variant, no match, no price.
The variant that wouldn't show up
The second issue was quieter. Some users didn't have the variant code column on their sales lines at all, so they couldn't see whether it was populating, and for one division the variant wasn't flowing automatically even when it should have. That combination is easy to misread as a pricing bug when it's really a field-visibility and setup issue.
A few practical takeaways if you're chasing something similar:
- Make sure the variant code is visible on the sales line for the roles that enter orders, so people can see what the system did (or didn't) fill in.
- Confirm the variant populates from the header dimension for every division, not just the one you tested.
- Treat the item card as a place for defaults you actually want to win, and remove prices from it once price lists own pricing.
- Test each division with a real customer from that division, since a working test on one division doesn't prove the others.
Why non-inventory vs inventory changed the accounting
One more thing came up worth flagging. The items in the test company were set up as non-inventory, and the plan was to bring them in as inventory items later. That choice isn't cosmetic. Whether an item posts as inventory or non-inventory changes which general ledger accounts the transactions hit, which changes what your accounting team sees at close. If you're mid-migration, decide the item type deliberately and let finance see the effect before go-live, not after.
The short version
Multi-division pricing in one Business Central company is very doable. The mechanics that make it reliable are boring on purpose: one clear source for price (the price lists), the variant populating on every line, and no leftover numbers on the item card quietly overriding everything. Get those three right and the correct price just shows up.
If you're setting up more than one price book in a single company, or you're seeing prices that don't match what you expect, we're happy to look at your dimension and variant setup with you and talk through where it's coming from. Reach out through our contact form or give us a call.