When Does Amazon Pay Sellers? Trace a Pending Payout
A scheduled Amazon payout is not the same as spendable cash. Learn how to trace proceeds through delivery-based reserves, disbursement, and bank settlement—and identify what is blocking payment.
Amazon generally settles seller accounts every two weeks, but that does not mean each sale reaches your bank within two weeks. Only eligible proceeds can be disbursed after fees, refunds, and applicable reserves. After Amazon initiates payment, funds can take up to five business days to appear in your bank account, according to Amazon’s explanation of seller payments. Your account’s Payments dashboard is the place to confirm its next scheduled disbursement.
To answer “when does Amazon pay sellers” for a specific order, trace three separate events: when proceeds become eligible, when Amazon sends them, and when the receiving bank credits them. A delay at each stage requires a different response.
This guide focuses on third-party marketplace sellers, primarily Amazon.com in the United States. It does not cover Amazon Associates commissions, AWS Marketplace disbursements, Amazon Pay merchant processing, or wholesale vendor invoice terms.
Start by locating the money, not counting days since the sale
A sales total is not a payout promise. An order may appear in your reporting while its proceeds remain unavailable for transfer. Conversely, Amazon may have sent a payment that your bank has not yet posted.
Use this diagnostic map before opening a support case or changing your cash forecast. Labels can differ across marketplaces and account interfaces.
| What you see | Likely stage | What to check next |
|---|---|---|
| Order proceeds are deferred | Eligibility not reached | Delivery date and release information |
| Balance exists but is unavailable | Reserve or account restriction | Reserve details and account notices |
| Available balance, no transfer | Awaiting disbursement | Scheduled date and request options |
| Transfer initiated, no bank credit | Bank processing | Transfer reference and destination |
| Payment failed or returned | Destination or processing exception | Failure reason and deposit details |
The important distinction: eligibility is not disbursement, and disbursement is not bank receipt. A faster transfer method cannot solve a reserve hold.
How delivery-based reserves affect your payment date
DD+7 starts from delivery—not the order date
Under a delivery-date-based reserve, commonly called DD+7, proceeds are generally held until seven calendar days after delivery before becoming eligible for disbursement. “DD” means delivery date, not disbursement date.
Webgility’s explanation of Amazon’s payout schedule changes describes the March 12, 2026 transition affecting legacy North American accounts. Many sellers were already on delivery-based terms. Treat that transition date as context, not proof that every marketplace or account has identical terms; confirm the reserve policy and notices applicable to your account.
Once a transaction clears its delivery-based hold, it still needs to enter an eligible disbursement. If it becomes available after the relevant cutoff, it may miss that transfer. Bank processing follows afterward.
For orders without confirmed tracking, an estimated delivery date may be used under the applicable policy. Check the date Amazon actually uses rather than assuming your shipping date started the clock.
FBA and seller fulfillment change the delivery step
Fulfillment by Amazon and merchant fulfillment can produce different order-to-cash timelines because transit times and delivery visibility differ. Faster delivery may bring the eligibility date forward, but it does not eliminate the reserve or guarantee an immediate bank deposit.
A universal “FBA pays in this many days” estimate therefore obscures the real variables. For a particular order, inspect delivery evidence, the applicable hold, disbursement timing, and the receiving bank separately.
Other reserves and restrictions can still matter
Delivery-based deferral is not the only reason money may be unavailable. Amazon may retain funds to address refund, claim, or chargeback exposure, and account verification or deposit-method issues can also interrupt payment. SellerEngine’s guide to reserves and disbursement issues explains why reserve balances and payment holds need separate investigation.
Do not turn a reserve balance into a fixed additional number of days without evidence. Also, do not subtract the same held proceeds twice when reconciling reports that display them in different views.
Find your next actionable payment date in Seller Central
- Choose the correct marketplace. Confirm which store, currency, and legal entity generated the proceeds.
- Open the Payments dashboard. Note the available balance, reserve or deferred amounts, and next scheduled disbursement information.
- Inspect the underlying transactions. Locate the order or group of orders you expected to be paid. Check delivery information and any displayed release date.
- Review account notices. Look for verification requests, deposit-method changes, or restrictions that explain why otherwise eligible funds have not moved.
- Check transfer history. Establish whether Amazon actually initiated the payment. Save the reference, amount, currency, destination account, and status.
- Match the bank receipt. Reconcile the credit to the transfer record, allowing for documented currency conversion or deductions.
This sequence prevents a common operational error: asking the bank to locate money that Amazon has not released, or asking Amazon to remove a reserve when the transfer is already in transit.
What can—and cannot—make a payout faster?
If your account offers an on-demand disbursement request, it can help move available funds sooner than waiting for a scheduled transfer. It does not make deferred proceeds available or override an account restriction. Check the conditions shown in your account before relying on it.
Likewise, faster bank-transfer options address the last part of the journey, not the delivery-based hold.
For eligible sellers managing U.S.-store proceeds, Amazon Seller Wallet provides another way to manage funds after disbursement. Amazon states that U.S. sales proceeds can appear in Seller Wallet within minutes of disbursement. That is wallet availability—not a promise that a subsequent external bank transfer has completed.
Before choosing an option, identify the delay you are trying to remove: waiting for eligibility, waiting for a transfer run, or waiting for bank credit. Compare costs and restrictions at that specific stage.
Cross-border sellers need a second reconciliation
When marketplace proceeds and operating expenses use different currencies, knowing when Amazon sends money is only half the answer. Finance also needs to know which currency arrives, where conversion occurs, and when the funds can cover local obligations.
- Confirm the payout destination. Check account ownership, supported country, currency, and required bank details against the marketplace’s requirements.
- Locate the conversion step. Establish whether Amazon, a receiving provider, or the bank converts the proceeds.
- Record the net receipt. Compare the disbursed amount with the credited amount using the actual conversion and fee records.
- Separate onward transfers. Money received into a collection account is not necessarily available yet in the account used to pay suppliers.
Do not assume every foreign-marketplace payout becomes U.S. dollars or that every international payment travels by wire. The configured receiving arrangement determines the route.
For the bank-processing portion, use the same discipline described in our guide to building reliable payout settlement estimates: distinguish initiation, processing, and beneficiary availability. Multi-currency infrastructure such as Global Accounts can support broader collection and treasury workflows, but confirm Amazon acceptance and account eligibility separately.
Turn payment status into a usable cash forecast
Maintain separate operational categories for deferred proceeds, available proceeds, transfers in transit, and cleared bank cash. These are forecasting categories, not a substitute for your accounting recognition policy.
For each expected receipt, capture the marketplace, currency, source transaction, eligibility information, scheduled transfer, transfer reference, and actual bank credit. Mark dates as confirmed or estimated. This makes a missed receipt explainable rather than simply “late.”
Hypothetical example: an order clears its delivery-based hold after the scheduled transfer cutoff. Its proceeds remain available for a later disbursement, while an earlier batch has already reached the bank. The right response is to revise that order’s expected receipt—not escalate the earlier batch as missing or assume all sales have been withheld.
Before committing supplier payments, test whether cleared cash covers the obligation if the expected Amazon receipt slips. If it does not, agree on a funding or rescheduling decision before payment release. An AP automation workflow can organize invoice approvals and payment execution, but it cannot shorten Amazon’s reserve period.
Next step: trace one missing receipt end to end
Choose one payment you expected to receive and identify its current stage. If it is deferred, inspect delivery and release information. If it is available, check disbursement timing and restrictions. If it has been sent, use the transfer reference to investigate bank receipt.
When escalating, provide the marketplace, affected transactions, expected and actual status, amount, currency, and relevant dates through a secure support channel. The most useful question is not simply “When will Amazon pay?” It is “Which condition must be satisfied before this money can move to the next stage?”
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
33 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.
Payment Operations Manager: Role, Authority, and Global Payout KPIs
A payment operations manager owns the execution and control of payments, not just the processing queue. For global payouts, success depends on clear authority over releases, exceptions, provider performance, and operational change.
Payment Operations Disallowed Due to Account Status: What to Do
An account-status restriction is not necessarily a funding problem or a payment-rail outage. Here is how finance teams can isolate the blocker, manage affected payables, and establish safe conditions for release.
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 flowchart logic here is solid, but I wish the article had addressed what happens when delivery confirmation itself is disputed—especially for merchant-fulfilled orders where carriers mark packages delivered but the customer claims non-receipt. That introduces a separate cash flow risk on top of the DD+7 hold because you're both waiting for eligibility and potentially facing a future A-to-z claim reserve.
That's a gap we've hit too. In those cases the delivery-based clock often still runs from the carrier scan, but Amazon can claw back the proceeds if the A-to-Z claim is filed and approved later. So you might see the funds become eligible under DD+7, enter a disbursement, then get reversed weeks afterward. We now flag those disputed deliveries separately in our reconciliation to avoid double-counting them as cleared receivables.
That's a gap we've hit too. In those cases the delivery-based clock often still runs from the carrier event, but the reserve gets extended or a separate hold appears if a claim is filed. The article's advice to check release dates per transaction helps, but you're right that disputed delivery creates a second layer of uncertainty that isn't really covered here.
The point about not using a faster transfer method to solve a reserve hold is something our AP team learned the hard way. We switched deposit methods thinking it would unlock funds sooner, but the DD+7 clock hadn't even started because delivery confirmation was missing on half the orders.
We ran into the same trap. Switching deposit methods added a verification delay on top of everything else, which actually made the first payout slower. Now we just confirm delivery tracking is uploaded before we even look at payment settings.
We had a similar issue where the carrier showed delivered but Amazon's system hadn't ingested the tracking event yet. The reserve release date just sat blank until the scan finally propagated, which added another three days. Now we flag any order over a certain value that doesn't show a release date within 48 hours of expected delivery.
The diagnostic map is useful, but I'd add one more row: 'Transfer initiated, bank confirmed receipt, but amount differs from expectation.' Currency conversion and VAT adjustments have caught us twice this year when reconciling cross-border disbursements, and the article's focus on U.S. sellers doesn't really touch that complexity.
Good catch. We've started treating currency conversion as a separate reconciliation step entirely, especially when proceeds cross multiple entities. The article mentions confirming the marketplace and currency up front, but you're right that the mismatch step deserves its own diagnostic row once the transfer lands.
Agreed, and it's not just VAT—marketplace facilitator tax withholding in certain U.S. states creates similar variance. We now pull the transaction-level detail from the payments report before reconciling the net deposit, otherwise the mismatch gets flagged as a bank error when it's actually a remittance issue.
The diagnostic map is helpful, but one correction: Amazon Seller Wallet availability isn't 'within minutes' for all U.S. sellers—it's still gated by account eligibility and the same delivery-based release rules apply upstream. We tested it last month and the Wallet just received funds faster after disbursement was already triggered, it didn't accelerate DD+7.
Correct. The Wallet doesn't change the upstream release timing, it just receives eligible funds faster once they're actually disbursed. We saw the same thing—still waiting on DD+7, just less time in transit after that.
Correct. The Wallet doesn't change the upstream release timing, it just receives eligible funds faster once they clear DD+7 and any other holds. We've seen the same gating—availability varies by account history and verification status.
This finally explains why our Amazon reconciliation breaks every month—we were treating 'available balance' as a confirmed outbound, but half of it was still sitting in a delivery hold that hadn't even started the DD+7 clock yet.
Same here. We also weren't accounting for the fact that delivery confirmation can lag 24-48 hours behind actual drop-off, so the DD+7 clock was starting later than we assumed. Now we pull delivery status before we forecast the disbursement date.
Same here. We also weren't accounting for the fact that delivery confirmation can lag 24-48 hours behind actual carrier scan, so the DD+7 eligibility date was sliding forward unexpectedly even on orders we thought were already delivered.
The distinction between eligibility, disbursement, and bank receipt is critical but often missed in cash forecasting. We've had to train our entire AR team to stop counting days from order date and instead trace each stage separately—especially after a controller nearly escalated a 'missing payment' that was just sitting in the two-day ACH queue.
Same experience here. The three-stage model in the article is now part of our weekly reconciliation checklist. We also flag any orders without confirmed tracking since those estimated delivery dates can push the eligibility window unpredictably.
We had the same issue with treasury assuming every Seller Central 'available' balance meant same-day liquidity. The break between eligible and actually disbursed was costing us overdraft fees until we rebuilt the weekly forecast to match the scheduled transfer dates instead of order volume.
The point about confirming which marketplace and legal entity generated the proceeds is underrated—we wasted two weeks last month chasing a 'missing' payout that was sitting in the UK entity's account while our AP team was looking at US Seller Central.
We had the exact same problem with multi-entity reconciliation. Now we tag every expected disbursement with the marketplace code and entity at forecast time, not after the fact when we're already hunting for it.
We now require the marketplace and entity ID in every reconciliation ticket template. Sounds basic, but it eliminated about 40% of our internal back-and-forth with treasury.
The section on FBA versus merchant fulfillment timelines is understated but important. We had a mixed catalog and our AR forecasting was consistently off until we stopped treating all Amazon receivables as a single bucket and started tracking by fulfillment method, then layering in the actual delivery dates instead of ship dates.
We did the same thing after our controller pushed back on our cash forecast assumptions. Now we segment by fulfillment channel in our payout tracker and use actual delivery confirmation dates instead of ship dates, which cut our variance by more than half.
We went through the same exercise. The delivery variance between FBA and seller-fulfilled was adding 4-6 days of spread to our DSO, which made weekly cash forecasting nearly impossible until we segmented it properly.
One thing worth emphasizing: DD+7 is calendar days, not business days, but the bank settlement window is business days. We've had sellers panic on a Monday when funds cleared delivery hold on Thursday but missed Friday's disbursement cutoff and then hit a weekend. The math gets messy fast if you're forecasting cash for payroll.
Exactly this. We now build the cutoff timing into our cash position forecast model explicitly, otherwise treasury is working off bad data every single week. The calendar vs business day split creates a reconciliation nightmare if you're trying to automate any part of the cash application process.
We hit this exact scenario last quarter. The disconnect between calendar-day holds and business-day settlement windows creates forecasting gaps that our treasury team had to manually adjust for. Would be helpful if Amazon surfaced the actual disbursement cutoff time in the dashboard instead of just showing a scheduled date.
The diagnostic map table is exactly what we needed for customer support. Half our tickets from marketplace sellers are them confusing reserve holds with transfer delays, and this gives us a structured way to triage before escalating to Amazon.
We're doing something similar now. I've started adding the reserve reason to our internal case tags so we can route delivery-date vs account-level holds differently. Cuts down on back-and-forth when the seller just needs to wait versus actually needing intervention.
We built a similar internal flowchart after the DD+7 rollout hit our clients. The number of sellers who think switching to express transfer will fix a reserve hold is still wild to me. Good to have a public reference we can point to instead of re-explaining the eligibility vs. disbursement distinction every time.
Does anyone know if the on-demand disbursement option has transaction limits or frequency caps? We have a client doing about $400K monthly through Amazon and they're exploring faster access to working capital, but I want to understand the practical constraints before we build forecasting around it.
From what I've seen, the on-demand option is limited to once per day and caps at your available balance minus any reserve bucket, but there's no published transaction ceiling. At $400K monthly you shouldn't hit friction unless there's a pattern issue flagged on the account side.
From what I've seen, the on-demand option is limited to once per day and caps at your available balance minus reserves. The bigger issue at that volume is going to be whether your client is still hitting delivery-based holds—if a big chunk of the $400K is sitting in DD+7 deferred status, on-demand doesn't touch it.