B2B Ecommerce Portal Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the price on the portal come out wrong so often?

Because a trade price is a calculation and almost every commerce platform is built to hold a number. There is a base list. There is a customer contract overriding some items by percentage off list and others by fixed price. There are quantity breaks that may apply per line, per order or against rolling annual volume. There is a branch adjustment, a currency, an incoterm, sometimes a rebate agreement, and a promotion that must win this month and lose the next.

Ask your commercial director to explain how one customer's price for one item is derived and you will get five minutes of nested conditions. That answer is the specification. A nightly price list export flattens all of it into a single figure per product, which is correct for the simplest accounts and wrong for the accounts that matter.

The fix is to stop storing the price. Call the pricing engine in the enterprise resource planning system at the point of display and again at order submission, with the full context of customer, ship to, item, quantity and cart contents. Cache at the session level for speed, never at the catalogue level, because catalogue caching is how a stale contract price reaches a screen. If the pricing call is too slow at browse scale, and on older systems it usually is, mirror the pricing inputs into a read replica and reimplement the rules, then run a nightly reconciliation that samples customer and item combinations and compares your engine against the source. That reconciliation job is unglamorous and it is the thing that makes the whole portal trustworthy.

What goes wrong with trade catalogue data and customer part numbers?

Product data is where these projects actually overrun, and almost nobody scopes it. A trade catalogue with 60,000 stock keeping units accumulated over thirty years typically has a description field, a price and very little else. No attributes to filter on, no images, inconsistent units of measure, pack quantities embedded in the description as text, and duplicate records for the same item created by two branches. A catalogue in that state cannot be browsed or searched, and no search technology compensates for absent data.

The second problem is customer specific part numbers. Reps maintain these in spreadsheets, the mapping is many to many rather than one to one because customers buy kits you assemble from several lines, and the same customer code sometimes means different things at different sites. A buyer who cannot search by the number printed on their own requisition will not use the portal twice.

Two fixes, both boring and both decisive. Enrich the top sellers properly rather than everything badly, because 2,000 fully attributed items with images, filters and unit of measure discipline beat the full file with a search that returns nothing useful. Then treat the customer part number cross reference as a first class object with an owner, an import path from the reps' spreadsheets and a review queue for conflicts. Budget the enrichment as its own workstream with its own person, because it loses every sprint planning it is entered into.

Why do the ERP, punchout and EDI integrations break after launch?

Three integrations decide whether trade buyers stay, and each fails differently.

The enterprise resource planning link fails quietly. A feed stops updating, the portal keeps serving the last values it received, and stock, credit position or customer hierarchy drifts away from reality with nothing on screen to indicate it. Stamp every imported value with the time it arrived and display that timestamp on the internal views, so a stale figure looks stale rather than looking current.

Punchout fails per partner. A buyer inside Ariba, Coupa or Jaggaer clicks through into a session on your site, builds a cart and returns it into their own requisition and approval flow, usually over cXML or OCI. The specification is public, the implementations are not identical, and a connection that works for one customer's Ariba instance can fail on another's because of a field their procurement team made mandatory. Treat punchout as a project of several weeks per trading partner, with a test account on the customer's side before you promise a date.

Electronic data interchange fails on the acknowledgement path. Everyone builds the inbound 850 purchase order. Fewer build the 855 acknowledgement, the 856 despatch advice and the 810 invoice properly, and the customer's accounts payable rejects invoices that do not carry their purchase order number in the field they expect. Build all four as intake and output paths into the same order object as the web portal rather than as a parallel pipeline, or you will end up with two order histories and two versions of the truth.

What happens when credit and the delivery promise are not covered?

This is the gap between a portal that takes orders and a portal that keeps accounts. A trade account is a hierarchy of parent group, member companies, sites and users, and credit sits somewhere on that tree. If the account is on hold, the portal must refuse the order at submission with a message the buyer can act on, and it must know whether the hold applies to the whole group or to one branch. A portal that accepts an order finance cancels the next morning destroys confidence faster than any bug, because the buyer told their site the material was coming.

The delivery promise is the other half. A contractor is not asking whether you have stock, he is asking whether he can collect from the branch two miles away within the hour or whether it is a four week special order he needs to know about now. Answering that means branch inventory, transfer times, carrier cut offs per location and handling rules for anything moving by freight rather than parcel.

Build the promise engine to answer the question asked: collect from a named branch with a time, delivery with a date, backorder with an estimate drawn from the open purchase order rather than a guess, and let the buyer choose whether to split or hold. Then record every promise and compare it against what actually happened. That comparison is how you find the branch or the carrier quietly costing you accounts, and it is the only reporting from a portal that a branch network takes seriously.

Should you build custom or configure what you already own?

If your trade pricing is a handful of published tiers or a straight percentage off list, your accounts are single site, and no customer has mandated punchout, do not build. Sana Commerce is designed around live pricing from the enterprise resource planning system and if you run a system it supports natively, it removes most of the pricing problem for a subscription rather than a build. BigCommerce B2B Edition will have a smaller operation trading inside a quarter. Adobe Commerce B2B and OroCommerce both model company accounts, price lists and approval workflows competently, and OroCommerce is worth serious attention if you have internal capability to extend an open platform.

The honest test is not whether those products do everything you want. It is whether the parts that do not fit are worth a six figure build. Build when two or more of these are true: your pricing cannot be expressed as a price list without being wrong, your customers' approval rules run on product category or project code rather than value thresholds, a major account has mandated a trading partner your platform's connector does not cover, availability across branches is a competitive weapon in your category, or you have already attempted a platform project and abandoned it, which usually means the rules genuinely did not fit.

How do hidden costs get into the quote?

The age and openness of your enterprise resource planning interface is the largest and the least visible. A modern application programming interface and a green screen system with a nightly fixed width extract are not variations of the same job, they are different projects with different risk profiles, and a firm that has only integrated the modern kind will learn on your budget. Ask for the specific system, version and interface to be named in the proposal.

Trading partners are the second, priced per partner rather than once, so a proposal saying punchout supported without naming partners is a placeholder. Product data is third, and most often assumed to be free because you already own the file. Fourth is multi currency with multi country tax, which multiplies test cases rather than adding them.

Insist that the reconciliation job comparing your pricing against the source system is a line item rather than an assumption. Without it you have a portal that is probably right, and probably is not a basis on which a branch manager will stop answering the phone.

What separates a build that works from one that fails here?

Adoption, and adoption is decided by the sales team rather than by the interface. Reps kill portals when they believe the channel competes with their own number, and no amount of design work overcomes that. Give the rep a console where they can order inside a customer's context at the customer's prices, quotes that convert to orders with one buyer click, and visibility of their accounts' abandoned carts above a value threshold, which is a better call list than their customer relationship system produces. Then make certain the commission plan credits portal orders from their accounts to them. That is a compensation decision, it is not a software decision, and it needs to be made before the build starts.

Second, ship the two features trade buyers actually use early: reorder from order history, and saved lists per job site. They increase basket size and they are what brings a buyer back on Tuesday.

Third, pilot with a small set of real accounts rather than launching to the whole base. Trade buyers give you one attempt, and a bad first order becomes a branch anecdote repeated for a year.

Finally, settle ownership before kickoff: the repository, the cloud accounts and the unrestricted right to hire another firm to continue. At Digital Heroes the client owns the code from the first commit. Your order intake channel is not something to rent from a supplier.