«Amazon orders come into Odoo on their own.» They do. The useful question is a different one: do they come in with everything you need to pick, invoice and reconcile? What breaks is rarely the connection — that shows up immediately — it is the mapping. A badly imported order throws no error: it throws a duplicate delivery in October and a VAT figure that will not reconcile in January.
What an Amazon order carries, and what it does not carry yet
The header carries the order identifier, the purchase date, the status, the channel (FBA or FBM), the marketplace it sold on and the shipping deadline. Lines come separately, with the ASIN, your seller SKU, the quantity, the price, the tax and the shipping charge as distinct amounts, plus promotional discounts. And there is a window in which an order exists but holds nothing useful: while payment is not authorised it sits as pending, its lines without prices or taxes and with no usable address. If your import creates it at that moment, it creates a half-empty order nobody knows how to repair later.
The identifier rules: without it, duplicates
Every order arrives with its Amazon identifier. That number must be stored on the Odoo order and be the first thing you look up before creating anything. If the import creates first and checks afterwards, any retry — a network drop mid-cycle, a cron overlapping the previous run, a manual sync fired while the automatic one was running — leaves you two identical orders and two deliveries. Store the identifier of each line too: it is what lets you recognise an amended line without deleting and rebuilding the whole order.
A detail that looks minor and is not: the check has to rest on a unique index in the database, not only on a prior search in Python. Two processes running at once can both pass the search and both create. It is one of the defects we see most often when auditing connectors somebody else built.
Addresses: they arrive restricted and they have to be deleted
Buyer data does not come with the ordinary read of an order. The shipping address and the contact details are requested separately, under a specific authorisation for restricted data, and the email you get is an Amazon alias that stops working. On top of that you are not allowed to keep them: once the period set by Amazon's data protection policy has passed, personal data is deleted, and only what tax law obliges you to keep stays. In Odoo that has two practical consequences: creating a permanent contact for every buyer is not always a good idea, and you need a purge mechanism somebody designed on purpose, rather than an oversight.
Taxes: in many cases you are not the one collecting them
In a good number of marketplaces it is Amazon that withholds and remits the sales tax, and the order lines can state who is responsible for doing so. If your import always applies the same tax without reading that field, the books go wrong in both possible directions: over-declaring or under-declaring. What you have to set up before the first order is a fiscal position per destination country, a price list per currency and an explicit rule for the case where Amazon is the responsible party. The country-by-country detail is in selling on several Amazons from one Odoo.
Cancellations: reading new orders only is not enough
An order can be cancelled while still pending, in which case it never really became an order. And it can be cancelled after it landed in Odoo and before it left the warehouse: if the sync only knows how to create, the cancellation never arrives and you ship goods nobody will pay for. The import has to re-read orders it already knows within a time window, driven by last-updated date, not just ask for new ones. And if the delivery is already validated, that is no longer a cancellation: it is a return, and it is booked as one.
What our connector does
The Amazon connector for Odoo handles order intake on Odoo 17, 18 and 19, and on Odoo 20 the day it ships: it does not create the sale order while Amazon still holds the order as pending, stores the Amazon identifier under a unique constraint per account and reuses an existing sale order instead of duplicating it, keeps the identifier of every line, fetches the shipping address in a separate call and re-reads orders by last-updated date, so status changes, cancellations included, show up on the sale order. It does not make tax decisions for you: by default the order comes in without taxes, and if you switch on invoicing from Odoo it applies the product's taxes through the fiscal position you configure. If what you have is a connector that already misbehaves, the diagnosis is in common SP-API errors with Odoo — and sometimes the right answer is to fix the one you have rather than buy another.
Frequently asked questions
How often should orders be imported?
Several times an hour is reasonable, but querying by last-updated date rather than pulling the whole history each pass. Amazon's API is rate limited, and a cycle that asks for too much runs out of quota exactly when sales peak.
Can I import historical orders?
Yes, with an initial load bounded by dates. If you already have orders created by hand, write the Amazon identifier onto them before switching the sync on: otherwise the first cycle recreates them.
What about Amazon Business orders?
They arrive flagged as such and come with an expectation of an invoice carrying the buyer's tax details. Separate them from day one: treating them as consumer orders means reissuing invoices later.
Useful links inside FlexigoTech
What we do about this
Orders come in, but nothing reconciles?
Tell us which marketplaces you sell on, whether it is FBA, FBM or both, and what does not add up: duplicates, taxes or cancellations. We look at the mapping before proposing anything. Write to comercial@flexigobe.com or book a call.