Odoo and Amazon Marketplace Integration

Native, and Enterprise only

Odoo maintains an Amazon connector itself. Verified against the Odoo 19 source, sale_amazon is present in the Enterprise addons and absent from Community.

That is the first decision. On Enterprise, you have a first-party module maintained by Odoo across versions, which removes the connector-abandonment risk that shapes every Shopify or WooCommerce project. On Community, you are back to a third-party app or a custom build against Amazon's Selling Partner API.

For a business whose Amazon channel is material, that alone can justify the edition, and it is worth pricing against a paid connector plus its maintenance rather than against zero.

What the connector does and does not do

It brings orders in and keeps them in step. Orders arrive as sale orders, customers are created, and fulfilment status flows back to Amazon for merchant-fulfilled items.

What it does not do is run your catalogue. Listing creation, content, images, A+ pages, advertising and pricing strategy stay in Seller Central. Odoo is the back office, not a listing tool, and expecting otherwise is the most common scoping mistake on these projects.

FBA changes who owns stock

This is the structural decision, and it is not a setting so much as a different operating model.

Merchant fulfilled. You hold the stock, Odoo directs the pick and ship, and inventory behaves like any other sales channel. Stock in Odoo is authoritative and Amazon receives availability from it.

Fulfilled by Amazon. The stock physically sits in Amazon's warehouses, and Amazon decides what ships from where. Odoo is now recording events rather than directing them, and its FBA stock figure is a reflection of Amazon's, not a source of truth.

Businesses running both, which is common, need both configurations at once, with FBA inventory in its own location so the two are never mixed in a single availability figure. Getting this wrong produces an availability number that is confidently meaningless.

Settlements are the real work

The single most underestimated part of an Amazon integration is money.

A settlement is not a payment for a batch of orders. It is a period's activity, net of referral fees, fulfilment fees, storage fees, refunds, reimbursements and adjustments, paid on Amazon's schedule. What lands in the bank equals no total that appears anywhere in your sales figures.

The workable approach is to treat the settlement report as the authoritative financial document and model each fee category as a cost, so the reconciliation ties. Trying to reconcile order by order against the bank does not converge, and finance teams new to marketplace selling reliably try it first.

The consequence for reporting is worth stating: revenue minus Amazon's fees is a very different number from revenue, and a margin dashboard that ignores fulfilment and storage fees will be cheerfully wrong.

Multiple marketplaces multiply everything

Selling across several Amazon regions means several currencies, several tax treatments, several settlement streams and possibly several legal entities.

Decide early whether these are one Odoo company or several, because it is expensive to change later, and it determines how VAT registrations, intra-community rules and consolidated reporting work. This is a finance and legal question wearing an integration costume, and it should be answered by the people who own those.

Returns, and the fee that follows

Amazon's returns process is customer friendly by design, which means returns are frequent and largely outside your control.

Model them properly in Odoo rather than as a manual credit note process: the return, the refund, the fee treatment, and whether the item comes back as sellable stock. Volume makes this matter, and a business that handles returns manually at ten a week discovers the problem at a hundred.

Practical notes

Rate limits are real. Amazon's API throttles, and a full sync must respect that. This is a case where batching and backoff are not optional extras, and it is covered generally in integration architecture.

Order data is partly masked. Amazon restricts what customer information you receive, so the partner records created in Odoo are deliberately thin. Do not build processes that assume a full customer profile arrives with the order.

Reconcile counts weekly at first. Orders in Amazon against orders in Odoo, for the same period. A quiet gap is easier to fix at a week old than at a quarter old.