Delivered But Not Paid: How to Find the FBM Orders Amazon Is Still Holding

Every FBM seller running meaningful volume has a version of this problem: you know some of your delivered orders aren't releasing on schedule, but you can't find them systematically. You can feel the gap in your disbursements. You can't locate the specific orders that are causing it.

At 50 orders a month, manual cross-referencing is annoying but feasible. At 300 orders a month, it breaks down. At 1,000 orders a month, it's not possible without dedicated tooling — and the orders that fall through don't generate any notification. They just quietly stay deferred until someone finds them or a deadline passes.

This article covers why delivered orders stay held under DD+7, what the actual trigger mechanism is, and what a systematic approach to finding them looks like at scale.

What "Delivered" Means to Amazon vs. What It Means to You

This is the distinction that causes the most confusion, and the most invisible losses.

When your carrier dashboard shows "Delivered," that reflects what the carrier recorded. When Amazon releases your DD+7 funds, it reflects what Amazon's system received from the carrier. These are not the same data source, and they do not always agree.

Amazon does not have direct access to delivery events. It receives data feeds from carriers — USPS, UPS, FedEx, and others — and uses those feeds to determine when the DD+7 clock starts and when it resolves. If the carrier's delivery confirmation didn't transmit to Amazon's system — due to a scanning failure, a data feed delay, or a rural route with weak final-mile coverage — Amazon's record of that order remains "in transit" regardless of what your carrier dashboard shows.

The practical consequence: your carrier says delivered, your customer has the item, and Amazon's DD+7 clock hasn't started. The funds stay deferred indefinitely until either the delivery signal eventually arrives or Amazon's fallback mechanism triggers.

Amazon's Fallback and Why It's Not Enough

Amazon does have a documented fallback for orders that never receive a delivery confirmation: it releases funds 7 days after the latest estimated delivery date. This generally works as described.

The problems with relying on it are timing and detection.

On timing: the fallback EDD is calculated from ship date plus expected transit window, then Amazon adds 7 days. For a rural route or a carrier with weak final-mile scanning, this can push your release date 3–5 days beyond what a confirmed delivery would have produced. Across dozens of orders a month, those extra days compound into a material cash flow difference.

On detection: Amazon does not notify you when an order enters the fallback path. The order sits in your deferred balance with no flag, no status change, no indication that something is wrong. You have no way to know which orders are on the normal DD+7 path and which are waiting for a scan that may never come — unless you're checking each order individually against its expected delivery date.

At 50 orders a month, that's feasible. At 500, it isn't.

The Scale Problem

The manual process for finding delivered-but-deferred orders is well understood by experienced FBM sellers. Download the Orders Report with the delivery date column. Cross-reference against carrier tracking in bulk. Flag anything showing in-transit status past its expected delivery date. Check those orders against your transaction history to confirm they haven't released.

Sellers who do this describe it as 3–4 hours of work per day at meaningful volume. The process works — when you do it. The failure mode is volume: at high order counts, the cross-referencing becomes error-prone and time-consuming enough that individual orders fall through. The ones that fall through don't announce themselves. They dissolve into the aggregate deferred balance and wait.

The orders that fall through first are almost always the ones with the smallest individual value — not worth chasing manually, but significant in aggregate. A 1–2% carrier scan failure rate at 500 orders per month is 5–10 orders where your funds are delayed by days or weeks. At an average order value of $150–$200, that's $750–$2,000 in delayed cash flow every month from scan failures alone.

What the SP-API Sees That You Can't

Amazon's SP-API exposes order-level data that Seller Central doesn't surface in any report: the current payout status per order, the carrier tracking data as Amazon received it, and the expected release date based on Amazon's internal delivery record.

This is the critical distinction. Your carrier dashboard shows what the carrier recorded. The SP-API shows what Amazon's system received. When those two records disagree — carrier says delivered, Amazon's system shows no delivery confirmation — the SP-API reveals the discrepancy. Your carrier dashboard doesn't, because it's only showing one side of the data gap.

This is what makes systematic detection possible. Instead of cross-referencing two separate data sources manually, the SP-API provides a single joined view: order status, Amazon's delivery record, payout status, and expected release date, all in one place.

What to Do When You Find Them

The action depends on how far the order has progressed.

If the order is pre-EDD: Contact the carrier to confirm delivery and request that the scan be updated. In many cases, a delivered package was simply not scanned at the door — the carrier can update their record, which then transmits to Amazon and starts the DD+7 clock.

If the order is past EDD but within a few days: Contact the carrier and simultaneously prepare documentation — tracking information, any delivery confirmation you have — in case you need to open a Seller Support case. The fallback mechanism should trigger, but having documentation ready shortens resolution time if it doesn't.

If the order is significantly past EDD with no movement: Open a Seller Support case with the order ID and tracking documentation. Be specific: "This order was delivered on [date] per carrier records but shows no delivery confirmation in Amazon's system. Funds remain deferred." A specific order ID with clear documentation resolves faster than a general inquiry about your reserve balance.

The window for all of these actions is wider when you catch them early. An order that's 2 days past EDD is easier to resolve than one that's 14 days past with a buyer who has already contacted Amazon.

How DD7 Radar Handles This

DD7 Radar connects to Amazon's SP-API and maps every FBM order to Amazon's internal delivery record — not just your carrier dashboard. Orders where the carrier shows delivered but Amazon's system shows no delivery confirmation are flagged automatically. Orders approaching their EDD without a confirmed delivery signal surface before the breach, not after.

If you've opted into email alerts, you're notified the moment one of these is detected — not in a batch, not on a schedule, but when the signal trips. The alert includes the order ID, the current status in Amazon's system, and the expected release date, so you have everything you need to act without going looking for it.

The broader ledger shows every order's payout status and release date in one place — the per-order view that Amazon's reports don't produce. Most orders need nothing. The ones that do are surfaced while the window to act is still open.

DD7 Radar starts with a complimentary 90-day audit of your FBM orders — no card required. If you're currently finding these orders manually, or not finding them at all, run your audit at dd7radar.com.