Overselling on Temu is not paid for with an apology: it is paid for in cancellations, in account metrics and in a customer who has already paid. And it almost never happens because the stock count in Odoo is wrong. It happens in between: from the moment a unit sells on one channel to the moment the other channel finds out, there is a window. Everything below is about narrowing that window and knowingly accepting what is left.
Master stock lives in Odoo, not in the channel
The rule is boring and it is the only one that holds: a unit exists in one place, and that place is Odoo. Channels do not hold stock, they receive a published figure. The moment two systems believe they own the same number you get the classic case: Temu subtracts from its copy, your shop subtracts from its own, and between them they offer more units than sit on the shelf. What Temu shows has to be a function of what is available in Odoo, not a value somebody edits by hand in the portal.
Allocating is not subtracting
If you sell the same SKU on Temu, on your own shop and on another marketplace, the question is not how much you have: it is how much you show each of them. Publishing everything everywhere maximises sales and multiplies cancellations; fixed quotas are safe and leave dead units in the channel that does not sell. The sensible answer is usually in between: a minimum quota for fast movers, the full available quantity for anything you hold deep. And if some of those goods sit in a warehouse that is not yours, they have to be counted before you publish them: that is the case with Amazon FBA inside Odoo. Whatever you decide, the policy belongs in Odoo as a readable rule, not in the head of whoever runs the channel.
A fixed quota nobody reviews ages badly. If allocation is not adjusted when turnover changes, you end up with half the shelf reserved for the channel that sells least.
The buffer goes per SKU, not per catalogue
The safety buffer is what you choose not to publish in order to absorb the lag. Set globally — take two units off everything — it is convenient and expensive: on a SKU that sells one a month you have just removed two months of sales, and on a best seller it saves you from nothing. The buffer is calculated per SKU, and per channel where needed: high turnover and a tight shipping deadline ask for more, a slow mover held deep needs none at all. In Odoo that should be a field on the product somebody can look at and change, not a constant buried in the connector's code.
Publish on confirmation, not when the batch is due
This is where most of the real risk sits. If stock syncs hourly, your overselling window is an hour long, and no buffer fixes an hour on a fast mover. The alternative is to publish when stock changes: an order is confirmed, a delivery validated, a receipt posted, and that move triggers an update for that SKU, not for all ten thousand. You still need the full sweep, but as an overnight safety net rather than the main mechanism. It is the difference between pushing changes and waiting your turn, and it is developed in real-time stock for marketplaces.
How long the channel takes to believe you
Publishing is not the same as published. The call can fail, it can queue, it can be accepted and applied minutes later. A serious connector records which figure it sent, when, and what the channel replied; it retries with growing backoff instead of hammering; and it is not satisfied by a 200 if the value left upstream is not the one it sent. Without that log, the day Temu shows seven units and Odoo says zero there is no way to tell which step broke. It is the same cycle seen from the other side as order intake.
When you need none of this
If you sell one-off pieces, or you have few SKUs held deep and a single channel, syncing instantly buys you nothing: a daily sweep and a generous buffer will keep you safe and save you a project. The problem appears when the same unit can sell in two places at once and restocking is slow. If that is not you, do not buy it; and if you are unsure, first count how many out-of-stock cancellations you have had this quarter, because that number is free.
What our connector does
The Temu connector for Odoo pushes stock per SKU, syncs by cron and by webhook, and records Temu's payloads and responses so there is something to audit when the numbers disagree. It publishes the on-hand quantity of the warehouse you assign to each Temu account, or a fixed quantity you maintain on the product yourself. It runs on Odoo 17, 18 and 19, with migration to Odoo 20 the day it ships. Subtracting reservations, keeping a buffer per SKU or splitting stock across channels with your own rules is not included out of the box: that policy is your call, and automating it is custom development. If you sell on more channels, allocation is decided once for all of them: that is in several marketplaces in one Odoo.
Frequently asked questions
How often should stock sync with Temu?
The trigger matters more than the frequency: publish when stock changes and keep a periodic full sweep as a safety net. A long fixed interval is what opens the overselling window.
Do you publish physical stock or available stock?
Available: physical minus what is reserved for orders not yet shipped, minus the buffer. Publishing the physical quantity is the short road to cancelling orders you thought you could ship.
What if I sell the same product on Temu and on my own shop?
Same master stock and an explicit allocation policy. If the shop is Odoo eCommerce there is no allocation to argue about: both sales draw down the same availability at the same instant, which is exactly what you want.
Useful links inside FlexigoTech
What we do about this
Cancelling Temu orders for lack of stock?
Tell us how many SKUs you share across channels, how often you sync today and where the goods physically are. We will tell you whether the problem is the trigger, the buffer or the allocation, and whether what you already have can fix it. Write to comercial@flexigobe.com or book a call.