Consignment & Vendor-Managed Inventory

Distributors, contract manufacturers and equipment suppliers routinely hold stock they do not own. Supplier-owned material sits in your warehouse until a production order consumes it. Your own finished goods sit at a customer site until the customer draws them down. In both directions the physical movement and the transfer of ownership happen at different moments, and the commercial agreement usually says the invoice follows consumption, not delivery.

Dynamics 365 Finance and Supply Chain Management covers one half of that natively. Vendor consignment is in the box: you define an inventory owner, receive supplier-owned goods against a consignment replenishment order, and run an ownership change journal that transfers the goods to your ownership and generates the purchase order the vendor invoices against. What is not in the box is customer consignment, where stock you still own physically sits at a customer location. Neither direction gives you the consumption capture, the periodic statement reconciliation, the aging control or the replenishment signalling the agreement actually requires. Most teams run that half in spreadsheets, and the gap surfaces as unbilled consumption, disputed vendor self-bills, and stock that has quietly aged past its return window.

What ECOSIRE builds

We build a licensed extension for Dynamics 365 Finance and Supply Chain Management, written in X++ as extension models only. Event handlers, chain-of-command, extension tables and form extensions. No overlayering of Microsoft code, so your one-version service updates are never blocked by us. The build is scoped to your agreements: which vendors consign to you, which customers you consign to, how consumption is proven, and when the ownership event fires.

Vendor consignment: supplier-owned stock in your warehouse

We extend the standard inventory owner model so consigned stock is fully visible as on-hand, reservable and pickable, while remaining off your balance sheet until the ownership change posts. On top of the standard consignment replenishment order we add automatic creation and release rules driven by min and max levels per item, warehouse and vendor, plus the ability to hold a replenishment for buyer review before it reaches the vendor.

The ownership change itself is the financial event. We wire it to your triggers: consumption on a production order picking list, a warehouse mobile app pick, a period-end sweep, or a manual journal. Each posted ownership change produces the purchase order and a pending vendor invoice line carrying the correct financial dimensions, so accounts payable is matching against a document that already agrees with the vendor statement.

Customer consignment: your stock on a customer site

For stock you own that sits at a customer location we model each site as a dedicated warehouse or site under your legal entity, with the customer recorded on the location. The stock stays in your inventory valuation and in your reorder calculations, which is exactly what your auditors and your planners both need.

Consumption arrives by whichever channel the customer can actually support: a usage file imported through the data management framework, an OData or data entity push from the customer system, a portal upload, or a counted reconciliation at period end. Each accepted consumption line generates the sales order and invoice, relieves the consignment location, and posts revenue and cost of goods sold with the ledger dimensions defaulted from the customer, site and item.

Consumption-based invoicing

Both directions share one engine. Consumption events are staged, validated against the agreement in force on the consumption date, priced from the trade agreement or the consignment-specific price list, then released to document creation. Rejected lines land in an exception queue with a reason, not in a silent log. Nothing invoices twice: every consumption line carries an idempotency key so a re-sent file, a retried batch job or a duplicate device message cannot create a second document.

Replenishment signals and agreement terms

We hold the commercial terms as data, not as code: min and max levels, review cycle, return window, ownership transfer trigger, consumption proof requirement, and the currency and price basis. Batch jobs evaluate levels on your schedule and raise replenishment proposals in both directions, with business events available so Power Automate can push a signal to a vendor portal or an internal channel.

Reconciliation, aging and audit

A consignment statement is produced per vendor and per customer for any period, listing opening balance, receipts, consumption, returns, adjustments and closing balance, reconciled to on-hand by inventory owner. Aging buckets and return-window alerts run as scheduled batch jobs so stock that is approaching a contractual return date is flagged while there is still time to act. Every ownership change, write-off and adjustment is traceable to a user, a document and a posting.

Warehouse execution

Where you run warehouse management, we extend the warehouse mobile app with menu items for consignment consumption, ownership change confirmation and customer-site counts, so the shop floor and the field record the event once, at the point it happens, rather than reporting it later on paper.

Who it is for

Distributors holding supplier-owned inventory under a consignment agreement. Manufacturers taking components on consignment from strategic suppliers. Equipment, medical device and spare-parts suppliers who place stock at customer sites and invoice on usage. Any organisation running multiple legal entities where consignment terms differ by entity and by counterparty.

How delivery works

It starts with a scoping call. We walk your consignment agreements, your current F&O setup, your legal entity structure and the systems that will send or receive consumption data. You get a written scope and a fixed quote before any code is written, so the price does not move mid-project.

On acceptance we build against your version of Finance and Supply Chain Management in our own development environment. The extension is delivered as a deployable package and, if you want it, as source in your Azure DevOps repository. We install first into your Tier-2 or higher sandbox through your LCS pipeline, configure it with your team, and support user acceptance testing there. Production deployment follows your change window and your release process. Typical lead time from signed quote to sandbox install is two to four weeks depending on scope.

What this is not

This is not a pre-built product you download today. Every build is made to your agreements and your environment. It is not a Business Central app. We do not overlayer, we do not modify Microsoft models, and we do not sell you a vendor portal you did not ask for. If your requirement is genuinely met by the standard vendor consignment features alone, we will tell you in the scoping call.

After go-live

Every build ships with a support window covering defect fixes and compatibility with service updates released inside that window. Beyond it we quote support annually. You keep the deployable package and, where included, the source, so you are never locked out of your own configuration.