Vendor managed inventory, or VMI, is an arrangement where the supplier decides when and how much of its own product to ship to you, based on sales and inventory data it can see and stock levels you have both agreed in advance. Your team stops placing replenishment purchase orders. The supplier’s system watches your numbers, orders to the limits you set, and ships on a schedule.
It sounds simple, and the mechanics are simple. The hard part is the agreement underneath it: who owns the goods, who carries the risk when demand collapses, and what happens if the supplier’s forecast turns out to be wrong. Get those three things right and the rest is process. Get them wrong and you will spend a year explaining to your finance team why you are now carrying twice the inventory you did in March.
This guide walks through the full operating cycle, the data that has to move between the two companies, the way reorder decisions actually get calculated, and the failure patterns that procurement teams run into after the program has been live a while.
Table of Contents
- What Is Vendor Managed Inventory?
- How Vendor Managed Inventory Works: The Operating Cycle Step by Step
- Step 1: Sign the agreement and fix the parameters
- Step 2: Connect the systems
- Step 3: Share the demand and inventory feed
- Step 4: The supplier calculates and places the replenishment
- Step 5: Ship, invoice, and settle
- Step 6: Review performance and adjust the parameters
- How vendor managed inventory works on a daily operating cycle
- What Data Buyers and Vendors Share
- How Inventory Levels and Reorder Decisions Are Set
- What the Supplier and Buyer Are Each Responsible For
- How Vendors Are Paid Under a VMI Agreement
- Vendor Managed Inventory vs. Buyer Managed Inventory
- Benefits and Business Impact of VMI
- Which KPIs Should You Track?
- When Vendor Managed Inventory Is Worth Using
- How to Set Up a VMI Program That Works
- Common VMI Mistakes and How to Fix Them
- Frequently Asked Questions
- Does vendor managed inventory give the supplier ownership of the customer’s inventory?
- Who pays for inventory under a vendor managed inventory program?
- Is VMI the same as consignment inventory?
- What is the difference between VMI and a purchase order system?
- How much inventory safety stock should a buyer keep under VMI?
- How long does it take to implement vendor managed inventory?
- Conclusion
What Is Vendor Managed Inventory?
Vendor managed inventory is a replenishment model, not a financing model and not a shipping model. The supplier takes over one specific decision: how much product you need, and when it should arrive. Everything around that decision stays where it was unless the contract moves it.
There are two parties, and occasionally a third. The buyer is the company holding the inventory, usually a retailer, distributor, or manufacturer. The vendor is the company that makes or imports the product. A third party shows up when a logistics provider or a sales agent sits between them, and at that point you need to be careful about which party can actually see the demand data.
The inventory under management is normally the supplier’s own product, at your location or in a shared warehouse. Suppliers do not typically manage your packaging, your other vendors’ lines, or anything they do not produce. If a distributor handles several manufacturers’ product under one VMI agreement, each manufacturer’s data has to stay separated, or the replenishment logic starts mixing demand signals.
What the buyer keeps: the commercial relationship, the payment terms, the choice of which suppliers to work with, and the right to audit what the supplier is doing. What the buyer gives up: the day-to-day ordering decision for that product line, and the ability to quietly order less when cash gets tight without renegotiating.
Worth saying plainly: VMI is not the same as a supplier being helpful. Practitioners in logistics forums argue about the boundary constantly, and the recurring question is whether a program counts as real VMI if the supplier cannot see timely demand data. A sales rep eyeballing your shelves and phoning in an order is order taking, not vendor managed inventory. The test is whether a system is acting on data you feed it.
How Vendor Managed Inventory Works: The Operating Cycle Step by Step
Vendor managed inventory how it works, in practice, is a loop with six moving parts: an agreement, a data feed, a replenishment calculation, a shipment, an invoice, and a review. Everything a VMI program does happens inside that loop, and most disputes trace back to one of the six being loosely defined.
Step 1: Sign the agreement and fix the parameters
Before any data moves, both sides agree on the scope, the minimum and maximum quantities for each SKU, the review and delivery schedule, the service level, and who carries risk if something goes wrong. This document is the program. Everything the systems do later is an execution of the numbers written here.
Step 2: Connect the systems
The two companies set up a data connection so demand information reaches the supplier without anyone re-keying it. Common routes are electronic data interchange, an API between the systems, or a supplier portal where your team uploads a file on a schedule. Whichever you pick, the feed has to be frequent enough to be useful and structured enough to be trusted.
Step 3: Share the demand and inventory feed
On each cycle, the buyer sends what sold since the last message, what remains on hand, what is already inbound, and the forward forecast. The supplier’s system reads that file, updates its own view of your inventory position, and reconciles it against its production and shipping plan.
Step 4: The supplier calculates and places the replenishment
This is the step that makes it VMI. When the projected position for an item falls to its agreed minimum, the supplier’s system generates the order quantity itself, up to the agreed maximum, and commits it. No purchase order is required from you for routine replenishment.
Step 5: Ship, invoice, and settle
The supplier ships against the agreed schedule and invoices on the trigger written into the contract, which is often delivery or consumption rather than order placement. Your team receives the goods, matches them to the invoice, and pays on normal terms unless the agreement specifies something different.
Step 6: Review performance and adjust the parameters
On a fixed cadence, usually monthly or quarterly, both sides look at fill rate, inventory levels, forecast accuracy, and any exceptions raised during the period. Min and max values, lead times, and forecast horizons get revised here. A program that skips this step drifts.
How vendor managed inventory works on a daily operating cycle
Inside that six-step loop, the day-to-day rhythm is much quieter. Data files or API calls land on a schedule, often nightly for point-of-sale data and weekly or daily for inventory positions. The replenishment engine runs, generates messages, and holds them for the next release window unless a rule sends them straight through.
Buyers usually keep a few levers under their own control inside this cycle: the ability to adjust a forecast before it publishes, a cap on how much value the supplier may order in one release, and a kill switch for a single SKU. Procurement teams report that having those three levers written into the agreement is the difference between a program that saves time and one that removes all discretion from the buyer.
Exceptions are where most of the attention goes, because the normal path requires no human involvement at all. A stockout, a promotion you did not tell the supplier about, a purchase order freeze at your finance team, or a shipment arriving short all break the pattern. Each one should have a named contact on both sides and an agreed response window.
What Data Buyers and Vendors Share
Data sharing is the mechanism that makes vendor managed inventory how it works possible in practice. If the feed is stale or incomplete, the supplier is guessing with extra steps, and the program degrades into the sort of guesswork that damages the relationship faster than no program at all.
It helps to sort the data into two very different categories. Master data changes rarely and sets the rules. Transaction and forecast data changes constantly and drives the decisions.
| Data | How often it changes | What the supplier uses it for |
|---|---|---|
| SKU master, pack size, case configuration | Rarely, at onboarding and on change | Interpreting every other message correctly |
| Unit cost and price list | On contract change | Valuing orders and invoicing accurately |
| Point-of-sale or shipment history | Nightly or daily | Measuring real sell-through rather than shipments |
| Current on-hand inventory position | Daily | Calculating the projected position against minimum levels |
| Open orders and in-transit quantities | With each feed | Preventing double ordering of the same units |
| Forward forecast by SKU and period | Weekly or monthly | Anticipating demand beyond the reorder trigger |
| Promotion, pricing, and display plans | As decided, with notice | Avoiding under-ordering during a known lift |
| Production capacity and lead-time updates | On change | Sequencing releases the supplier can actually fulfil |
Two fields cause more argument than any other. The first is the on-hand count, because a mismatch between your system’s number and the supplier’s number produces orders nobody asked for. The second is inbound inventory: if a shipment is not reported as in transit, the replenishment logic sees less stock arriving and orders again to compensate.
Master data deserves a named owner on the buyer’s side. New SKUs, discontinued lines, and changed pack sizes all need to propagate to the supplier’s system, and in my experience the gap almost always opens on the buyer’s side, not the supplier’s.
There is a privacy dimension too, especially when the buyer sells competing products. Point-of-sale data at SKU level is commercially sensitive, and a good agreement says who inside the supplier’s organisation can see it and what they may do with it. Suppliers have an obvious incentive to learn the demand pattern of every store they ship to, including stores that also carry a rival’s line.
How Inventory Levels and Reorder Decisions Are Set
Reorder decisions come down to five numbers: the minimum, the maximum, the lead time, the demand rate, and the forecast horizon. Everything else is a consequence of those five, and most arguments about whether a program is working really are arguments about one of them.
The minimum is the floor. When projected inventory reaches it, the supplier orders. The maximum is the ceiling: the supplier never plans inventory above it, which is what stops a program from turning into forced overstocking. The reorder point sits above the minimum because you have to cover demand during the lead time before anything arrives.
Put simply, reorder point equals average demand per day multiplied by lead time in days, plus a safety stock allowance. Order quantity is whatever brings the projected position back to the maximum. If demand is steady, the cycle repeats at that quantity indefinitely.
A worked example makes it concrete. Take a packaged beverage line where your normal sales run 12 cases a week per store, replenishment happens weekly, and the supplier’s lead time is five days. Average demand of roughly 1.7 cases a day over a five-day lead time gives a lead-time demand of about 8.5 cases. With a safety allowance of 4 cases, the reorder point lands near 13 cases, and you might set the maximum at 30.
At that pace, roughly 17 cases flow each cycle, and inventory on hand oscillates between about 13 and 30. Now apply a promotion that triples weekly sales and the same numbers break: the system still orders 17 cases, the store sells out in four days, and you have a stockout in the middle of the campaign. That gap is why promotion notice belongs in the agreement rather than in a good intention.
Two rules keep the parameters honest. Revisit them on a schedule, because demand patterns shift faster than contracts do. And decide explicitly who computes the numbers, because “the supplier proposed them” and “we approved them” are very different positions when the forecast misses.
What the Supplier and Buyer Are Each Responsible For
Ambiguity about who does what is the most common reason a VMI program stalls. This table is the version I would put in the agreement itself, because naming the owner of each task is what stops arguments six months in.
| Activity | Usually owned by | Notes |
|---|---|---|
| Long-range demand forecasting | Both, with a named owner | Buyer supplies plans and promotions; supplier supplies capacity and market context |
| Short-term sales and inventory feed | Buyer | Accuracy of this feed is the buyer’s main lever |
| Setting min and max levels | Supplier proposes, buyer approves | Approval must be a real decision, not an automatic acceptance |
| Generating replenishment orders | Supplier | The defining feature of the model |
| Approving orders above a value threshold | Buyer | A cap prevents a run of large automated releases |
| Production prioritisation | Supplier | Requires the buyer to share realistic demand, not a padded forecast |
| Scheduling and delivery | Supplier | Against an agreed delivery calendar |
| Receiving, counting, and discrepancy claims | Buyer | Needs a short window to raise a claim |
| Invoicing and reconciliation | Both | Supplier issues, buyer matches and approves |
| Exception handling | Shared, with named contacts | Response times agreed per exception type |
| Performance review and parameter reset | Shared, on a calendar | The step most often skipped, and the one that matters most |
Two rows in that table are where most programmes go wrong. If production prioritisation is assigned to the supplier without the buyer sharing honest forecasts, the supplier will be blamed for a demand signal it was never given. And if the parameter reset has no calendar date attached, the numbers stay frozen at whatever they were at launch.
How Vendors Are Paid Under a VMI Agreement
Payment is the part buyers most often assume changes under VMI, and usually it does not. VMI moves a replenishment decision. It does not, by itself, change who owns the goods or when the invoice is raised, and treating it as if it does is how a program ends up with an unexpected liability on the balance sheet.
In a standard VMI arrangement, the buyer still owns the inventory once it is delivered, the supplier invoices on delivery or on a fixed interval, and payment runs on ordinary terms. The supplier carries no obligation to hold unsold stock and no right to charge a storage fee. The economics look different from the buyer’s perspective only because the quantity arriving is driven by consumption rather than by a purchase decision.
Title and risk of loss need to be explicit. A workable clause names the moment title passes, which in a standard program is delivery at the agreed location, and says who bears loss or damage in transit. Vague language here tends to surface at the worst possible time, usually after a damaged pallet and a large invoice.
Consignment is a different arrangement layered on top. Under consignment, the supplier keeps ownership of the goods sitting at your site until they are consumed, and the buyer pays for them as they are used. That changes the cash position substantially and is worth modelling separately before anyone signs.
Commercial terms can also move under VMI without moving ownership. A supplier may offer a rebate or discount tied to volume, to reduced buyer administrative effort, or to the share of demand it now handles directly. A payment term such as extended days payable is sometimes offered in exchange for tighter forecast discipline. These are contract terms, not features of the model, and they should be valued on their own merits rather than accepted as a VMI benefit.
Billing triggers deserve a specific line in the agreement. Delivery-based invoicing, consumption-based invoicing, and a weekly aggregated invoice behave very differently for the buyer’s accounts payable process, and switching between them mid-programme creates reconciliation work that nobody budgets for.
Vendor Managed Inventory vs. Buyer Managed Inventory
Both models can work. The deciding factor is usually how much signal the supplier has about end demand, and how much effort your team wants to spend generating purchase orders.
The comparison below sets out the practical differences between the two, and adds consignment, co-managed, and just-in-time for context, since those terms get mixed up constantly.
| Model | Who decides replenishment | Who owns the inventory | Payment timing | Best fit |
|---|---|---|---|---|
| Vendor managed inventory | Supplier, from shared data and agreed limits | Buyer on delivery | On delivery or on an agreed cycle | High volume, repeatable SKUs, one dominant supplier |
| Buyer managed inventory | Buyer, from its own forecast | Buyer on delivery | On delivery or on an agreed cycle | Many suppliers, wide assortment, low volume per line |
| Consignment | Usually the supplier or shared | Supplier until consumed | As consumed | New product launches, high risk of obsolescence, cash constrained buyers |
| Co-managed | Both, inside agreed limits | Buyer, sometimes supplier | Varies by clause | Relationships where neither party will hand over full control |
| Just-in-time | Buyer schedules tightly to production | Buyer | Short cycle or on receipt | Repeatable assembly work with a nearby supplier |
The information flow is the real difference. Under buyer managed inventory, demand knowledge lives in your organisation and gets translated into orders that the supplier reacts to. Under VMI, that knowledge is handed over, which is what allows the supplier to plan production and freight with much less noise. It is also why the bullwhip effect usually shrinks in a VMI program: the supplier sees the actual consumer sale, not an order that has already been distorted by a layer of guesswork.
Working capital moves in the buyer’s favour, sometimes a lot. If you were ordering to a forecast and holding three months of cover, and you now hold three weeks, the difference is meaningful. It is also not free money, because the shift in quantity can shrink your negotiating position on unit cost, and your cash conversion cycle only improves if the payment terms stay where they were.
Risk does not disappear under VMI. It moves. The buyer gives up control of quantity, so the exposure shifts toward overstocking, obsolescence, and a lack of leverage when the supplier is late. The mitigation is not to refuse the model but to keep approval limits, a defined exit path, and a second source for the items that would actually hurt you.
Benefits and Business Impact of VMI
The gains people describe in VMI programs fall into two groups. The first group is real and repeatable when the setup is sound: lower inventory, fewer stockouts, less manual ordering, better forecast visibility. The second group is frequently promised and rarely automatic.
On availability, a well-run program usually lifts the in-stock rate because the replenishment trigger responds to consumption within days rather than to a monthly planning cycle. On carrying cost, the reduction comes from shorter lead-time demand and a lower safety allowance, not from a better rate of return on the goods. Buyers also report recovering meaningful administrative time, since routine ordering stops being a weekly task for someone on the team.
Forecast accuracy usually improves, and this is worth explaining because it is slightly counter-intuitive. The supplier is not forecasting better than your team. It is forecasting a smaller problem, using actual sell-through rather than shipments, which removes a layer of distortion. That same transparency helps both sides plan capacity.
Coordination costs fall as well. One scheduled call replacing a stream of order emails is a real saving, and it improves when a dispute comes up because both sides can point at the same data.
Now the part that is not automatic. VMI does not fix a product that is hard to forecast. It does not make a supplier who cannot meet lead times become reliable. It does not improve data quality on its own, and it will happily order more inventory than you need if the maximum was set generously and never revisited. It does not remove the buyer’s need to pay, verify, and reconcile, and it does not protect you from a supplier who is slow to respond to exceptions.
One honest caveat about the headline savings. Frequently cited figures for supply chain cost reductions from VMI programmes come from vendor-published studies and should be read with that in mind. The number I would actually trust is your own, measured over two or three review cycles on a single product line, because that is the only figure that reflects your demand pattern, your lead times, and your data quality.
Which KPIs Should You Track?
A VMI program without metrics becomes an argument about whether it is working. Pick a small set, review them on a fixed date, and write down what each one is supposed to tell you before you look at it.
| Metric | How it is calculated | What it reveals |
|---|---|---|
| Fill rate | Units supplied divided by units demanded, as a percentage | Whether the supplier is meeting demand when it matters |
| On-time in-full delivery | Deliveries complete and on schedule as a percentage of total | Whether the supply promise is being kept |
| Stockout frequency | Count of SKU and location stockout events per period | Whether the minimum levels are set realistically |
| Days of inventory on hand | Inventory value divided by average daily cost of goods | Whether the programme is actually cutting working capital |
| Inventory turnover | Cost of goods sold divided by average inventory value | The same signal over a longer window, less noisy week to week |
| Sell-through rate | Units sold as a percentage of units received | Whether the max values are causing slow-moving build-up |
| Forecast accuracy | Actual demand against the agreed forecast, by period | Whose forecast is drifting, and by how much |
| Order cycle time | Time from replenishment trigger to goods receipt | Whether the process itself is adding delay |
| Inventory discrepancy rate | Difference between system position and physical count | Whether the shared data can be trusted |
| Cost per unit administered | Programme running cost divided by units handled | Whether the effort saved is worth the fees charged |
Read them in pairs rather than individually. Inventory days and sell-through together tell you whether stock levels are genuinely lean or simply frozen. Fill rate against stockout frequency catches the classic case where a supplier hits its numbers while the shelf still runs empty, which happens when a location is excluded from the count.
Watch the trend, not the single period. One quarter of a stockout caused by an unforecast promotion tells you very little about the programme. Four consecutive quarters of rising inventory days against flat sell-through tells you the maximum values are set too high and nobody is challenging them.
When Vendor Managed Inventory Is Worth Using
VMI is not a universal upgrade. It works when a handful of conditions are true at the same time, and the conditions are about your data and your relationship rather than about the product.
Demand for the SKUs in scope has to be reasonably repeatable. A stable base demand with known peaks is workable. Genuine volatility with no pattern is a poor fit, because the supplier is being asked to forecast noise.
Volume has to justify the coordination. A line moving a few cases a week does not repay the setup cost or the ongoing review time. Lines moving steadily, week in week out, for a supplier you already buy most of your volume from, are the sweet spot.
Data has to flow without heroic effort. If your inventory positions are updated weekly by hand from spreadsheets, the replenishment logic will be reacting to stale information and the programme will never feel reliable enough to trust.
The relationship has to survive more control. Practitioners in supply chain forums are blunt about this: VMI tends to hold together in cooperative relationships and fray in adversarial ones. Handing a supplier your sell-through data is a bigger concession than most buyers realise at the start.
It suits retail, grocery, and consumer packaged goods first, because point-of-sale data is clean and high frequency. It also works well for line-side components in automotive and electronics assembly, where a stockout stops a line. It is a poor fit for long-tail industrial distribution with hundreds of slow-moving lines, for anything with a short obsolescence cycle and no agreement on who eats the write-down, and for a supplier whose own production is unstable.
One more practical test before you start: can you name, in a sentence, what the supplier does better with your data than your own team does? If the answer is vague, you are probably building an administrative project rather than fixing a problem.
How to Set Up a VMI Program That Works
A VMI implementation that runs as a ninety-day pilot with a named decision at the end of it will outperform one launched across the whole assortment on day one. Here is the sequence I would follow.
Pick the supplier and the scope carefully
Start with one supplier you already buy a high share of volume from and a limited number of SKUs with steady demand. Large programmes fail on scope long before they fail on technology. You want a partner with integration capability, because a supplier who cannot receive a data feed will quietly turn the programme into manual ordering.
Measure the baseline first
Record your current inventory days, stockout frequency, fill rate, and the hours your team spends ordering. Without a baseline, the review at the end has nothing to compare against and the programme gets judged on opinion.
Write the agreement before the integration
Cover the min and max values and who proposes them, the data feed and its frequency, delivery calendar, service levels, promotion notice, invoicing and title transfer, discrepancy claims, return handling, the review cadence, audit rights, and the exit terms. The exit clause matters more than buyers expect: state what happens to the inventory sitting at your site and how quickly the arrangement can be unwound if service drops.
Connect the data and prove it with a reconciliation
Run the feed for two or three cycles in observation mode, where orders are generated but not released. Compare the supplier’s proposed orders against what your own team would have ordered. This is the cheapest way to find parameter errors, and it is far less expensive than discovering them after go-live.
Agree the exception rules
Write down what happens when a promotion is announced late, when a delivery is short, when inventory is damaged in transit, and when either side wants to pause orders. Name a contact and a response time for each. Most programme failures are exception failures wearing a different label.
Pilot for ninety days, then decide
Days one to thirty are for clean data and stable parameters. Days thirty-one to sixty are for tuning limits against real consumption. Days sixty-one to ninety are for measuring against the baseline and reviewing the parameters one last time. At day ninety, expand, hold, or stop, and write down which one it was.
Roll out in stages
Add SKUs in batches rather than all at once, and keep the review cadence fixed from the first batch. A programme that grows faster than its governance is the most common route back to buyer managed inventory, usually without anyone formally deciding to go back.
Common VMI Mistakes and How to Fix Them
Almost every failed VMI program I have seen failed in one of a handful of predictable ways. None of them are technology problems.
Min and max levels set once and never revisited. Demand shifts, seasonality arrives, and the parameters keep pointing at last year’s business. Fix it by putting a parameter review on the same calendar as the performance review, with a rule that values are re-derived from recent consumption rather than from the original onboarding model.
The supplier ships to the maximum every cycle. This is the most repeated complaint from procurement teams, and it turns a replenishment program into forced overstocking. Fix it by requiring the supplier to show the order rationale alongside each release, then challenge the quantity against actual sell-through. If you cannot see why an order fired, you cannot audit it.
Promotions run without notice. The supplier cannot cover demand it did not know about, and the buyer still gets blamed for the resulting stockouts. Fix it with a written notice period for promotions, display changes, and pricing activity, and agree who funds the incremental units if the programme orders them.
Nobody owns the numbers. If the supplier sets the minimum and maximum and the buyer only receives them, the buyer has agreed to something it never evaluated. Fix it by splitting the roles explicitly: the supplier proposes, the buyer approves, and approval happens on a schedule rather than on demand.
Service levels are set at a level the supplier cannot hit. A ninety-eight percent fill rate on lines with a five-day lead time and volatile demand is a target chosen for the contract, not for reality. Fix it by starting with the supplier’s demonstrated performance, improving from there, and reviewing the target only after the data is stable.
Safety stock quietly inflates. A low tolerance for stockouts pushes the minimum upward, then the average inventory follows. Fix it by tracking the days of inventory trend alongside fill rate, and by asking which one has moved since the last review.
Exceptions go uncommunicated. A missed delivery is noticed a week later and handled as a complaint rather than a correction. Fix it with named contacts, a response window, and a standing exception message that goes out the same day.
Incentives point in opposite directions. A buyer rewarding the supplier on volume and the supplier rewarded on margin will produce orders that are not driven by demand. Fix it by tying the supplier’s scorecard to fill rate and inventory days rather than to shipped value.
Supplier authority is unlimited. Removing all approval from the buyer removes all correction too, and one miscalculated parameter becomes a very expensive quarter. Fix it with a per-order value threshold, a per-SKU cap, and a documented pause procedure that the buyer can use without a negotiation.
There is a broader pattern behind all of these. VMI works when the agreement is specific and reviewed on a schedule. It struggles in relationships where trust is being substituted for definitions, and it breaks when nobody is assigned to keep the definitions current.
Frequently Asked Questions
Does vendor managed inventory give the supplier ownership of the customer’s inventory?
Usually not. In a standard VMI program the supplier decides what to ship and when, but title still passes to the buyer on delivery, and the buyer carries the cost and the obsolescence risk. Ownership moves to the supplier only when the arrangement is consigned, which is a separate contract term. The two decisions are often confused, so state title transfer explicitly in the agreement rather than assuming either default.
Who pays for inventory under a vendor managed inventory program?
The buyer pays, in the ordinary way. VMI changes the timing and quantity of what gets delivered, not the payment obligation. Invoices are typically raised on delivery or on a fixed cycle, and the buyer settles on standard terms. If the supplier is financing the stock by retaining title until consumption, that is consignment and it changes the cash position materially, so it deserves its own clause and its own modelling.
Is VMI the same as consignment inventory?
No, they solve different problems and are often combined. VMI moves the replenishment decision to the supplier. Consignment moves ownership, so the supplier keeps title to the goods sitting at your site until they are used, and payment follows consumption. You can run consigned VMI, standard VMI, or neither. What matters is that the agreement names which one applies, because the cash and risk consequences differ sharply between them.
What is the difference between VMI and a purchase order system?
A purchase order system is a mechanism for buying; VMI is a decision model that decides what to buy. Under buyer managed inventory, your team raises purchase orders based on its own forecast. Under VMI, the supplier’s system generates the replenishment order from shared data and agreed limits, so routine purchase orders disappear for those SKUs. Your purchase order system still exists for everything else, plus for approvals above agreed thresholds.
How much inventory safety stock should a buyer keep under VMI?
Less than you would under buyer managed inventory, because the supplier sees consumption in near real time and reacts within a day or two rather than a planning cycle. In practice, safety stock becomes a smaller buffer sized around the variability of demand during the supplier’s lead time, plus a little protection for known promotions. Set it from recent consumption data, not from a rule of thumb, and revisit it every review cycle.
How long does it take to implement vendor managed inventory?
For a single supplier and a limited SKU list, ninety days is a realistic pilot: roughly thirty days to agree terms and get clean data flowing, thirty to tune parameters against real consumption, and thirty to measure against a baseline and decide. Enterprise programmes spanning many suppliers and systems take considerably longer, usually because of integration and contract work rather than the replenishment logic itself. Running the feed in observation mode before releasing orders is what keeps the timeline honest.
Conclusion
Vendor managed inventory is a working arrangement, not a slogan: shared data, agreed minimum and maximum levels, a supplier that orders inside those limits, and a review that puts the numbers back under scrutiny on a fixed date. Understood that way, vendor managed inventory how it works is straightforward to explain and demanding to run.
If you are starting now, do four things in order. Get the data feed clean enough that you would trust a stranger to make decisions from it. Write down the service level you actually need and what happens when it is missed. Agree the replenishment rules, including who proposes min and max values and who approves them. Then assign decision rights in writing, because that last item is the difference between a programme that saves your team time and one that takes control away from it without giving anyone the ability to fix it.