One ERP for Every Branch - What Changes When a Distributor Runs a Dozen Locations
Branches accumulate. A distributor opens one to follow a customer, buys two more with an acquisition, and inherits a fourth with a different system and its own way of doing things. Ten years later there are a dozen locations, three generations of software, and a finance team closing the books from spreadsheets. The ERP question at that point is not whether a system can run a warehouse. Most can. It is whether one system can run the network - shared inventory, one customer across many branches, central purchasing with local receiving, and a profit and loss for each location that the general managers believe.
This guide is for industrial, electrical, plumbing and HVAC, medical and pharmaceutical, and route-based food and beverage distributors with several branches, and for the people selecting their next system. It covers what changes once a company runs a dozen locations, the decisions to make before anyone looks at software, and the demonstration scenarios that separate a true multi-branch distribution ERP from a single-warehouse system with a branch field added.
What changes at a dozen branches
Inventory is shared but stocked locally - A counter sale at one branch should be able to promise stock sitting at another. Transfers, in-transit quantities and branch-level minimums and maximums have to live in the system, not in a daily email.
One customer, many branches - A contractor or hospital group buys from three locations under one contract. Pricing, credit limits, rebates and statements have to follow the customer, not the branch that happened to take the order.
Purchasing is central, receiving is local - Vendor agreements and suggested orders are built centrally; receipts, returns and vendor claims happen at the dock. Both views have to agree.
Branches are profit centers, sometimes legal entities - General managers are paid on branch results. Intercompany transfers, allocated costs and branch-level margins decide whether the numbers are trusted or argued about every month.
Orders arrive five ways - Counter, inside sales, route or van sales, e-commerce and EDI or punchout from the largest accounts. Each channel has its own pricing, picking and invoicing habits, and the system has to carry all of them.
The warehouses are not alike - A distribution center needs directed put-away, wave picking and carrier integration. A small branch needs a scanner and a short pick list. One system has to serve both without making the small branch run the big one's process.
Decide the operating model before you see software
One instance, one item master - A single instance with one item master, one customer master and one price book is the basis for every branch benefit above. Separate instances per branch recreate the problem the selection is meant to solve.
What the branch decides and what the center decides - Stocking levels, local vendors, counter pricing and hiring are often branch decisions; contract pricing, vendor agreements, credit and the chart of accounts are usually central. Write the split down. Every exception to the central model costs money to build and support.
Hub and spoke, or direct - Decide whether branches replenish from a distribution center, directly from vendors, or both, and for which product lines. The answer drives the replenishment, transfer and costing requirements.
The counter and the route - Decide how counter sales, will-call, route deliveries and van stock will work across branches, because these are the processes the largest vendors demonstrate least well.
Acquired branches - Decide the rule for the next acquisition now. A new branch should be a configuration exercise, not a project.
Write requirements for the network, not the headquarters branch
Requirements workshops should include branch managers, counter and inside-sales leads, the credit team and the people who run the distribution center, not only the head-office team. Run them by process across branches, so the differences come out in the room, and write each requirement as a scenario that names the branches involved. "A customer on a national contract orders at Branch A's counter; the item ships from the distribution center; the invoice carries the contract price and the rebate accrues to the customer account" can be demonstrated and scored. "Multi-branch capability" cannot.
Our guide to the distribution ERP selection playbook covers the workshop method in more detail.
Demonstration scenarios that expose a weak fit
Give every finalist the same scenarios on your own data, and have each branch's people score the parts that affect them.
Cross-branch availability and transfer - A counter order at one branch filled from another, with the transfer, the in-transit quantity and the receipt shown end to end.
One customer, three branches - A contract customer ordering at three locations with one price agreement, one credit limit and one monthly statement.
Central purchase order, local receipts - One vendor agreement, one purchase order with releases to several branches, receipts at each dock, and the spend visible centrally.
Hub-to-branch replenishment - Branch minimums and maximums driving a replenishment order from the distribution center, with the shortfall sourced from the vendor.
Five order channels in one day - A counter sale, an inside-sales order, a route delivery with van stock, a web order and an EDI order, each priced and invoiced correctly.
Branch profit and loss - A month-end that shows each branch's margin after transfers and allocated costs, and the consolidated result for the company.
Rebates and chargebacks - Vendor rebates earned across branches and customer rebates accrued across orders, with the claims produced from the system rather than a spreadsheet.
A new branch - The finalist configures a new location during the demonstration, showing how long it takes and what has to be decided.
A finalist that handles these well at three branches will usually handle a thirteenth. One that struggles with them in a scripted demonstration will struggle more in production.
Choosing the implementation partner for a multi-branch rollout
Rollout experience - Ask for programs where a template was built at a pilot branch and rolled out in waves, and speak with those clients.
Named people - The partner's distribution lead and the consultant who will configure pricing and rebates matter more than the account team. Meet them before you sign.
A credible wave plan - The plan should say which branch goes first and why, how long each wave takes, how data is converted branch by branch, and how the template will be protected from branch-by-branch customization.
Partner selection deserves the same rigor as software selection; here is how we approach implementation partner selection, and what to look for in a partner for distribution.
Common mistakes
Letting the largest branch write the requirements - The other branches discover the gaps during testing, when changes cost the most.
Demonstrating one warehouse at a time - Every finalist looks good in a single-site demonstration. The cross-branch scenarios are the real test.
Treating item and customer harmonization as a data task - Deciding how a dozen branches will describe the same products and the same customers is a business decision, and it takes months.
Leaving an acquired branch on its old system "for now" - For now becomes forever, and the network benefits never arrive.
Choosing on the counter screen - A fast counter screen matters, but it is the easiest thing for a vendor to show. Pricing, rebates, transfers and branch reporting are where the differences hide.
What this looks like in practice
In a recent program for a specialty distributor, the requirements, the RFP and the scripted demonstrations were built around branch operations and route delivery rather than the head-office view, and the selected system went live on schedule. A national distributor came to us after a stalled program; the reset started with the same question, what the branches needed the system to do. Both followed the same ERP software selection method.
Frequently asked questions
Should every branch run the same ERP? Yes, on one instance with one item master and one customer master, unless a branch is run as a separate business or is likely to be sold.
Should we go live at every branch at once? Rarely. Most multi-branch programs build the template at a pilot branch, then roll out in waves of two to four branches, so later waves benefit from what the first one learned.
How long does an ERP selection take for a multi-branch distributor? Twelve to twenty weeks. More branches and more order channels push it toward the upper end, mostly because the workshops have to include every location.
Do we need a separate warehouse management system? Often not. Many distributors run the branches and even the distribution center on the ERP's own warehouse functions. A high-volume distribution center with automation or a third-party logistics arrangement may justify a separate system; decide site by site and make the exchange between the two part of the requirements.
What if the branches are separate legal entities? Then intercompany transfers, transfer pricing and consolidation become selection requirements and demonstration scenarios, not implementation details.
What about the branch we acquired that runs a different system? Bring it onto the platform in the first wave after the pilot, with its data converted the same way as every other branch. Keeping it separate costs more every year it stays.
If you run several branches and the ERP question is on the table, talk to John about your ERP program.
