Why your Amazon payouts never match per order (and how to reconcile the FX gap)
If you sell on a marketplace whose currency differs from your bank’s, you have probably tried to compute, per order, how much you will actually be paid — and found that the numbers never tie out. Here is why, and the reconciliation approach that does tie out to the cent.
The SP-API does not expose a per-order FX rate anywhere, and it is not an oversight:
Orders API (getOrders/getOrder): amounts in the marketplace currency only. No FX, no converted amount.
Finances API (listFinancialEvents / listTransactions): also marketplace/transaction currency only, and no applied FX rate.
Transfers API: gives you the amount actually disbursed — but at the disbursement level, aggregated, not per order.
The reason is that Amazon does not convert per order. When Amazon Currency Converter for Sellers (ACCS) is used, the conversion is applied once to the net disbursement — many orders, fees, refunds and reserves aggregated — at ACCS’s own rate and timing.
If you build your books by applying a spot FX rate to each order, they will never reconcile against your bank deposits. The residual sum(converted_orders) – actual_transfer becomes a moving error you cannot close, because your per-order spot rates were never the rate Amazon used.
Stop reconciling per order. Reconcile per disbursement:
Group every financial event that belongs to a settlement/disbursement, in the marketplace currency, and sum to the net.
Compare against the transferred amount in your bank currency.
net_bank / net_marketplace is the effective blended FX rate for that disbursement.
That single rate ties out exactly, because it is derived from what actually happened, not from an external rate feed.
If you need a per-order figure (for COGS or margin), allocate the blended rate proportionally to each order’s net. It is an allocation, not Amazon’s per-order rate (which does not exist) — but every order rolls up to the deposit you actually received.
This is the same principle behind most Amazon financial reconciliation: the source of truth is the disbursement, not the order. Fees drift between the settlement report and the API, refunds land in different periods than the sale, and FX is applied on the aggregate. Reconcile top-down from the money that hit your bank, and let the residual be your alarm — if sum(matched) != total, something is unclassified, and that residual is usually where unclaimed money hides.
I build reconciliation tooling on the SP-API for exactly these gaps (the approach was acknowledged by Amazon’s SP-API team on issue #5353). If reconciling Amazon payouts is eating your week, my contact is at proficientstack.com. Either way, reconcile by disbursement, not by order — it is the difference between books that close and books that don’t.
The SP-API does not expose a per-order FX rate anywhere, and it is not an oversight:
Orders API (getOrders/getOrder): amounts in the marketplace currency only. No FX, no converted amount.
Finances API (listFinancialEvents / listTransactions): also marketplace/transaction currency only, and no applied FX rate.
Transfers API: gives you the amount actually disbursed — but at the disbursement level, aggregated, not per order.
The reason is that Amazon does not convert per order. When Amazon Currency Converter for Sellers (ACCS) is used, the conversion is applied once to the net disbursement — many orders, fees, refunds and reserves aggregated — at ACCS’s own rate and timing.
If you build your books by applying a spot FX rate to each order, they will never reconcile against your bank deposits. The residual sum(converted_orders) – actual_transfer becomes a moving error you cannot close, because your per-order spot rates were never the rate Amazon used.
Stop reconciling per order. Reconcile per disbursement:
Group every financial event that belongs to a settlement/disbursement, in the marketplace currency, and sum to the net.
Compare against the transferred amount in your bank currency.
net_bank / net_marketplace is the effective blended FX rate for that disbursement.
That single rate ties out exactly, because it is derived from what actually happened, not from an external rate feed.
If you need a per-order figure (for COGS or margin), allocate the blended rate proportionally to each order’s net. It is an allocation, not Amazon’s per-order rate (which does not exist) — but every order rolls up to the deposit you actually received.
This is the same principle behind most Amazon financial reconciliation: the source of truth is the disbursement, not the order. Fees drift between the settlement report and the API, refunds land in different periods than the sale, and FX is applied on the aggregate. Reconcile top-down from the money that hit your bank, and let the residual be your alarm — if sum(matched) != total, something is unclassified, and that residual is usually where unclaimed money hides.
I build reconciliation tooling on the SP-API for exactly these gaps (the approach was acknowledged by Amazon’s SP-API team on issue #5353). If reconciling Amazon payouts is eating your week, my contact is at proficientstack.com. Either way, reconcile by disbursement, not by order — it is the difference between books that close and books that don’t.
Fuente: Artículo original