Every Lazada seller we have worked with in Bangkok eventually hits the same wall. The marketplace dashboard shows one set of numbers, the warehouse team sees another, and finance cannot tie either one to the bank deposit. A Lazada Odoo integration done properly fixes this. It routes every order, stock movement and payout through a single ledger in Odoo, instead of three disconnected spreadsheets.
This post walks through how we actually build these integrations. We cover how we map SKUs, how we keep one stock count across Lazada and offline or Shopee channels, and how we reconcile the fortnightly settlement report against what Odoo expects to receive. For the broader connector work, including Shopee and TikTok Shop, see our Odoo API integration services page.
Why a Lazada Odoo integration has to replace the seller center for accounting
Lazada Seller Center is built for listing management and order fulfillment. It was never designed for accounting or multi-channel inventory. It tells you an order was placed and shipped. It will not tell you whether that sale affected your withholding tax position, your month-end cost of goods sold, or your available stock for a wholesale customer buying the same SKU offline.
Once order data lives in Odoo as a sales order, everything downstream behaves normally. Delivery orders consume stock through standard routes. Invoices follow your VAT and e-Tax Invoice rules. The sale shows up in the same reports as your walk-in and B2B revenue. That consistency is the entire point. Without it, you are running two businesses that happen to share a warehouse.
Lazada Odoo SKU mapping: the step people underestimate
Lazada listings rarely use the SKU codes you already use in Odoo. Sellers often create listing-level SKUs per variant, per bundle, or per promotional set. Those codes multiply fast once a product has several colors or pack sizes.
Our approach on every project:
- Keep Odoo's internal reference as the single source of truth for each product variant.
- Build a mapping table (a simple Odoo model or a field on the product variant) that stores the Lazada SellerSku against the Odoo product_id.
- Handle bundles explicitly. If a Lazada listing sells three Odoo products as one kit, the integration must explode that one marketplace order line into three stock moves, not one.
- Reject unmapped SKUs at the sync step, not silently later. An order with no matching SKU should raise a visible error queue, not disappear into a failed cron log.
This mapping table is the piece most "simple" connectors skip. It is also the piece that breaks first once a catalog grows past a few hundred variants. If your catalog already spans several storefronts, our e-commerce development team can scope the cleanup as its own fixed-price phase before the connector goes live.
One stock ledger across marketplace and offline sales
The second question every merchant asks is some version of this. If I sell the last unit on Lazada five minutes before a shop sale, will the system know? The honest answer depends entirely on sync frequency and whether both channels write to the same Odoo stock location.
We set this up with marketplace orders arriving as sales orders tied to the same warehouse the offline team uses. Odoo's reservation logic then handles the conflict the same way it would for two simultaneous shop orders. First reservation wins, the second backorders. We typically poll Lazada's order API on a short interval, often between two and ten minutes depending on order volume. We do not rely on webhooks alone, because webhook delivery is not always guaranteed. Silent gaps are worse than a short delay.
A genuine limitation here. Near-real-time is not the same as real-time. On a fast-moving flash sale, a two-minute polling window can still allow an oversell if both channels drain the last units inside that window. We mitigate this by holding a small safety buffer in the Lazada channel stock feed rather than exposing 100 percent of on-hand quantity. That costs a little potential revenue. It avoids the cancellation and reputation cost of overselling.
Syncing stock back to Lazada
The sync runs both directions. Orders come in; available quantities go out. We push Odoo's on-hand quantity, minus the safety buffer and minus quantities reserved for other channels, back to Lazada through its stock update API on the same interval as the order pull.
Multi-warehouse setups are where this gets tricky. If a seller fulfills from both a Bangkok warehouse and a Chonburi warehouse, Lazada only wants one number per SKU. We compute that number in Odoo at the product level, summed across the locations actually eligible for Lazada fulfillment. Lazada has no way to interpret raw per-warehouse figures correctly, so we never send them.
Order status and fulfillment flow
The order lifecycle we implement usually looks like this:
| Lazada status | Odoo action |
|---|---|
| Order placed | Create sales order, confirm, reserve stock |
| Ready to ship | Generate delivery order, print Lazada shipping label |
| Shipped | Validate delivery, post stock move |
| Delivered | No Odoo action required (informational) |
| Returned / RTS | Create return, restock if applicable, credit note |
| Cancelled before shipment | Cancel sales order, release reservation |
Cancellations and returns are where custom connectors usually show their age. A return that is not mapped to a proper Odoo credit note and stock-in move will quietly inflate your reported sales. It will also understate your returns rate, which then throws off demand planning for the next purchase order.
Lazada settlement reconciliation: closing the loop with finance
Lazada pays out on a fixed cycle and deducts commission, payment processing fees, shipping subsidies and sometimes penalties before the transfer hits your bank account. The settlement report it provides is detailed. It is not, however, in a format accounting can post directly.
Our reconciliation routine:
- Import the settlement report, CSV or API depending on account tier, into Odoo as a batch linked to a settlement date range.
- Match each settled order line back to its original sales order and invoice.
- Post the commission, logistics fee and any penalty lines as separate expense lines against the same order, not as one lump deduction, so margin reporting per SKU stays accurate.
- Reconcile the net payout against the actual bank statement line using Odoo's bank reconciliation. We follow the same discipline here that we apply to API-driven payment and order flows for other channels, a pattern described on our Odoo consultancy services page.
- Flag any order present in Odoo but missing from the settlement batch, and any settlement line with no matching Odoo order, as exceptions for the finance team to review weekly rather than at month-end.
This last step matters more than it sounds. Marketplace settlement timing rarely lines up cleanly with calendar months. Without a weekly exception check, finance ends up trying to explain a six-week backlog of mismatches during the close. That is exactly when nobody has time for it.
What a Lazada Odoo integration does not solve on its own
A Lazada Odoo integration will not fix a catalog that has duplicate or inconsistent product data. It will not retroactively clean up historical orders that were entered manually before the connector went live. We have seen projects stall for weeks because the SKU cleanup took longer than the integration build itself. Plan for that cleanup as its own phase, with its own fixed scope, rather than folding it into the connector timeline.
If you are running Lazada alongside Shopee, TikTok Shop or a physical store, the same architecture extends to each channel. One Odoo stock ledger, one SKU mapping table per marketplace, and the same reconciliation discipline applied to each settlement cycle. That is the pattern we bring into every API integration engagement, regardless of which marketplace is first on the list. For sellers planning to add their own storefront alongside Lazada, our web development team can scope that build as a separate phase too.
