Which six things fork when you add a second storefront?
This is requirement nine of the twelve on Acro’s Acumatica fit test, the one filed under breaks. It breaks a native connector for a reason worth stating precisely: a second storefront is not a second theme, it is a second set of answers to questions the ERP thought had one answer.
Six objects fork. Everything else can usually stay shared, and the cost of a multi-brand build is mostly the cost of arguing about these six with people who each assumed a different answer.
Work down the list with a specific second brand in mind rather than in the abstract, because the abstract answer is always "share everything" and the real answer almost never is.
Catalogue. Which items appear on which storefront, and whether an item can appear on both under two different names. Two brands selling the same physical part under two part numbers is normal, and it is a data-modelling decision, not a merchandising one.
Price scope. Whether a customer who buys from both brands gets one negotiated price or two. If the contract was signed with the group rather than the brand, the price belongs to the group and the storefronts have to read it.
Inventory scope. Whether the two storefronts draw from the same warehouses, from different warehouses, or from the same warehouses with a reserved allocation each. The third option is the one that quietly needs custom work.
Customer identity. Whether the same buying organisation is one customer record with two ship-to structures, or two customer records that happen to share an owner. This decides credit, statements and the answer to "what did they buy from us last year".
Order numbering and source. Whether an order can be identified as belonging to a brand after it lands in the ERP, without anybody opening it. If the answer is no, your brand reporting is manual forever.
Content. Descriptions, images, attributes and language per brand. This is the fork people plan for and the cheapest one to change later.
Where should brand live, and where should region live?
Brand and region look like the same problem and behave differently. Brand forks identity and catalogue, and usually leaves stock alone. Region forks currency, tax, language and stock location, and usually leaves catalogue mostly alone. Modelling them with the same mechanism is what produces a system where changing a French description in Quebec republishes a price in Ohio.
The table below is the allocation that survives contact with an ERP-run business. The third column is the part that gets skipped in planning and then costs money.
| Criterion | Model it here | What breaks if you model it elsewhere |
|---|---|---|
| Brand | In the commerce layer, as a storefront or channel boundary. The ERP needs to know a brand exists only so it can label an order and, if the brands hold separate stock, pick a warehouse. | Modelling brand in the ERP as a separate company or tenant splits your customer master, which means a shared customer now has two credit limits and two histories. |
| Region | In the ERP for currency, tax and warehouse; in the commerce layer for language, market and presentation. | Modelling region only in the commerce layer produces orders in the wrong currency that post cleanly and reconcile wrongly, which is the expensive failure because nothing errors. |
| Catalogue membership | In the ERP, as an attribute or item class the connector filters on, so the rule is auditable next to the item. | Curating the item list by hand in each storefront works until the third storefront, at which point nobody can answer why a part is missing from one of them. |
| Contract price | In the ERP, scoped to the customer, not to the storefront. The storefront asks for a price for a customer, and gets whatever the contract says. | Duplicating price lists per storefront means a renegotiated contract has to be applied in as many places as you have brands, and it will be applied in one fewer. |
| Inventory availability | In the ERP, per warehouse, with the storefront told which warehouses it may quote from. | Splitting stock per storefront in the commerce layer creates two truths for one shelf, and the second one is always the one your customer is reading. |
| Customer identity | In the ERP, once, with storefront access as a property of the account rather than a copy of it. | A duplicate customer per brand breaks credit limits, because two records each holding half the exposure is not a credit limit. |
What does each platform give you for a second brand?
The platforms answer this question with different shapes, and the shape decides what your integration has to do. Two of them publish specific numbers, which are quoted here with the date they were read.
Shopify forks at the store. Shopify documents that a Plus organization can hold "a maximum of ten stores on their contract with no additional cost: One main store. Nine expansion stores", and is explicit that "Store settings, products, collections, and inventory aren’t synced between stores". That is a hard architectural statement: two Shopify stores are two systems that your integration keeps in step, not one system with two faces. Below Plus, the multi-brand path is markets and catalogues in a single store, and there you meet the cap of three active catalogues across all B2B markets on Basic, Grow and Advanced.
BigCommerce forks at the channel. BigCommerce documents multi-storefront as channels and sites, where a channel is "a place where a merchant’s store sells products" and a site is "a website owned or controlled exclusively by the merchant", each site linked to exactly one channel, and says channels let a merchant sell "to many customers in many places from a single catalog". The catalogue stays shared, which is the opposite trade from Shopify: less isolation, less duplication.
Shopware and Drupal Commerce both model several storefronts inside one installation rather than as separate systems. We have not verified a published per-plan storefront count for either, so we are not going to quote one. What we can say from the shape is that both put brand and region in the same database, which removes the reconciliation problem Shopify expansion stores create and replaces it with a permissions and scoping problem.
| Criterion | Where the fork happens | What stays shared | What the integration then has to do |
|---|---|---|---|
| Shopify Plus expansion stores | At the store. One main store plus nine expansion stores on the Plus contract at no extra cost. | Users and billing are managed centrally. Products, collections and inventory are not synced between stores. | Publish to each store separately and keep them in step. Every sync you write, you write once per store. |
| Shopify below Plus, markets and catalogues | At the market, inside one store. | Everything. One catalogue of products, one inventory, one customer list. | Fit your brands and your price classes into three active catalogues across all B2B markets, which is the documented cap on Basic, Grow and Advanced. |
| BigCommerce multi-storefront | At the channel, with one site per channel. | The product catalogue. BigCommerce describes selling to many customers in many places from a single catalog. | Decide per-channel visibility and pricing, and accept that a product edit is a shared edit across brands. |
| Shopware or Drupal Commerce | Inside one installation, as sales channels or stores. | The database, the customer model and the integration. | Scope everything explicitly. One integration serves all storefronts, which is cheaper to run and easier to get subtly wrong. |
Checked against: Shopify Help Centre: overview of expansion stores for Plus organizations, read 20 August 2026, Shopify Help Centre: B2B features by plan, three active catalogues across all B2B markets below Plus, read 20 August 2026, Shopify Help Centre: B2B and Markets, markets and submarkets used to represent sets of customers, read 20 August 2026, BigCommerce docs: introduction to multi-storefront, channels and sites, read 20 August 2026
Where does the ERP stop being able to tell the storefronts apart?
There is a point in every multi-brand build where the ERP loses the thread, and it is worth knowing in advance where that point is rather than discovering it in month four.
On Acumatica with the native commerce connector, the boundary is visible in a specific place. Stock items can be restricted per store using entity mapping filters, so a two-store setup can send one range to a direct-to-consumer store and another to a wholesale store. Matrix items do not honour that boundary. In Acumatica community thread 31345, a merchant running two Shopify stores off one Acumatica instance reported that when the connector pushes a matrix template item, "it pushes every single matrix stock item associated with the template item and we have no control". The thread’s accepted answer, from an Acumatica MVP in July 2025, confirms it: "The Template Items import does not respect attributes set on the Variance stock items. It seems not to be possible with the current connector." The recommendation was to log a feature request.
Read that as the general rule rather than as one bug. Filtering usually exists at the level the connector was designed around, which is the item, and stops existing one level down, which is the variant. If your brand split runs through variants, for example the same shirt sold in different colourways per brand, the native path does not have a filter at the level your business splits at.
The other place the ERP loses the thread is the customer. If the same buying organisation shops both brands and you gave them two customer records to keep the storefronts tidy, then credit, statements and history are now split, and no amount of reporting puts them back together reliably. Give them one record and solve presentation in the commerce layer.
What should you settle before you build the second storefront?
The multi-brand decision is made once and paid for monthly, so it is worth an afternoon with the people who own each answer. Six questions decide the architecture, and you can answer all six without a vendor in the room.
If you cannot answer question two or question five, that is the finding. Both are commercial decisions wearing technical clothes, and neither gets easier after a platform is signed.
Does any customer buy from more than one of your brands today? If yes, they get one customer record and the storefronts share it.
Is a contract price negotiated with the group or with the brand? Whoever signed it owns the scope of it.
Do the brands ship from the same warehouses? If yes, do not split stock in the commerce layer for tidiness.
Can somebody in accounts tell which brand an order came from without opening it? If not, add the field before launch rather than after the first board pack.
Does your product model split at the item or at the variant? If it splits at the variant, check the connector filters at the variant level before you assume it does.
How many storefronts will exist in three years? Three is a different architecture from two, and on Shopify below Plus three price classes plus a second brand already exceeds the three-catalogue cap.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Should two brands run as two Shopify stores or as one store with two catalogues?
- Two stores when the brands need genuinely different products, themes and customer bases, and one store with markets and catalogues when they mostly differ in presentation and price. The cost of two stores is duplication: Shopify documents that store settings, products, collections and inventory are not synced between stores, so every integration you build gets built twice. The cost of one store is the cap, since Basic, Grow and Advanced allow up to three active catalogues across all B2B markets, and a second brand plus two price classes uses them all.
- Can one Acumatica tenant serve more than one storefront?
- Yes. Acumatica community thread 31345 describes a merchant running a direct-to-consumer Shopify store and a wholesale Shopify store from one Acumatica instance, and restricting which stock items reach which store through entity mapping filters. The limit found in that thread is matrix items, where the accepted answer states the template item import does not respect attributes set on the variant stock items, so the whole matrix goes to both stores. Verify per-store filtering on your own item shapes before you commit to the design.
- Do we need a separate ERP tenant per brand?
- Almost never, and the reason is the customer master. Separate tenants split your customer records, which means a customer who buys from both brands has two credit limits, two statements and two histories, and nothing in either tenant knows about the other. Separate tenants are the right answer when the brands are separate legal entities filing separately, and the wrong answer when they are trading names of one business.
- How do we stop the same product appearing twice under two brand names?
- Decide first whether it is one item or two. If it is physically the same part from the same bin, keep one inventory item in the ERP and let each storefront present it under its own name and images, which keeps stock honest. If the brands have genuinely different packaging or part numbers that customers order by, they are two items with separate stock, and the ERP should say so. What does not work is one item in the ERP with two stock figures maintained by a person.
- What is the cheapest multi-brand setup that actually works?
- One ERP tenant, one customer master, one integration, and storefront-level scoping done with data already in the ERP such as an item attribute or item class that says which storefront a product belongs to. That keeps the rule auditable next to the item and keeps the number of integrations at one regardless of how many storefronts you add. It costs more thought up front than curating a product list per store, and it is the difference between a third storefront taking a week and taking a quarter.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.