Distribution and Wholesale ERP Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the pricing engine turn into the biggest scope failure?

Almost every enterprise resource planning (ERP) project for a distributor is scoped with a line that reads import existing price lists. That line is doing an enormous amount of work. A wholesale price is rarely a number on a product. It is the result of a customer tier, a contract that overrides the tier for eleven items, a quantity break table that behaves differently for a case than for a pallet, a promotional price with an end date, a rebate that accrues rather than discounting at the line, and a sales manager's authority to override any of it within a floor.

This is specific to distribution because your competitors sell the same goods. The price is the product. In manufacturing the bill of materials is the hard model, and in retail it is the catalogue. Here it is the pricing hierarchy and the order in which its rules resolve.

The fix is to make pricing the first thing built and the first thing tested, not a configuration task in month four. Take fifty historic invoice lines across your five most awkward accounts, run them through the engine, and require the output to match to the cent before anything else ships. If the engine cannot reproduce yesterday's invoices, no amount of warehouse functionality will make the system trustworthy to the people who quote.

What goes wrong when you migrate SKUs, price lists, open orders and stock balances?

Migration is where distribution projects slip, and it slips for a reason that is easy to predict and easy to underestimate. Your item master has been accumulating for fifteen years. It contains superseded part numbers, two records for the same item from different suppliers, units of measure that disagree between purchasing and selling, and items that exist only because someone needed a line on a quote in 2019. Loading all of it means paying to carry that mess into a new system and then explaining it to your own team for years.

Open orders are worse than the item master because they are moving. An order with three lines shipped, one line backordered and a partial payment applied does not import as a row. It imports as a state, and the state has to agree with what your warehouse physically did last Thursday. This is why a parallel run matters. Run the new system alongside the old one on a subset of orders for a full cycle so that the two can be compared while the old one is still authoritative.

Stock balances need a clean cutoff tied to a physical count, not a snapshot from a report. A build that imports theoretical quantities inherits every discrepancy the old system was hiding, and your team will blame the new software for drift that predates it.

Why do accounting, carrier and trading partner integrations break after launch?

They break because each one has a different owner and none of them is you. Accounting synchronisation to QuickBooks, Xero or a NetSuite general ledger breaks on chart of accounts changes and on period locks, so an invoice posted after a period closes fails silently and reappears as an unexplained variance at month end. Build the sync with an explicit failure queue that a human sees the same day, rather than a retry loop that swallows errors.

Carrier integrations through ShipStation, EasyPost or direct FedEx and UPS interfaces break on rate and service changes, address validation behaviour and label format revisions. The failure is rarely dramatic. It is a service level that quietly stops being returned, so your cheapest option disappears from the rate shop and nobody notices until freight cost per order moves.

Electronic data interchange (EDI) with large retail accounts breaks in the most expensive way, because the trading partner controls the specification and enforces compliance with chargebacks. Every partner has its own map, its own required qualifiers and its own testing cycle, and onboarding is calendar time you do not control. Treat each partner as a separate deliverable with its own certification window rather than as one integration line called EDI.

What happens when available to promise and backorder handling are not covered?

This is the gap that costs orders rather than hours. Available to promise means the quantity a rep can commit today, which is on hand stock minus allocations to open orders, plus inbound purchase orders arriving inside the promise window, adjusted for what the warehouse has already picked but not yet shipped. Systems that show on hand quantity instead of available quantity produce the exact failure distributors describe: a rep promises stock that is physically in the building and already spoken for.

Backorders compound it. A partially shipped order needs to know what is still owed, at what price, against which purchase order, and with what allocation priority when the replenishment lands. Without that, the receipt gets allocated to whoever calls first rather than to the customer who has been waiting three weeks, and your best account learns to double order to protect itself. That behaviour then corrupts your demand signal, which corrupts reorder points, which is why nobody trusts them.

The fix is unglamorous. Model allocation explicitly as a reservation against a specific order line, make picking consume the reservation rather than the free stock, and show the promise date on the quote screen where the commitment is actually made.

Should you build custom or configure what you already own?

Configure, honestly, if your operation is standard. One or two warehouses, list pricing with straightforward discounts, no trading partner requirements and workflows that look like how NetSuite, Acumatica or Odoo already think. You will go live faster, you will not carry maintenance ownership, and the money is better spent on inventory or a second picker. That is the right answer for most distributors under a few million in revenue, and any developer who will not say so is selling.

There is a middle path that is frequently the best one. Keep your accounting package as the general ledger and build only the operational layer on top: order capture, pricing, allocation, warehouse flow and a customer portal. You get differentiation where it earns money and avoid rebuilding a ledger that already works, which usually pulls the total toward the lower end of the range.

Build the whole thing when your fulfilment promise, your pricing logic or your portal is the reason buyers choose you, and when you are already paying every year for customisations that force a boxed product to behave your way. The tell is simple. You are fighting the current system to do the specific thing that makes you money.

How do hidden costs get into the quote?

From Digital Heroes delivery experience, a distribution build that connects order management, multi location inventory, warehouse operations, purchasing, billing and a client portal runs $60,000 to $150,000 and takes five to nine months to a production ready first release. A leaner core of order management plus inventory starts near $40,000. Enterprise scope with trading partner integration, advanced replenishment, multi entity and hardware grade scanning runs $150,000 to $300,000 and beyond.

The lines that go missing are consistent. Each trading partner counts as its own deliverable. Barcode scanning on rugged hardware is a different project from a web pick list, because you are designing for gloves, cold and poor warehouse wireless coverage. Data migration and the parallel run deserve their own budget line, typically the largest single one. Payment processing inside the portal brings card industry compliance scope with it. And recurring cost is real: hosting, third party interfaces and support usually run 15 to 25 percent of the build per year, so a quote that ends at go live is not a quote for owning the system.

What separates a distribution build that works from one that fails here?

The strongest signal is a vendor who pushes back on scope. If they cut features to protect a launch date rather than quietly agreeing to everything, they have shipped this class of system before and they are protecting the launch rather than the invoice. A team that has never dealt with allocation, backorders or a three way match against receipts and invoices will agree to all of it and discover the difficulty at your expense in month six.

Ask them to walk through available to promise on a project they actually delivered, naming what they did about picked but unshipped stock and about inbound purchase orders inside the promise window. Ask which accounting package, which carrier interface and which trading partner they have certified against, by name and by direction of data. General integration experience is not the same as having survived a retailer's compliance testing.

Then insist on phased delivery with working software every few weeks, a parallel run before cutover, and written ownership of the source code, the data and the deployment. A single nine month build with one delivery at the end transfers all the risk to you, and in distribution the risk is not that the software is late. It is that the first invoice run after cutover is wrong and your customers see it before you do.