Ask the Amazon MCP Server, in plain English, for your Unified Transactions Report. It returns Amazon’s order-and-item level transaction detail with every fee broken out per line, grouped into readable buckets that sum to exactly what Amazon deposited. Amazon has no API that returns this report, so Seller Labs reconstructs it in Data Hub as sl_transactions_pivot, where it reconciles to your settlement totals.
What the Unified Transactions Report is
Your settlement report tells you what a whole settlement was worth. It does not tell you what any single order was worth.
The Unified Transactions Report works at order-and-item level: one row per order, per SKU, per fee line, across Marketplace, FBA, and Webstore. That is the grain a finance team needs to answer “which orders produced this deposit,” and it is why people go hunting for this specific report instead of the settlement summary.
What it looks like in practice
No SQL, no report request, no waiting for a file to generate.
You ask: “Pull my unified transactions report for last month and break the fees out by bucket.”
The MCP Server returns a breakdown like this, from one real settlement worth $246,691.29:
| Bucket | Line items | Total |
| product_sales | 14,412 | $372,645.71 |
| fba_fees | 14,223 | -$73,902.22 |
| selling_fees | 14,512 | -$46,719.23 |
| marketplace_tax_withheld | 13,366 | -$25,440.37 |
| product_sales_tax | 13,469 | $25,326.18 |
| other | 1,287 | -$6,867.89 |
| shipping_revenue | 1,642 | $4,753.84 |
| promotional_discount | 1,365 | -$3,202.50 |
| shipping_revenue_tax | 235 | $97.77 |
| Settlement total | 74,511 | $246,691.29 |
That is 74,511 individual fee lines collapsed into nine numbers, and the bottom line is the deposit. Tax collected and tax withheld sit in their own buckets, so you can produce a clean net-of-tax revenue figure without unpicking anything by hand. The same bucketing runs all the way down to a single order, so you can ask what any one order actually paid you after every fee.
Why you cannot just pull this from Amazon
Getting this report out of Amazon is where most teams stall, so it is worth being precise about what Amazon does and does not give you.
No API returns the Unified Transaction Report. In Seller Central you can absolutely get it: go to Finance › Manage payments › Reports Repository, set Account Type to “All (Unified Reports)” and Report Type to “Transaction,” pick a date range, and request the report. What you cannot do is request that same report through the Selling Partner API. There is no report type for it, and the request for one on Amazon’s own repository was never granted.
That manual flow produces a perishable file, not a data source. Requested reports sit in the repository and expire, so last quarter’s request is no longer downloadable and has to be requested again. Fine for answering one question. Not something you can build a monthly close on, and not something you can point a BI tool at.
Amazon’s Finances API returns the underlying events, not the report. The listTransactions operation gives you transactions for a posted-date range with per-item fee breakdowns. So the raw material is genuinely reachable. What you do not get is a finished ledger: you have to page through the full history, normalize roughly 35 raw Amazon fee names into categories a human can read, group events into the settlements that paid them, and then prove the result ties to what Amazon actually deposited. That last step is the one that bites, and developers have been publicly stuck on it for years.
That reconstruction is what Data Hub already did. Not access to hidden data, but the finished, reconciled ledger, kept current, so nobody on your team is maintaining a financial ETL pipeline as a side project.
Does it reconcile?
Yes, and here is the measurement rather than the adjective. We compared a full fiscal year of Amazon’s own settlement totals against the totals reconstructed in Data Hub, for a Seller Labs customer doing about $2.9M a year on Amazon.
| Metric | Value |
| Settlements compared | 52 |
| Amazon’s total | $2,912,450.06 |
| Seller Labs’ reconstructed total | $2,912,452.81 |
| Variance | -$2.75 |
| Variance as a percentage | -0.000094% |
| Transaction line items reconciled | 983,067 |
| Settlements matching to the penny | 50 of 52 |
Two of the 52 settlements were not penny-exact. The worst was off by $3.32 on a settlement of $209,149.07, which is 0.0016% of that settlement. We investigated the cause and could not confirm it, so we are not going to offer you a theory about it.
We publish the misses because a report claiming to be flawless is a report nobody in finance believes. Fifty of fifty-two exact, worst case $3.32 out of $209,000, is a number you can take to a CFO. You can run the same comparison on your own account by asking the MCP Server for your settlement totals next to Amazon’s.
What to know before you close a month
Four things, stated up front rather than left for you to discover mid-reconciliation. Some are limits, one is a design choice you need to know about. If your underlying question is why a Seller Central figure and a Seller Labs figure disagree at all, start with Why Seller Central and Seller Labs Numbers Can Differ, which covers the general case.
Lines are timestamped by posted date, not order date
Each line carries the moment the financial event posted to Amazon, typically at shipment or charge, which is not the date your customer placed the order. Amazon defines it the same way for its own Payment Date Range reports: they cover transactions “based on the date when transactions were posted to your account. This may not correspond to the order date or the shipment date.” If you need true order dates alongside the fees, ask the MCP Server to join your order data, and it will build that query.
Because posting runs behind ordering, some lines land in a different calendar month than the sale. Here is what we measured across two accounts.
Average posting lag, order date to posted date. Before Amazon’s DD+7 reserve policy, both accounts ran between 1.2 and 2.5 days, and one held that range across five consecutive settlements (2.49 days across 262,614 order lines all-time). After the DD+7 cutover on March 12, 2026, the account we could observe through the change jumped to roughly 10 days and stayed there, matching the 7-day hold Amazon added. So expect a couple of days before DD+7, and around 10 days for a US or Canada account after it, depending on how fast your orders deliver.
The share of lines crossing a month boundary is a different story, and we deliberately will not give you one number for it. It is not a property of your business; it is a function of where a two-week settlement window happens to sit relative to the first of the month. On a single account with essentially unchanged posting lag, consecutive settlements measured 0.69% and 98.69%. Another settlement on that account came in at 0.37% despite a 10-day lag, purely because its window ended on the month boundary. Across all settlements on one account the all-time figure was 8.64%, with individual windows ranging from 0.44% to 14.54%.
The practical read: settlements straddling the first of the month carry nearly all your cross-month lines, and settlements sitting inside a month carry almost none. Any single percentage, ours included, describes one window rather than your business. Ask the MCP Server to measure your own.
It is a settled-transactions report, and it does not yet carry deferred status
It shows what posted and settled. You can reconcile what landed in your bank to the penny, but you cannot see the funds Amazon is currently holding under DD+7 behind it.
This is the one place where Amazon’s own reporting is currently ahead of ours, and we would rather say so than have you find out at close. As of April 30, 2026, Amazon’s Date Range Transaction Report for US, Canada, Mexico, and Brazil includes a deferred-or-released status column and a Transaction Release Date column, and its Finances API exposes the same per transaction. We do not carry either field today. If tracking your held balance is the priority right now, use Amazon’s report for that specific question and use this report for reconciling what actually settled.
Timestamps are UTC, and Amazon’s manual download is not
When you download the Unified Transaction Report from Seller Central, the timestamps come in marketplace-local time, which for a US account means Pacific, shifting with daylight saving twice a year. Data Hub stores transaction_ts in UTC. Both are correct; they are different clocks, 7 or 8 hours apart depending on the month.
That difference lands squarely on month boundaries. A transaction posting late on January 31 Pacific is already February 1 in UTC. Compare a Seller Central download against a Data Hub query on naive dates and a handful of transactions look like they are in the wrong month, which reads as missing data when it is really a clock difference. UTC is deliberate: it is the one timestamp that never shifts under you, so it stays stable across daylight saving and across marketplaces in different zones. The report also carries transaction_ts_marketplace, the same instant rendered in marketplace-local time, if you want to eyeball a row against Amazon’s file.
Multi-currency is untested
Every figure on this page comes from USD marketplaces. We are not claiming reconciliation accuracy for non-USD venues.
Why this matters for agencies and high-volume sellers
When a client or an outside accountant challenges your numbers, the answer cannot be “trust the dashboard.” It has to be a settlement total that ties to a bank deposit, with every fee line behind it.
Because this lives in Data Hub rather than in a report you have to re-request, that proof is a repeatable question across every account you manage. A seller can add their agency or accountant as a user on their Seller Labs account, and from there the advisor can query the client’s Data Hub through the MCP Server directly, which is often the difference between resolving a dispute in an afternoon and trading spreadsheets for a week.
Prefer to write your own SQL?
Data Hub gives you standard MySQL credentials, so you can query these tables directly. Start from sl_transactions_pivot for the reconciled per-order rows and group by settlements for deposit cycles, pulling exact field names from the Data Dictionary.
One thing to know if you are writing date filters by hand: convert the bounds of your range, not the column. Wrapping transaction_ts in a timezone conversion forces a conversion on every row before comparing, which defeats the index and turns a fast query slow.
SELECT SUM(product_revenue)
FROM sl_transactions_pivot
WHERE transaction_ts >= CONVERT_TZ('2025-10-01', 'America/Los_Angeles', 'UTC')
AND transaction_ts < CONVERT_TZ('2025-11-01', 'America/Los_Angeles', 'UTC')For most people, asking the MCP Server is faster and there is nothing to maintain.
For the full reconciliation query, including the three rules that make it tie to the cent and the check that proves it tied for the right reasons, see How to Reconcile an Amazon Settlement to the Penny with SQL.
Get started
The Amazon MCP Server connects Claude (and other AI assistants) to your Amazon data so you can ask questions in plain English. It is powered by Data Hub, a centralized Amazon data warehouse holding your full order lifecycle, fee breakout, and settlement history in one place. The MCP Server is available on the Genius Bundle plan.
New to the MCP Server? Start with Connecting the Amazon MCP Server to Claude. To go deeper on tying deposits back to orders, see How to Reconcile Amazon Orders From Creation to Settlement.