When ERPNext drop shipping fits your sales and stock flow
Drop shipping suits a business that sells items its supplier ships straight to the customer, and that wants the sale, the purchase and the invoicing linked in ERPNext without recording warehouse receipts or deliveries for goods that never sit on your shelves. In ERPNext, the mechanism is a supplier delivery flag on sales order lines. When that flag is set, ERPNext can generate a linked purchase order to the supplier, and both documents can be closed without creating stock movements in your warehouses. This fits catalogues where the supplier holds inventory, where bulky or low-margin items are not worth storing, or where you are testing a range before buying stock. It does not fit items you must control physically, such as those with batch recall exposure or tight quality checks at your own dock, because those controls depend on stock passing through your warehouse.
The decision is really about where your inventory risk and accounting record should sit. If you hold the stock, you need receipts, deliveries, valuation and stock reconciliation working together. If the supplier holds it, the sales and purchase documents carry the economics, and your stock ledger stays clean. Before committing, confirm with your ERPNext version and your own configuration how the supplier delivery flag, the generated purchase order and the closing behavior work, since these details have changed across releases and should be tested on a non-production site. Also confirm how returns, partial shipments and cancelled sales orders will be handled, and who is allowed to set the flag on a sales order line through your roles and permissions.
Plan for the operational gaps that remain. Drop shipments rely on the supplier confirming dispatch and sharing tracking details, which ERPNext will not verify on its own, so decide who records that information and where it lives. Any item you sell both from stock and by drop shipment needs a clear rule for which path applies, otherwise reports on sales and stock will mix the two. Finally, ask your implementation team to confirm the accounting entries your chosen version creates for these flows, so your finance and audit teams can trace revenue, cost and payable amounts before go-live.
Which drop shipping setup fits your catalog and supplier mix
The simplest pattern is an order where every line ships from one supplier. Each sales order line is marked for supplier delivery, and ERPNext generates one linked purchase order that the supplier fulfills directly to the customer. Reconciliation stays manageable because the sales order, purchase order and invoices all point to one counterparty, and closing both documents is a single review.
- Clear document chain: one sales order maps to one purchase order, which simplifies tracing a shipment back to its customer.
- Supplier defaults matter most: default supplier, price list and currency on the item or customer record decide which supplier a line uses, so review them before go-live.
- Fewer split decisions: no order splitting is needed, so users rarely have to choose which lines go where.
- Simple exception handling: a cancelled or short-shipped supplier order affects one purchase order and one sales order.
- Limited consolidation: you cannot combine supplier shipments for the same customer order, so freight and delivery notes come from each supplier separately.
Before committing, confirm with your supplier how they report shipment, whether they send delivery confirmations you need to record, and how they handle returns on drop shipped goods.
Many orders combine items the business ships from its own warehouse with items a supplier ships directly. The sales order carries both kinds of line, and only the drop shipped lines generate purchase orders. The trade-off is that one customer order now produces several downstream documents, and fulfillment, invoicing and closing must be tracked line by line rather than per order.
- Line-level flags: the drop ship marking is set per line, so the warehouse picks and ships only the stock lines.
- Multiple fulfillment paths: delivery notes cover stock lines while the supplier handles the rest, which makes status reporting on the order harder to read at a glance.
- Invoicing timing: decide whether the customer receives one invoice or split invoices, since partial delivery can leave the order in mixed status.
- Order splitting in practice: users must avoid mixing supplier and warehouse lines when they want one shipment, so set clear rules for sales staff.
- Reporting effort: dashboards that count open orders need filters for drop shipped lines or they will misstate warehouse workload.
Test a mixed order end to end with your own items, including a partial cancellation, to see how the documents and statuses behave in your ERPNext version.
Some items are both stocked and drop shipped, for example when your warehouse holds a fraction of demand and a supplier covers the rest. This is the hardest case because the same item can be fulfilled from two sources, and stock balances may look available while being committed elsewhere. You need a rule for which source is used first and how stock levels are read when a drop shipped line is open.
- Source decision: define whether the sales team chooses drop shipping per line or whether a fixed threshold applies, and record the rule in writing.
- Stock availability: reserved or committed quantities can make warehouse balances misleading, so check how reservation and projected stock are displayed.
- Valuation and reconciliation: drop shipped units should never post warehouse stock movements, so confirm that stock ledger entries are absent for those lines.
- Supplier default settings: an item with a default supplier can route every order to that supplier, which may conflict with stock-first fulfillment.
- Replenishment: material requests and reorder rules should exclude demand already covered by a supplier to avoid double ordering.
Illustratively, if an item has 20 units in stock and an order asks for 30, your team must decide who ships the extra 10 and how that split is recorded. Confirm this rule before configuring the item.
Supplier defaults decide how automation behaves, and they carry the most configuration risk when a catalog spans many suppliers. Default supplier on items, supplier-specific item codes and default prices all influence which purchase order is generated. Poorly set defaults can send orders to the wrong supplier or price, and the error surfaces later in invoicing or disputes rather than at order entry.
- Item to supplier mapping: maintain one clear default per item where possible, and document exceptions for alternate suppliers.
- Price and currency alignment: check that supplier price lists match the selling terms, or margins will drift without any single visible error.
- Approval and review: decide whether generated purchase orders need approval before they reach suppliers, which adds a control step.
- Master data ownership: name who maintains supplier defaults, since changes made by purchasing affect sales order behavior too.
- Access control: limit who can change supplier defaults and drop ship flags, as these changes affect financial outcomes.
Ask your implementation partner to walk through your supplier master data with you before setting automation, and confirm how your chosen ERPNext version applies these defaults.
Configuration options and when each one fits
This table compares the main drop ship settings in ERPNext, from the item flag and default supplier to the sales order line and purchase order behavior. Read each row as a decision: when the setting fits your flow and what it changes in the documents that follow.
| Setting | When it fits | What it changes downstream |
|---|---|---|
| Item-level drop ship flag | Products your supplier always ships directly to customers and that you never hold in your own warehouse | Lets sales order lines for this item default to supplier delivery, so staff do not have to set it on every order |
| Default supplier on the item | One supplier fulfils the item, so purchase orders can be generated without choosing a supplier each time | Pre-fills the supplier on the purchase order created from the sales order line, which reduces wrong-supplier orders |
| Supplier delivery on sales order lines | A single order mixes drop shipped and warehouse-fulfilled items, or the flag is not set on the item master | Marks only that line for supplier delivery, so warehouse pick lists and delivery notes skip it |
| Purchase order generation from the sales order | Each drop shipped line should trigger its own supplier order tied to the customer | Creates the linked purchase order, which must be submitted and received through the supplier before the order closes |
| Supplier address and customer shipping address | The supplier ships to the end customer, not to your warehouse | Carries the customer address onto the purchase order so the supplier delivers to the right place. Confirm this with your supplier's process |
| Warehouse settings on the sales order line | Items that never enter stock should not be tied to a warehouse that holds balances | Avoids stock ledger entries for the line, but check how your setup handles the warehouse field before go-live |
| Income and expense account settings | Your accounting differs for drop shipped sales, such as recognizing cost on invoice rather than on delivery | Determines how sales invoices and supplier invoices post, which should be confirmed with your finance team before testing |
How to set up drop shipping in ERPNext
This sequence confirms the ERPNext version and features, configures drop-shipped items and suppliers, and proves that a supplier-delivered sales order creates a linked purchase order with no stock ledger entries. Each step ends with a check you can record before go-live.
Confirm the ERPNext version and features
Your administrator confirms which ERPNext version runs in your environment and checks that it appears on the supported versions list. They then confirm that the supplier delivery option is available on sales order item rows in that version and that buying and selling are both enabled for your company. Check that a test sales order form shows the supplier delivery option on its item rows. Confirm the exact field label with your vendor or partner for your version before you configure anything.
Configure drop-shipped items and suppliers
Set up each drop-shipped item with a default supplier, purchase unit of measure and selling rate. Confirm the supplier record holds the currency, payment terms and address the purchase order will need. Where possible, keep drop-shipped items separate from stocked items so that inventory reports stay easy to read. Check that each item lists the supplier in its supplier table and that the item is not blocked for sales.
Create a test sales order
A user with sales permissions creates a sales order for a test customer and adds one line for a drop-shipped test item. They mark that line as delivered by the supplier and select the supplier. Use test records so no production data is affected. Save and submit the order, then confirm that the line still shows the supplier after submission.
Generate and check the purchase order
From the submitted sales order, a purchasing user creates the purchase order for the supplier-delivered lines. Check the supplier, quantities, rates and the link back to the sales order against the test order. Confirm that the ship-to address is the customer's address, since you should verify whether your version copies it automatically. Confirm that the price matches what you agreed with the supplier. Do not submit a purchase order with a wrong ship-to address or rate.
Confirm no stock ledger entries
Submit the purchase order and any follow-up documents your process requires. Then open the stock ledger and stock balance reports for the test item and warehouse, filtered by the test order and voucher references. Check that no stock ledger entries or stock movements appear for the drop-shipped quantities. If any appear, stop, cancel the test documents in the correct order and review the item's delivery settings before any live use.
Close both documents and record results
After the test cycle, the accounts user records the supplier invoice and the customer invoice. Then the sales order and purchase order are closed or completed using the status options your version provides. Check that both documents show a closed or completed status, that outstanding amounts are zero, and that the stock ledger still has no entries for these quantities. Record the test results and approval before go-live.
Access, pricing and data risks for drop shipped orders
Drop shipping moves supplier pricing and customer addresses into documents that many users can see. The cards below cover the controls that keep those documents scoped, the data that reaches each supplier, and the trail left after both sides close.
Who can create supplier orders
A drop shipped sales order line can generate a purchase order to the supplier, which commits money and sends customer details out of the company. Limit the permission to create purchase orders from sales orders to the roles that handle purchasing, and confirm which roles can submit those purchase orders. Test the setup with a user who holds only sales roles. Confirm the exact role and permission behavior in the ERPNext permissions documentation for your version.
Supplier pricing visibility
The purchase order carries supplier cost, while the sales order carries the price charged to the customer. Sales users who can open purchase documents can see the margin on each line. Decide which roles may view purchase rates, and check whether field-level restrictions in your version can hide supplier cost from sales staff. Confirm this with a test order before go-live.
Customer data sent to suppliers
The supplier usually needs the customer name, delivery address and contact details to ship the goods. Those fields come from the sales order and flow onto the purchase order and any shipping documents. Decide which fields suppliers must receive, and whether your print formats or email templates include more than that. Review a sample purchase order as the supplier would see it.
Supplier portal and email access
If suppliers receive purchase orders by email or through a portal, anyone who can open the link or the mailbox can see customer data for that order. Confirm how outgoing documents are sent, who receives copies, and whether links expire. Limit supplier accounts to their own orders, and document the process for revoking access when a supplier relationship ends.
Audit trail after closing
Closing a drop shipped line leaves the sales order and purchase order in a final state, but the history of edits, cancellations and amendments still matters for disputes and audits. Confirm which versions and change logs ERPNext keeps for submitted and cancelled documents, and who can cancel or amend them. Set a review step for closed drop shipments that compares customer invoice, supplier invoice and delivery confirmation.
Questions buyers ask before setting up drop shipping
How much does drop shipping setup cost with a partner compared with doing it in-house?
The software itself is not the main cost. ERPNext is free to self-host, according to the ERPNext pricing page, so the spend is people time. A partner bills for the written scope: mapping the sales order to purchase order flow, cleaning item and supplier master data, testing, training and handover. That work is usually one-time. Recurring costs appear only if you add support, hosting or a retainer. An in-house build costs staff hours plus the learning curve on the Frappe Framework. To compare fairly, ask each option for the same list: number of suppliers, number of item groups, integrations in scope, test cycles, training sessions and hosting responsibility.
How long does it take to configure drop shipping in ERPNext?
Duration depends on how many suppliers ship directly, how each one confirms and delivers orders, and how clean your item master is. A single supplier with standard items is a far smaller job than a dozen suppliers with different lead times and invoice formats. Existing ERPNext use matters too: if buying, selling and accounting are already live, the work is mostly configuration and testing. If ERPNext is not yet in production, the drop shipping work joins that project. Confirm the version first. According to Frappe's supported versions page, version 15 is supported until the end of 2027 and version 16 until the end of 2029, while version 14 reached end of life on January 31, 2026. Ask the partner for a timeline inside the written scope.
What does our team need to supply before drop shipping setup starts?
The implementation team needs three groups of inputs from you:
- Item master: item codes, units of measure, default supplier for each drop shipped item, standard buying prices and tax templates.
- Supplier terms: supplier master records, price lists, lead times, delivery methods, cancellation rules, return conditions and the invoice format each supplier uses.
- Sample orders: several real orders covering edge cases, such as multi-item orders, partial shipments, cancellations and orders where one line ships from a supplier and another from your warehouse.
The sample orders matter most, because they show how the process actually runs and where your team currently makes manual decisions. Your finance lead should also confirm how supplier invoices are booked.
Can our own team test drop shipping before going live?
Yes, but test on a separate environment that matches your production version and apps. The Docker demo setup in the frappe_docker repository is marked for short-lived evaluation only, so it is not a place to keep test data or build a process. A typical test plan includes: creating a sales order with drop shipped lines, generating the linked purchase order, confirming the supplier, raising the supplier invoice and the customer invoice, and closing both documents. After each step, check that no warehouse stock movement or stock ledger entry was created for those lines. Repeat the test with partial deliveries and cancellations. Record every result so the process can be audited later.
How are returns handled for drop shipped orders?
Returns are the step most teams have not defined before go-live. Goods shipped by a supplier never enter your warehouse, so a return needs a decision on who receives the goods, who issues the credit note to the customer and who credits the supplier. Confirm how your ERPNext version links returns on drop shipped lines to the original sales order and purchase order. Set the rules in writing: whether the supplier collects the goods, whether your team inspects them, and how refunds are approved. Ask the implementation partner to test a full return and a partial return, including the accounting entries, before the process is used with customers.
How do supplier invoices and customer invoices match up for drop shipping?
Each drop shipped line creates two commercial documents: a customer invoice raised from the sales order and a supplier invoice booked against the linked purchase order. Accounts payable and accounts receivable stay separate, and the margin is the difference between the two. Because no stock moves through your warehouse, the valuation side should not change inventory balances. Check these points in testing:
- The supplier invoice matches the purchase order quantity and price.
- Tax on both invoices follows your tax templates.
- Payments to the supplier and receipts from the customer clear the correct documents.
Ask your finance lead to review a sample month-end close with the drop shipped transactions included.
Does drop shipping need custom development, or does standard ERPNext cover it?
Standard ERPNext covers the core flow of marking sales order lines for supplier delivery and generating the linked purchase order. Custom work becomes necessary when you need extra steps, such as sending order data to a supplier portal, importing tracking numbers or matching supplier confirmations automatically. Start with custom fields, print formats and workflow settings, which need no code. Server Scripts can add document-event logic, but according to the Server Script documentation, they are disabled by default from version 15 and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them, so check hosting before you design around scripts.
Who should own drop shipping data and settings after go-live?
Assign one business owner for the process and one technical owner for the ERPNext configuration before go-live. The business owner usually sits in sales or operations and approves supplier onboarding, delivery terms and return rules. The technical owner, whether in-house or a partner, manages item and supplier master data changes, permissions and version upgrades. Write down who can change supplier records and who approves a new drop shipping supplier. If a retainer covers support and upgrades, define its scope in writing, including what happens when a new supplier is added or a process changes.
How DeployOpen scopes and delivers ERPNext drop shipping
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, so drop shipping is configured in your ERPNext environment and not in a shared service. We agree the drop shipping rules, supplier flows and closing checks in writing before build starts, and engagements are fixed-scope.
How we scope
- Map which items, customers and suppliers will use drop shipping, and which stay on warehouse stock
- Confirm the supplier confirmation, shipment and invoicing steps each drop shipped order follows
- Agree in writing the deliverables, timelines and acceptance tests before any build begins
How we build
- Configure drop ship flags on sales order lines and the linked purchase order generation
- Test that closing both documents creates no warehouse stock movements and no stock ledger entries
- Review accounting entries for receivables, payables and cost of goods sold with your finance team
How we hand over
- Deliver written configuration records, test scripts and a runbook for daily drop shipping work
- Train order desk, purchasing and finance staff on the exact sequence for each document
- Document any custom scripts or exported customizations so your team can maintain them
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live
- Re-test drop shipping flows when you upgrade ERPNext or change supplier or pricing rules
- Confirm with your own environment and vendor documentation how each ERPNext release affects these flows
