Skip to content

Deferred Transactions and the 7-Day Rolling Window Explained ​

If you've recently noticed your P&L report under-reporting sales for the most recent week or so, you're almost certainly running into Amazon's deferred transactions policy. This article walks through what's actually happening behind the scenes, why the gap appears, and how to reconcile your numbers correctly.

The Short Version ​

Amazon now holds most sales as deferred transactions for around 7 days after delivery before releasing the funds for payout. SellerLegend, by default, only counts released transactions in your P&L (just like Amazon's own settlement reports do). So if you're comparing the last 7-14 days against an external source that includes pending balances, the recent window will look smaller than expected.

This is by design, not a sync issue.

What Is a Deferred Transaction? ​

A deferred transaction is a sale where Amazon has confirmed the order but is temporarily holding the funds before paying them out. Most transactions are deferred for some period before they are released into your settlement payout.

There are two common reasons Amazon defers a transaction:

  1. Delivery Date Based Reserve (DD+7) -- Amazon holds the proceeds while the order is in transit and for 7 calendar days after the delivery is confirmed. The reserve protects against returns, claims, and chargebacks before the money becomes yours.
  2. Invoiced Orders (Amazon Business / B2B) -- For business buyers paying by invoice, the funds stay deferred until the buyer settles the invoice -- typically 30 to 45 days after the order date.

This was historically rare and only applied to invoiced B2B sales. Starting late 2024 and rolling out through 2026, Amazon extended DD+7 to most regular consumer sales as well, which is why so many sellers are seeing it for the first time.

The Lifecycle: How a Transaction Moves From Deferred to Released ​

This is where the confusion usually creeps in. A single sale doesn't stay on the same date in the report -- it actually appears twice, on different dates:

  1. Day 0 (order date or delivery date): The transaction is posted as deferred, with a promised release date 7 to 14 days in the future.
  2. Release date: The original deferred entry is reversed (taken back), and a new released entry is posted on the actual release date -- not the original sale date.

So an order delivered on April 24 with a 7-day reserve doesn't simply "become released" on May 1 in place. Instead, the April 24 deferred line is removed, and a fresh released line appears on May 1. From a reporting standpoint, the sale has effectively moved forward in time from April into May.

Worked Example ​

Imagine a seller with steady daily sales of $100. Amazon switches them onto DD+7 starting April 1.

Date in P&LReleased sales (default view)What's actually happening
Apr 1$0Apr 1 sales are deferred, will release ~Apr 8
Apr 2$0Same -- deferred until ~Apr 9
.........
Apr 8$100First day of releases catching up
Apr 9$100Steady state begins
...$100/dayRolling window in equilibrium
Apr 30$100Apr 23's sales releasing today
Apr 24-30understatedThese sales will release in early May

After the first 7 days, the report shows $100/day as expected -- but the trailing week of April will always look empty until those May releases arrive.

Why the Recent Period Looks Underreported ​

If you compare a calendar month (say, April) against an external Amazon report that does include deferred amounts, you'll see two systematic gaps:

  1. The trailing window. The last 7 days of the period contain sales that have been deferred but not yet released. They'll show up in May, not April.
  2. The "first month" effect. The very first month Amazon enables DD+7 on your account is the worst case -- there are no earlier deferrals releasing back into it, so only the early days have caught up by month-end. Subsequent months stabilise once the rolling window is fully populated.

This is why a one-month comparison right after DD+7 is enabled almost always shows a shortfall, even when nothing is wrong with the data.

How to Reconcile Correctly ​

A few practical tips:

  • Use the Include Deferred toggle for trend analysis. SellerLegend's P&L report has an Include Deferred / Exclude Deferred toggle right above the report. Switch to Include Deferred to see the full pipeline -- "everything Amazon currently owes me, released or not."
  • Use Exclude Deferred (the default) for reconciliation against payouts. Amazon's settlement payouts only ever include released funds, so to reconcile against your bank statement, leave the toggle on Exclude Deferred.
  • Wait 7-14 days before reconciling a period. The rolling window means a calendar month is only fully populated about two weeks after it ends.
  • Compare apples to apples. When comparing against an Amazon Seller Central report, check whether that report includes deferred amounts. The Seller Central Payments → Transactions view, the Deferred Transactions report, and the unified custom transaction report all behave differently.
  • Match a single transaction across both views. If a specific sale looks missing, switch to Include Deferred -- you'll usually find it sitting on the original date as a deferred entry, with a promised release date a week or two out.

Why SellerLegend Excludes Deferred by Default ​

Deferred amounts are not yet yours. Amazon holds the funds precisely so they can be reduced or reversed if returns, claims, or chargebacks come in during the reserve window. Treating deferred amounts as realised revenue would inflate your P&L, mismatch your bank deposits, and make accounting and tax reconciliation much harder. So the default reflects only money Amazon has actually released to you.

The Include Deferred mode is there for sellers who want forward visibility -- forecasting, trend analysis, and pipeline tracking -- without needing to manually pull the deferred report from Seller Central.

External References ​