Vendor Managed Inventory Software: Why Retailer Feeds Break Your Replenishment Proposals

Why taking over replenishment quietly moves the risk onto you

A supply chain director signs a vendor managed inventory agreement with a national retailer because the buyer asked and because it locks in shelf space. What has actually happened is that the retailer has handed over the replenishment decision and kept the penalty. Their buyer stops placing orders. Your team now decides how much of each item goes to each distribution centre every week, and if you are short you get a service level charge, and if you are long the retailer's inventory turns fall and the category manager starts a conversation you will not enjoy.

Monday morning is where this lands. A demand planner downloads a product activity extract from one account, a spreadsheet emailed by a second account, and a portal report from a third. One sends units, one sends cases, one sends retail dollars. One reports store on hand as of Saturday close, another as of Friday. One includes stores that were closed for a remodel, with zeros that look exactly like zero demand. The planner cleans all of it in Excel, applies min and max levels from a contract stored in a shared folder, builds a proposal, emails it or drops it as an 850, and finds out on Wednesday which lines the retailer cut.

The failure is not that planners are careless. It is that the decision is being made from a signal nobody has cleaned, against rules nobody has encoded, on a clock that does not allow for either. In the VMI builds we have delivered, the pattern that repeats is that the planner is spending most of Monday on data preparation and almost none of it on the actual replenishment judgement, which is the only part of the job that needs a human.

Problem 1: every retailer sends a different signal and all of them are dirty

The standard flows exist. Product activity data and product transfer and resale reports are real EDI documents and some accounts send them cleanly. Others send a weekly flat file. Others expect you to log into a supplier portal and pull a report. Formats differ, units differ, calendars differ, and the store list changes without a notification.

Underneath the format problem is a data quality problem that is far more expensive. A store showing zero sales for a week either sold nothing or had nothing to sell, and those two facts demand opposite replenishment responses. Feeding an out of stock into a forecast as genuine zero demand teaches the model to starve that store permanently. Promotional weeks distort baselines. New store openings look like demand spikes. Store closures look like collapse. None of this is visible unless someone models it deliberately.

What a custom build does: an ingestion layer per account that normalises units, calendars, and store lists, then a cleaning pass that flags likely out of stock zeros using on hand history, separates promotional lift from baseline, and quarantines stores whose data changed shape this week. The planner sees exceptions rather than a wall of rows. This layer is unglamorous and it is where most of the value sits, because everything downstream inherits its quality.

Problem 2: the proposal rules live in a contract, not in a system

Every VMI relationship has its own arithmetic. Minimum and maximum days of supply per item class. Order multiples and pallet layers. A minimum order value or a full truck requirement before the account will accept a shipment. Lead time by distribution centre. Seasonal build rules. A promotional calendar with an agreed ship window. Item level restrictions on which DC gets which pack size. Those rules are negotiated per account and per season, and they usually exist as clauses in a document and habits in a planner's head.

What a custom build does: encode the rules as data, per account, per item class, with effective dates, so a change to a pallet configuration or a days of supply target is a field edit rather than a new formula in a workbook. Then the proposal engine runs the rules and shows its work. This matters more than it sounds. When a retailer questions a proposal, the useful answer is the specific rule and the specific numbers that produced it, not a planner reconstructing what the sheet did.

Truck build belongs here too. A proposal that is correct at item level and wrong at truck level gets cut anyway, so the engine has to round to layers and pallets and fill toward a full trailer using the next most needed items rather than arbitrarily.

Problem 3: what TrueCommerce and Blue Yonder actually do

TrueCommerce is solid at the message layer. It moves the documents, it connects to a lot of trading partners, and if your problem is that you cannot receive a product activity file at all, it solves that. What it does not carry is your commercial logic. Feed cleaning, out of stock inference, per contract proposal rules, and truck build are yours to define, and a connectivity platform will hand you the data rather than the decision.

Blue Yonder is genuinely powerful replenishment and forecasting software. The honest issue is fit and cost of change. It is built and priced for large enterprise deployments, the implementations are long, and once configured, adjusting per account rules is a project rather than an afternoon. If you are a supplier with five VMI relationships that each renegotiate terms annually, the rate of change in your rules is higher than the rate at which a heavyweight configuration can absorb them. Suppliers who succeed with it tend to be large enough to keep specialists on staff.

The gap between the two is the common case: you can receive the data and you cannot express your own rules over it without a spreadsheet.

Problem 4: nobody closes the loop on what the retailer did with your proposal

You send a proposed order. The account acknowledges it, and the acknowledgement cuts three lines, changes a quantity on two, and accepts the rest. In most supplier operations that acknowledgement is read once by a customer service coordinator and then disappears. The next week's proposal is built as if the cut never happened.

What a custom build does: treat the acknowledgement as feedback. Store proposed versus accepted at line level, track the reasons where they are given, and surface the pattern. When one distribution centre systematically cuts a particular pack size, that is a conversation to have with the buyer, and you need the history to have it. Reconciliation matters as well. If proposed, accepted, shipped, and received all differ, and only the last two get compared, you never learn where the loss happens.

Problem 5: you are measured on a scorecard you cannot reproduce

The retailer grades you on in stock rate, on time delivery, weeks of supply against target, and fill rate. Their numbers come from their systems. Yours come from yours. They will not match, and when the quarterly review happens the supplier who cannot reproduce the scorecard has no position.

What a custom build does: calculate the same measures from the same feeds the retailer sends you, then reconcile to their published scorecard and explain the variance. It is a modest piece of work with disproportionate commercial value, because it turns the review from a defence into a negotiation about which items are genuinely capacity constrained and which store clusters need a different target.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape for VMI is consistent. A focused first release covering ingestion and cleaning for one major account, rules driven proposals with truck build, and an exception based planner workspace runs $85,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding additional accounts, acknowledgement and reconciliation tracking, forecast integration, promotional planning, and scorecard reproduction runs $200,000 to $500,000 phased over 8 to 14 months.

What drives price up in VMI specifically: the number of accounts, because each one is a new feed, a new calendar, and a new rulebook, and the second account is not half the cost of the first but it is not full price either. Portal scraping for accounts that publish reports without a file transfer option. Store level rather than DC level replenishment, which multiplies the row count by a large factor and changes the engineering. Direct store delivery, if you have it. And forecasting depth, since a statistical baseline with promotional decomposition is a different scope from a simple weeks of supply rule.

What keeps price down: starting with one account, DC level only, and your top selling items, then proving the proposal beats what the planner produces by hand before extending.

Build versus buy, and when buying is right

Buy, or stay manual, if you run one VMI relationship with a modest item count and stable terms. The spreadsheet is genuinely fine at that size and a build would be capital spent on elegance. Buy an enterprise replenishment platform if you are large enough to staff it properly and your account rules are stable enough that configuration is a once a year exercise.

Build when your rules change faster than a configuration cycle, when you run several accounts whose feeds and terms conflict, when a service level penalty clause has already cost you money, or when the planner who understands the cleaning logic is a single point of failure. That last one shows up constantly. The rules are not secret, they are simply unwritten, and the moment that person leaves the account performance drops before anyone can explain why.

How to choose a developer for VMI software

Ask them how they would tell a genuine zero sales week from an out of stock week. A developer who has done replenishment work will talk about on hand history, sales continuity, and confidence flags. One who has not will say the data says zero. That single question separates the two groups faster than any reference call.

Ask what EDI they have actually run. Product activity data, product transfer and resale, planning schedules, purchase orders, and order acknowledgements are different documents, and every trading partner implements them with their own conventions. Ask for the partner and the document, not a general claim.

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 Excel, which means you paid for software and kept the spreadsheet.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from anyone who treats that as negotiable.