The controller at a packaging materials manufacturer in suburban Cleveland opens her morning file: B2B Pricing Master.xlsx. Four tabs. Standard Pricing. Volume Breaks. Account-Specific (47 accounts). Promo Codes. The "Last Modified" column shows six different names. Three rows in the Account-Specific tab carry yellow highlights with a comment that reads "see email from John 3/12." John retired in October.
The CFO has banned new account-specific pricing without his sign-off. New rows keep appearing anyway. A salesperson in Atlanta added one last Tuesday for an account she described to her manager as "really important" with no further documentation. The controller has stopped flagging them. Her job is to close the books, not police the field.
This is the file the manufacturer wants to migrate into a B2B portal. It is also the file that will sink the project if it migrates as-is.
Pricing complexity is not optional in B2B
It is tempting, when scoping a portal, to imagine you can simplify your way out of this. Publish list prices. Apply a single volume curve. Be done.
You cannot. Your customers expect their negotiated terms to be honored. Some have signed contracts dating back four years. Some have handshake deals from 2017 that nobody can find in the CRM. Your top thirty accounts each have at least one SKU on a special price, and most have several. Payment terms vary — net-30 is the default, your A-tier accounts get net-45, anyone new pays prepay until they earn a credit line.
The choice is not "complexity vs simplicity." It is controlled complexity vs spreadsheet anarchy. A B2B portal forces you to put structure around what is already there. The pricing master will not get simpler. It will get visible, governable, and auditable. That is the win.
The pricing patterns a B2B portal must handle
If you talk to a manufacturer who has actually done this — not a software vendor — the list of pricing patterns is consistent. Any portal that cannot handle all of these is a non-starter for a serious B2B operation.
| Pattern | What it looks like in practice |
|---|---|
| Volume tier breaks per SKU | Qty 1–9 at list, 10–49 at −8%, 50+ at −15%. Breaks vary by SKU. Some products have no break; some have five. |
| Account-specific contract pricing | Top 30 accounts have negotiated prices on specific SKUs, often unrelated to volume. Contracts may cover three SKUs or three hundred. |
| Payment-term variations | Net-30 default. Net-45 for A-tier. Prepay or COD for new accounts and watchlist accounts. 2/10 net 30 for a small group with the discount baked into the invoice. |
| Account-specific promo codes | BLACKFRIDAY-ACME works only for Acme Corp. Q3-RESTOCK-EAST works only for accounts in the east region. Promos stack with contract pricing only when explicitly allowed. |
| Hidden pricing for unauthenticated visitors | Competitors browse your site. So do procurement teams at accounts you do not yet serve. List pricing visible to logged-in buyers only; "Sign in for pricing" or "Request quote" otherwise. |
| Bundled pricing | Buy product A and product B together for a combined discount. The bundle price replaces the sum of line prices, not adds to it. |
| Quote-locked pricing | A quote issued at price X is valid for 30 days. If the catalog price changes during that window, the quote stays at X. The order, when placed, must honor the locked price — not the live one. |
There is no winning a portal RFP without all seven. Manufacturers who buy a portal that handles only three or four end up running a parallel pricing process in spreadsheets, which is exactly what they were trying to escape.
The architecture decision: ERP master, portal master, or hybrid
This is the question that determines whether your portal project takes nine months or twenty-two. Most pricing-related rework comes from getting it wrong on day one.
You have three real options.
Option 1: ERP-driven (NetSuite, Acumatica, Epicor, SAP)
The pricing master lives in the ERP. The portal queries the ERP at quote time and at order time to compute the price.
Pro. Single source of truth. Finance owns it. The price the portal shows is the price that will appear on the invoice, because they come from the same source. No reconciliation. Auditors are happy. Accountants are happy.
Con. ERP pricing UIs are awful for marketing-driven changes. NetSuite SuitePricing and Acumatica's price worksheets work fine for finance teams maintaining contract pricing quarterly. They are miserable for a marketing manager who wants to spin up a 72-hour promotion on Tuesday morning. Cycle time on a new promo can run 5–10 business days because the pricing change has to go through the ERP change-control process.
Option 2: Portal-managed
The pricing master lives in the portal. The portal pushes prices to the ERP when an order is created, so the invoice matches.
Pro. Fast iteration. A marketing manager can launch a promo in 20 minutes. A salesperson can request a one-off override and get it approved same day. Account-specific pricing is editable by the people who actually negotiate it.
Con. Drift risk. You now have two systems that both think they own price. If anyone updates the ERP directly — for an EDI customer who never logs in to the portal, for example — the two will diverge silently. Reconciliation becomes a monthly project. Finance teams are uncomfortable because the system of record for revenue is no longer the ERP.
Option 3: Hybrid (most common, and usually correct)
Contract pricing and volume tiers live in the ERP. Promotional pricing and account-specific overrides live in the portal. At quote time, the portal applies its own promo and override layer on top of the price the ERP returns.
Pro. Finance keeps control of the durable pricing — the contract prices that show up on quarterly audits. Marketing and sales get a fast lane for short-lived adjustments. The expensive ERP change-control process is reserved for the changes that actually warrant it.
Con. You have to define the boundary precisely and document it. Anything ambiguous (is a 90-day "introductory price" a promo or a contract price?) becomes an argument. The portal must clearly show which layer produced which price so disputes can be resolved.
| Architecture | Source of truth | Change cycle for a promo | Best fit |
|---|---|---|---|
| ERP-driven | ERP | 5–10 business days | Manufacturers with stable pricing, conservative finance, low promo cadence |
| Portal-managed | Portal | Same day | Manufacturers with high promo cadence, weak ERP pricing tools, marketing-led commerce |
| Hybrid | Both, with defined ownership | Same day for promos, 5–10 days for contracts | Most North American manufacturers with $50M+ B2B revenue |
If you are unsure, default to hybrid. It is more work to set up than either pure option, but it is what mature B2B operations end up running anyway.
What a good portal does at quote and order time
Behind the buyer's "Add to Quote" button, the portal runs a sequence. It is not magic. It is six steps, in order:
- Look up the buyer's account and their account tier
- Apply contract price if an account-SKU contract exists for the requested quantity
- Otherwise apply the volume-tier price for the requested quantity from the SKU's tier table
- Apply any active promo codes the buyer is eligible for, respecting stacking rules
- Compute the line total and apply any bundle adjustments across lines
- Lock the price to the quote and start the validity clock
Two principles matter here.
Show the full breakdown. Buyers will notice if the math is hidden. Show the list price, the volume break applied, the contract override, the promo discount, the final unit price. Hidden math reads as gouging even when it is not. Visible math reads as a fair, structured negotiation — which is what B2B buyers expect and what your sales team has been promising them.
Lock the price for the validity window. A quote issued at $84.50/unit on July 3 with a 30-day validity must convert to an order at $84.50 even if the catalog price moves to $87.00 on July 18. The portal must store the quote-time price and use it at order time. This is one of the patterns SaaS B2B platforms most often get wrong, and it is the one your accounts will catch you on first.
For the broader question of when a portal is the right move at all, see the B2B portal vs email decision framework. For the procurement-side integration that often runs alongside account-based pricing, see the article on punchout catalog and procurement integration.
The visibility question: should buyers see other buyers' pricing?
No. A buyer at Account A should never see what Account B is paying. That is non-negotiable. It will end relationships and, in some categories, expose you to anti-discrimination scrutiny.
But your buyers also know they are not your only customer. They know the buyer down the street is probably getting a different price. Pretending otherwise insults them.
The right disclosure posture is transparency about the pricing logic, opacity about other accounts' specific numbers. Tell every buyer, in plain language on the portal:
Your pricing reflects three factors: your contracted rates on specific products, volume breaks based on the quantity you order, and your payment terms. Promotional pricing is offered periodically and may differ between customers based on segment and history.
That is the truth. It tells the buyer they are inside a structured system, not at the mercy of a salesperson's mood. It also explains why two different accounts might see different unit prices on the same SKU without inviting them to demand parity.
The cleanup project nobody budgets for
Before you can launch a B2B portal, you must rationalize the pricing master that is currently living in spreadsheets, email threads, and people's heads. There is no skipping this. The portal will encode whatever you give it. Garbage in, garbage out, except now the garbage is automated and visible to your customers.
When manufacturers actually do this exercise, they typically find:
- 15–25% of account-specific pricing is undocumented — no contract on file, no email trail, just an entry in the spreadsheet
- 8–15% of "active" special prices have technically expired but were never removed
- 5–10% of accounts have contradictory pricing across SKU lines (a tier-A discount on some products, a tier-C price on others, with no recorded reason)
- A handful of accounts have pricing that, when reconstructed, predates anyone currently employed at the company
Budget 4–8 weeks for the cleanup, with a finance lead and an inside-sales lead working it together. The output is a clean pricing master broken into three files: standard with volume breaks, account contracts (every line dated and tied to a contract reference), and active promos (every line with an expiration date).
This is the most painful part of any B2B portal launch. It is also the part with the most lasting value. The portal goes live; the discipline that produced the clean master is what keeps it clean.
Governance: the rules that keep the master from rotting
A B2B portal makes governance possible. It does not enforce it for you. You have to define the rules and stand behind them.
The rules that matter:
- Authority to create new account pricing. Sales reps cannot do it unilaterally. Define a threshold — any new account-specific price below standard book price by more than X% requires a finance approval ticket
- Mandatory expiration dates. Every special price has an end date. No more permanent specials. If it needs to be renewed, it goes back through review. This single rule prevents 80% of the rot
- Contract reference required. Every account-specific price links to a contract document, an email approval, or a CRM record. No reference, no price
- Quarterly audit. Finance pulls the active special-pricing list every quarter and asks the account owner to confirm or remove. Anything not confirmed within 14 days expires automatically
- Promo stacking rules in writing. Decide whether promos stack with contract pricing, with volume breaks, with each other. Document it. Configure the portal to enforce it
This is unglamorous work. It is also the difference between a portal that buyers trust and a portal that produces a different price every time someone reloads the page.
For manufacturers running their portal alongside an existing OMS and warehouse stack, the governance layer becomes part of the broader operations discipline. The same "controlled complexity" mindset that fixed your exception handling workflow and replaced your shipping spreadsheets is what fixes pricing too. If you are evaluating self-hosted infrastructure to keep pricing data inside your own perimeter rather than in a vendor's multi-tenant database, the self-hosted deployment model is worth a look. For manufacturers who would rather hand the operational layer to a partner, managed e-commerce operations covers the day-to-day governance work as a service.
What you will be looking at in 12 months
Twelve months after launch, the controller is no longer maintaining B2B Pricing Master.xlsx. The file still exists somewhere on the shared drive. Nobody opens it.
What replaced it is not simpler. It is a pricing engine inside the portal with three layers (standard with volume breaks, contract overrides, active promos), a governance workflow that requires sign-off on new specials, and a quarterly audit that ages out anything stale. The complexity is the same. The difference is that it is now in one system, with one history, with one set of rules, visible to the people who need to see it.
Your top thirty accounts still get their negotiated prices. Your salespeople still close deals at the prices they promised. Your CFO finally knows, on any given day, the actual revenue impact of every special price in force. The handshake deals from 2017 are documented or retired.
That is what a B2B portal does for pricing. Not simplification — structure. The accounts that mattered before still matter. They just stop being a yellow-highlighted row with a note that says "see email from John."
Talk to OrderHUBx about scoping a B2B pricing engine for your operation.