What does "two storefronts on one Acumatica tenant" actually mean?
This is requirement nine of the twelve on Acro’s Acumatica fit test, multi-store, multi-brand or multi-region storefronts, and it is filed under breaks. The reason it breaks is not that Acumatica refuses to talk to two stores. It is that the controls for deciding what each store receives exist at some levels of the product model and not at others.
In Acumatica’s commerce connectors, each connected storefront is its own store record with its own entity mappings. Those mappings are where you decide which records synchronize, and they carry filters. So the mechanism for "this range goes to the wholesale store, that range goes to the consumer store" is a filter on the entity mapping, expressed against something on the item, such as an attribute or an item class.
That mechanism is real and it is used in production. The merchant in Acumatica community thread 31345 states plainly that "regular stock items can be restricted per store using entity mapping filters". The rest of this page is about where that stops working, because that is the part nobody publishes.
What did Acumatica community thread 31345 establish?
The thread is worth reading in full because it is one of the few public records of a two-store Acumatica setup being pushed until it fails. It was opened on 4 July 2025 by a merchant running two Shopify stores, one direct to consumer and one wholesale, against a single Acumatica instance.
Their problem was matrix items. In their words, "when the eCommerce connector pushes a matrix template item over to Shopify, it pushes every single matrix stock item associated with the template item and we have no control". They wanted to send some children of a template item to one store and other children to the other.
An Acumatica MVP first suggested setting attributes at the item class level and using the Update Matrix Items action to push those values down onto the generated stock items so that entity-level filtering could see them. On 7 July that was withdrawn as not solving the actual case, because it restricts all the stock items together rather than selectively. The answer marked best, on 8 July 2025, is unambiguous: "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 it as a feature request, and the merchant drafted one asking for a multi-select of Shopify stores at both the template and the child stock item level.
Two things follow from that. First, the answer is a limitation rather than a misconfiguration, so no amount of setup work in your own tenant will produce a different result on the same release. Second, the granularity of the filter is the item, not the variant, and any brand or channel split that runs through variants is outside what the native connector was built to express.
Checked against: Acumatica community 31345: mapping items with multiple stores, accepted answer 8 July 2025. Read 20 August 2026, Acumatica commerce connectors overview, read 20 August 2026
Which parts of a two-store setup have per-store control, and which do not?
The table below separates what thread 31345 and Acumatica’s own connector documentation establish from what we are inferring. Anything marked as needing verification is something to prove in your own sandbox rather than something to plan around.
The pattern worth carrying away is that per-store control follows the entity. Where the connector synchronizes an entity you can filter, you get a boundary. Where it synchronizes an entity as a unit, such as a template item and its children, you get all of it or none of it.
| Criterion | Can it differ per store? | What that is based on |
|---|---|---|
| Stock items | Yes, through entity mapping filters on the store’s mapping. | Stated by the merchant in thread 31345 as working, and not contradicted by any reply. |
| Matrix or template items and their children | No. The whole family goes to every store the template goes to. | Accepted answer in thread 31345, July 2025: the template items import does not respect attributes set on the variant stock items. |
| Prices | Not per store in any way we could verify. Acumatica’s connector publishes a stock item’s Default Price, and per-customer pricing reaches Shopify B2B through the Price List entity as catalogues. | Established on our page about customer-specific pricing. Two stores that need different list prices for the same item is the case to test first. |
| Customers | Needs verification in your tenant. | A buyer who shops both stores should stay one Acumatica customer. Whether your two stores can share that record without producing duplicates depends on your customer matching rules, which is a setup decision rather than a connector feature. |
| Orders | Yes, in the sense that orders carry the store they came from. | Each store is a separate connection, so store identity is available on the imported order. Confirm it lands somewhere your reporting can read before launch. |
| Warehouses and availability | Needs verification. Warehouse to location mapping is per store in the connector configuration. | If both stores draw the same warehouses, this is straightforward. If you want a reserved allocation per store, that is not something the mapping expresses. |
What should you test in a sandbox before committing to a two-store design?
Five checks, none of which needs a developer, and all of which are cheaper now than in month five. Run them against a copy of your real item data rather than against demo data, because the failure in thread 31345 only shows up on a real matrix family.
If check two fails and your catalogue is mostly matrix items, that is the finding, and it points at either restructuring the product model or putting a layer between Acumatica and the two stores.
Filter one stock item to store A only, sync both stores, and confirm it is absent from store B. That proves the mechanism on your release.
Take a real matrix family, mark half the children for store A, sync, and see what arrives in store B. Expect all of them, per thread 31345, and check whether that is actually a problem for your catalogue.
Put the same customer through both stores and confirm you end up with one Acumatica customer, not two.
Place an order in each store and check that somebody in accounts can tell which store it came from without opening the order.
Change a price on one item and confirm what both stores show afterwards, then decide whether the two stores are allowed to differ on list price at all.
When are two Acumatica tenants the right answer instead?
Rarely, and the test is legal rather than technical. Separate tenants are correct when the two brands are separate legal entities with separate books, separate tax registrations and no shared customers. In that case you are not running one business with two storefronts, you are running two businesses.
Separate tenants are the wrong answer when the brands share customers, because the customer master splits and takes credit limits, statements and purchase history with it. A customer with two records has no credit limit, only two halves of one.
The reverse of this page is also a live question: one Shopify store reaching several Acumatica tenants, which is what an acquisition produces. Acumatica community thread 29392 covers it, and the short version is that the native Shopify app will not do it. We work through that case on our architecture page about one ERP and many storefronts, because the answer changes the shape of the whole integration rather than one setting.
One more honest note. Everything above describes the native commerce connector. If your two storefronts need genuinely different catalogues, different prices and different variant sets, the native connector is not the component that gets you there, and the decision to add a layer is better made at design time than after a launch that half worked.
Checked against: Acumatica community 29392: connecting one Shopify store to multiple Acumatica tenants, accepted answer March 2025. Read 20 August 2026
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Can the Acumatica commerce connector send different products to different Shopify stores?
- Yes for ordinary stock items, using filters on the entity mapping for each store, which the merchant in Acumatica community thread 31345 describes as working. No for the children of a matrix or template item: the accepted answer in that thread, dated 8 July 2025, states the template items import does not respect attributes set on the variant stock items, so the whole family goes wherever the template goes. Test this on a real matrix family before you design around it, and re-check it on your release since it may have changed.
- Do two Shopify stores need two Acumatica tenants?
- No, and usually they should not have them. Thread 31345 documents two Shopify stores running against one Acumatica instance, which is the normal shape. Two tenants split your customer master, so a customer who buys from both brands ends up with two credit limits and two histories, and nothing in either tenant knows about the other. Reserve separate tenants for separate legal entities with separate books.
- How do we send a product to the wholesale store but not the consumer store?
- Put the rule on the item as data, then filter the store’s entity mapping on it. An attribute or an item class works, and the advantage over hand-curating a product list in each store is that the rule stays auditable next to the item and survives the third storefront. What will not work is expressing the rule at the variant level, because the connector filters at the item level.
- Can one Shopify store connect to several Acumatica tenants?
- Not with the native Acumatica app. In Acumatica community thread 29392 a merchant hit "an error indicating an invalid ERP URL and tenant login name" trying to add a second tenant, and the answer marked as accepted in March 2025 states you cannot use the Acumatica app for this and recommends creating separate custom apps in Shopify per tenant. The merchant confirmed a separate custom app worked. Treat it as possible but unsupported by the standard path, and expect to own the apps you create.
- Does running two stores double the integration cost?
- Not on Acumatica’s side, because both stores talk to the same tenant and the same entity mappings pattern. It does double the configuration surface, so every mapping change becomes two changes and every test becomes two tests. Where cost genuinely doubles is on Shopify if the two brands are separate Shopify stores, since Shopify documents that products, collections and inventory are not synced between stores in a Plus organization.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.