Amazon Deferred Transactions and DD+7: Solve the Accounting at the Source, Not the Settlement

Amazon has spent the last two years migrating sellers to a payout policy called DD+7 — Delivery Date plus seven days. On the surface it is a cash-flow story: Amazon holds your money longer. But the more consequential effect is quieter. DD+7 invalidated a working assumption that an entire generation of Amazon accounting tools was built on: that settlement reports are a reliable record of when business happened. They no longer are.

This article explains what DD+7 and deferred transactions actually do to your books, examines the two ways the industry has responded — month-end adjustment journals layered on settlements versus accounting built on transaction dates — and shows why we believe the second approach is the only one that makes your P&L, rather than Amazon's payout schedule, the source of truth for your business.

What Amazon's DD+7 Policy Actually Does

Under DD+7, Amazon holds the proceeds of most consumer orders until seven days after the order's confirmed delivery date. Between shipment and release, the money sits in a bucket Seller Central calls Deferred Transactions. B2B orders are held longer — typically 30 days from the order date. Refunds and fees tied to deferred orders can be deferred along with them.

Three mechanical details matter for accounting:

• Deferred transactions are excluded from settlement reports. A sale does not appear in a settlement until its hold ends. Your bi-weekly settlement file is no longer a complete record of the period's business — it is a record of what Amazon chose to release.
• The delay is variable, not fixed. Seven days is counted from delivery, and delivery depends on carrier speed, geography, and returns handling. In practice a sale can take one to three weeks to surface in a settlement.
• The amounts are unchanged. DD+7 does not cost you revenue. It moves the timing of cash — which is exactly why it should be handled as a receivables question, not allowed to reshape your revenue recognition.

Amazon's stated rationale is fraud reduction and coverage for returns, claims, and chargebacks. Whatever the motivation, the result is the same: Amazon became your slowest-paying customer, and the reports most accounting integrations depend on stopped describing your months accurately.

Why Settlement-Based Books Drift Under DD+7

Most Amazon accounting software was designed around a sensible-sounding pipeline: import each settlement, summarize it into a journal entry, post it to QuickBooks or Xero, and match it against the bank deposit. Clean, auditable, and — before deferred transactions — approximately correct on timing, because settlements closed every two weeks and contained everything.

DD+7 removed the "contained everything" part. Consider a single order:

The sale belongs to March. The customer bought in March, the demand happened in March, the ad spend that drove it was March ad spend. But settlement-driven books record it in April, because that is when Amazon released the money. Multiply that by every order in the last week or two of every month and the distortions compound:

• Month-end P&Ls misstate performance. Each month loses its final days of sales to the next month and inherits the previous month's tail. Launches, promotions, and peak weeks look smaller in the period they actually ran.
• COGS and fees follow the wrong dates. When revenue slips a period, the costs recognized against it slip too — or worse, land in a different period than the revenue they belong to. Margin analysis by month becomes unreliable.
• Year-end gets genuinely difficult. Amazon's 1099-K reports gross activity by transaction date. Settlement-driven books follow release dates. Every December-to-January boundary now produces a gap your accountant has to explain with bridge schedules.
• Advertising ROI drifts. Ad platforms report spend by day. If revenue is recorded by release date, campaign and ASIN profitability comparisons quietly stop lining up with the periods the spend ran in.

DD+7 is a payout policy, not an accounting principle. The problem is not that Amazon holds money for seven days — it is that settlement-driven bookkeeping lets a payout policy decide what period your revenue belongs to.

Two Ways to Solve It: Adjustment Journals vs Transaction-Date Accounting

The industry has produced two structurally different answers to this problem, and the difference between them is worth understanding before you commit your ledger to either.

Approach 1: Keep settlements as the source of truth, add a monthly adjustment

This is the path taken by settlement-first tools, with A2X's "Monthly Adjustments for Amazon Deferred Transactions" workflow as the most prominent example. Settlements keep posting as before. Then, once a month — A2X generates these on the 5th of the following month — the tool creates one adjustment journal per marketplace that accrues everything deferred during the month and reverses everything released during the month, with the net landing in a designated deferred-transactions asset account. To start, you establish an opening balance for the deferred amounts that existed before you enabled the feature.

To be fair to this approach: it produces a correct month-level revenue total, it keeps bank-feed matching intact, and it is a rational engineering choice for a product whose architecture treats the settlement file as the atomic unit of truth. If the settlement must remain the foundation, an accrual overlay is the best available patch.

But it is a patch, and it has the properties of one:

• Summary-level resolution. The adjustment is one journal per marketplace per month. Your P&L total is corrected; your ability to trace any individual order, SKU, or day inside that correction is not part of the mechanism.
• A permanent moving part. Every month adds an accrual and a reversal that your finance team — and eventually your auditor or a buyer's diligence team — has to understand, verify, and explain. The opening balance has to be right or every subsequent month inherits the error.
• Recognition still anchored to release data. The underlying entries still follow settlement releases; the adjustment pulls the totals back into place after the fact. The books are corrected, not correct by construction.

Approach 2: Make transaction dates the source of truth

The alternative is to stop treating settlements as the record of business and start from the transaction level: record every sale, fee, refund, and its cost of goods on the date Amazon posts the financial event, and demote the settlement to what it economically is — confirmation of what Amazon owes you, and then a movement of cash.

Under this model there is nothing to adjust, because nothing was recorded on the wrong date in the first place. DD+7 stops being an accounting problem and becomes what it always should have been: a receivables aging question. This is the model NeonPanel is built on.

How Transaction-Date Accounting Works: Posted Date, Clearing, A/R, Cash

NeonPanel rebuilds the Amazon ledger from posted transaction data rather than settlement summaries. The mechanics follow a chain any controller will recognize:

Step 1 — Record sales, fees, and COGS on their posted dates

Every financial event — product sales, shipping, promotions, taxes, referral and FBA fees — posts to a clearing account on the date it occurred, regardless of when Amazon will release the money. COGS is recognized with the sale, using batch-level FIFO costing rather than a period average, so the margin recorded for each day reflects what the units sold that day actually cost to land. The result is a truly accrual P&L: every sale and its costs in the correct calendar day and month, independent of DD+7, reserve changes, or any future payout policy Amazon invents.

Step 2 — Use statements to move clearing to accounts receivable

Amazon statements stop driving revenue recognition entirely. When a settlement arrives, it does one job: confirm which posted transactions Amazon now owes you, moving them from clearing into Amazon A/R. Clearing reconciles to A/R continuously, which gives finance teams the controls they already know — aging, exposure, reserves — instead of a custom deferred-balance construct. The full trace from any journal line back to the specific Amazon transaction behind it is preserved, which is what makes the ledger audit-ready by construction rather than by explanation.

Step 3 — Close A/R to cash when the payout lands

When Amazon disburses, NeonPanel closes A/R against the bank deposit, completing the chain: posted transaction → clearing → A/R → cash. Bank matching stays exact. And your cash visibility improves rather than degrades, because DD+7 now shows up where a delay belongs — as Amazon A/R days you can see, age, and plan inventory and ad spend against.

The entire chain syncs to your accounting system automatically, whether that is QuickBooks or Xero — real journal entries in a real ledger, not an emulated report layer.

What Changes for Your Finance Team

Moving the source of truth from settlements to posted transactions changes four things that matter well beyond DD+7:

• Period reporting you can defend. Revenue, COGS, fees, and taxes sit in the period of economic activity — standard accrual logic, the way GAAP expects it and the way your CPA wants to see it at year end. Monthly and weekly P&Ls reflect selling activity, so margin analysis, promo post-mortems, and cohort models are trustworthy again.
• 1099-K reconciliation becomes a mapping, not an investigation. The 1099-K is built from gross transaction activity by date. So is your ledger. Tying one to the other becomes a direct exercise, with any residual timing differences explicitly visible instead of buried inside settlement summaries.
• Ad spend matches the sales it drove. Amazon Ads spend, promo rebates, and performance costs land in the same posted periods as the revenue they generated, so campaign, ASIN, and period-level profitability stop drifting.
• DD+7 becomes a working-capital metric. Instead of distorting recognition, the hold is visible as Amazon receivable days — earned, owed, and banked amounts distinguishable day by day. If Amazon changes payout rules again, your recognition logic does not move, because it was never anchored to payout structure.

The Two Models at a Glance

Both models can produce a defensible monthly revenue figure. The difference is what sits underneath it: a corrected summary, or a ledger that was never wrong. For teams preparing for diligence, audit, or a lender review, that difference is the whole conversation. For a broader feature-by-feature view, see A2X vs NeonPanel.

Make Your P&L the Source of Truth

DD+7 will not be Amazon's last payout policy change. The durable answer is not a smarter patch on settlements — it is accounting whose recognition logic never depended on settlement structure in the first place. NeonPanel records your Amazon business at the transaction level, on the dates it happened, with batch-accurate COGS, and lets settlements do the one job they are actually good at: moving money.

That is what makes the P&L — not the payout schedule — the single source of truth for performance, tax, and advertising decisions across your whole operation. It is the same foundation NeonPanel's Amazon accounting automation extends to Shopify and TikTok Shop on one unified ledger.

See DD+7 handled correctly in your own ledger.
Connect your Seller Central account and watch sales, fees, and COGS land on their posted dates — with settlements reduced to A/R and cash, the way they should be. Explore Amazon accounting automation →

Further reading: Amazon Seller Tax Reports: Tools and Methods for Accurate Reporting · Amazon Seller Bookkeeping Guide · Best Accounting Software for Amazon Sellers in 2026

FAQ