A fractional CFO went through his client’s Amazon numbers by hand. Twenty thousand ASINs, a full reconciliation in Excel, our data on one side and Amazon’s on the other.
Only 28% of order IDs showed up in both.
His read: we were keying the report on the wrong date. He was right. Not quite for the reason he first gave, and the real one is worth your afternoon, because it is almost certainly happening in your books too.
A sale used to have two dates. Now it has three.
This is the part worth slowing down for, because the shape of the problem changed and most reporting did not change with it.
It used to be two dates. You had the order date, and you had the ship date. The ship date was when the transaction posted, and posting was also when the money came to you. Two of those three ideas were the same date, so nobody had to be careful about which one they meant. You could say “the transaction date” and be understood.
Under the delivery-date-based policy, those two came apart. Amazon holds the funds for a period after delivery before releasing them. The transaction still posts around ship time. The money arrives later. What used to be one date is two.
So a sale carries three distinct dates:
| Date | What it is |
| Order date | When the customer bought |
| Transaction date | When the sale posted, around ship time, a few days after the order |
| Release date | When Amazon released the money to you |
Here is one order from the reconciliation, all three:
- Ordered April 7
- Transaction posted April 8
- Money released April 18
The first gap is small and always was. The second gap is the new one, and it is the wide one: ten days between the sale posting and the money moving.
That is Amazon working as designed, and as a cash flow fact it is unremarkable. It becomes an accounting problem the moment something records the third date and calls it the transaction date, because under the old two-date world those were the same thing and now they are ten days apart.
That is precisely what had happened to us, and it is what the CFO caught.
Why the calendar makes it worse
Most of the time a ten-day gap moves a transaction from one week to another and nobody notices or cares.
Then the gap crosses a month boundary. The sale happened in one accounting period and lands in the next one. Revenue, the fees against it, and the cost of the goods all shift a month to the right, together.
Which brings us to the part that should bother you: this is at its worst in December.
Your biggest sales month feeds most of its back half into January. December reports light. January reports inflated by sales it did not make. Then the comparison you actually care about, this December against last December, is measuring two differently distorted numbers against each other.
If you have a real Christmas season, and most sellers do, your single most important month is the one your books describe worst.
Growth is what hides it
A distortion like this should be obvious. It usually is not, and the reason is that it looks exactly like growth.
Pull revenue a month right in a business that is climbing, and every month still comes in above the one before it. The shape you expect is the shape you see. Nothing trips an alarm. The error is not sitting next to the growth where you might spot it, it is folded inside it.
That is also why this tends to surface at the worst possible moment. Cash basis genuinely does not have this problem, and cash basis is where most sellers live. You inherit it the day you move to accrual, and you move to accrual when a bank, an acquirer, or a diligence team asks you to. First serious look at your numbers, and the periods are wrong.
The CFO in this story asked around his own network about it. About half of them did not know it existed. His words: a pretty obvious timing issue, and he was surprised nobody had picked it up.
It is not only a P&L problem
Worth being precise here, because this is the part tooling most often skips.
Money earned and not yet released is an asset. It belongs on the balance sheet while it waits. Deferral is not just a P&L timing question, it produces receivable and payable entries that have to exist and then have to unwind when the money lands.
The way the CFO put it: he does not especially care when the money hits. He wants the transaction captured in the accounting period it belongs to. That is the whole discipline in one sentence, and it is the difference between a report that reconciles to your bank and a report you can close a month on.
How we proved it, which is the useful part
We got this wrong twice before we got it right, and the wrong turns are the transferable lesson.
First we read our own database schema. Clear answer. Then we read the ingest code. Also a clear answer, consistent with the first.
Both were read correctly. Both were wrong, for the same reason: a schema and an ingest path describe what you store, not what your supplier sent you. Everything discarded on the way in is invisible to both, and what we were looking for had been discarded on the way in.
Two methods settled it, and neither involved reading our own code.
We diffed the customer’s own Amazon export against our data. Eight orders, matched field by field. Eight of eight matched Amazon’s Transaction Release Date column exactly, to the second. Zero of eight matched the transaction-date column. That is not a subtle statistical lean, it is a switch in one position: we had the third date sitting where the second one belonged.
Then we captured the raw API payloads and confirmed it from the other direction. Amazon sends two linked transactions for a deferred event: one when it is charged, one when it is released. Same amount on both. We checked every linked pair in a ninety-day window, 1,911 of them, and the amounts matched on all 1,911.
That detail matters for a reason worth stating plainly, because the opposite conclusion is the tempting one: no money is missing. The two records are the same sale seen twice, and anyone who “fixes” this by keeping both will double-count their revenue. The problem was never a missing amount. It was a date.
If you are ever in this position, arguing with a customer about whose data is wrong, skip the schema. Diff their export against your database, and capture what the API actually sends.
What your tooling can and cannot see
Here is where it gets genuinely interesting for anyone running books on Amazon accounts.
A2X is the established name in Amazon accrual accounting, and they are straightforward about the constraint on their own site: third-party tools like A2X cannot see deferred transactions until those transactions are included in settlements. Deferred transactions do not appear in the settlement file until the cash moves.
Their answer is a month-end adjustment journal, generated on the fifth of the following month. It accrues what was deferred into the month it was earned and reverses what was released, netting into an asset account, and it deliberately leaves the settlement entry that matches your bank feed alone.
That is a sound piece of accounting. It gets your monthly totals into the right period, and if you are closing books on Amazon revenue you want something doing that job.
What it does not give you is the deferred dimension on the individual transaction, and it does not let you close before the fifth.
At the time of writing, Amazon’s Finances API carries that dimension directly. Every transaction comes with a status of deferred, released, or deferred-then-released, plus the reason for the deferral and the date it matures. Both of the dates that came apart are in there: the deferred record carries the transaction date, the released record carries the release date, and they reference each other. The information is not inferred from a settlement after the fact. It arrives attached to the transaction.
We know, because we were throwing it away. Our own ingest read that status and dropped the deferred rows on the floor, which is exactly why our timestamps were release dates and why the CFO’s reconciliation fell apart. The fix is a real change and it is not done at the time of writing. But the gap between what Amazon sends and what most tools can see is not a limit of the data. It is a limit of reading it out of settlements.
What to do about it on your own account
Three things, in order.
Find out which of the three dates you are looking at. Not which one you assume, which one is actually in the column. Take a handful of orders you can identify, put your reporting next to Amazon’s transaction-date column and its Transaction Release Date column, and see which one lines up. It is an afternoon, and until you have done it every number downstream is resting on a guess.
Be especially suspicious of anything built before the policy split those dates apart. A report written when the transaction date and the release date were the same thing had no reason to distinguish them, and it will not have started distinguishing them on its own.
Measure your own lag. The ten-day gap above is one account’s experience, not a constant. Yours depends on your categories, your fulfillment, and your delivery times. What you want is the range and the shape of it, because that tells you how much of a typical month is exposed to landing in the wrong one.
Then look at your month boundaries, starting with December. The cost of this is concentrated in the last few days of a period, and concentrated hardest in your biggest month. If you only ever check one boundary, check that one.
None of this requires new software. It requires knowing which of the three dates you are actually recording. That used to be a question you could get away with not asking, because two of the answers were the same. It is not that question any more.
