How Often Does Amazon Pay Sellers? Timing and Cash Flow
Amazon’s settlement schedule is only part of the payment timeline. Learn how reserves, transfer options, and cross-border banking determine when seller proceeds become usable cash.
Amazon generally settles marketplace seller accounts every two weeks, then transfers the available positive balance to the bank account on file. According to Amazon’s seller payments guide, funds can take up to five business days to appear in your bank account after Amazon initiates payment.
That does not mean every sale reaches your bank within two weeks. Delivery-based reserves, refunds, fees, account restrictions, and your account’s disbursement settings can change when proceeds become available.
For finance teams funding inventory, suppliers, or international contractors from Amazon revenue, the important distinction is sales recorded versus funds available versus cash received. This guide covers third-party marketplace sellers—not Amazon Pay merchant processing or wholesale suppliers operating under Vendor Central terms.
Amazon’s payment schedule has separate stages
A settlement date is not a guaranteed bank-credit date. Treat the payment process as a sequence, with a separate status and owner for each stage.
| Stage | What happens | Cash-planning implication |
|---|---|---|
| Order and delivery | The order is fulfilled and delivery is recorded | Revenue is not yet spendable cash |
| Reserve period | Proceeds remain deferred under applicable rules | Forecast release separately from sales |
| Available balance | Eligible proceeds remain after deductions and holds | Use this balance to estimate the next transfer |
| Disbursement | Amazon initiates the bank transfer | Record the transfer reference and initiation date |
| Bank credit | The receiving bank credits the funds | Confirm usable cash before releasing dependent payments |
The general two-week cadence is a starting point, not a substitute for your account’s payment information. Check Seller Central for the next scheduled disbursement, available balance, deferred transactions, and transfer status.
Do not assume that choosing an Individual or Professional selling plan alone guarantees a particular payment frequency. Community reports describe account-specific differences, but they are not a reliable basis for promising a weekly deposit.
How the DD+7 reserve affects when sellers get paid
DD+7 means delivery date plus seven days. Under this delivery-date-based reserve approach, proceeds generally remain deferred until seven calendar days after delivery before becoming eligible for disbursement, subject to other account conditions.
Riverbend Consulting’s DD+7 analysis describes the reserve mechanism and its cash-flow implications. Secondary reporting identifies March 12, 2026, as a migration date for affected legacy accounts in the US and Canada; it should not be read as the date every Amazon seller worldwide first entered DD+7. Many sellers already operated under delivery-based reserves.
Because public summaries do not establish every account’s terms, verify your applicable policy and any migration notice in Seller Central. Avoid treating a rollout headline as an account-specific payment commitment.
Delivery timing matters more than the order date
For delivery-based reserves, placing or shipping an order does not necessarily start the release clock. Carrier delivery confirmation matters. Where Amazon uses an estimated delivery date instead, that date can affect the expected release.
This is particularly important for merchant-fulfilled orders with long transit times or missing tracking events. Fulfillment by Amazon does not, by itself, mean proceeds are immediately available.
Also distinguish deferred order proceeds from other account-level holds. Refunds, chargebacks, claims, or account reviews can affect the amount available even after an ordinary delivery-based reserve period has elapsed.
Hypothetical example: eligible is not the same as paid
Assume an order is delivered on October 1 and is subject to DD+7. Its proceeds would ordinarily become eligible on or after October 8, provided no other restriction applies.
If the account’s scheduled disbursement occurs before those proceeds become available, they may miss that transfer. They would then wait for a later scheduled disbursement or an eligible manual transfer request. Bank processing follows initiation.
This example illustrates the sequence, not a promised deposit date. Adding seven calendar days to delivery does not tell you when cash will reach the bank.
Why the payout is smaller than the sales balance
Amazon transfers an available net balance, not gross sales. Its settlement calculation accounts for the opening balance, sales, expenses, refunds, and amounts withheld in reserve.
For reconciliation, separate these categories rather than labeling every difference a “payment delay”:
- Fees and expenses: deductions that reduce the amount payable.
- Refunds and adjustments: changes to previously recorded sales or balances.
- Deferred proceeds and reserves: money not yet eligible for release.
- Transfers in transit: money already disbursed but not yet credited by the bank.
A larger sales week can therefore coexist with a smaller bank deposit. The deposit may relate to older eligible orders, while recent sales remain deferred.
Can Amazon sellers get paid faster?
Some accounts have a Request Transfer option, and eligible US sellers may have access to Express Payout. The Seller Assistant payment-schedule guide describes these alternatives. Availability and current terms should be checked in your own account.
These options address different parts of the timeline:
- Request Transfer: may let an eligible seller initiate a disbursement of available funds without waiting for the next automatic payment.
- Express Payout: can shorten the bank-delivery stage for eligible sellers and supported bank accounts.
Neither should be treated as a way to unlock reserved proceeds. Faster bank delivery cannot make an undelivered order eligible, remove a claim-related hold, or turn a negative balance into a payout.
Before changing your cash forecast, confirm eligibility, supported receiving accounts, current fees, transfer limits, and the expected delivery time displayed by Amazon. Do not extend US-specific accelerated-payment terms to other jurisdictions.
What changes for international sellers?
Cross-border sellers have another decision: the currency in which proceeds arrive. Amazon Currency Converter for Sellers lets eligible sellers receive converted proceeds in supported local currencies. Supported stores, currencies, and pricing depend on the program’s current terms.
Keep conversion economics separate from payment timing. A faster deposit is not necessarily a better outcome if the conversion route increases the cost of funding your suppliers.
For each marketplace, record:
- The sales currency and intended receiving currency.
- The receiving account’s country, ownership details, and supported currency.
- The conversion amount, applied rate, and disclosed charges.
- The final amount credited and the bank-credit date.
If you collect and spend in the same currency, investigate whether an eligible same-currency receiving setup can avoid unnecessary conversion. Confirm Amazon’s acceptance requirements before changing deposit details; a multi-currency account is not automatically an approved Amazon receiving account.
Payouts.com’s Global Accounts can support broader multi-currency collection and holding workflows. Evaluate marketplace compatibility separately from the account’s treasury value.
There is also a second payment journey after Amazon’s deposit: paying your own overseas recipients. Build that transfer window separately, using the principles in our guide to payout settlement times by country. An incoming Amazon disbursement does not guarantee a supplier receives money that same day.
A practical checklist for forecasting Amazon-funded payments
The strongest control is to maintain separate forecasts for expected reserve releases, expected disbursements, and expected bank credits. Do not collapse them into one “Amazon payment date.”
- Confirm the account terms. Record the applicable reserve policy, automatic schedule, and available transfer options for each marketplace.
- Group deferred proceeds by expected release date. Use delivery information rather than applying one delay to all orders.
- Bridge gross sales to available funds. Reconcile fees, refunds, adjustments, and reserves without double-counting amounts already reflected in Amazon’s available balance.
- Track each initiated transfer. Retain its reference, currency, amount, receiving account, and expected bank-credit date.
- Investigate the correct stage. Deferred funds require a reserve or delivery check; a failed transfer requires a receiving-account check; an initiated transfer beyond the expected window requires tracing.
- Compare incoming cash with committed outflows. Flag supplier due dates that fall before a conservative bank-credit estimate. Arrange a funding buffer rather than relying on early arrival.
- Release dependent payments against confirmed liquidity. Keep payment approval separate from funding availability.
For larger vendor and contractor programs, Payouts Automation can support the downstream payment workflow. It does not change Amazon’s reserve policy or accelerate Amazon’s release of seller funds.
The bottom line
Amazon generally settles seller accounts every two weeks, but your usable-cash date depends on reserve release, account-specific disbursement settings, and bank processing. International sellers must also account for receiving-currency choices and any onward payment journey.
Start with Seller Central: identify what is deferred, what is available, and what has actually been sent. Then forecast supplier payments from expected bank credit—not from the order date or gross sales dashboard.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
39 commentsRelated resources
Payout Settlement Times by Country: Build Reliable Payment ETAs
An instant domestic rail does not make an international payout instant. Use this country reference and operating framework to set payment ETAs that account for funding, calendars, and recipient-bank availability.
Virtual Cards for Supplier Payments: From Acceptance to Reconciliation
Virtual cards can connect approved invoices to controlled payments, but supplier acceptance and settlement need their own operating rules. Here is how finance teams can evaluate the economics and manage the full payment lifecycle.
ACH Wire Transfer Time: A Cutoff and Escalation Playbook
ACH and wires run on different clocks. Learn how to set release deadlines, identify where a payment is waiting, and decide whether an urgent replacement is safe.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The reserve period stage in the table is exactly why we stopped using Amazon proceeds as a direct input for supplier payments. We now treat it like a T+14 minimum, flag anything still in reserve separately, and only release internal payment approvals once the bank credit line actually shows up. Learned that the hard way after a missed net-30 deadline turned into a net-60 with penalty fees.
We went with T+17 instead after tracking a quarter's worth of settlements. The extra three days account for bank processing variance and the occasional disbursement that falls right after a reserve period expires, pushing everything to the next cycle.
We did the same after getting burned twice in the same month. The T+14 minimum assumption is conservative but necessary. Do you also separate FBA from merchant-fulfilled in your flagging, or treat all Amazon reserves the same?
The section on delivery-date reserves is good but it doesn't address what happens when you have a mix of FBA and merchant-fulfilled inventory in the same account. Do those reserve periods run in parallel or does Amazon apply the longer hold to everything until the account settles?
They run in parallel. Each order has its own DD+7 clock that starts from its delivery confirmation, regardless of fulfillment method. The account-level disbursement just sweeps up whatever has become eligible across all orders by that settlement date. The confusion usually comes from looking at the total available balance instead of tracking individual order release dates.
They run in parallel. Each order has its own DD+7 clock that starts from its delivery confirmation, regardless of fulfillment method. The issue is that Amazon calculates your available balance at the account level, so if you have claim holds or account-level reserves, those can block everything even if individual FBA orders are past their seven days.
The article points out that Request Transfer and Express Payout don't unlock reserved proceeds, which is true, but it would be helpful to know whether Request Transfer at least lets you pull the available balance mid-cycle without waiting for the biweekly cadence. We've had situations where eligible funds were sitting in the account for days while we waited for the next automatic disbursement, and if Request Transfer actually works for that it could smooth out some of the working capital lumps.
Yes, Request Transfer pulls whatever balance is already in the Available column, so if you have eligible proceeds sitting there mid-cycle you can initiate the disbursement early instead of waiting until the automatic settlement date. The main catch is that it doesn't change the bank-credit timing, so you still have to budget for the transfer and receiving-bank delay after initiation.
Yes, Request Transfer pulls whatever balance is already in the Available column, so if you have eligible funds sitting there mid-cycle it can definitely help with short-term liquidity gaps. The catch is you're still constrained by the same bank-processing window, so you're really just controlling the initiation date, not the end-to-end timeline.
The Riverbend Consulting reference for DD+7 is useful, but I'm surprised the article doesn't walk through how to actually adjust your AP automation system to account for the disbursement-to-credit lag when you're paying vendors on tight terms. We had to build a separate Amazon-specific cash buffer into our sweep logic because assuming 'two weeks' caused three missed wire windows in Q1.
We did the same thing. Built a three-day cushion specifically for Amazon deposits and excluded them from our general working capital calculations. The alternative was constantly explaining to vendors why a 'scheduled payment' kept sliding two days later than promised.
We ended up doing the same thing with a separate buffer account. The real problem is that your AP system doesn't natively know the difference between a regular ACH and an Amazon disbursement that might still be five business days out after initiation. We just hard-coded a seven-day offset for any inbound tagged as Amazon settlement and that solved most of the timing mismatches.
The staged sequence breakdown is helpful but I still don't see how this plays with foreign exchange timing if you're a Canadian seller getting paid in USD and then converting to CAD for supplier payments. Does the DD+7 clock start from carrier confirmation in the destination country or when Amazon records it in their system?
DD+7 starts from delivery confirmation in the destination country, but the FX timing is a separate problem. Amazon disburses in the currency your bank account is registered in, so if you're receiving USD to a USD account, the conversion to CAD happens at your bank when you initiate the transfer, not during Amazon's settlement. That means you're eating spot rate risk between when proceeds become eligible and when you actually convert and pay suppliers.
DD+7 starts from delivery confirmation in the destination country, but the FX timing is a separate layer you control. Amazon disburses USD to your USD receiving account, then you decide when to convert. If you're converting immediately on receipt, you're adding 5+ days of bank transfer time plus whatever your FX provider needs. We started holding a small USD buffer specifically for this reason so supplier payments aren't waiting on both Amazon's timeline and conversion settlement.
The layered sequence table is the clearest breakdown I've seen of why Amazon proceeds don't behave like typical AR. We finally stopped treating the settlement date as a deposit date after missing two payroll runs last quarter, now we forecast from bank credit backward and add buffer days for every stage including the reserve window.
We did something similar after a close call with a wire deadline. Now we assume five full business days after the disbursement date shows in Seller Central, and we only count the available balance minus any recent refund activity from the last 72 hours. Overcautious maybe, but it's cheaper than emergency bridge financing.
We did something similar after a close call with a wire deadline. Now we assume five full business days from disbursement initiation to usable funds, and we flag any transfer over $50K for manual confirmation before we commit downstream payments. The buffer cost us some supplier early-pay discounts at first, but it beats explaining a missed payroll.
The part about refunds and chargebacks affecting your available balance even after DD+7 elapses is something we learned the hard way. We had three weeks where the settlement amount was way lower than expected because a batch of returns from Prime Day finally processed, and those deductions hit accounts that were otherwise clean through the reserve period. Now we track open return windows separately and assume 2-3% of gross sales stay locked until that window closes.
We had a similar situation but with A-to-Z claims instead of returns. The reserve released on schedule, but then account-level holds from unrelated claims reduced the available balance by almost 40%. Now we track claim activity separately and adjust our next-disbursement estimate before it goes into the cash position.
We saw the same pattern after holiday returns spiked. The worst part is those refunds don't just reduce the current settlement—they can push your available balance negative and delay the next disbursement entirely if you don't maintain enough buffer from newer orders.
The point about 'eligible is not the same as paid' finally explains why our Q4 cash forecast was off by almost two weeks. We were tracking delivery dates and adding seven days, but completely ignored where those proceeds fell relative to the actual disbursement schedule. Now we map eligible dates against Amazon's calendar and flag anything that might roll to the next cycle.
We had the same realization after missing a supplier payment deadline. The real issue is that Amazon's disbursement schedule doesn't care about your reserve release timing, so you can have cash sitting eligible for days until the next automatic transfer window opens.
We did the same thing and ended up building a quick script that pulls the disbursement schedule from Seller Central daily and flags which eligible buckets actually make it into the next transfer window. The gap between eligibility and actual disbursement is where most of our variance was hiding.
The 'hypothetical example' section is good but it glosses over what happens when your next scheduled disbursement is 10 days out and you've got a supplier payment due in 5. Request Transfer eligibility isn't automatic and the article doesn't clarify what triggers account-level approval for that feature.
Request Transfer eligibility seems to be tied to account health metrics and sales history, but Amazon doesn't publish the exact thresholds. We've had it available on one seller account for over a year but still don't have access on another account with similar volume, so it's not purely revenue-based.
Request Transfer eligibility seems to be tied to account health metrics and sales history, but Amazon doesn't publish the exact thresholds. We had to wait about 90 days after onboarding before the option even appeared, and it disappeared temporarily during a policy dispute even though our balance was positive.
The DD+7 reserve section is helpful but I wish the article showed how to model this in a 13-week cash forecast when you have multiple SKUs with different ship-to-delivery windows. Right now we're just adding 21 days to order date as a blended assumption which feels sloppy but tracking every delivery confirmation manually isn't realistic either.
We do something similar but bucket SKUs into three cohorts: same-day/next-day, standard (2-5 days), and slow movers that usually take 7+ days. Then we apply DD+7 plus the cohort average plus 5 bank days. Still not perfect but way more manageable than line-item tracking and gets us within a few days on most weeks.
We ended up building a simple lookup table that maps each SKU to its historical median delivery window, then feeding that into our cash model. It's not perfect but it gets us closer than a flat 21-day assumption. The real problem is when Amazon uses an estimated delivery date instead of actual confirmation—those outliers still mess up the forecast.
Interesting that you call out merchant-fulfilled orders with missing tracking events. We had a nightmare quarter where our 3PL wasn't uploading carrier scans consistently and it took us weeks to figure out why disbursements were lower than expected even though everything had shipped. Amazon was holding those proceeds indefinitely because there was no delivery confirmation trigger.
We had the exact same issue with a regional carrier that didn't integrate properly with Amazon's tracking system. What finally helped was switching to a 3PL that auto-validates tracking uploads daily and alerts us to any gaps before the settlement period closes.
This is why we now require proof of carrier delivery confirmation before we release the next batch to our 3PL. The tracking upload gap cost us almost 40 days of working capital before we traced it back to their ops team not scanning at pickup.
Does anyone know if Express Payout actually moves the needle enough to justify the fee? We've been looking at it for our US account but if it only shaves a day or two off the bank-credit stage and everything is still stuck behind the seven-day delivery hold anyway, I'm not sure it solves our real problem.
We tested it for three months last year and honestly, you're right about the real bottleneck. Express Payout got us funds maybe 36 hours sooner on average, but when most of our revenue is sitting in DD+7 reserves anyway, it didn't change our working capital position enough to matter. Only makes sense if you're trying to catch a specific payment deadline and your available balance is already substantial.
We ran the same math and decided against it. Express Payout might get you the wire a day faster, but when 80% of your orders are sitting in DD+7 reserve anyway, you're just paying to accelerate the last 10% of the timeline. Better ROI for us was cleaning up carrier tracking so deliveries confirm faster.
The distinction between sales recorded, funds available, and cash received is exactly what our controller keeps drilling into the team. We've finally started building our weekly cash forecast from the available balance view in Seller Central instead of just multiplying last week's sales by 0.85 and hoping it shows up on schedule. The DD+7 reserve layer makes the old shortcut completely useless.
Same here. We also started flagging deferred transactions separately in our forecast model so we're not double-counting revenue that hasn't cleared the reserve yet. The DD+7 piece especially messed up our old assumptions.
Same here. We also started flagging deferred transactions separately in our forecast model so we're not constantly explaining to leadership why a strong sales week didn't produce the expected deposit. The reserve period creates enough lag that you really can't treat Amazon like a predictable receivable.