Almost no wholesale business charges one price to everyone. One account gets a standing 15% discount from a negotiation two years ago. Another only gets a break on the one category they buy in bulk. A third pays list price because nobody's gotten around to renegotiating with them. None of this is unusual - it's just rarely written down anywhere the actual catalog can see it.
The three shapes this pricing takes
- Tiered or customer-group pricing. A handful of named tiers (Retail, Wholesale, VIP) that a customer gets assigned to, each with its own discount or markup applied across the board.
- Per-account negotiated pricing. One specific customer, one specific rate, agreed outside any tier structure and usually remembered rather than recorded.
- Per-category margin. A different markup depending on what's being bought - a distributor might apply a smaller margin on high-turnover staples and a larger one on slower-moving specialty items, for the same customer.
Most real accounts are actually some combination of all three, which is exactly where a spreadsheet stops being able to keep up.
Where the spreadsheet approach actually breaks
The spreadsheet itself isn't the problem - keeping it in sync with a catalog that changes is. A cost price moves, and now every hand-entered markup calculated from the old number is quietly wrong until someone notices. A rep applies last quarter's tier to a customer who's since renegotiated. Two people edit the same pricing sheet in the same week and only one version survives. None of these are rare edge cases; they're just what happens by default when a price rule lives in a document instead of next to the data it's supposed to apply to.
What actually needs to own it instead
The rule needs to sit next to the real catalog, not beside it in another file, and it needs to reapply itself automatically the moment the underlying price changes - not the next time someone remembers to update a sheet. That also means the rule can't require re-typing the whole catalog per customer; it has to compute the customer's price live, from the one real number, every time it's asked.
How Feedwyre approaches this
A child feed is a second feed that reads your real catalog live and applies one account's pricing rule - a flat percentage, a fixed amount, or a per-category override - before handing products back. Change the real cost price once, and every child feed reading from it reflects the new number immediately, with nothing to re-key anywhere. Set up one child feed per pricing tier or per negotiated account, and each one keeps its own API keys, download links, or portal logins, so a customer never sees a rate that isn't theirs. We walk through a distributor running three different margins for three different customer types in the margin case study.
Give every account its own price, automatically
Set up a child feed with its own margin rule in a few minutes - no second spreadsheet required.
Start free trial