Consider a hypothetical store whose monthly orders grow from a few thousand to more than ten thousand, while profit fails to keep pace. One possible cause is a fragmented operating setup: extra market apps, wholesale price sheets, manual order fixes, ERP retries, cross-store reconciliation and shared admin logins. The figures are a teaching situation, not a measured client result.
The system has not collapsed. The team is simply busier. Gross margin is being eaten by app fees, order edits, wrong prices, delays and rework. The useful question is not “can we stay on a lower Shopify plan”. It is whether the current plan can still take the next order through automatically, accurately and in a way you can audit.
This article uses Shopify’s published plan boundaries as checked on 8 September 2026. It separates what lower plans already do from what Shopify Plus still uniquely provides, then gives a working cost ledger, an upgrade-evaluation checklist and a 90-day evaluation method. Plan matrices change; confirm the current Help Center and partner contract before treating any row as a purchase reason. The article lists no platform list prices, implementation fees, changing rates or ROI targets.
Roles, systems of record, checkout change control and release ownership after you already run Plus or a multi-market stack are covered separately in Plus multi-market governance. This page asks whether plan limits are the bottleneck and what evidence you need before requesting a proposal.
First, the boundary: a lower Shopify plan can already do B2B
One outdated judgement has to be retired: Shopify B2B is not a Plus exclusive. Shopify currently states that Basic, Grow, Advanced and Plus can all use B2B. Companies, company locations, net payment terms, self-serve ordering, catalogues, quantity rules, PO numbers and Shopify Flow are available on those plans for the core wholesale path.
Markets is not Plus-only either. Region markets, multiple currencies, domains and languages, product catalogues, tax treatment and market discounts can be configured on lower plans. The real gap is complexity and assignment method. On Basic, Grow and Advanced you can assign up to three active catalogues across all B2B markets; assigning three catalogues to one B2B market uses the whole limit, and an existing assignment has to be removed or moved to draft before catalogues can be added to another market. Those B2B catalogue features also require the current Shopify Markets experience (new Markets). Direct catalogue assignment to a company or company location, plus deposits, partial payments and payment requests per fulfilment, remain Plus-only.
| Capability | What lower plans can already do | The actual limit | What Plus adds |
|---|---|---|---|
| Core B2B | Companies, company locations, net terms, volume pricing, PO numbers, self-serve ordering, Flow | Up to three active catalogues across all B2B markets; B2B catalogue features on Basic, Grow and Advanced require new Markets | Unlimited B2B market catalogues; catalogues assigned directly to a company or company location; deposits, partial payments, payment requests per fulfilment |
| Markets | Region markets, multiple currencies, domains, languages, catalogues, taxes and market discounts | Basic and Grow cannot customise the theme, or checkout and account pages, per market. Advanced can customise the theme and checkout/account pages per market | Per-market customisation of the Information, Shipping and Payment checkout blocks; business entities per market |
| Checkout | Checkout and accounts editor, brand styling, eligible apps on Thank you and Order status (not Starter) | Eligible apps cannot be placed on the Information, Shipping and Payment steps; Checkout Branding API is not available | UI extensions on those three core steps, Checkout Branding API, and finer B2B versus DTC checkout context |
| Staff governance | Separate users and roles within the current plan | User and organisation permission boundaries still have to be checked against the live plan | Multi-store collaboration and approval designed around the organisation’s actual capability, including unlimited staff accounts and user groups on current Plus documentation |
| APIs and automation | GraphQL Admin API, Flow, public apps, and public App Store apps that contain Shopify Functions | Lower API capacity; some Function APIs remain Plus-only or in preview; custom apps that contain Function APIs require Plus. Complex logic still needs queues, cache and retries | Higher GraphQL Admin API capacity, custom Function apps, Plus-only resources and a larger organisation-governance surface |
One condition is easy to miss. A B2B order has to be associated at checkout with a company location that has already been set up. Otherwise contract prices may not apply and the order is processed at DTC prices. Being able to run B2B on a lower Shopify plan does not mean every customer, market, contract price and payment step will line up by itself.
Four hidden costs: profit is not lost to a single feature
1. Monthly fees for apps and middleware
One market needs translation, pricing, tax or a local payment method. Another app owns the wholesale catalogue. A third pushes orders into the ERP. Each subscription looks modest. Together they create mapping work, version upgrades and hours spent deciding which tool is at fault.
List every app, connector and homegrown script from the last 90 days: monthly fee, per-order fee, development hours, failed retries. Do not renew an app from memory if it has no usage log. Mark whether it is filling a plan gap, a process gap, or only repeating a display the store already has.
2. Manual quotes, order fixes and reconciliation
When wholesale buyers need contract prices, breaks, PO numbers, net terms or a deposit, sales, support, finance and the warehouse often run a relay. The price list is edited in a spreadsheet, the order is edited again in admin, then the invoice and the receipt have to be matched. If the company location is not attached correctly, a wrong price is not a support ticket. It is margin leaving the order.
Each week record quoting hours, order-fix hours, reconciliation hours, wrong-price order count and the value of reworked orders. Record customer wait time as well. A delayed order confirmation can lead to warehouse rescheduling, carrier changes and further support work.
3. Markets, legal entities and copied stores
Ordinary Markets is enough for many cross-border brands to regionalise. When different countries need different invoicing entities, collecting entities, inventory ownership or checkout rules, market configuration and finance reconciliation stop being one spreadsheet. Splitting into several independent stores can work around some experience limits. It also duplicates products, inventory, orders, apps and permissions.
This cost is often written down as extra store subscriptions. It also includes data copies, tax checks, content publishing and time spent locating the failing copy. Do not only ask what another store costs. Ask how many extra syncs, how many manual checks, and who owns the rollback.
4. Failures, permissions and rework
A checkout app collides at peak. The ERP retries after an API throttle. Staff share a login and change the wrong price. A multi-store publish has no approval record. In each case the store can still sell. Every exception still needs a person to finish the job. Lower plans can use apps and automation. Plus will not design idempotency, cache, queues or rollback for you. The difference is higher capacity and a more complete set of customisation entry points.
Record each 429, sync delay, bad publish, manual rollback and checkout exception. Convert internal hourly cost and event loss. That is how you tell whether a patch is saving money or deferring the bill.
Connecting a more complex ERP, WMS or finance stack does not, by itself, require Plus. Integration discipline is a project, not a plan badge.
Three paths: do not treat every pain as an upgrade
Path 1: stay on the current plan and clean the process and data
If region markets are enough, B2B catalogues stay within three active assignments, buyers do not need company-level price lists, the three core checkout steps do not need custom UI, and staff headcount fits the current plan, start with products, customers, company locations and order data. Queues, cache, error alerts, Flow and eligible apps usually remove more duplicate labour than an immediate upgrade.
Path 2: keep the current plan and add apps, or isolate a business workflow in another store
If the need is a one-off wholesale entrance, a specific payment display or a content module, an app or a theme change may be enough. If different brands, legal entities or lines of business must be isolated, several ordinary stores can be assessed — provided sync, tax, inventory, marketing data and permission ownership are written into the plan. An app that can cover the feature is not automatically the lowest long-term cost. Count monthly fees, development, maintenance and who is on the hook when it fails.
Path 3: treat Plus as a bottleneck project, not a status upgrade
Enter a Plus evaluation when any hard boundary is already present: more than three B2B catalogues, or catalogues that must be attached directly to a company location; deposits, partial payments or payment requests per fulfilment; custom logic on the Information, Shipping or Payment steps; business entities that must differ by market; API throttling that is delaying fulfilment; staff demand above the current plan; or multi-store permissions, billing and security policy that cannot be governed in one place.
A more complex operating system, a longer app list or a louder internal wish for “enterprise” is not, on its own, that boundary.
What Plus actually removes is four kinds of bottleneck already in production
1. Put B2B contract rules back on a verifiable order path
The value of Plus is not another wholesale label. It is putting catalogues and collection rules on the same order path you can inspect. Unlimited B2B market catalogues, direct company or location assignment, deposits, partial payments and payment requests per fulfilment suit brands whose customer-level contracts keep multiplying. The company, location, catalogue, market and price relationships still have to be drawn first. An upgrade will not repair dirty data.
2. Let checkout customisation reach the three core steps
Basic and above can use the checkout and accounts editor, and can add eligible apps on Thank you and Order status. Only Plus opens eligible UI extensions on Information, Shipping and Payment, plus the Checkout Branding API. For a store that serves DTC and B2B together, that is the difference between hoping the default checkout is close enough and designing delivery copy, payment display and brand treatment by context.
Thank you and Order status are not the same surfaces as the three core checkout steps, and they are not the same thing as a separate post-purchase extension. B2B payment, delivery and subscription compatibility still has to be tested against current feature documentation. Plus is not a master switch for every checkout restriction.
3. Put markets, entities and organisation governance on one map
Configuring business entities by market is a Plus capability. A Plus organisation can also support expansion stores for the same brand, plus organisation-level users and billing. Expansion-store eligibility, count and permitted use have to be checked against the current contract. They should not be assumed for arbitrary extra brands, and this article does not treat any published expansion-store count as a purchase reason.
Permissions need the same honesty. Current Plus documentation supports unlimited staff accounts and user groups, but Markets permissions are not assigned per market. A user who can see orders may still see orders from every market. After an upgrade you still design roles, organisation structure and approval so that privilege is not accidental. Confirm the live permission model; do not treat this paragraph as a substitute for admin review.
4. Leave headroom for API peaks — and keep engineering discipline
API capacity has to be checked against the specific APIs in use, the current plan and Shopify’s published limits. A higher ceiling does not replace batching, cache, backoff retries or idempotent writes.
Use API logs as upgrade evidence. If there are no 429s, delays or failed orders, a larger number on a comparison chart is not enough to justify Plus. If throttling is already causing inventory, order or finance sync to be reworked, put the interface redesign on the same project as the upgrade.
Platform fees, payment terms and service quotes belong to the contract in force for that project. This article lists no fixed rates and makes no ROI claim.
Upgrade evaluation checklist: bring evidence before you ask for a quote
Copy the following seven items into the project review document and have finance, operations and engineering sign the same page:
- Plan and scope: current plan, billing region, payment processor, monthly order volume, online GMV, and the countries, companies and warehouses you intend to add.
- Boundary evidence: catalogue count, company-location count, market count, entity count, staff-user count, independent-store count and API 429s in the last 30 days. Attach a screenshot or export for each.
- Hidden-cost ledger: app and connector monthly fees × 12, plus quoting, order-fix, reconciliation and rework hours × internal hourly cost, plus wrong-price, delay and incident loss. One-off development, migration and implementation sit on a separate line. Do not replace this ledger with a platform list price or a marketing percentage.
- Alternatives: for each need, state whether an existing app, Flow, theme, Advanced, or a separate store can cover it. If it cannot, the reason must map to a published plan boundary.
- Plus proposal: name the direct catalogues, payments, entities, core checkout, API, user groups or expansion-store capabilities you intend to use, and mark which of those still need extra development.
- Migration ownership: who accepts theme, customers, company locations, catalogues, orders, inventory, tax, payments, apps, permissions and rollback.
- 90-day measures: for each bottleneck, set a baseline, a target, a sampling definition and a stop condition. Do not treat Shopify case-study figures or marketing percentages as this store’s result.
Two files can be handed over directly. Deliverable one is the hidden-cost and incident ledger, with fields for date, order or market, exception type, labour minutes, app fee, money impact, owning system and evidence link. Deliverable two is the capability-boundary matrix, with DTC, B2B, markets, entities, checkout, API and permissions on one axis, and lower-plan option, app option, Plus option, one-off implementation and ongoing maintenance on the other. They turn a quote conversation from “I think we are stuck” into which rule, how much money, and who signs the acceptance.
A 90-day evaluation: evaluate the upgrade through a controlled pilot
The sequence below is a working method for one project. It is not a promise that costs will fall, that conversion will rise, or that 90 days is the right window for every store. It is not a claim that a Plus subscription is reversible; contract terms are separate from the evaluation method.
Days 1–30: baseline and model
Freeze a 90-day baseline. Export orders, wrong prices, order fixes, reconciliation time, API throttling, checkout exceptions, app invoices and user permissions. Draw the market–entity–store–warehouse–ERP data flow. Choose one representative country, one B2B company location and one DTC checkout path as the pilot.
Days 31–60: shadow run and a narrow cutover
First prove catalogue assignment, company-location prices, net terms or deposits, tax, inventory, invoices and refunds in a test or shadow flow. Test the three core checkout steps on desktop and mobile, across markets and with failed payments. Give every interface a queue, backoff, idempotency key and alert. Group permissions by role and keep a rollback version.
Days 61–90: production review
Compare baseline and pilot on the same definitions: B2B wrong-price rate, manual order-fix hours, reconciliation delay, order-sync delay, 429 count, checkout errors, rollback time and privilege incidents. The suggested pass test is not that every metric must improve. It is that the pre-defined hard boundaries have been removed, and that labour and exception cost are no longer growing in a straight line with orders. If that bar is missed, pause the wider rollout and repair data and process first.
Where WESWOO can take part
After you already have the cost ledger and the boundary matrix, WESWOO can join Shopify Plus planning, theme and checkout development, B2B and multi-market migration, systems work and post-launch optimisation. The focus of the work is turning catalogues, company locations, markets, entities, checkout, permissions and data flow into a plan you can execute, then reviewing it at 90 days on a shared definition.
WESWOO can help decide which needs belong on a lower Shopify plan, which need Plus, and which should sit in an app, an ERP or custom development. Actual effort, timeline, contract price and return have to be confirmed from your store’s data. No outcome is promised. Bring the two deliverables to an assessment so the upgrade is an investment with an acceptance standard, not only a more expensive invoice.
Feature boundaries: Shopify B2B features by plan, checkout extension technologies, Shopify Functions availability.