Every Amazon seller has had this moment. Seller Central shows a strong two weeks of sales, the settlement closes, and the deposit that lands in the bank is smaller than anyone expected, or bigger, or arrives a few days later than the date on the statement. Nothing is missing. The money is on a different clock from the sales.
This post walks through the clocks behind one Amazon payout, the three things that move money between settlements (deferred transactions, the account level reserve and refunds), and a checklist for explaining a single deposit line by line.
A single sale touches five different dates before the cash is in your account:
A sales report sorts by the first date. Your bank sorts by the last one. Every gap between "what I sold" and "what I was paid" lives somewhere between them.
Under Amazon's delivery-date-based reserve policy, often called DD+7, the funds from an order are held until seven days after its delivery date. Until then the order appears in the Payments dashboard as a deferred transaction. It has been posted, so it counts in your sales, but it has not been released, so it is not in the payout yet.
That one rule explains most surprises:
The useful number here is not the deposit itself but the deferred balance: what Amazon owes you that has not been released yet. If it keeps climbing, cash is falling behind sales. Watch it before peak season, when it can grow by weeks of revenue.
Separately from deferred orders, Amazon can hold back an account level reserve to cover refunds, A-to-z Guarantee claims and chargebacks that may still come in. In the settlement summary it shows up twice: the previous period's reserve is added back, and a new reserve is subtracted.
So what affects your deposit is the change in the reserve, not its size. A reserve that grows from one period to the next lowers the payout by the difference, and one that shrinks raises it. A new account, a spike in claims or a jump in sales can all push it up.
A refund is booked in the settlement in which it posts, not with the original order. An order paid out in September and refunded in October lowers the October deposit. The same goes for fee corrections Amazon makes after the fact and for reimbursements, which arrive in whatever period Amazon processes them.
If you compare a month of orders with a month of deposits, these lines will always look misplaced. They are not. They belong to the money timeline, not the sales one. For why refunds and physical returns differ again, see Amazon returns vs refunds.
Two more gaps open after the settlement closes:
And if a settlement ends negative, for example after a large refund wave or a big storage fee month, there is nothing to deposit. Amazon carries the negative balance into the next settlement or charges the card on file.
Work from the bank backwards. One deposit at a time is enough to find most problems.
After a few rounds the pattern is usually clear: the deposit follows release dates, the dashboard follows order dates, and the reserve sits on top.
In DataDoe, Amazon's financial events sit in the Settlements & P&L Components table (amazon_settlements_with_cogs), one row per transaction, with these dates:
.svg)
transaction_posted_date matches the date and time column of Amazon's Transaction report. For a deferred order it is earlier than the release.transaction_release_date matches Transaction Release Date.date is the marketplace-local date (Pacific time for the US and Canada). Once a transaction is released it equals the release date; while it is still deferred it is the date of the deferred posting.Two details save time. First, the settlement start, settlement end and deposit timestamps are not columns on this table; they sit in DataDoe's raw finances data and are filled when a settlement report header matches the settlement ID. Second, that deposit timestamp is when Amazon starts the transfer, not when the money reaches the bank, so expect the bank line a few business days later.
Refund rows have settlement_type REFUND and are money events, not warehouse returns. Each cost or fee type has its own column, and expenses are negative. One refund flavour, "Refund Customer Return - Not Received", is not available from Amazon's Finances data, so it will not appear in these rows.
DataDoe does not read your bank account. The bank side of the match stays with you or your accounting system; what DataDoe gives your AI is every Amazon line with its dates, so the Amazon side of the match does not need a spreadsheet.
With DataDoe connected to Claude or another AI client, ask in plain words:
For the structure of the settlement report itself, see Amazon settlement reports: how to reconcile your disbursements. For the fee lines inside it, see the FBA fees breakdown.
Usually because recent orders are still deferred under DD+7, because refunds and fees from earlier orders posted in this period, or because the reserve grew. Sales are counted by order date; the deposit follows release dates.
At the end of each settlement period, which is typically 14 days. The deposit date on the statement is when the transfer starts, and the bank credit follows a few business days later.
No. Deferred transactions are released into a later settlement once the hold ends. If an order is refunded before release, the refund offsets it instead.
An amount Amazon holds back from a payout to cover refunds, claims and chargebacks that may still come in. Each settlement adds back the previous reserve and subtracts a new one, so only the change affects your deposit.