Direct Fulfillment is Amazon Vendor Central’s drop-ship programme: Amazon takes the order from a consumer and you ship it to that consumer yourself. Inside Odoo it behaves nothing like a collection purchase order. The order arrives with a delivery promise already attached, the shipping label comes from Amazon, and the availability figure you publish becomes a commitment.
One account, two different businesses
A Vendor Central account can run two models at once. In the collection model Amazon sends a purchase order, you consolidate a pallet, and a carrier collects it for an Amazon warehouse. In Direct Fulfillment, Amazon sells to a consumer and passes you that consumer’s address to ship to. The documents have similar names. The operational reality is not similar at all.
That matters for an ERP project because teams scope the two together and then discover the second one is a different warehouse process, a different clock and a different definition of what inventory means. If you are still working out how the Amazon side connects at all, the Vendor Central side of our Odoo work covers the document flow end to end, and EDI against a direct API integration is the other decision usually on the table. This page is about the drop-ship half specifically.
The order arrives with a promise already made
In the collection model you acknowledge a purchase order and there is room to negotiate quantities and dates. In Direct Fulfillment a consumer has already been given a delivery expectation before you see anything. You are not confirming what you can supply at your convenience, you are confirming against a commitment somebody else made on your behalf. Acknowledgement, shipment confirmation and tracking all carry windows, and those windows live in your vendor agreement rather than in anything we can usefully quote here.
You ship to a person, not to a warehouse
This is the change that breaks warehouse habits. A residential address, one or two units, retail packaging, and a customer who complains to Amazon rather than to you. Pickers used to building pallets are now picking singles, and the consequence of a mis-pick stops being a receiving discrepancy and becomes a consumer-facing defect.
The label is Amazon’s, not yours
You do not choose the carrier or buy the postage. The label is issued through Amazon, which means your system has to request it, print it, and then confirm the shipment using the tracking that came back. That is a sequencing requirement rather than a preference. A parcel that leaves on your own label is a parcel Amazon cannot see, and an unseen parcel is treated as one that never shipped.
Availability stops being information and becomes a commitment
In the collection model your stock figure informs a purchase order you can still acknowledge downwards. In Direct Fulfillment the availability you publish is what Amazon sells against. An optimistic number does not start a conversation, it produces a cancelled consumer order. This is where drop-ship punishes a business whose stock figures are approximately right, and most businesses’ stock figures are approximately right.
Running drop-ship orders out of a spreadsheet?
Tell us your Odoo version and roughly how many Direct Fulfillment orders a week you handle. We will tell you what the integration would and would not change for you.
Talk to Us About Amazon and OdooWhat this asks of Odoo specifically
Odoo has the parts — sales orders, delivery orders, and a stock figure that can be published — but none of them knows anything about Amazon’s rules. The integration has to carry four things, and they are worth naming separately because teams tend to buy the first and discover the other three.
Orders landing as something a picker can work from
The order has to arrive as a delivery order with the consumer address intact and the Amazon order reference held on the record, so that a query can be answered without logging into a second system. Holding that reference is what makes everything downstream auditable, and it is the cheapest thing on this list to get right.
An availability feed somebody has actually decided
Someone has to choose which Odoo locations count towards the number you publish and whether you hold a buffer. That is a business decision rather than a configuration one, and it is worth making explicitly, because the default of counting everything is exactly how a business oversells.
Labels and confirmation in the right order
Request the label, print it, pack, then confirm with the tracking that came back — all from the Odoo delivery order rather than from a separate browser tab. A confirmation sent before the parcel physically exists is the drop-ship version of the shipment notice problem that drives Vendor Central chargebacks on the collection side.
Invoicing that agrees with what shipped
You invoice Amazon, not the consumer, and the invoice has to match the units that actually went out of the door. Partial shipments and cancellations are where that agreement quietly breaks, and the break shows up as a deduction rather than as an error message.
Where running both models from one Odoo goes wrong
Three recurring ways. The first is one stock figure serving both, so a unit gets promised to a consumer order and also counted towards a pallet you are building. The second is a single picking process, which means singles are handled by a workflow designed for cartons and the packaging standard slips without anyone deciding that it should. The third is reporting: if collection and drop-ship sit in the same bucket you cannot see which of the two is making money, and they are rarely making it equally.
None of that requires a second ERP. It requires the two flows to be distinguishable inside the one you already have — separate operation types, a deliberate location strategy, and a tag that survives all the way into reporting.
What an integration will not fix
It will not make you quicker at picking and it will not make a packaging standard appear. If your defects come from how parcels are physically prepared, software reports the problem and does not solve it — the same is true of the preparation and packaging defect families on the collection side. It will not recover anything already charged. And it will not fix stock accuracy. It will expose it, immediately, in front of consumers.
So if your availability data is unreliable today, a drop-ship integration is the wrong next purchase. Fix counting first, then automate.
Being straight about our own position
We build Amazon integrations for Odoo, including the Vendor Central connector, so we have an obvious interest in you buying one. Two things against that interest. We are an independent provider, not an Amazon partner, and we hold no Amazon certification — anyone implying otherwise is overstating their position. And if your drop-ship volume is small and steady, working it by hand in Amazon’s own interface is a legitimate answer; an integration earns its keep when volume or window pressure makes manual handling the risk rather than the saving. If you sell to consumers directly rather than to Amazon, the Seller Central connector is a different piece of work and the wrong page.
Where to start
Take last month’s Direct Fulfillment orders and answer three questions from your own records. How many were confirmed inside the window. How many were cancelled for availability you thought you had. And how many shipped on a label you requested properly rather than improvised. If you cannot answer those from Odoo today, that gap is the project — and it is usually a smaller project than the team expects, because the hard part is deciding the availability rule rather than writing the integration.