No production of your own, no warehouse of your own. You buy from your supplier, a logistics provider stores and ships, and you sell. That is a fine model, and for a young brand often the only sensible one. But there is a misconception inside it that only hurts once it is too late: no warehouse of your own does not mean no stock administration. This is what stays in Odoo, what you integrate, and why an integration is rarely your first step.
The warehouse is outsourced, the administration is not
The pallets sit with someone else, the forklift is not yours, and the people picking are not on your payroll. That stock is still yours. It sits on your balance sheet, you bought and paid for it, you will invoice it, and you are responsible for its valuation at year end. When your accountant asks what was in that warehouse on 31 December and what it was worth, “my logistics provider knows” is not an answer.
So you simply run that stock in Odoo, as a location of your own that happens to sit elsewhere. Purchases arrive at that location, sales leave from it, and you see in your own system what you have. That you never touch the goods yourself changes nothing about that.
That sounds obvious, but in practice many young brands only see their stock in their provider’s portal. That works right up until you want to know your margin, or your accountant calls.
The question that shapes your scope
If you are going to integrate, exactly one question needs answering first: what can that partner do, and over which interface? In practice you meet three flavours.
A modern API is the nicest: real time, two-way, well documented. You push orders and pull statuses and stock levels the moment they change.
EDI also appears, especially at partners who work heavily with retail themselves. That is fine, and it has the advantage that the message structure is already fixed.
And then there is the flat file: a CSV dropped on an SFTP a few times a day. Old-fashioned, but it works, and more partners do this than you would expect. The difference sits in how current your data is and in what you have to build to make it reliable.
All three can work. But they differ substantially in build time, in maintenance and in what you have to agree about. That is why this is the question you ask before anyone estimates hours. Anyone estimating a fulfilment integration without knowing which of the three it will be is guessing - and together with your EDI track this often determines the bulk of your scope.
Start with the portal, integrate when it hurts
Here we argue against what you expect to hear from a systems partner. Nearly every fulfilment partner has a portal: you pass orders, you see stock levels, you download a report. At low volume that is fine. An integration is then mostly an invoice.
You integrate at the moment the manual work starts to hurt. You will recognise that moment: daily order counts rise until retyping becomes a day job, errors creep in, or a retailer sets lead-time requirements you simply cannot meet by hand. That is when an integration pays for itself, and not a day earlier.
That is also just good project management. If you have a hard go-live date, the question is not “what do we eventually want” but “what has to stand to be able to ship”. A portal-first approach takes a risky integration off your critical path and moves it to the moment your business pays for it.
The despatch advice does not come from you
There is one place where all of this converges, and it deserves separate attention. Supply a large retailer and they expect an electronic despatch advice - the DESADV - often within a tight window before the truck reaches the delivery location.
That message does not originate with you. It originates with your logistics provider, because they know when a pallet is actually ready and what is on it. You are in the middle: it has to reach the retailer in the right format and on time.
So the message with the tightest deadline in the whole chain is the message a third party creates. That is not a disaster, but it is why the agreements with your fulfilment partner are part of your EDI track rather than something you arrange afterwards. How that triangle works is covered in EDI with a large retailer.
What it costs, and why you want to see it
Fulfilment is almost always priced variably: a rate per order, per order line, per pallet, per storage slot per week. Precisely because it is variable, those costs belong attributed to where they come from.
With analytic accounting in Odoo you attach fulfilment costs to the customer and product group causing them. Then you see that the retailer with the big pallets costs you little per euro of revenue, and that the channel with many small loose orders eats your margin. Without that attribution it stays one logistics lump in your income statement and you only know it was expensive, not what drove it. That is the same reasoning as with promo discounts and annual agreements: costs that belong to your revenue should be visible against that revenue.
In short
Outsourcing fulfilment is sensible, but it outsources your warehouse, not your administration. Run your stock in Odoo as a location of your own that sits elsewhere. Before any estimate, ask what your provider can do - API, EDI or flat file - because that shapes your scope. Start on their portal and integrate when volume demands it, not earlier. Bear in mind that the despatch advice with the tightest deadline originates elsewhere. And attribute your fulfilment costs analytically, so you can see which channel eats your margin.
Selling without your own warehouse and wondering what to integrate? Schedule a no-obligation Quickscan and we will look at your fulfilment partner, your stock administration and what does and does not belong on your critical path.
Read more: EDI with a large retailer · Promo discounts and annual agreements in your P&L · PIM, EDI and customer portal for wholesale · Connect Shopify to Odoo · What does an Odoo implementation cost?