Shopify B2B in 2026: What Works, What Requires Customisation and Where It Fits
B2B e-commerce is taking on work that used to be spread across email, spreadsheets, sales calls and customer service. Product discovery, account-specific assortments, contract pricing, payment terms, repeat orders and order status are increasingly expected to work as one joined-up buying experience.
- 1. Shopify B2B has entered the main platform conversation
- 2. Companies, locations, buyers, catalogs and pricing
- 3. Store architecture: two decisions, not three
- 4. ERP, PIM, CRM, EDI and custom development
- 5. Implementation cost, timeline and platform fit
- A decision checklist for a serious evaluation
- The Grebban view
The commercial case is no longer marginal. McKinsey’s 2024 B2B Pulse found that 71% of respondents offered some form of e-commerce. Among those businesses, online sales generated 34% of revenue and had overtaken in-person sales as the largest revenue channel. Buyers still move between human, remote and self-service interactions, but the transaction and its context increasingly need a reliable digital core, as McKinsey’s B2B Pulse analysis also makes clear.
That shift changes the platform discussion. Shopify used to be easy to shortlist for DTC and easy to dismiss for demanding B2B. In 2026, dismissal is difficult to justify. The company and catalog model has matured, the native storefront and checkout remain strong, and Shopify can now support a meaningful range of manufacturers, distributors, wholesalers and brands with mixed B2C and B2B operations. It has become a genuine contender in the B2B platform market.
That is also why Shopify B2B has become interesting to Grebban. Our Flagship B2B point of view begins with a higher ambition than putting a trade catalog behind a login. The strongest B2B experiences make more of the sales organisation’s expertise available digitally. They guide buyers towards the right products and configurations, communicate product and brand value, reflect each account’s commercial context, and make routine purchasing genuinely self-service without removing the salesperson from the moments where judgement matters.
Shopify now offers an increasingly credible foundation for doing that within the same commerce platform and storefront layer used to create modern consumer experiences. That combination is the opportunity. The question is how far it works natively, where it requires customisation and which operating models it genuinely fits.
Grebban’s Shopify B2B work spans businesses including Kasthall, Macforum, Vitamin Well Group and Opaje. Their commercial models differ, which is precisely why platform evaluation needs to begin with the buying model rather than a generic B2B feature list.
Selected Grebban clients using Shopify B2B
Shopify’s April 2026 release widened that opportunity further. Foundational B2B features, previously restricted to Shopify Plus, became available across Basic, Grow and Advanced. Companies, company locations, B2B catalogs, quantity rules, volume pricing, payment terms and self-service ordering no longer require Plus by default.
Wider availability is an important product change, although plan access is only one part of the evaluation. The harder question is whether Shopify’s operating model can represent the way the business sells without pushing its most important rules into fragile workarounds.
Five questions reveal that fit:
- What is genuinely native on each Shopify plan.
- Whether Shopify’s company, location, buyer and catalog model fits your commercial structure.
- Whether B2B and DTC should share a store, or operate separately.
- Which systems should own customer, product, price, inventory and order data.
- What still requires configuration, an app, an integration or custom development.
This article works through those questions as Shopify B2B stands in September 2026.
01
1. Shopify B2B has entered the main platform conversation
On 2 April 2026, Shopify extended foundational B2B features to Basic, Grow and Advanced. Most of the commercial core is now available across all paid plans. The remaining plan boundaries concern catalog granularity, contextual storefronts and checkout, and advanced payment workflows, as well as how custom Functions and checkout extensions can be delivered.
Shopify B2B features
| CAPABILITY | BASIC | GROW | ADVANCED | SHOPIFY PLUS |
|---|---|---|---|---|
| Companies and company locations | Yes | Yes | Yes | Yes |
| Buyer permissions | Yes | Yes | Yes | Yes |
| B2B market catalog assignments | Up to 3 | Up to 3 | Up to 3 | Unlimited |
| Direct catalog assignment to a company or location | No | No | No | Yes |
| Quantity rules and volume price breaks | Yes | Yes | Yes | Yes |
| Net payment terms, vaulted cards and payment reminders | Yes | Yes | Yes | Yes |
| Purchase order numbers, reorders and checkout-to-draft | Yes | Yes | Yes | Yes |
| Quick-order list and Trade theme | Yes | Yes | Yes | Yes |
| Contextual storefront and checkout through Markets | No | No | Yes | Yes |
| Deposits, partial payments and payment requests per fulfilment | No | No | No | Yes |
| Shopify Flow with B2B objects | Yes | Yes | Yes | Yes |
| Public App Store apps using Shopify Functions | Yes | Yes | Yes | Yes |
| Custom apps using Shopify Functions | No | No | No | Yes |
| Checkout UI extensions in the information, shipping and payment steps | No | No | No | Yes |
On Basic, Grow and Advanced, B2B catalog functionality also depends on the new Shopify Markets setup. That should be checked before a lower-plan implementation is scoped.
The table changes the plan-selection discussion in two important ways.
The lower plans are now credible for a bounded wholesale model. A business with a small number of pricing tiers, standard payment terms and no need for customer-specific catalogs can use native B2B without adopting Plus solely to unlock the data model.
Second, Plus remains materially different for businesses with complex account-level pricing. On Basic, Grow and Advanced, the limit is three active catalog assignments across all B2B markets. Assigning three catalogs to one market consumes the entire allowance. Plus removes that ceiling and permits catalogs to be assigned directly to an individual company or company location.
That distinction is easy to underestimate. Imagine a distributor with three customer tiers in two regions. If the assortments or prices differ by both tier and region, the model can require more than three assignments before customer-specific exceptions have even been considered. The relevant question is not how many price lists exist today. It is how many distinct combinations of assortment, currency, market and commercial agreement need to be represented.
Advanced introduces another important threshold. Contextual storefront and checkout customisation through Markets is available on Advanced and Plus. This matters when different B2B markets require different content, navigation, payment options or checkout treatments, rather than price changes alone.
Extension strategy has a separate plan boundary. Any paid plan can use a public App Store app that contains Shopify Functions, but a custom app containing Functions requires Plus. Checkout UI extensions on the information, shipping and payment steps also require Plus. The thank-you and order-status surfaces are separate extension targets and should not be treated as equivalent to modifying the checkout itself.
Plus is therefore not simply the plan for larger companies. It is the plan boundary for a specific kind of complexity:
- unlimited and directly assigned catalogs;
- customer-level pricing exceptions;
- deposits and partial-payment workflows;
- payment requests per fulfilment;
- custom apps using Shopify Functions and checkout UI extensions in the core checkout steps;
- broader enterprise governance and platform capabilities beyond B2B.
For EU merchants, Shopify currently lists Plus at €2,250 per month on a one-year term or €2,100 per month on a three-year term. A variable platform fee may apply to more complex or higher-volume businesses, and B2B and DTC rates can differ. Pricing should therefore be modelled from the actual contract, not from the headline subscription alone.
Choose the plan after modelling the commercial structure. Revenue and company size are useful indicators, while catalog granularity, market variation and payment logic are better predictors of the required tier.
The 2026 plan boundary (Figure 01)
The core is now broad. Commercial granularity still determines the tier.
.
| CAPABILITY LAYER | BASIC | GROW | ADVANCED | SHOPIFY PLUS |
|---|---|---|---|---|
| Shared B2B foundation – Companies, locations, buyers, quantity rules, volume pricing, terms, PO numbers, reorders, quick order | Included | Included | Included | Included |
| Catalog assignment – How many commercial contexts can be represented natively | 3 across markets | 3 across markets | 3 across markets | Unlimited + direct |
| Contextual experience – Market-specific storefront and checkout | Not included | Not included | Included | Included |
| Advanced payments – Deposits, partial payments and payment requests per fulfilment | Not included | Not included | Not included | Included |
Plan selection should follow catalog, market and payment complexity. Company size is only a proxy.
02
2. Companies, locations, buyers, catalogs and pricing
Shopify’s B2B data model is opinionated. This is one of its strengths when the model fits, and one of the first places to look for friction when it does not.
The structure has three primary levels:
- Company: the parent organisation.
- Company location: the entity used in a B2B transaction.
- Customer: the individual buyer acting for that business.
A company can contain multiple locations. Each location can have its own tax ID, tax exemptions, billing and shipping address, pricing, payment terms, checkout settings and contacts. The individual customer authenticates and is given access to one or more locations within that company.
This structure determines how customer master data, entitlements, prices, credit terms and orders need to map into Shopify.
The account model (Figure 02)
Commercial context sits at company-location level. Buyers act inside that context.
The first fit test is structural: can real customers, legal entities, buyer access and commercial rules be represented without exceptions becoming the model?
The first fit test is organisational
For many manufacturers, distributors and brands, Shopify’s model maps cleanly:
- a corporate group becomes the company;
- subsidiaries, branches, stores or delivery entities become locations;
- procurement users become contacts;
- price lists become catalogs;
- terms and checkout behaviour attach to the relevant location.
The model becomes more difficult when the commercial reality does not follow that hierarchy.
A Shopify customer can belong to only one company, although that customer can access multiple locations within it. If a purchasing consultant, franchise operator or shared-services team buys for several unrelated legal companies, the standard identity model needs additional consideration.
The native buyer permissions are also deliberately simple. Shopify provides Ordering only and Location admin. That is enough for many businesses, but it is not a multi-stage procurement hierarchy. Businesses that require separate requesters, approvers, budget owners, finance users and administrators should treat authorisation as a design and extension problem, not assume it exists in the core.
Address management has a similar boundary. A location has one saved shipping address. Buyers can be allowed to enter a one-time address at checkout, but that address is not stored for future use. This is acceptable for occasional drop shipments. It can become awkward for customers that regularly order to a changing network of project sites.
Catalogs are the centre of the commercial model
A B2B catalogue can control product availability and pricing at variant level. Multiple catalogues can be assigned to a company location on Plus, or through B2B Markets within the plan limits.
Catalogue precedence depends on how the catalogues are assigned. Among multiple catalogues assigned directly to a company location, Shopify uses the lowest product price. When a directly assigned company-location catalogue overlaps with a B2B Market catalogue, the directly assigned catalogue takes precedence, even if its price is higher.
That makes the result deterministic, but it also means the catalogue architecture needs to be intentional. A base catalogue, a market catalogue and an account exception are not interchangeable layers. Before overlapping them, the team needs to know which assignment method wins and why that precedence is commercially correct.
Pricing can be expressed as an overall adjustment or fixed product prices. Quantity rules support minimums, maximums and increments. Volume pricing supports up to ten price breaks per product, applied independently at variant level. A price-break quantity must be greater than the variant minimum and must be a multiple of its increment. Three consequences matter in practice:
- Quantities cannot be combined across variants to satisfy an increment or minimum. Five blue units and five grey units do not fulfil a minimum of ten on either variant.
- Minimums, increments and price breaks have to be designed together. A valid commercial price ladder can otherwise be impossible to express as valid order quantities.
- Once volume pricing is applied to a product, its price becomes fixed and the catalog’s overall adjustment no longer applies.
The storefront layer also deserves attention. Liquid exposes quantity rules, volume pricing and company-location context, but the buyer’s contract price is presented through price and compare-at-price values rather than as a visible catalogue or price-list object. Without deliberate interface design, a negotiated price can look like a consumer promotion instead of an account entitlement.
These are reasonable rules, but they may not match an ERP price engine that calculates breaks across a product family, contract, assortment or total order.
The evaluation should therefore use real commercial examples, not a generic list of requirements. Take the twenty most important customers and run their actual agreements through the model:
- Which products can they buy?
- Which price is shown for each product?
- Is the price fixed, discounted or calculated elsewhere?
- Are minimums and breaks per variant, product family or total order?
- Which currency is contractual?
- Which exceptions require sales approval?
- What happens when two rules apply?
If those cases can be represented cleanly, Shopify’s native catalog model can remove a large amount of custom logic. If they cannot, that complexity does not disappear. It moves into an integration, an app or a bespoke price service.
Payment terms and order review are useful, but bounded
Native payment terms include no terms, net 7, 15, 30, 45, 60 and 90, plus due on fulfilment. A fixed calendar date can be set on an individual draft order. Customers can pay before or after the due date through their account, but Shopify does not automatically capture payment when the terms expire.
On Plus, deposits can be defined for companies, locations and draft orders. Dynamic terms or deposits based on order value, customer type, products or metafields can be implemented through a third-party app or a custom app using the Payment Customization Function API. That makes them extensible, but not equivalent to a fully native credit-control engine.
Order review follows a similar pattern. A company or location can be configured so that every checkout becomes a draft for review. Conditional review, such as holding only first orders, high-value orders or orders containing restricted products, requires a Payment Customization Function or an app. The distinction matters when estimating implementation and ownership.
Customer onboarding needs an explicit operating model
Shopify Forms can create a new company, location and customer from an account request. By default, the company remains unapproved until a team member reviews it, and Shopify Flow can automate approval. This is a useful foundation for trade applications.
There are two boundaries to plan for. The form does not add a buyer to an existing company, and it cannot be exposed to unauthenticated users when a dedicated B2B store is fully gated. Existing-account requests, duplicate detection, credit checks and CRM routing may therefore require a more deliberate workflow.
Shopify B2B works best when its primitives correspond to the business:
company → location → buyer → catalog → terms → order
When those relationships are clear, the platform is doing real work. When every relationship needs an exception, Shopify may still be usable, but the solution should be evaluated as a customised commerce architecture rather than a standard B2B setup.
03
3. Store architecture: two decisions, not three
Architecture discussions often present blended, dedicated and multi-store as three alternatives. They are not peers. A Shopify B2B architecture has two separate decisions: whether B2B and DTC share a store, and whether the wider organisation needs one store or several.
Store type: blended or dedicated
Shopify supports a blended store, where B2B and DTC share one store and admin, and a dedicated B2B store with its own admin, storefront, inventory and settings. Shopify explicitly warns that changing later is difficult because companies, catalogs and storefront customisations need to be rebuilt.
The right decision is operational, not aesthetic.
| DECISION DIMENSION | BLENDED STORE | DEDICATED B2B STORE |
|---|---|---|
| Commerce model | B2B and DTC in the same store | B2B in a separate store |
| Admin | One admin and one store context | A separate admin and store context |
| Customer experience | A shared storefront foundation adapted to the buyer's B2B context | A B2B-specific storefront, navigation and account experience |
| Products | Strong when ranges, product models and merchandising substantially overlap | Strong when ranges, packs or merchandising are materially different |
| Inventory | Shared across both channels and not reserved by customer type | Separate from DTC by default |
| Teams and operations | Commercial and operational processes overlap | Teams, processes or responsibilities are distinct |
| Brand and content | Shared foundation with contextual adaptation | Greater separation and a potentially gated experience |
| Integrations | One store context, but every app and flow must support both audiences | A separate store context that is integrated and operated separately |
| Reporting | Same-store data segmented by customer context | B2B-specific store reporting |
| Typical fit | One commerce operation serving consumer and business buyers | A structurally separate B2B operation |
A blended store is not simply the cheaper option. It can be the better operating model when customers, products, inventory and teams overlap. A dedicated store is not automatically more enterprise. It is better when separation is real and valuable.
Inventory is often the deciding factor. In a blended store, B2B and DTC share inventory and stock cannot be reserved by customer type. If the business promises wholesale allocation independently from consumer availability, that requirement needs to be solved operationally, through external inventory logic, or through a separate store.
International selling adds another layer. B2B Markets can vary language, currency, domains, catalogs, theme content, checkout and account configuration, duties, taxes and discounts. The experience a company location receives is determined by the markets it matches and can change with the shipping address. Multi-currency B2B through Markets requires Shopify Payments. This is powerful, but it means the market model and company-location model must be designed together.
Organisation architecture: single-store or multi-store
Multi-store is a separate organisational decision. A group can operate several stores, and each of those stores can be blended or dedicated. Treating multi-store as a third store type hides the actual question: where does the organisation need an operational boundary?
| DECISION DIMENSION | SINGLE-STORE ARCHITECTURE | MULTI-STORE ARCHITECTURE |
|---|---|---|
| Operating model | One shared commerce operation | Several operations with meaningful autonomy |
| Brands | One brand or a portfolio that can share one storefront context | Distinct brands, propositions or release cycles |
| Legal entities | One primary commercial entity | Several entities with separate legal or financial setup |
| Inventory | One shared inventory context | Separate ownership, allocation or regional pools |
| Markets | Variation can be handled within one store | A market boundary also changes ownership, operations or systems |
| Teams | Central team and shared processes | Distributed teams with store-level responsibility |
| ERP and systems | One commerce endpoint and integration context | Several endpoints governed by a reusable integration pattern |
| Governance | Central control with less duplication | Shared components and standards, plus explicit local ownership |
| Trade-off | Lower duplication, but more contexts inside one store | Clearer separation, but more operational and technical overhead |
| Decision principle | Consolidate what the business genuinely shares | Separate where a meaningful operating boundary already exists |
Separate stores can provide clearer ownership, inventories, legal settings and release cycles, while an organisation-level architecture can still standardise components, integrations and governance. Consolidating everything into one store is not inherently more mature. Neither is multiplying stores.
Native Shopify or headless?
B2B complexity is sometimes used as an automatic argument for headless. Ordering complexity alone is a weak reason to take on a separate frontend architecture. Design ambition alone is not a headless argument either.
Shopify’s native theme architecture has a meaningful advantage: the storefront, customer accounts, apps and platform roadmap are designed to work together. A native build generally reduces the amount of functionality a team needs to recreate and maintain, while Liquid can still support a highly differentiated interface and shifts much of the storefront performance burden to Shopify. Grebban’s broader position is to use commerce platforms according to their native strengths, rather than forcing an architecture onto a platform because it is fashionable.
Headless can be right when the reason is specific and durable:
- the experience requires build steps, server-side data retrieval or runtime behaviour that the native stack cannot support responsibly;
- the experience spans several backends or channels;
- the interaction model is unusually complex;
- content and product discovery need a frontend architecture that cannot be delivered responsibly in the native stack;
- a shared frontend layer serves multiple stores or commerce engines;
- organisational capability already exists to own the additional surface area.
Buyers usually care more about finding the right product, seeing the right price and availability, repeating an order quickly, and knowing that the transaction will be fulfilled correctly. Native Shopify can do those things well.
The storefront should still do more than process orders. Grebban’s B2B perspective is that a portal should communicate product value, not only product details. The best salespeople do not begin with a grid of SKUs. They frame the problem, guide the choice, explain trade-offs and give the buyer confidence. A strong digital experience should make that expertise available without removing the human relationship.
That hybrid model reflects how B2B buying actually happens. McKinsey’s 2024 B2B Pulse found that buyers divided their preferences roughly between in-person, remote and digital self-service, and used an average of ten interaction channels. The implication is not that a portal replaces the sales team. It is that account history, product guidance, quotes, orders and support should remain coherent as a buyer moves between them.
Two architecture decisions, in the right order (Figure 03)
First decide whether B2B shares a store with DTC. Then decide whether the organisation needs one store or several.
Decision Principle
Consolidate where the business is genuinely shared. Separate where a meaningful operating boundary exists.
A multi-store architecture can contain blended stores, dedicated stores or both. It is an organisational pattern, not a third store type.
04
4. ERP, PIM, CRM, EDI and custom development
Shopify can be the commerce layer without being the system of record for everything.
“The question isn't whether Shopify can do B2B. The question is where Shopify's native model should end, and where the rest of the business architecture should begin.”
Anders Eriksson, Grebban
This is the area where many platform evaluations become too shallow. A pre-built ERP connector may exist, but connector availability is not an integration design. The objects supported, direction of synchronisation, update frequency, conflict rules and failure handling still need to be verified.
Direct or partner integration routes exist for systems including Acumatica, Microsoft Dynamics 365 Business Central, NetSuite, QuickBooks, Akeneo and Syndigo, alongside iPaaS options such as Pipe17, Patchworks and OmnifiCX. That availability is useful, but some App Store integrations do not fully support B2B companies and catalogs. The supported objects and data directions still need to be verified against the actual operating model.
The architecture should begin with ownership, not tools.
.
| DOMAIN | TYPICAL SYSTEM OF RECORD | WHAT SHOPIFY NEEDS | FAILURE TO PREVENT |
|---|---|---|---|
| Companies and locations | ERP or CRM | Stable external IDs, addresses, tax status, status and entitlements | Duplicate accounts or orders attached to the wrong legal entity |
| Buyers and access | CRM, identity platform or Shopify | Verified identity, company-location assignment and permissions | A buyer sees the wrong account, prices or orders |
| Product master | PIM or ERP | Sellable product structure, variants, units, attributes and publish status | A technically valid Shopify product that cannot be ordered correctly |
| Catalog and contract pricing | ERP, price engine or Shopify, depending on complexity | Deterministic prices and product availability by context | Stale price, overlapping rules or a silent fallback to retail pricing |
| Inventory and availability | ERP, WMS or OMS | Available-to-sell quantity and relevant lead-time signal | Accepting an order that operations cannot fulfil |
| Orders | Shopify at capture, then ERP or OMS for fulfilment | Company, location, PO, terms, currency, tax and line-level identifiers | An order that cannot be posted, allocated or invoiced downstream |
| Credit and payment status | ERP or finance system | Terms, holds, balances and payment updates required for the buyer journey | Allowing orders outside policy or presenting inaccurate account status |
| Content and product guidance | PIM, CMS and Shopify | Structured value propositions, applications, documentation and media | A functional catalog that does not help buyers make a decision |
The table is intentionally not universal. Some organisations should own customer data in CRM, others in ERP. Some can let Shopify calculate B2B prices, others must publish prices from a contract engine. What matters is that ownership is explicit for every object and every update.
Governance matters because Shopify makes a great deal editable in the admin. That convenience can create ambiguity if a price, catalogue assignment or company attribute is also controlled by an upstream system. For every commercial field, define the system of record, the allowed editor, the update direction and what happens when the values disagree.
Questions a connector demo does not answer
Before approving an integration approach, ask:
- Which B2B objects are supported, including companies, locations, catalogs and terms?
- In which direction does each object move?
- Which identifier survives a migration and prevents duplicates?
- How are deletions, deactivations and merges handled?
- Is pricing sent as a calculated result or recreated in Shopify?
- What is real time, what is scheduled, and what is manually reconciled?
- What happens when Shopify and the source system change the same record?
- How are failures retried, replayed and surfaced to an operator?
- Can a failed order block fulfilment without disappearing from view?
- How will the team test peak loads, large catalogs and high-volume updates?
These questions are less exciting than a storefront demo. They are also where a large share of B2B delivery risk lives.
A practical capability boundary
A useful default is to let Shopify's native model answer who can see what and at what price. Custom logic should earn its place by representing the customer's actual commercial process, not by recreating a primitive the platform already owns.
The most useful way to scope Shopify B2B is to distinguish five categories.
.
| CATEGORY | TYPICAL CAPABILITIES IN 2026 | WHAT IT MEANS FOR SCOPE |
|---|---|---|
| Native core | Companies, locations, buyers, catalogs, fixed prices, quantity rules, volume breaks, net terms, PO numbers, reorders, vaulted cards, draft review, sales staff permissions, and account requests through the first-party Shopify Forms app | Configure and design the operating model. Avoid rebuilding it elsewhere. |
| Native but plan-dependent | Contextual storefront and checkout on Advanced and Plus; unlimited and directly assigned catalogs, deposits, partial payments and payment requests per fulfilment on Plus | Model the requirement before choosing the plan. |
| Extensible through Shopify | Conditional order validation, deposits and regulatory fees, shipping-selection logic, minimum quantities across variants or product groups, account extensions, Flow automations and API-driven company/catalog management | Requires the right app distribution and plan, a deliberate configuration model and an owner for ongoing maintenance. |
| External or custom domain | ERP/PIM/CRM integration, EDI, complex RFQ and quote workflows, procurement approvals, punchout, CPQ, real-time contract prices, credit-limit decisioning, actual available inventory and service/aftermarket workflows | Treat as architecture and product work, not theme configuration. |
| Unsupported or high-friction in the standard model | Subscriptions, pre-orders and try-before-you-buy purchase options; accelerated checkouts; agentic storefronts; pickup points and local delivery; orders above 500 line items; one buyer acting for multiple unrelated companies | Redesign the process, validate a supported workaround, or consider another platform. |
Extension work is more than writing the rule
Shopify Functions can enforce commercial rules at checkout, but enforcement is not the same as a useful buyer experience. If a minimum quantity, pallet rule or restricted combination should be visible in the cart, the storefront normally needs to mirror the rule and explain how the buyer can resolve it. The Function remains the server-side backstop.
Function-based rules do not automatically include an admin interface. Configuration may begin as JSON or metafield data. If commercial teams need to change thresholds, product groups or regional fees, the scope should include a safe configuration interface and governance for those changes.
The plan and delivery route also matter. Public App Store apps containing Functions can run on any paid plan, while custom apps containing Functions require Plus. Within Cart Transform, lineUpdate requires Plus, while lineExpand and linesMerge are more broadly available within the API's restrictions. Checkout UI extensions in the information, shipping and payment steps also require Plus.
B2B checkout configuration should be treated as its own implementation and test workstream. Extensions that read fields such as a shipping address may also require approval for protected customer data, which adds lead time. These details are easy to discover late if the team scopes only the visible rule.
Typical examples are operational rather than decorative: choosing parcel or pallet shipping from the basket, applying a container deposit or regulatory fee by destination, enforcing a minimum across a product group, or preventing an order that cannot be fulfilled downstream.
The final row needs nuance. Some constraints can be handled through draft orders, separate identities, external procurement systems or a revised workflow. That does not make them native. A credible scope should record the exception, its owner and its operational consequence.
The current platform requirements list accelerated checkouts, local delivery, pickup points, subscriptions, legacy customer accounts and agentic storefronts as incompatible. B2B orders and drafts are limited to 500 line items, and purchase options such as subscriptions, pre-orders and try before you buy are not supported. These constraints should be tested early against real orders, not discovered during acceptance testing.
The useful dividing line is not native versus custom. It is commodity versus competitive advantage. Company accounts, catalogs, terms and checkout should remain close to the platform where possible. Product selection, configuration, sales-assisted journeys and service can justify custom investment when they encode how the business wins.
Standardise the transactional core. Differentiate in the buying logic.
The capability boundary (Figure 04)
Scope each requirement by how it is actually delivered, not by whether it appears in a sales narrative.
A reference system-of-record architecture (Figure 05)
A connector is a transport mechanism. The architecture is the set of ownership, mapping and recovery decisions around it.
A connector is a transport mechanism. The architecture is the set of ownership, mapping and recovery decisions around it.
05
5. Implementation cost, timeline and platform fit
There is no responsible universal price for a Shopify B2B implementation. Activating a feature set, migrating a legacy portal and redesigning a multi-market commercial operation are different pieces of work.
The cost model should include at least:
platform and payment costs + apps and middleware + implementation + data migration + internal change + ongoing operations and optimisation
This is why “B2B is included in the plan” is true but incomplete. The licence may include the primitives. It does not clean customer data, decide who owns contract prices, reconcile an ERP failure, redesign sales operations or create a useful buyer experience.
Measure the operating model, not only online revenue
A B2B programme should have a business case that reaches beyond channel revenue. Digital sales matter, but they do not reveal whether the new operating model is easier to run, more reliable for customers or more useful to the sales organisation.
Track measures such as:
- the share of eligible orders placed digitally;
- manual order-entry hours and touches per order;
- time from account application to approved buyer access;
- time required to complete a repeat order;
- order-error, support and rework rates;
- sales and customer-service time reallocated from administration to advice, relationship development and growth.
A portal can increase digital revenue and still fail if it creates more reconciliation, support and exception handling. Equally, it can create commercial value before revenue moves if it frees scarce sales and service capacity, improves data quality and makes the buying experience more dependable.
What actually takes time
.
| WORKSTREAM | THE VISIBLE OUTPUT | THE DIFFICULT PART |
|---|---|---|
| Commercial discovery | Requirements and prioritised journeys | Converting exceptions and tacit sales knowledge into explicit rules |
| Account and catalog model | Companies, locations, contacts, markets and catalogs | Mapping legal entities, price tiers, entitlements and edge cases |
| Data migration | Imported products, accounts and history | Duplicates, identifiers, incomplete ownership and inconsistent source data |
| Integration | Working connections to ERP, PIM, CRM, WMS or EDI | Direction, timing, reconciliation, failures and operational support |
| Experience design | Discovery, ordering, reordering and account flows | Serving expert repeat buyers and less familiar evaluators in the same system |
| Validation | Accepted end-to-end scenarios | Testing real prices, taxes, currencies, permissions, terms and downstream posting |
| Adoption and launch | Buyers and sales teams using the platform | Account activation, changed responsibilities, training and exception handling |
Grebban’s public guidance puts a typical Shopify replatforming at three to nine months, depending on complexity and ambition. That range is deliberately broad because the work above varies more than the storefront technology does.
When “under two months” is credible
A bounded first B2B release can be delivered in under two months, but only when the boundary is real. Typical conditions are:
- an existing Shopify foundation or a clean, net-new dedicated store;
- a small number of well-defined catalogs and customer tiers;
- clean product and account data;
- standard payment terms and checkout behaviour;
- one initial region or a limited market model;
- no new complex ERP, EDI, CPQ or approval programme;
- fast decisions and available internal owners;
- a deliberately phased backlog after launch.
It should not be presented as the timeline for a full replatforming with unresolved data, several systems of record, bespoke pricing, international rollout and organisational change. A date without a scope boundary is not a timeline. It is a promise to absorb risk.
The better approach is to define a commercially useful first release and make its exclusions explicit. The first release might cover authenticated pricing, quick ordering, reorders, PO numbers, standard terms and reliable ERP order posting for one customer segment. Quotes, advanced approvals, EDI onboarding or additional markets can follow once the core is stable.
Implementation is a set of risk reductions (Figure 06)
Progress is evidence that the commercial and operational model works, not the passage of calendar weeks.
.
| 01 | Commercial model | → | Real customer agreements resolved |
|---|---|---|---|
| 02 | Data and identity | → | Clean records and durable IDs |
| 03 | Integration | → | Monitored failure and recovery |
| 04 | Experience | → | Priority journeys completed end to end |
| 05 | Adoption | → | Buyer and operator ownership in use |
Where Shopify B2B fits well
Shopify is a strong fit when most of the following are true:
- the business sells identifiable SKUs through repeatable order flows;
- customer relationships map to companies, locations and individual buyers;
- assortments and prices can be expressed as a manageable catalog structure;
- standard terms, PO numbers, reorders and draft review cover the core order lifecycle;
- B2B and DTC share products, inventory, teams or brand, making a blended store valuable;
- the ERP or PIM can publish stable data into Shopify and receive valid orders back;
- sales teams want self-service to handle routine work while retaining high-value relationships;
- the organisation benefits from Shopify’s native storefront, checkout, app and operational ecosystem.
Common examples include a consumer brand adding wholesale, a manufacturer moving routine repeat orders out of email, a distributor with structured customer tiers, or a multi-market business whose commercial variation can be represented through Markets and catalogs.
Where it is a conditional fit
Shopify can still work, but architecture and scope matter more, when the business has:
- deeply customer-specific contract prices calculated in real time;
- complex credit exposure, holds or account balances controlled by ERP;
- several buyer roles and multi-stage approval chains;
- EDI and self-service orders that must converge into one operational queue;
- large, frequently changing project-delivery networks;
- RFQ, configure-price-quote or technically assisted product selection;
- several legal entities, inventories or commercial teams;
- rich service, spare-parts or installed-base journeys beyond the initial transaction.
These are not automatic disqualifiers. They are signals that the project is more than “turning on Shopify B2B”. The decision depends on whether Shopify can remain a coherent commerce layer while the specialised logic lives in systems designed to own it.
Where the standard model is a poor fit
The standard implementation is a poor fit, or requires a fundamental process redesign, when:
- subscriptions, pre-orders or another unsupported purchase-option model is central to B2B revenue;
- normal orders exceed 500 line items;
- a single buyer must routinely act for several unrelated companies through one identity;
- the business requires a deep native role and approval hierarchy;
- product configuration, price calculation and contractual eligibility cannot be resolved before checkout;
- the core experience depends on features Shopify explicitly marks as incompatible with B2B;
- most of the intended solution would sit outside Shopify’s native model.
At that point, a different platform may be the more economical choice. The cost of a platform is not just its licence or initial build. It is the amount of permanent translation required between the platform’s assumptions and the business’s reality.
The Checklist
A decision checklist for a serious evaluation
Before selecting Shopify B2B, a project team should be able to answer these questions with real examples:
- How many distinct catalogs do we need once assortment, tier, market and currency are combined?
- Which customers require genuinely unique prices rather than a reusable tier?
- Can every buyer be represented by one company and one or more locations within it?
- Are Shopify’s two native buyer permissions sufficient?
- Which system owns companies, locations, products, prices, inventory, credit and orders?
- What happens when each integration is delayed or fails?
- Do B2B and DTC need shared inventory, staff, brand and reporting?
- Which checkout and payment rules are standard, conditional or customer-specific?
- Are there normal orders above 500 line items or quantities aggregated across variants?
- Which workflows require RFQ, EDI, punchout, CPQ, approvals or service data?
- What should a buyer be able to complete without a salesperson, and where should human support enter?
- Which complexity should be digitised, which should remain external, and which should be removed?
If the answers align with Shopify’s model, the platform can provide a strong native commercial core and remove a great deal of portal-specific infrastructure. If the answers depend on exceptions, the implementation can still succeed, but only if those exceptions are designed and costed explicitly.
The Grebban view
The Grebban view
Shopify B2B in 2026 is substantially more capable and more widely available than it was a year ago. Its strongest proposition is not that it can reproduce every legacy B2B process. It is that companies, catalogs, pricing, terms, accounts, checkout and automation now form a coherent native foundation within the wider Shopify platform.
The best implementations use that foundation for what it is good at. They do not mistake a connector for an architecture, or a transaction flow for a complete customer experience. They decide which complexity belongs in Shopify, which belongs in ERP or another specialist system, and which should not be carried forward at all.
They also recognise that self-service is not the opposite of sales. A useful B2B experience digitises the best parts of the salesperson: product understanding, guidance, confidence and continuity. It gives expert buyers speed when they know what they need, and gives less familiar buyers enough context to make a sound decision.
That is where Shopify B2B fits best: as a native commercial core, surrounded by deliberate systems and a customer experience designed around how the business actually sells.
That combination is why we find Shopify B2B compelling. It creates room to standardise the transactional core without standardising the business's buying logic. The platform can own identity, commercial context and order capture, while design and engineering focus on the decisions, guidance and workflows that make the B2B proposition distinctive.