A B2B implementation on Shopify that puts selling to businesses in order
We design and deliver B2B platforms for manufacturers and distributors who want to move price lists, trade terms and recurring orders into one process.
Before we set the Shopify scope, we analyse the sales model, the integrations and the exceptions that cannot be left out.
- Company and location
- Branch, delivery address and assigned users.
- Catalogue
- The assortment assigned to this company or segment.
- Prices after login
- Catalogue price, discount or a quantity threshold.
- Quick ordering
- Search, buying lists and pack-size multiples.
- Payment terms
- Deferred payment, a deposit or a PO number.
- Order history
- Fulfilment status and reordering a previous purchase.
Data from
- ERP
- PIM
- WMS
- CRM
- company accounts
- catalogues and pricing
- recurring orders
- ERP, PIM and WMS
When should you put a B2B platform on Shopify in place?
Usually once manual order handling starts costing before it shows up in a report. An order arrives by email or phone, a salesperson checks the price list, availability, trade terms and credit limit, then re-enters the data into another system.
With a dozen or so clients, this model can work. As sales grow, the number of exceptions, corrections and status questions grows with it. The client waits for an answer, and the sales team spends its time on operations that a platform can handle instead.
A B2B portal can take over the repeatable part of the process. Salespeople stay needed for negotiations, individual offers and relationship building, instead of spending most of the day taking standard orders.
Consequences of the current model
Outdated price lists
Prices sent out in several versions go out of date.
Manual re-entry
Orders need manual checking and re-entering between systems.
Dependence on a salesperson
The client depends on a salesperson's working hours and availability.
Scattered history
Information about previous orders stays scattered across emails and the ERP.
Growing exceptions
Every new group of customers adds more operational exceptions.
Shopify B2B — which sales model does it suit best?
Best when the sales rules can be clearly described. Before preparing the scope, we establish how prices are set, who can order, which products a given group sees, what payment terms apply and where the data comes from.
Shopify's native B2B model handles the repeatable part of wholesale: companies and their locations, assigned buyers, catalogues with their own prices, quantity thresholds, payment terms with a PO number, order history and reordering. The full list is gathered among the platform's features.
Integrations enter the scope the moment price lists, accounts, stock or fulfilment statuses have a single source outside the store — usually an ERP, and with a large catalogue a PIM or WMS as well. Without them the platform means maintaining the same data by hand in two places; how responsibility is split between systems is settled before configuration.
Broader Shopify features — and sometimes the Plus plan — are needed when a catalogue goes directly to a specific company or location, when there are many catalogues, when advanced payment features are involved, or when the buying process goes beyond the standard checkout. We choose the plan after those requirements are settled, not before.
Shopify fits well when
- 01customers can be organised as companies and locations
- 02the offer is based on catalogues, price groups or clearly described agreements
- 03orders repeat often
- 04minimum quantity or price-threshold rules apply
- 05the customer needs access to history and reordering
- 06the ERP, PIM or WMS can exchange data through an API or a stable integration mechanism
- 07most of the buying process can run self-service
The project needs a wider comparison when
- every order's price is set through individual configuration
- the process includes several elaborate approval stages
- the offer resembles a CPQ configurator
- the number of contract exceptions outnumbers the shared rules
- the source systems cannot provide stable data
- the model relies on features Shopify B2B does not currently support, or needs a large number of extensions for them
In those situations, a B2B implementation on Magento 2 is usually the better answer.
The key features of a B2B platform on Shopify
What the platform gives a business customer and a sales team, in five groups — from who is buying to where the data comes from.
- 01
Companies and users
The customer as a structure rather than a single account: the organisation, its branches and the people who may buy on its behalf.
- company profiles
- company locations
- several buyers per company
- user permissions
- 02
Catalogues and prices
What the customer sees once logged in, and the price they get with it — instead of a price list attached to an email.
- customer catalogues
- individual prices
- discounts
- quantity rules
- 03
Ordering
A path for someone who knows what they want and orders it regularly — not for a customer browsing the range.
- quick ordering
- reordering
- order history
- 04
Payments and documents
Trade terms assigned to a company or a location, visible in the cart and on the order.
- payment terms
- PO numbers
- 05
Integrations
Not a feature of a plan but a scope of work: they decide whether the platform's data agrees with the rest of the company.
- ERP integrations
- PIM integrations
- WMS integrations
- CRM integrations
Which of these are available depends on the Shopify plan used in the project — this list is not a set that every plan delivers in full. Catalogues assigned directly to a specific company or location, an unlimited number of market catalogues and some advanced payment features need the Plus plan; the rest of the list also works on Basic, Grow and Advanced. See plan features (opens in a new tab).
A price list is one of several elements that have to be modelled
The platform has to know who is buying, on behalf of which company the order is placed, what they can see and on what terms they can pay.
- 01
Companies and locations
One organisation can have several branches, delivery addresses, buyers and sets of terms. It has to be decided at which level prices, catalogues and permissions are assigned.
- 02
Users and roles
A buyer may only place orders for their own location. A company administrator can see other users' orders, manage addresses or reorder purchases.
- 03
Catalogues and availability
Different customers can see a different range of products. Part of the assortment can be available to a whole segment, part to selected companies only.
- 04
Prices and discounts
The model can be based on catalogue prices, a percentage discount, quantity thresholds, or a price list assigned to a group or a specific location.
- 05
Ordering rules
Minimum quantity, pack-size multiples, a maximum quantity, quick variant adding and reordering a previous purchase all shape the interface design.
- 06
Payments and documents
Payment terms, a PO number, deferred payment, a deposit, an invoice or an order requiring approval all need to match the company's own rules.
- 07
Delivery and tax
The cost, method and address of delivery can depend on the company's location, order value, product type or data passed from the ERP.
- 08
Sales handling
It has to be decided which actions the customer performs, which the salesperson, and which the system. The portal can handle standard orders while leaving unusual cases to the sales team.
A business customer can reorder without involving a salesperson
After logging in, the user gets access to their company's data, the right catalogue, prices and terms.
The interface should lead to placing an order quickly, not reproduce a path built for a retail customer.
The business customer's path
- 01
Secure access
The customer logs into an account assigned to the company or its location. Only authorised people get access to prices and the offer.
- 02
The right buying context
The system recognises the company, location, the user's role and the assigned terms.
- 03
Finding products quickly
The customer uses the catalogue, search, quick-order lists or the history of previous purchases.
- 04
An order that matches the agreement
The cart accounts for prices, quantity rules, the delivery method, payment terms and a PO number.
- 05
Self-service after the purchase
The user checks order history, tracks shipments, reorders previous purchases and can handle returns within the scope the company's process allows.
What a B2B implementation on Shopify covers
The list of apps comes after the processes are defined. Every element has to answer a concrete need of the customer, the sales team or the admin.
- 01
Process analysis and technology qualification
We describe customer types, how prices are set, roles, ordering rules, payments, logistics and exception handling. This confirms whether Shopify is the right choice.
- 02
Plan and architecture choice
We establish whether a dedicated store, a B2C + B2B model, Shopify Plus, the Advanced plan or a simpler setup is needed. The decision follows from the features the project needs.
- 03
B2B customer experience design
We design login, the company account, location selection, the catalogue, search, quick ordering, the cart, checkout, history and reordering.
- 04
Shopify B2B configuration
We build the structure of companies, locations, contacts, catalogues, prices, quantity rules, payment terms and permissions defined in the agreed model.
- 05
Development and extensions
We build the elements that configuration alone cannot deliver. The scope can include storefront components, account or checkout extensions, or an app handling a specific process.
- 06
Integrations
We connect Shopify to the systems named in the architecture. Every integration gets a description of the data, the direction of exchange, the frequency and error handling.
- 07
Data migration
If the project replaces an existing portal, we prepare the scope for moving companies, contacts, addresses, catalogues, order history and other agreed data.
- 08
Testing, launch and handover
We check scenarios for different companies, locations, roles, catalogues and terms. After acceptance, the project is launched, documented and handed over for further development.
ERP, PIM and WMS have to feed the same order process
Before implementation we establish which system owns each class of data. Without that split, prices, stock and customer data drift apart.
The ERP usually owns accounts, trade terms, documents and settlement status. The PIM can own descriptions, attributes and the structure of product information. The WMS passes on availability and fulfilment data. Shopify presents the right context to the logged-in user and takes the order. The final split depends on the current architecture; the analysis also checks sync frequency, error handling and how operations are retried.
Source systems
- ERPtwo-way
accounts, terms, settlements
- PIMinto Shopify
descriptions, attributes, structure
- WMStwo-way
availability, fulfilment
- CRMtwo-way
contacts, relationship history
Shopify B2Bbusiness customer portal
Data recipients
- Company accountout of Shopify
catalogue, prices, terms
- Orderout of Shopify
PO number, quantity rules
- Fulfilment statusout of Shopify
shipping, invoice
One source per data type
Every type of data has a designated source system.
Error scenarios in scope
The integration covers error scenarios, not only a correct API response.
No half-processed orders
A price or stock update cannot leave an order partially processed.
Visible sync health
The client's team gets a way to check whether the synchronisation is working correctly.
The implementation delivery process
Every stage ends with a concrete decision or artefact.
Six stages lead from diagnosing the sales model to launching and stabilising the B2B channel.
- 01
Diagnosis and qualification
We learn the sales model, the current architecture, the number of customer groups, data sources and the expected level of self-service.
ResultA process map, a list of constraints and a technology decision.
- 02
Solution architecture
We choose the store model, the Shopify plan, data sources, the integration approach and how responsibility is split between systems.
ResultAn architecture diagram and a description of the data flow.
- 03
UX and prototype
We design the tasks buyers and company administrators perform most often.
ResultA prototype of the key journeys and acceptance criteria.
- 04
Configuration and development
The storefront, B2B configuration, extensions and the agreed integrations are built.
ResultA working test environment.
- 05
Data, QA and UAT
We import test data and check the process for different companies, roles, prices, payments and order variants.
ResultA test report, a list of fixes and business acceptance.
- 06
Launch and stabilisation
We prepare production data, a cutover plan, monitoring and documentation for the client's team.
ResultA live B2B channel and an agreed backlog of further work.
How much does a B2B implementation on Shopify cost, and how long does it take?
We give neither a single price nor a single duration for this service — the same name covers a configuration for a dozen accounts and a portal for several hundred companies priced from an ERP. The eight things below move the estimate and the schedule most.
What moves the estimate and the schedule
- The Shopify plan
- The scope of B2B features and their limits differ between plans, and the plan decides how much of the process can be configured and how much has to be built.
- The number of companies and locations
- A few dozen accounts can be entered and checked by hand. Several hundred with branches and assigned buyers means an import, assignment rules and test scenarios for every variant.
- The number of catalogues
- One wholesale price list for everyone is different work from catalogues assigned to segments, companies or locations — each with its own prices and its own upkeep.
- Individual trade terms
- Discounts, quantity thresholds, payment terms and credit limits either map onto rules or need logic of their own. The second case is development, not configuration.
- Integrations
- The number of systems, the directions of exchange, the frequency and the quality of the data on the ERP, PIM, WMS or CRM side. Every flow needs error handling and reprocessing.
- Buying processes
- An order approved by a manager, a request for quote, buying lists or recurring orders all go beyond the standard path and are estimated separately.
- Customer migration
- Moving accounts, contacts, addresses and order history into the structure of companies and locations depends on how that data is linked in the current system.
- The scope of custom development
- Anywhere from a configuration on an off-the-shelf theme to custom storefront components, account or checkout extensions and an app handling a specific process.
The estimate and the schedule are produced after the sales-model analysis and once the architecture is settled — only then is it clear what is configuration and what is development. If the implementation replaces a running portal, the other half of the scope is described by migration to Shopify.
FAQ — Shopify B2B
Concrete answers, without declaring terms we agree individually during the analysis.
Let's discuss a B2B implementation on ShopifyYes, provided the rules of that trade can be described. Shopify has a native B2B model: companies and locations, assigned buyers, catalogues with their own prices, quantity thresholds, payment terms and order history. What it does not replace is a quote configurator, or a process where every order's price comes out of a negotiation. The criteria we check before that decision are gathered in the section on whether Shopify fits.
Not on every project. Shopify B2B is currently available on the Basic, Grow, Advanced and Plus plans. Most core features — companies, catalogues, payment terms, self-service ordering, quantity rules and PO numbers — work on all of these. Shopify Plus offers the wider capabilities more complex projects need — among other things catalogues assigned directly to a specific company or location, an unlimited number of market catalogues, and some advanced payment features. So the plan follows from the B2B features required, the number of catalogues, the customer structure and the scale of the project, rather than the other way round. See plan features (opens in a new tab).
It depends on the plan and the catalogue model. Prices and availability can be varied by customer segment through Markets and catalogues. Assigning a catalogue directly to a specific company or location is a Shopify Plus feature.
Yes. Payment terms are assigned to a company or one of its locations — payment within a term, on fulfilment or upfront — and a PO number can be added to the order. The credit limit and receivables control usually stay in the ERP, so before implementation we establish whether the platform should block an order once the limit is exceeded, and where it reads that from.
Yes. Quantity rules — a minimum, a pack-size multiple and a maximum — are set in the B2B catalogue, and price lists support thresholds where the price depends on the quantity ordered. More elaborate conditions, such as a minimum order value per company or a threshold counted across a product group, may need an extension or an app; we check that before quoting.
Customers use Shopify's new customer accounts. Login happens through an email address assigned to the company and a one-time code. Legacy customer accounts cannot be used for B2B orders.
A dedicated B2B store can restrict the offer to logged-in business customers. The exact mechanism depends on how strict the lock needs to be, the theme, and any extensions involved. A full login wall may require extra development or an app.
Yes. Shopify calls this variant a blended store. One admin and storefront serve both retail and business customers, and some content, prices, products and terms can be varied. We describe this on a separate page, B2C + B2B implementation on Shopify.
The prices a customer sees come from price lists in Shopify, and the ERP is usually their source — the price lists are synchronised rather than queried while the page renders. For most wholesale models that is enough, and it is safer: the cart then does not depend on the ERP being up. If the price has to be produced in the source system at the moment a product is added to the cart, that has to be designed separately, with performance and order consistency checked; where there are many such rules, the usual point of reference is a B2B implementation on Magento 2.
Yes, if the systems can provide the data and an integration mechanism suited to the planned process. Before pricing, we define the data scope, sync frequency, system responsibility and error handling. Shopify's API also covers B2B objects.
We do not give a single price, because the same service covers a configuration for a dozen accounts and a portal for several hundred companies priced from an ERP. The estimate is driven by the Shopify plan, the number of companies and locations, the number of catalogues, individual trade terms, integrations, buying processes, customer migration and the scope of custom development — all eight are set out in the section on cost and time.
We do not give a date before the scope and the architecture are settled — they decide how much of the process can be configured and how much has to be built. The schedule is produced after the sales-model analysis and splits into six stages, each ending with a decision or material to accept, so progress is visible without waiting for the end of the project.
Shopify supports migrating customers and order history into companies and locations. How much can be moved depends on the data available in the current system and how it is linked. The full process needs to be planned as a separate migration scope — see migration to Shopify.
After launch, the platform needs integration monitoring, app updates, behaviour analysis and backlog development. The scope of further collaboration is agreed separately as part of Shopify maintenance.
Let's check whether Shopify can handle your B2B sales model
On the first call we will go through the customer structure, pricing rules, how orders are placed and the systems that need to exchange data with the store.
