In drop shipping, a merchant sells goods it does not stock itself: the order comes in, but the supplier ships directly to the end customer. This preserves capital and warehouse space, yet it moves the critical question into the interface: is the item available at the supplier at all, at what price and with what lead time? The scale is clear from B2B trade: online B2B trade by wholesalers and manufacturers via online shops and marketplaces grew 7 percent to 509 billion euro in 2024 (IFH Cologne), and marketplaces now account for 56 percent of e-commerce revenue in goods (bevh). This article shows how drop shipping runs cleanly when the ERP remains the leading system: reading supplier feeds via EDI, CSV/SFTP or REST API, mirroring availability and lead time into the shop, automatically splitting orders by supplier and returning tracking. We orchestrate such multi-supplier flows via a middleware so that drop-ship and stock goods converge in one process without double maintenance.
Key takeaways
- Drop shipping stands or falls with reliable supplier feeds: stock, price and lead time have to arrive automatically, not as a manually maintained list.
- Suppliers deliver in different formats -- EDIFACT, CSV over SFTP or REST API. A middleware normalizes these formats onto a common data model.
- Availability and lead time belong mirrored per supplier into the shop so that customers do not order what has long been out of stock at the supplier.
- Incoming orders are split by supplier and placed automatically; shipping confirmation, tracking and goods-receipt messages flow back into shop and ERP.
- Stock and drop-ship goods need a clear separation in the data model so that one order and inventory process maps both procurement paths without contradiction.
Why Drop Shipping Is Gaining Importance in 2026
In wholesale, drop shipping is not a fringe phenomenon but is professionalizing as a margin-friendly alternative to holding your own stock. Anyone offering a broad assortment without stocking every item cuts tied-up capital and inventory risk and extends the range beyond their own warehouse capacity. The market provides the tailwind: total B2B e-commerce by wholesalers and manufacturers stood at over 1.5 trillion euro in 2024, of which 509 billion euro ran via online shops and marketplaces (IFH Cologne). For B2C online retail, the trade association raised its 2025 forecast to 92.4 billion euro, up 4 percent on the previous year's 88.8 billion euro (HDE).
At the same time, weight is shifting toward platforms and assortment breadth. Marketplaces account for 57 percent of online retail revenue according to the trade association (HDE); the bevh puts their share of e-commerce in goods at 56 percent, or 46.2 billion euro (bevh). Anyone wanting to compete on platforms and in their own shop with a broad range can hardly avoid drop-ship goods -- and therefore the question of how supplier data reaches the sales channel reliably and up to date. This is exactly where professional drop shipping separates from the makeshift solution: not in the idea, but in the interface.
Drop shipping is a data problem, not a logistics problem
Reading Supplier Feeds: EDI, CSV/SFTP and REST API
Suppliers provide stock and price data in very different ways. Large distributors often run classic EDI with EDIFACT messages such as PRICAT for price and catalog data or INVRPT for inventory reports; mid-sized providers drop a CSV file via SFTP, usually nightly; modern providers offer a REST API through which availability can be queried in near real time. For multi-supplier operation this means a shop has to handle several channels at once without building a separate island for each supplier. The classic variant is covered in depth in our article on EDI integration with EDIFACT.
| Channel | Typical for | Timeliness | Characteristic |
|---|---|---|---|
| EDI / EDIFACT | Large distributors, industry | Batch to near-event | Standardized (PRICAT, INVRPT), but format-strict |
| CSV over SFTP | Mid-market, classic wholesale | Usually nightly | Simple, but without schema guarantee |
| REST API | Platform-oriented, modern providers | Near real time | Flexible, with rate limits and auth |
| Punchout / OCI | Procurement-oriented catalogs | Interactive | Catalog at the supplier, cart returned |
None of these channels is inherently better. What matters is that the middleware can read all of them and map them onto a common data model, instead of tying the integration to the weakest format. A supplier with a nightly CSV delivers a daily snapshot, an API supplier a near-current view -- and both realities have to arrive correctly in the shop as lead time and availability. The demand on timeliness rises with the assortment: anyone carrying fast-moving items in drop shipping needs more frequent feeds than someone selling long-lived C-parts.
Tie feed frequency to turnover speed
Data Quality and Mapping Across Supplier Formats
The most demanding part of drop shipping is rarely the connection but the translation. Every supplier names fields differently, measures in different units and defines stock in its own way. Without consistent mapping, two feeds run past each other and the shop shows contradictory information. How heterogeneous sources are mapped onto a uniform model is covered in detail in our article on data mapping between ERP and shop. The following six fields are the most common stumbling blocks (project experience).
Article-number mapping
Supplier article number, own article number, EAN and manufacturer number have to be linked unambiguously -- otherwise the wrong item is ordered from the supplier.
Units and quantities
Packaging unit, minimum order quantity and tiering vary per supplier. A feed in bundles has to be converted to the sales unit in the shop.
Pricing logic
Purchase price, tiered prices, surcharges and currency arrive differently. The sales price is formed from them in the ERP, not in the feed.
Stock definition
Is the reported stock freely available, reserved or including inbound? The same figure means something different per supplier and has to be normalized.
Timestamp and time zone
A nightly feed is a snapshot with a timestamp. Without a clean time reference, stale stock wrongly looks current.
Categories and attributes
Classification, attributes and descriptions follow each supplier's own schema and have to be mapped onto the shop's categories and product-data pipeline.
One data model, many suppliers
Data quality is not an end in itself. Insufficient product information is among the reasons purchases are abandoned; the average cart abandonment rate stands at around 70 percent (Baymard Institute). If stock, lead time or price in the shop are wrong, it costs conversion and produces rework. The effort of mapping supplier data cleanly therefore pays off directly in sales -- all the more since the average order value in e-commerce for 2025 is given as 146.19 euro (bevh) and every avoidable cancellation costs a real contribution margin.
Mirroring Availability and Lead Time per Supplier
Once the feeds arrive normalized, the shop has to make the right statement: is the item available, and when will it arrive? For drop-ship goods, the lead time combines the supplier's processing time and shipping -- it differs from stock goods, which ship immediately from your own warehouse. This difference belongs transparently in the shop, not in a blanket default. How to keep stock consistent across several sources is shown in our article on inventory synchronization across multiple warehouses.
- Normalize stock: From the supplier feed, the freely available stock is derived -- cleaned of reservations and defined uniformly per supplier.
- Calculate lead time: The supplier's processing time plus shipping duration yields the drop-ship lead time the shop shows per item and supplier.
- Buffer and thresholds: A small safety deduction on scarce stock prevents the last reported unit from being sold twice.
- Assess feed age: If the feed is too old, the item is shown more conservatively or set to on request instead of showing stale availability.
- Display in the shop: Customers see availability and a realistic lead time per supplier -- not a flattering blanket figure for the whole assortment.
Missing stock is the norm, not the exception
These failure patterns are not a niche topic but everyday reality in multi-supplier operation. Robust interfaces treat missing or faulty data as the rule, not as a disruption -- the principles are explored in our article on error handling in interfaces. For the customer, what counts in the end is that the shop's promise holds: a high e-commerce customer satisfaction of 96.2 percent (bevh) also comes from availability and lead time being reliably correct.
Automatically Splitting Orders by Supplier
In drop shipping, a cart often contains items from several suppliers, partly mixed with your own stock goods. When the order comes in, it has to be broken down by supplier and placed automatically -- each partial order to the responsible supplier, each stock line to your own warehouse. This breakdown belongs in the middleware, because the shop should not know the procurement logic and the ERP as the leading system maps the order cleanly. The basic pattern is manageable:
def split_order(order, catalog):
groups = {}
for line in order.lines:
item = catalog.lookup(line.sku)
# Source per line: own warehouse or supplier
if item.source == 'stock':
key = 'WAREHOUSE'
else:
key = item.supplier_id # drop-ship supplier
groups.setdefault(key, []).append(line)
purchase_orders = []
for key, lines in groups.items():
if key == 'WAREHOUSE':
purchase_orders.append(pick_from_stock(lines))
else:
po = build_supplier_po(key, lines) # per supplier
purchase_orders.append(po)
return purchase_orders # to the ERP for confirmationIt is important that the split stays traceable: each customer order has one or more supplier orders linked as belonging together. Only then can partial deliveries, tracking and invoices be assigned correctly later. The ERP carries the order, the prices and the procurement; the middleware orchestrates the flow and hands over to the leading system instead of building a second order engine in the shop.
- Grouping by source: Each line is assigned to its source -- your own warehouse or a specific drop-ship supplier.
- Preserve the link: Customer order and all derived supplier orders stay referenced so that status and tracking remain unambiguous.
- Respect minimum quantities: Tiering and minimum order quantity per supplier feed into the partial order before it is placed.
- Ensure idempotency: Reprocessing the same order must not trigger a duplicate placement.
- Hand over to the ERP: The partial orders run into the ERP, which carries the order, purchase price and posting.
Returning Tracking and Goods-Receipt Messages
The flow does not end with placement. The supplier confirms the shipment, provides a tracking number and reports what was actually shipped. These responses have to find their way back into shop and ERP so that the customer receives tracking and the order counts as fulfilled correctly. Without this return, the drop-ship order stays open in the system even though the goods are long since with the customer. The return shares its technical patterns with other logistics processes, as our article on shipping and logistics interfaces shows.
Shipping confirmation and tracking
The supplier's tracking number is assigned to the customer order and provided to the customer -- per partial shipment when several suppliers are involved.
Mapping partial deliveries
If a supplier ships only part, the order stays partially open. The status per line reflects exactly what is already on the way and what is still outstanding.
Goods-receipt message
The message of what was actually shipped or posted as goods receipt flows back into the ERP -- the basis for invoice, inventory management and reconciliation.
Drop shipping is only automated when not only the order goes out but tracking and goods receipt come back. The return closes the loop that placement opened.
Cleanly Separating Stock and Drop-Ship Goods
A shop rarely carries pure drop-ship goods. Usually, own stock articles and drop-ship articles mix, and some articles are even obtainable from both sources. For one order and inventory process to map both paths without contradiction, the data model needs a clear marking of the source per article and per line. The separation is not a cosmetic detail but decides availability, lead time and placement in the order split.
| Attribute | Stock goods | Drop-ship goods |
|---|---|---|
| Stock source | Own warehouse in the ERP | Supplier feed (EDI/CSV/API) |
| Lead time | Immediately from warehouse | Supplier processing plus shipping |
| Placement | Picking in your own warehouse | Order with the drop-ship supplier |
| Updating | Real time from the ERP | Supplier's feed frequency |
| Return flow | Own carrier | Supplier's tracking and GR message |
If an article is obtainable from both sources, a defined rule decides the path -- for example, priority for your own stock while available, otherwise drop-ship. This logic belongs in the leading system and the middleware, not in a per-order decision. The basis remains a consistent master-data foundation, as described in our article on master data synchronization with MDM: only when articles, prices and sources are managed centrally does the separation of stock and drop-ship goods stay robust.
Tax and returns apply to drop-ship goods too
Error Handling and Implementation as a Middleware
Introducing automated drop shipping follows a manageable sequence. The decisive factor is capturing the suppliers and their formats early and planning for error handling from the start -- because in multi-supplier operation the question is not whether a feed fails, but when. According to IFH Cologne, online B2B trade is expected to grow a further 6.3 percent in 2025 (IFH Cologne); anyone automating drop-ship goods cleanly can capture that growth without proportionally growing manual work.
From supplier onboarding to a productive drop-ship process
- 1
Capture suppliers and formats
Document per supplier the channel (EDI, CSV/SFTP, REST API), frequency, field structure and stock definition -- the basis for the mapping.
- 2
Define a canonical data model
Set a common model for article, stock, price and lead time onto which each supplier is mapped via its own mapping.
- 3
Build feeds and mapping
Develop connectors per channel, normalization of formats and the mirroring of availability and lead time into the shop.
- 4
Order split and return flow
Implement automatic splitting by supplier, handover to the ERP and the return of tracking and goods-receipt messages.
- 5
Test, failure behaviour, go-live
Test with real feeds, calibrate failure and edge cases, and start production with monitoring of feed freshness and error rates.
Projects reveal recurring mistakes that can be avoided with a little foresight (project experience). Planning for them prevents wrong availability, duplicate placements and open orders in live operation.
- One feed as the single truth: Without a timestamp and a failure rule, stale stock wrongly counts as current.
- Missing article-number mapping: If the wrong supplier article number is ordered, the wrong item reaches the customer.
- No separation of stock and drop-ship goods: If the sources mix, the order split becomes unreliable.
- Forgotten return flow: Without tracking and goods-receipt messages, orders stay open even though the goods are delivered.
- No idempotency: Reprocessed orders trigger duplicate placements with the supplier.
- Feed frequency too coarse: Fast-moving items with a feed that is too infrequent lead to sales without cover by real stock.
We build this orchestration as a middleware that reads several supplier channels, normalizes them onto a data model and brings drop-ship and stock goods together in one order and inventory process. Which channels, formats and frequencies suit your assortment is something we clarify as part of our services around ERP and shop integration.
Sources and studies