Inventory Models and Availability in SAP Commerce: Deposit, Dropship, Consignment, Cross-Dock

The inventory model is chosen in a business strategy meeting and paid for in engineering. "We will dropship the long tail" is one sentence that becomes supplier integrations, real-time stock feeds, order splitting, per-supplier sourcing rules, and a returns flow the merchant does not control. Because the model shapes system requirements this deeply, the CX Works material is right that it belongs at the start of a project, not discovered in a fulfillment retrospective. This guide covers the four canonical models, the multi-model reality most serious estates arrive at, and how each lands in SAP Commerce's stock service, sourcing strategies, and order management.

Why the Model Is an Architecture Decision#

Inventory reaches almost everything the customer experiences: what you can offer (assortment breadth), what you can promise (delivery dates and accuracy), what it costs (margin, delivery, working capital), and how returns work. Get it wrong and the failure is brand-visible: cancelled orders from phantom stock, split shipments the customer did not expect, delivery promises you cannot keep. The model is dictated partly by the nature of the business (a brand manufacturer holds its own stock; a marketplace-style long-tail retailer cannot) and partly by suppliers, who often impose the model because they hold the leverage. Four models cover most of the field.

Deposit: You Own the Stock#

Buy upfront, store in your own warehouse(s), carry the inventory risk in exchange for better margins. The fulfillment flow is the simplest: order arrives, sourcing picks a warehouse that can fill it, warehouse picks/packs/ships to the customer. The commerce implications are the friendliest:

• Stock accuracy is native: you own the warehouse, so real-time levels are knowable and the stock service reflects truth. Availability promises are reliable, and customer service can answer confidently.
• Fulfillment is fast and controlled: you own the process end to end.
• The catch is assortment and capital: deposit does not scale to long-tail SKU counts without prohibitive inventory investment. It fits focused brand/category retailers.

In SAP Commerce this is the model the platform assumes by default: warehouses, stock levels per warehouse, straightforward sourcing.

Consignment: You Hold It, They Own It Until Sold#

Mechanically like deposit (goods in your warehouse, you run the operations) but you do not buy the stock until it sells; the supplier carries inventory risk. Customer experience matches deposit's speed and accuracy because the goods are physically yours to ship. The wrinkle is financial and integration-shaped: the buy-on-sale event must trigger back to the supplier, which is an order-event integration rather than a fulfillment change. Fulfillment-by-Amazon-style services are consignment industrialized (a third party stores, packs, ships, and handles returns for a fee), and integrating one means treating that service as your fulfillment backend through its APIs.

Dropship: The Supplier Ships Direct#

Goods live at the supplier's warehouse and ship directly to the customer. This is the long-tail enabler (no upfront inventory, onboard SKUs cheaply) and the customer-experience minefield, because you do not control the part the customer judges you on. The engineering weight lands here:

• Real-time stock from suppliers is the whole game. Stale supplier stock produces phantom availability and cancelled orders; you need feeds (the integration and hot folders guides) frequent enough to keep the stock service honest, per supplier.
• Order splitting is normal. A multi-item order sources to multiple suppliers and ships as multiple packages from multiple locations at multiple times, which hits delivery cost and customer expectation. Sourcing rules that prefer a single supplier able to fill the whole order (when one exists) reduce split-shipment cost.
• Supplier performance is your performance. Measure out-of-stock rate, return rate, shipping delay per supplier, and restrict or deprioritize poor performers in sourcing. Supplier onboarding includes training them to your fulfillment standard, because the customer blames your brand, not theirs.
• Status tracking requires integration: order state per item comes from the supplier's system or manual entry, and the customer expects to see it.

Cross-Dock: Aggregate, Then Re-Split#

When suppliers cannot dropship per-order (common with wholesalers and manufacturers) but you want to avoid holding deposit stock, cross-dock threads the needle: collect customer orders through the day, aggregate them per supplier at a cutoff, send bulk orders, receive the goods at your warehouse, re-split into customer orders, and ship. Little to no storage, but the slowest model (goods must reach you before reaching the customer) and potentially the highest delivery cost (an extra leg). The order-closing strategy is a real design choice: wait for all items before shipping (slower, fewer packages) versus ship-as-received (faster, more packages), or an algorithm blending both and prioritizing suppliers who can complete whole orders or same-day batches.

The Multi-Model Reality#

Serious estates rarely pick one. The common shape: deposit for top sellers (margin already committed, so sell these first), dropship for the long tail, cross-dock for suppliers who refuse dropship. This is where SAP Commerce's flexibility earns its keep and its complexity bites:

• The stock service abstracts source: whatever the model, availability resolves through per-warehouse (or per-supplier-as-warehouse) stock levels, so the storefront asks one question regardless of the model behind the answer.
• Sourcing strategy is where the models live. SAP Commerce's order sourcing (or SAP Order Management / the OMS you integrate) evaluates configurable rules to pick fulfillment locations: prefer deposit stock (cost already sunk), prefer whole-order fulfillment (reduce splits), respect supplier performance, honor cross-dock cutoffs. A custom SourcingStrategy is the normal deliverable for a multi-model estate, and it encodes the business's priorities as code (the internationalization guide's warning about the out-of-box delivery cost strategy applies to sourcing too: expect to build).
• Per-model workflows must be recognized by the system: an order sourced to a dropship supplier follows a different lifecycle than one sourced to your warehouse, and the process engine (business processes, the events guide) branches accordingly.

Availability as Customer Experience#

Whatever the model mix, availability display is a design surface, not a raw number:

• Show the truth you can back: "in stock", "ships in N days", "available at store X", calibrated to how confidently the underlying model knows. Deposit can promise precisely; dropship should hedge honestly rather than promise and cancel.
• Reserve appropriately: high-demand and peak events (the high-traffic guide) may need soft reservation at add-to-cart or checkout to prevent overselling shared stock, especially where offline channels draw from the same pool (the omnichannel guide's shared-stock case).
• Feed freshness is an SLA: for supplier-dependent models, stock-feed staleness (the integration monitoring guide's freshness principle) directly causes overselling; alert on it like a money-path failure, because it is one.

The Decision Table#

Choose against your business nature, supplier leverage, and growth plan; expect to combine; and design the sourcing strategy and stock feeds as first-class deliverables, because the inventory model you sketched on a whiteboard is, in the end, the most operationally consequential architecture decision in the whole build.