A salesperson agrees a discount, but the customer signs in and still sees the list price. Instead of placing the order, they pick up the phone or send an email. That disconnect means the real B2B transaction is still happening outside the ecommerce platform. A well-designed Magento module for customer-specific pricing shows each account its agreed terms and lets routine orders proceed without manual checks.
Magento offers useful standard pricing mechanisms, but implementation starts with policy: where prices originate, who owns them and which rule wins when contract, promotion and volume pricing overlap.
When customer-specific pricing becomes necessary
Customer groups can support a straightforward wholesale model. Pricing becomes more complex when one account has negotiated rates for selected SKUs, another receives a brand-level discount and a third buys against annual volume breaks. At that point, pricing is part of the customer’s contract and is often owned by the ERP or sales system rather than by ecommerce marketing.
The commercial benefit is strongest for manufacturers and distributors with large catalogues and repeat purchases. Once signed in, the buyer sees the correct net price, availability and delivery terms and can order outside office hours. The account manager remains responsible for negotiation and growth rather than keying routine orders.
Standard Magento pricing or a bespoke module?
Magento Open Source includes group prices, tier prices, special prices and catalogue/cart rules. These work well when policy can be represented by a small number of maintainable rules. Adobe Commerce B2B adds shared catalogues whose custom products and prices are visible to assigned company accounts.
Bespoke Magento 2 development becomes a sensible option when the business needs a large customer–SKU matrix, ERP-owned contract records, effective dates, unusual units of measure or a pricing hierarchy that standard configuration cannot express safely. Custom code should not be the default, however: standard configuration backed by a robust import is often cheaper and easier to upgrade.
Practical example 1: contract price versus promotion
A plumbing distributor lists a pump at £420 net. Contractor A has a contract price of £365 until 31 March; a public spring promotion offers 10% off. The pricing specification must state whether the contract remains £365, becomes £328.50, or the lower eligible price wins. If nobody decides, developers will end up making a commercial decision that belongs with the business.
Practical example 2: pack and quantity rules
An electrical wholesaler sells cable by 100-metre drum. Customer B pays £78 per drum up to nine drums and £72 from ten. The ERP sends price per drum, while Magento’s product page also shows an indicative price per metre. The module must validate multiples of 100 metres, calculate tiers on whole drums and keep basket, order, invoice and ERP totals identical.
Practical example 3: branch-specific agreement
A builders’ merchant group has one company account and six branches. Four branches use national terms, while two project sites have temporary prices and delivery surcharges. The price key therefore includes company location and delivery context, not merely the user ID. When the project agreement expires, the system falls back to national terms and records why.
Define precedence, tax and currency
Specify the source of truth and a deterministic precedence table. Cover contract price, group price, tier price, catalogue promotion, basket coupon, negotiated quote and manual override. Decide which rules compound, which are mutually exclusive and whether “lowest price wins” is commercially acceptable.
For UK trade sales, decide how net and VAT-inclusive values appear and ensure the invoice carries the right VAT breakdown. GBP rounding must be consistent across unit, row, basket, order and ERP. If the same estate serves consumers, consumer price communications normally need to show the total price including mandatory taxes and charges, in line with current CMA guidance.
Also specify currency, minimum quantity, units of measure, price validity and who may see price information. A buyer may be able to create a basket but need approval before committing the company.
Design the data and integration
A price model should not duplicate the complete catalogue per customer. At scale, the matrix may contain millions of rows, so indexing, import throughput, cache invalidation and retention matter.
A daily local synchronisation may suit stable agreements. Live ERP calculation provides fresher data, but it also makes the storefront dependent on the ERP’s response time and availability. A hybrid is often safer: approved prices are stored and indexed locally, updates arrive in batches, and the basket performs a time-limited validation only for genuinely time-critical terms.
Operations need an import dashboard or another clear source of evidence showing the last successful run, accepted and rejected rows, rejection reasons, the source version and reconciliation totals. Sales staff should be able to inspect an account’s effective price without asking a developer. An audit trail should explain exactly which rule produced the amount on a disputed order.
Decide what happens when pricing fails
If an import is late or a live service times out, never fall back silently to an unrelated price. Agree whether Magento uses the last validated price for a limited period, prevents checkout, or accepts the order for review. The choice depends on margin and customer-service risk.
Use idempotent imports so replaying a file cannot duplicate records. Validate currency, effective dates, units and impossible values before publishing. Send actionable alerts rather than relying on a salesperson to discover the problem.
Keep customer-specific prices fast
Pricing must work on category listings, search, product pages, requisition lists, quick order, basket and checkout. Avoid one remote ERP call per product. Pre-index account or catalogue pricing where possible and load it in sets. Test realistic 100- and 500-line baskets, concurrent sign-ins and large import windows.
Hyvä can reduce browser overhead, but it cannot repair an inefficient backend pricing model. Database design, cache segmentation, queues and load testing all belong in the pricing project. The practical consequences are covered in our guide to Magento store speed optimisation.
Pilot before full rollout
Select a representative set of accounts: one with straightforward group terms, one with product contracts, one with tier pricing and one with multiple branches. Reconcile displayed prices and order totals against the ERP for several weeks. Include cancellations, credit notes and expired agreements.
The best pricing module is almost invisible to the buyer: they sign in, see the terms they recognise and place the order. On a Magento 2 B2B platform, that simple experience depends on clear commercial rules, data ownership, sensible failure handling and thorough testing — not merely installing an extension.
