How to standardize processes across multiple sites in your ERP: Blueprint with roles, workflows, and permissions

Why does growth across multiple sites break down without an ERP structure? 

The early days of most commerce and logistics businesses are manageable: one warehouse, one team, one process, one place. If someone doesn't know how to handle a return, a quick question across the room clears it up.

Then growth kicks in. A second warehouse, an external fulfillment partner, maybe a wholesale site on top of the D2C shop. And suddenly, what used to be obvious no longer works. Not because the team got worse, but because the underlying warehousing process was never built for multiple sites.

Inventory drifts apart because each site develops its own logic, and no one knows which site is handling which order. Team members build island solutions like Excel sheets, WhatsApp groups, or handwritten notes. And during peak season, when mistakes are most expensive, this is exactly when the mistakes pile up.

This isn't an organizational problem. It's a structural problem. The fix isn't a new communication rule. It's a multi-site ERP that carries the standardization across locations automatically. It locks it in, without anyone having to chase it constantly.

What does standardization really mean for a multi-site ERP? 

When large enterprises talk about process standardization, they usually mean months-long documentation projects, certifications, and outside consultants. Standardization in the ERP sense is much more pragmatic: growing commerce businesses with two or three sites use the ERP to unify processes across all of them.

Example: A new warehouse team member at Site B can, on day one, work exactly the way the team at Site A does, because the ERP shows her precisely what she's allowed to see, what she needs to do, and how the process runs. Not because someone explained it to her.

That's the difference between an ERP that manages data and an ERP that carries processes.

The 3 layers: roles and permissions, workflows, inventory management 

Layer 1: Set up roles and permissions: who sees what, who can do what 

Before you can standardize warehouse workflows in the ERP, you have to sort out who at which site needs which information, and who doesn't. That's the foundation.

A common mistake: Everyone gets access to everything, because it's easier to configure. That sounds practical but creates problems. Warehouse team members see purchasing conditions they shouldn't. Someone accidentally changes master data that applies across sites. And when something goes wrong, it's unclear who did what.

What a clean role model looks like:

In Xentral, roles and permissions are configured at the user level and can be restricted per site based on what actually makes operational sense. That means: the same person can have full warehouse rights at Site A and read-only access at Site B.

Why this matters for AI: If an AI agent processes incoming invoices and needs to assign them to the correct site automatically, that only works if the permissions structure is cleanly defined. An agent that doesn't know which documents belong to which site can't prepare a meaningful decision for anyone. So the role structure isn't just for people. It's the foundation that makes cross-site automation work at all.

Layer 2: Standardize ERP workflows for the warehouse: what has to be the same everywhere, what's allowed to vary 

Not every process has to be identical at every site. But some do. And when that isn't clearly defined, this is exactly where most mistakes happen.

The rule of thumb: Anything that generates data used across sites has to be standardized. Anything that stays purely local is allowed to vary.

Must be standardized:

• Picking: If pick lists at Site A are sorted by storage location and at Site B by order sequence, you end up with different error rates and no comparable reporting. Unified pick logic in the ERP prevents that.

• Incoming invoice processing: Every incoming invoice has to be captured, reviewed, and assigned to the right site using the same scheme. Otherwise the cost center is wrong, and accounting has a problem.

• Returns handling: Returns that get valued and posted differently across sites create inventory discrepancies. Unified return reasons, valuation rules, and posting logic are non-negotiable.

Allowed to vary:

• Packaging materials (local suppliers, different formats)

• Local suppliers for consumables

• Shift schedules and internal warehouse organization

• Regional shipping providers

In Xentral, you can define workflows across sites using the workflow editor, while still handling local exceptions. That means: the base process is the same everywhere, but Site B can still use its regional parcel carrier.

Layer 3: Managing inventory across multiple sites in the ERP: the most technically concrete part 

As soon as two warehouses hold the same SKU (Stock Keeping Unit), questions come up that can't be answered without a clean ERP configuration. For a lot of operations managers, this is where things really get tricky.

• Which inventory is available where?

• How is a transfer between sites represented?

• How do you prevent overselling when both warehouses list the same item?

Multi-site inventory management: the ground rules

1. Cleanly separate storage locations and sites. Each site is set up in the ERP as its own warehouse, with its own storage locations. Total inventory for an SKU is the sum across all sites, but each site runs its own partial inventory. The warehouse lead sees the big picture, while warehouse team members only see their own area.

2. Represent transfers between sites as their own movement. When goods move from Site A to Site B, that isn't a simple rebooking. It's a transfer order with its own status. Why that matters: while the goods are in transit, they don't fully belong to Site A or Site B. A cleanly represented transfer prevents this "in-flight" stock from being sold twice.

3. Manage available inventory per channel. An ERP reliably coordinates inventory across multiple warehouses. If your shop and your wholesale site pull from the same warehouses, you need to define which inventory is reserved for which channel. In Xentral, you can configure inventory buffers and channel assignments through warehouse management. That way you don't have an item showing as available in the shop when it's already reserved for a wholesale order.

4. Actively prevent overselling. The most common mistake in multi-site operations: two channels access the same inventory at the same time, without any locking mechanism in the ERP. The fix is central inventory management, where available inventory updates in real time — not once a day via batch import.

Overview: multi-site inventory management

And this is where the automation support of an AI-native ERP comes in: Once this inventory structure is cleanly represented in the ERP, an AI agent in Xentral can spot inventory anomalies before they turn into problems.

Example: The agent notices that Site B will fall below the minimum stock level for an SKU in the next three days and automatically suggests a transfer order from Site A. But that only works because the data structure underneath is cleanly set up. Without standardized inventory management, the agent has no reliable foundation.

Blueprint: your step-by-step plan for building a multi-site setup 

Now for the practical rollout of the theory. The blueprint below lets you set up an ERP for multiple warehouses, including roles, workflows, and inventory management. Use it as the foundation for your own build.

Step 1: Set up sites and warehouses in the ERP 

• Model every physical site as its own warehouse in the ERP
• Structure storage locations by site (aisles, racks, zones)
• Add external fulfillment partners as their own warehouse (even if you don't have direct access to the physical structure)

Step 2: Define the role model 

• What roles exist in your business?
• Which role needs access to which site?
• What data can each role see, and what can it not see?
• Set up roles in the ERP and configure permissions per site

Step 3: Standardize the core processes 

• Define picking logic uniformly across all sites
• Set up incoming invoice processing with site assignment
• Configure the returns process with unified reasons and posting rules
• Handle local exceptions (packaging, suppliers) as site-specific parameters

Step 4: Configure inventory management 

• Set up central total inventory with site-level partial inventories
• Define the transfer process between sites and represent it in the ERP
• Configure inventory buffers and channel assignments for shop and wholesale
• Set minimum stock levels per site and SKU

Step 5: Build the workflows in the ERP 

• Configure standard processes as workflows in the ERP
• Define automatic triggers (e.g. a transfer suggestion when minimum stock is undercut)
• Set up notifications and escalation rules per site

Step 6: Test and roll out 

• Pilot at one site before rolling out to all of them
• Train team members on the new processes and to be clear: on the process, not on the software
• Watch the first four weeks closely, document deviations, and adjust the configuration

Step 7: Activate AI agents (once the foundation is in place) 

• Only turn on AI agents once Steps 1–6 are running stably
• Starting point: inventory monitoring and automatic transfer suggestions
• Next step: incoming invoice processing with automatic site assignment

Important: Step 7 isn't an optional bonus. It's the central reason Steps 1 through 6 matter so much. An AI-native ERP can only manage multiple warehouses and automate across sites when the data and process structure underneath is clean.

Final words: a few solid foundations create orderly growth 

Growing across multiple sites doesn't happen on autopilot. When a second warehouse or an external fulfillment partner joins the picture, processes that used to run on personal communication stop working.

The good news: this is solvable. Not through more meetings or new communication rules, but through a clean structure in the ERP with roles, workflows, and inventory management that run uniformly across sites.

And once that structure is in place, something interesting happens. You don't just get better visibility. You get the foundation that lets AI agents do real work and prepare decisions. Agents can then support things like transfer suggestions, invoice processing, or inventory monitoring, without anyone having to step in manually.

So there it is: the difference between an ERP that stores data and an ERP that actively carries your business.