Vendor Managed Inventory Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does a vendor managed inventory build keep expanding past the first account?

The brief is contained: ingest the product activity feed from your largest account and generate an order proposal. Three weeks in, the proposal is correct at item level and gets cut anyway, because it does not round to layers and pallets and does not fill toward a full trailer. So truck build comes in scope. Then the planner points out that the minimum and maximum days of supply differ by item class and were renegotiated in the spring, so rule versioning comes in. Then a second account is mentioned, and the second account sends cases where the first sends units and reports on a different week ending day.

The expansion is real rather than sloppy. In vendor managed inventory the proposal is only useful if it is acceptable, and acceptability is a truck level and contract level property, not an item level one.

Scope by account and by acceptance instead. Take one account, distribution centre level only, your top selling items, and commit that the proposal is accepted at the same or a better rate than the planner's spreadsheet across three cycles. Everything that acceptance needs comes in scope by definition. Everything else, meaning the second account, store level replenishment, promotional planning and scorecard reproduction, goes on a written exclusion list. Run the new proposals in parallel with the planner's workbook for those three cycles and do not skip the parallel period. It is the most common way these projects lose trust in month two.

What goes wrong with retailer feed history and store master data?

Four things, and none of them are visible until you look. Store lists change without notification. A remodel closes a location for six weeks and the feed keeps reporting it with zeros that look identical to weak demand. New store openings look like demand spikes, and closures look like collapse. Any baseline built across those events is wrong in a direction you cannot see.

Units and calendars are the second problem. One account sends units, one sends cases, one sends retail dollars, and one reports on hand as of Saturday close while another reports Friday. Historic files carry whatever convention was in force at the time, which may not be the current one.

Promotional weeks are the third. Lift from a feature or a display is not baseline demand, and a model that cannot separate them will over order after every promotion ends. The fourth is item identity, because a pack size change or a reissued item number breaks the history join silently and leaves you forecasting a new item with no past.

What works: a per account ingestion adapter that normalises units, calendars and store lists into one internal model, then a cleaning pass that flags likely out of stock zeros from on hand history, separates promotional lift from baseline, and quarantines stores whose data changed shape this week. Build the item identity crosswalk before anything reads history, and expect that to take real weeks with your demand planner sitting in it.

Why do the retailer feeds and portals break after launch?

Because the intake is not one channel and never will be. One account sends a proper product activity document over your messaging provider, one emails a spreadsheet, and one expects you to log into a supplier portal and pull a report. Trying to force every account onto a single channel is a negotiation you will not win, so the software absorbs the difference.

Each channel then fails in its own way. Files arrive late, arrive twice, or arrive with a header row that changed after the retailer updated their reporting tool. Portals redesign without notice, which breaks browser driven extraction. Messaging feeds truncate silently when a store list grows. The symptom is rarely an error. It is a Monday where one distribution centre looks like it stopped selling, and the proposal reacts.

The controls are unglamorous and they are the difference between a system planners trust and one they route around. Reconcile every ingest against expected shape: store count, item count, week ending date and total units compared with the prior period, with a hard stop rather than a warning when the deviation is implausible. Alert when an expected file has not arrived by its usual hour, because a missing file is worse than a bad one. And treat portal extraction as a maintained component with a health check, not a one time script.

What happens when out of stock inference and truck build are not covered?

These are the two gaps that convert a technically correct system into a commercially useless one. The out of stock problem is the quieter and more damaging of the pair. Without inference, every week a store had nothing on the shelf teaches your model that the store does not sell the item, and the replenishment quantity falls. Next week the store is out again for longer, and the signal reinforces itself. The stores that need the most attention get the least, which is exactly the pattern a retailer's in stock scorecard punishes.

Inference is not complicated, it is simply a step teams skip. Use on hand history and sales continuity to flag suspected out of stock periods, exclude them from the baseline rather than counting them as demand, and mark them so a planner can see why a number moved.

Truck build is the loud failure. A proposal that is right at item level and wrong at pallet or trailer level gets cut by the account, and the cut looks like your system being wrong. The engine has to round to layers and pallets and fill toward a full trailer using the next most needed items, not arbitrary ones, and it has to respect minimum order value or full truck requirements where the agreement sets them.

Both belong in release one. A first release without them will produce proposals the planner corrects by hand, which means you paid for software and kept the spreadsheet.

Should you build custom or configure what you already own?

Stay manual if you run one relationship with a modest item count and stable terms. The spreadsheet is genuinely adequate at that size and a build would be capital spent on elegance. We would tell you that directly rather than quote you.

TrueCommerce is solid at the message layer. It moves the documents and connects to a lot of trading partners, so if your problem is that you cannot reliably receive a product activity file at all, that is the right purchase and it is a smaller cheque than a build. What it will not carry is your commercial logic: cleaning, out of stock inference, per contract rules and truck build stay yours to define.

Blue Yonder is genuinely capable replenishment and forecasting software, built and priced for large enterprise deployments. If you are large enough to keep specialists on staff and your account terms are stable enough that configuration is an annual exercise, configure it and do not build. The mismatch that pushes suppliers toward a build is rate of change rather than capability. Five relationships that each renegotiate terms every year generate more rule changes than a heavyweight configuration cycle absorbs comfortably.

Build when your rules change faster than a configuration cycle, when several accounts conflict, when a service level clause has already cost you money, or when the planner who understands the cleaning logic is a single point of failure.

How do hidden costs get into the quote?

Five items are routinely absent. The first is the account count, because each account is a new feed, a new calendar and a new rulebook. The second account is not half the price of the first, and the fifth is not free.

The second is portal extraction for accounts that publish reports with no file transfer option. That is a maintained component with a running cost, not a build line.

The third is store level rather than distribution centre level replenishment. It multiplies row counts by a large factor and changes the engineering approach, so a quote priced at distribution centre level does not scale to store level by adding a percentage.

The fourth is forecasting depth. A weeks of supply rule is a different scope from a statistical baseline with promotional decomposition, and the two get conflated in conversation constantly. The fifth is the parallel running period, which needs your planner's hours as much as the developer's. Ask for all five priced as named items before you compare proposals.

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

Three tests, all runnable in a first conversation. Ask how they would distinguish a genuine zero sales week from an out of stock week. Someone who has done replenishment work will talk about on hand history, sales continuity and confidence flags without prompting. Someone who has not will say the data says zero. That single question separates the two groups faster than any reference call.

Ask which documents they have actually run and with which trading partners, by name. Product activity data, product transfer and resale, planning schedules, purchase orders and order acknowledgements are different documents with different conventions per partner, and a general claim about integrations means nothing here.

Ask how the proposal explains itself. If the output is a quantity with no visible rule trail, planners will not trust it and will rebuild it in a workbook, and the retailer conversation about a questioned proposal will still be a planner reconstructing what a formula did. The useful answer names the specific rule and the specific numbers that produced the quantity.

Then settle ownership in writing before kickoff: the repository, the infrastructure accounts and the right to hire another firm. This matters more in vendor managed inventory than in most categories, because the rules you encode are your commercial agreements with your largest customers, and needing a supplier's cooperation to change them is not a position you want to be in during a renegotiation.