On this page
Nobody sets out to run a distribution business on ten pieces of software. It happens one sensible decision at a time. The accounting system does not handle directed picking, so a warehouse product goes in. The website needs live pricing, so a connector goes in. Sales want a pipeline, so a CRM goes in. Each purchase is justified on its own merits, each one solves a real problem, and each one is approved by a different person in a different quarter.
Five years later the finance director asks what the company spends on software and gets a number from the licence schedule. That number is not wrong. It is just a small fraction of what the stack actually costs.
How a distributor ends up with ten systems
The pattern is consistent enough to be predictable. A wholesale distributor typically starts with a core accounting system and then adds, in roughly this order: a warehouse management tool once pick accuracy becomes a customer complaint; an e-commerce platform or B2B portal once buyers start ordering online; a CRM once the sales team outgrows a shared mailbox; a pricing or rebate tool once contract pricing gets too complicated for the order screen; a commissions spreadsheet that eventually becomes a commissions application; a field service or repair system if the business services what it sells; and a reporting or BI tool bolted on top of all of it, because none of the others can answer a question that spans two systems.
That is seven, and it does not count the shipping rate engine, the EDI translator, the tax service or the document capture tool for supplier invoices. Ten is not an exaggeration; for a distributor between $5M and $200M in revenue, ten is normal. Every one of those choices is defensible. The problem is the space between them, and nobody owns that space.
The costs that never reach the licence line
Integration and middleware upkeep
Connections between systems are not build-once assets; they are dependencies with a maintenance schedule. Field mappings drift, API versions deprecate, tokens expire, a partner renames a field and a nightly job starts failing quietly. Somebody has to notice and fix that — usually either an external consultant or the one internal person who understands the whole picture and therefore cannot take a two-week holiday.
Duplicated master data
Ask how many systems hold a customer record, then ask which one wins when they disagree. In a stack of ten, the same customer typically exists in the ERP, the CRM, the e-commerce platform and the shipping tool, with four slightly different addresses and two different credit limits. Item data is worse, because units of measure, pack quantities and substitutions have to agree for the whole chain to work. The cost is not storage — it is the time spent maintaining four copies and the orders that go wrong when they diverge.
Reconciliation labour
Every integration creates a reconciliation. Did every web order land in the ERP? Do warehouse shipment records match invoiced quantities? Does the commissions tool agree with the sales ledger? Somebody checks these, usually at month-end, usually manually, usually under time pressure. It rarely appears in a budget because it is absorbed into existing salaries — which is precisely why it is invisible and never gets fixed.
Vendor finger-pointing during an outage
When orders stop flowing from the website into the ERP at 9am on a Monday, the first hour goes on establishing whose fault it is. The e-commerce vendor posted successfully. The middleware vendor passed it on. The ERP partner never received it. Each is reading their own logs and each is telling the truth about their own scope. That is not a negotiating problem — it is an architectural consequence of holding ten contracts.
Training across many interfaces
A counter salesperson checking stock in one system, price in another and credit status in a third is not doing three jobs; they are doing one job badly across three interfaces. Onboarding takes longer, cross-training is harder, and holiday cover becomes a real operational risk because expertise is fragmented by tool rather than by function.
The security and access surface
Ten systems mean ten sets of credentials, ten permission models, ten offboarding steps when someone leaves, and ten places where customer and pricing data lives. Most distributors are confident about revoking ERP access on someone's last day. Far fewer are confident that the same person no longer has a login to the pricing tool or an export sitting in a personal cloud folder.
The cost of questions you stop asking
This one never shows up anywhere, and it may be the largest. When answering "what is our margin by customer by product line including freight" means pulling from three systems and reconciling by hand, that question gets asked once a year instead of once a month. The stack does not just cost money; it narrows the range of decisions the business is capable of making.
Upgrades are where the bill comes due
In a single system, an upgrade is a project. In a stack of ten, an upgrade is a negotiation with nine other vendors. Vendor A ships a required update, that update changes an API response, and two integrations built against the old response break. The vendors responsible for those integrations have their own release schedules and their own definition of urgent — and the update was not optional, because the old version is out of support.
The practical result is that stacks become frozen. Teams stop upgrading anything because the blast radius is unknowable, and then run production on unsupported versions — which is a security problem, a compliance problem and eventually a very expensive forced migration. If your organisation has ever said "we cannot upgrade that until we replace the other thing," you have already paid this cost; it just was not itemised.
"We are currently in the transition phase, moving from our existing ERP platform to the Centerprism solution. Frankly, it's a big lift for us. The Centerprism team has been great to work with as we move through implementation, data migration, and training." — Shields Electronics, Centerprism client
What changes when everything shares one database
The alternative is not "one vendor for everything" as a slogan. It is a specific technical property: the modules share a single database, so there is nothing to integrate between them.
Centerprism is built this way. The distribution work runs on one database, which means warehouse management, order management, pricing management and the rest are reading and writing the same customer record, the same item record and the same open order — not synchronised copies of them. A price change is not published to three systems; there is only one place it exists. A stock allocation is not reconciled overnight; it is the same row the picker and the salesperson are both looking at.
The effects are unglamorous and cumulative:
- No middleware to maintain between modules, because there is no gap for middleware to sit in.
- One master record per customer and per item, so there is no "which one is right" conversation.
- One upgrade path with a knowable blast radius, rather than nine dependencies that must agree.
- One vendor accountable when something breaks, and one support relationship to hold to a standard.
- One permission model, so access granted and revoked once actually means granted and revoked.
- Cross-module questions answerable directly — which is what makes a tool like PrismView possible in the first place, since it queries live data across modules without an interface being built first.
The twenty-minute stack audit
Before anyone proposes a replacement, count what you have. This is a whiteboard exercise, not a consulting engagement, and twenty minutes with the right three people in the room is enough for a first pass.
Draw six columns and fill one row per system. Include everything — the shipping tool, the spreadsheet that calculates commissions, the Access database nobody admits to.
| Column | What to write in it |
|---|---|
| System | The name people actually use for it, not the vendor's product name |
| Owner | The one named person who would be called if it broke at 7am |
| Annual cost | Licence plus support plus hosting plus any consultant retainer |
| Data it duplicates | Which records also exist elsewhere: customers, items, prices, orders, stock |
| What breaks if it stops | Name the downstream process, not the system: "orders stop reaching the warehouse" |
| Who we call | The support contract that covers it, and its response commitment |
Then add three lines at the bottom of the board, usually more revealing than the table itself:
- Every integration between two rows — draw them as arrows. Count the arrows, not the boxes. Arrows are what you actually maintain.
- Every manual reconciliation — anything a person checks between two systems on a schedule. Note who does it and how long it takes.
- Every "we cannot upgrade X until Y" — these are your frozen dependencies and your real risk register.
Deliberately do not put a dollar figure on the hidden costs during the session. Estimating integration maintenance in the room produces made-up numbers that get argued about instead of the finding. The finding is the shape: how many arrows, how many reconciliations, how many frozen dependencies.
Reading your own results honestly
A stack of ten with two arrows between them is fine: those are genuinely separate tools, and consolidating them would create work without removing risk. A stack of six with fourteen arrows is a different animal — a distributed system nobody designed, maintained by people whose job title says something else. Three patterns are worth taking seriously on the finished board:
- A row with no owner. Software that runs your business and belongs to nobody is not a cost problem, it is an availability problem waiting for a bad week.
- The same data listed in four rows. Wherever a record is duplicated four times, you are paying for maintenance four times and getting arguments for free.
- A reconciliation that takes more than half a day a month. That is an integration failing quietly and being patched by a human. It will not improve by itself.
If distribution-specific gaps are what drove the add-ons in the first place — lot and serial control, will-call, contract pricing, directed picking — it is worth checking what a distribution-native platform covers natively before assuming the gaps are permanent. Our wholesale distribution page maps the common ones, and the datasheet library has module-level detail for each.
When consolidating is the wrong answer
Consolidation is not automatically correct, and a vendor telling you otherwise is selling rather than advising. If a specialist system is genuinely best-in-class for something that differentiates you commercially and has exactly one clean integration point, keep it. If a tool serves one department, holds no shared master data and would take six months to replace for a marginal gain, keep it. If you are mid-way through a peak season, do nothing until it ends.
The case for a single source is strongest where the arrows are densest — the core transaction chain from quote through order, price, allocation, pick, ship and invoice. That chain crosses the most systems, duplicates the most data and produces the most reconciliation. It is also where a broken integration costs you a shipment rather than a report.
Run the audit first. If the board tells you the arrows are the problem, we are happy to walk through what that chain looks like on one database — request a demo, or read what other distributors said about the move on our testimonials page.
