One ERP, many storefronts: where does the shared layer stop?

Requirement nine of the twelve on Acro’s Acumatica fit test is multi-store, multi-brand or multi-region storefronts, and the reason it is filed under breaks is not a missing feature. It is that the second storefront makes you choose an architecture, and most businesses make that choice by accident when they build the first one.

There are three shapes. The question that separates them is simple and worth asking out loud in the room: what does the fourth storefront cost, given the first three exist?

Point-to-point means each storefront has its own integration to the ERP. It is the fastest way to get storefront one live and the reason is honest: there is nothing to design. The cost is that storefront four costs roughly what storefront one cost, and every pricing rule change has to be made four times by four people who each believe they made it correctly.

A shared commerce layer means one component talks to the ERP and every storefront talks to that component. Catalogue scope, price resolution, availability and customer identity are decided once, and each storefront receives a view. Storefront four is then a configuration exercise plus a front end. The cost is that you now own a component, which needs a deployment story, monitoring, and somebody whose job it is.

A copy per brand means each storefront holds its own duplicated products, prices and customers, synchronized by scheduled jobs. It looks like the cheap option because no new component appears on the architecture diagram. What it actually buys you is N copies of your data drifting apart at different rates, and the drift is discovered by customers.

A shared layer that owns too little is a proxy with a maintenance bill. One that owns too much becomes a second commerce platform, which is a much larger thing than anyone budgeted for. The split below is the one that holds up.

The shared layer owns everything where a wrong answer would be wrong for every brand: what a customer is, what they are entitled to see, what they pay, what is available, and whether an order has already been accepted. It owns identity and truth.

Each storefront owns everything a customer can see and nothing a customer can be harmed by: presentation, language, merchandising, search, content, and the brand’s own catalogue selection expressed as a scope rather than as a list. It owns experience.

One rule keeps this honest over time. If two storefronts would ever need different answers to the same question, that question is not shared, it is scoped, and the shared layer takes the scope as an input. Price for customer X is shared. Price for customer X on brand B is scoped. Deciding which of those you are building is the whole design conversation, and it is much cheaper to have before the first storefront than after the second.

Every ERP has a granularity below which it cannot express per-storefront behaviour, and finding yours is a concrete afternoon rather than an abstraction.

On Acumatica with the native commerce connector, that boundary is the item. Stock items can be filtered per store through entity mapping filters. Matrix items cannot: in Acumatica community thread 31345, the accepted answer from July 2025 states that "The Template Items import does not respect attributes set on the Variance stock items. It seems not to be possible with the current connector", so pushing a template item pushes every child to every store that receives it.

The general form of that rule is worth carrying to any ERP. Per-storefront control exists where the connector was designed to filter, and stops one level below it. If your brand split runs through the level below, the native connector is not the component that expresses your architecture, and something has to sit between.

Two more boundaries are worth checking in your own tenant rather than assuming. Whether an order carries its storefront of origin into a field your reporting can read without a person opening the order. And whether inventory can be scoped per storefront at all, because reserving a share of one warehouse for one brand is a business decision that most connectors have no way to express.

This is the acquisition shape. You bought a company, they run their own Acumatica tenant, and somebody has asked whether the existing website can just sell their products too. It is the same problem inverted, and it is harder.

The public record on the Acumatica side is Acumatica community thread 29392, opened 12 March 2025 by a merchant who had been told this was possible and could not make it work. Connecting a second tenant through the native Acumatica app in Shopify produced "an error indicating an invalid ERP URL and tenant login name" when using the same URL with different tenant login credentials. The answer marked as accepted, on 19 March 2025, states plainly that you cannot use the Acumatica app for this, and recommends creating separate custom apps in Shopify, one per tenant. The merchant confirmed that a separate custom app connected to the second tenant did work.

The same thread names the second problem before anybody has solved the first. Once two tenants write into one Shopify store, their SKUs collide. The accepted answer notes that unless a product is created as a template item in Acumatica the variant logic will not engage, and suggests pre-creating products in Shopify with matching names and different SKUs so the connector matches on name while respecting the SKU. That is a workaround, and it tells you what the real problem is: two ERPs have two item masters and one storefront has one namespace.

So the architecture question after an acquisition is not "can we connect both tenants". It is "who owns item identity and customer identity across the group", and there are only four answers. Consolidate onto one ERP, which is the expensive, correct, slow answer. Run one storefront per tenant, which is cheap and leaves you selling to the same customer twice. Put a layer in the middle that owns a canonical item and customer identity and fans out to both tenants, which is the answer most groups eventually arrive at. Or trade under one brand and route orders by product ownership, which works while the catalogues do not overlap and stops working the day they do.

Whichever you pick, pick it deliberately. The default, which is a custom app per tenant plus a naming convention, is a decision too, and it is one made by whoever was on the ticket that week.

The cheap answer is right more often than an agency page usually admits. If you have one storefront now, one more planned, and no third on anybody’s roadmap, build the second one point-to-point and spend the saved money on catalogue content. A shared layer built for two storefronts that never becomes three is a component you maintain for nothing.

Four conditions flip the answer, and any two of them together are enough.

The last one deserves emphasis because it is the one people discount. A shared layer is not only cheaper at the fourth storefront, it is the only shape where a pricing rule can be changed once. For an ERP-run business, that is usually the argument that actually matters, because pricing is what your customers notice.