Choosing a B2B commerce platform as an industrial or MRO distributor

Start with the scope, because it saves you reading the wrong page. This page works the platform decision for an industrial or MRO distributor: which integration questions decide the shortlist, and what a yes to each one costs. It does not describe the sector, and it does not profile the verticals inside it. The /sample-report vertical pages on this site already do that, in more detail than a scenario page could, and they are linked at the end.

Plenty of businesses have a big catalogue. What makes an industrial or MRO distributor a distinct case is that four hard requirements arrive together, and each one on its own is solvable while the combination is what breaks a standard implementation.

The first is that price is per account. A fastener that lists at one number is sold at four different numbers to four customers, because three of them signed something. The second is that stock is in several places, and which place matters, because a customer collecting from the Winnipeg counter does not care what is on the shelf in Calgary. The third is catalogue scale: tens of thousands of items, most of them supplied as a manufacturer data file with a terse description and no image, most of them never viewed. The fourth is cultural, and it is the one that sinks projects. Orders come through the counter, through a rep, and through a quote, and the people who take those orders are measured on speed.

That fourth point deserves stating plainly because it does not appear on any feature comparison. If your inside sales team can key an order faster than the website can, and the website shows a price they know is wrong for that account, they will not use it and they will tell customers not to bother either. An industrial distributor’s commerce project is judged by the order desk before it is ever judged by a buyer.

One thing this shape does not automatically require is a bespoke platform. Plenty of industrial distributors run perfectly good businesses on a native connector with a deliberately scoped online catalogue. What the shape does require is that you find out which of the four requirements are real for you before you pick, rather than after.

Work through this table with your own numbers rather than reading it as a description of the sector. Every row links to a page that explains the mechanic properly, and the column that matters is the last one: what it does to the shortlist if the answer is yes.

The pattern that emerges from filling it in is usually clear. A distributor answering yes to contract pricing at volume and yes to warehouse-specific availability is not going to be well served by a configuration-only project, whatever the demo showed. A distributor answering no to both, with a curated online range sold at list, can buy a native connector and spend the difference on catalogue content, which is where the return actually is.

Catalogue size is the requirement most often stated and least often understood. A large SKU count does not break a commerce platform. Modern platforms hold hundreds of thousands of items without complaint. What it breaks is everything that assumes a human curated the catalogue.

Search is the first casualty. An industrial catalogue is largely manufacturer data: a part number, a forty-character description full of abbreviations, and a category. A buyer searching for a half-inch stainless hex bolt gets nothing, because the record says "BOLT HEX SS 1/2-13X2 18-8". Fixing that is a data project, not a platform project, and it is normally the single largest line item on an industrial distributor’s first phase. Any platform evaluation that spends more time on theme design than on how attributes will be populated has its priorities inverted.

The second casualty is pricing volume. Contract pricing rows multiply as customers times items times break quantities. A distributor with a large catalogue and a few hundred contract accounts can produce more price rows than any push-based architecture will carry comfortably, and the constraint that bites first is usually structural rather than numeric. Shopify documented on 20 August 2026 that Basic, Grow and Advanced plans allow "up to 3 active catalogs across all your B2B markets", with 25 catalogues per company location and 10,000 per store on Plus. Count your distinct price groups before you count rows.

The third is variant modelling. Industrial families with size, material, finish, thread and pressure rating exceed what Shopify represents as one product, and Acumatica’s connector reports it as a plain sync failure rather than a warning. The workaround is to flatten those families into separate products, which works and which costs you the filtering experience the buyer wanted in the first place.

These projects fail in a recognisable sequence, and the sequence is worth knowing because every stage of it is cheaper to prevent than to repair.

It starts with a demo that showed tiered pricing, because tiered pricing is the layer that maps cleanly onto commerce platforms and every vendor demos it. The project is scoped on that basis. Somewhere in build, someone discovers that the connector publishes the stock item Default Price rather than the effective sales price. Acumatica’s own community, asked about exactly this, answered "No. Only Default Price is supported." The team fixes it for the largest twenty accounts by hand-loading price lists, which works and quietly commits somebody to maintaining them forever.

Then availability. The site launches with a single company-wide stock figure, because that was the fastest thing to publish. A customer in one city orders something the system says is available and it is in another warehouse, three days away. The branch manager stops trusting the number. Within a month the counter staff are telling regulars to phone instead, which is the point at which the project has failed regardless of what the traffic report says.

Then the order desk. Orders arrive from the website in a shape the desk has to touch: a wrong unit of measure, a missing purchase order number, tax recalculated on import so the total no longer matches what the customer saw. Acumatica has a dedicated community thread on preventing tax recalculation on imported orders, which is a good sign that it bites everyone. Each of these is small. Together they mean an online order costs more to process than a phoned one, and the business quietly concludes that ecommerce does not work for them.

The common root is the same in every case: the project treated the storefront as the deliverable and the integration as a task. For this company shape the integration is the deliverable, and the storefront is how customers see it.

The version that works is narrow on catalogue and complete on mechanics. That is the opposite of the instinct, which is to publish everything and add the hard mechanics later, and it is the opposite for a specific reason: a customer will forgive a catalogue that does not yet include everything, and will not forgive a price that is wrong for their account.

Pick the customers who will use it first, and design for them. For most industrial distributors that is the existing accounts who reorder consumables, not new buyers found through search. Reorder from history, a correct price, a stock figure they can act on, and a purchase order number field will earn more order-desk deflection in the first quarter than a search experience across the full file.

Set the success measure before launch, and make it an operations measure rather than a revenue one. Online revenue in year one is mostly revenue that used to arrive by phone, so counting it as growth flatters the project and teaches you nothing. Counting the share of reorder lines that no longer touch a human tells you whether the thing is working.

We build integrations, so treat the following as evidence against our own interest. A good number of industrial distributors should buy a native connector and stop there, and the ones who should are identifiable in advance.

If your online range is a deliberate subset sold at list or at a simple tier, if you ship it from one warehouse, if your item families fit inside three attribute dimensions, and if no customer has asked for punchout, then a native Acumatica connector into Shopify or BigCommerce will do the job and the money is better spent on catalogue content and on getting your counter staff to use it. Adding middleware to that situation buys you a component to maintain and nothing a customer can see.

The honest boundary is a single question: is there a customer who will see a price on your website that is not the price they have agreed with you? If the answer is no, the cheap architecture is correct. If the answer is yes and you cannot fix it by restricting who sees what, you have crossed into the territory where configuration stops and building starts, and no amount of connector tuning will carry you back.

This page is deliberately shape-first, because the four decisions above behave the same way whether you sell fasteners or hydraulics. What it does not do is tell you how your vertical buys, which data files it lives with, or what its buyers search for. That work already exists on this site as sample reports, one per vertical, and each of those is longer and more specific about the industry than a scenario page has any business being.

Read the vertical page for the industry description and the buying behaviour, and read this page for the integration decisions. If you only have time for one, read the vertical page first: it will tell you which of the four decisions above is likely to be your expensive one.