Ask the Seller Labs MCP Server, in plain English, to reconcile your Amazon orders from the moment they’re placed to the day Amazon pays you. It traces every order through its full lifecycle — placed, deferred, released, settled — and breaks each payout into product revenue, fees, tax, and net deposit. The MCP Server runs on Data Hub, your centralized Amazon data warehouse, so the entire order-to-payout history is one question away instead of a spreadsheet project.
Why Amazon reconciliation is hard
Amazon doesn’t pay you when an order ships. It charges the customer, holds the funds, and releases them in batches on a roughly 7–14 day delay. Between “order placed” and “money in the bank,” every order passes through several states — and Seller Central’s built-in reports won’t give you a clean order-to-payout view.
For an agency managing multiple client accounts, that turns reconciliation into a recurring, high-stakes chore: every client wants proof that each deposit matches their orders and that Amazon’s fees are what they said they’d be. Done in spreadsheets, it’s slow and error-prone.
Built for agencies and high-volume sellers
This is where the Seller Labs MCP Server changes the workflow. Because every account’s full order lifecycle lives in Data Hub, reconciliation becomes a repeatable question you can ask across accounts — in plain English — instead of a monthly spreadsheet rebuild:
-
“Show me every order that made up last week’s deposit, with fees broken out.”
-
“Which orders are still deferred, and how long have they been waiting?”
-
“What was my net payout after fees and tax for last month, by SKU?”
The AI writes the SQL against that client’s Data Hub and returns the answer. That’s the difference between having Amazon’s data and being able to answer questions with it.
What it looks like in practice
Here’s a reconciliation question and what comes back — no SQL, no spreadsheet:
You ask: “Show me every order in last week’s settlement, with fees broken out and the net payout.”
The MCP Server returns a per-order table like this:
| Order ID | Product revenue | Selling fees | FBA fees | Tax collected | Net payout |
| 1XX-XXXXXXX-XXXXXXX | $42.99 | -$6.45 | -$5.43 | $3.01 | $34.12 |
| 1XX-XXXXXXX-XXXXXXX | $18.50 | -$2.78 | -$3.22 | $1.30 | $13.80 |
| … one row per order, totaling to the deposit amount. | |||||
You can follow up in the same conversation — “now only the FBM orders,” or “total the net payout by SKU” — and the MCP Server re-runs it. (Figures shown are illustrative.)
Key concepts
-
Order placed (deferred): The order exists and the customer has been charged, but Amazon hasn’t released the funds yet. The money is “deferred.” This is where most of your recent orders sit at any moment.
-
Released / settled: Amazon closes a settlement period and releases the net payout — product revenue minus selling fees, FBA fees, and other deductions.
-
Settlement: The batch event that groups released transactions and corresponds to a deposit cycle.
-
Reconciliation: Matching each settlement’s payout back to the specific orders (and their fees) that produced it.
The order lifecycle, stage by stage
Because the MCP Server queries a centralized warehouse, you can follow one order through every stage:
-
Order is placed — it appears with revenue recognized but payment still deferred. No settled payout yet.
-
Funds are deferred — the order waits out Amazon’s hold period. The aging of these deferred orders is your “money not yet released” view: which orders are still pending, and how long they’ve waited.
-
Funds are released — the order moves into a reconciled per-order view that breaks the payout into product revenue, selling fees, FBA fees, shipping revenue, tax collected, tax withheld, and net payout.
-
Settlement closes — the released transactions roll up into a settlement record tied to the deposit cycle.
Because all four stages live in the same data layer, you can answer “which orders made up this deposit?” and “how much am I still owed?” with a single question.
What you can break out per order
For each reconciled order, you can audit every dollar:
-
Order ID and transaction timestamp
-
Product revenue
-
Selling fees, FBA fees, and other transaction fees
-
Shipping revenue (shipping credit) — its own field
-
Shipping expense for merchant-fulfilled orders
-
Product and shipping tax collected, broken out separately so you can produce a clean net-of-tax figure
-
Marketplace tax withheld
-
Total net payout
-
The settlement the order was paid in, and the event type
The tax fields being broken out separately matters: most Seller Central exports won’t give you a net-of-tax revenue figure directly.
A worked example
Take a single order placed on June 8. Immediately after the sale it shows up with revenue recognized, but no payout row yet — it’s deferred. About a week later, around June 16, that same order releases into a settlement with its full fee breakdown and a net payout.
Run the same view across a date range and you can watch the entire deferred-payment aging curve: which days’ orders are still pending, and which have settled. That curve is your answer to “how long until my money settles” — measured on your own historical pattern, not a generic estimate.
ℹ️ On release-date precision: Amazon doesn’t expose an exact future release date for an unsettled order at scale. What a data warehouse gives you is better in practice — your actual historical deferral pattern (typically ~7–14 days), so you can estimate when pending orders will pay out based on how that account has behaved.
Going deeper: how the MCP Server reconciles for you
You never touch the schema, but knowing what the MCP Server reaches into makes your prompts sharper. It has context on your Data Hub schema, so it knows which tables hold each stage of the lifecycle:
-
orders / order_items — where an order first appears, deferred, before any payout.
-
transactions (described by transaction_types) — the raw financial event stream tied to each order.
-
sl_transactions_pivot — the reconciled per-order view it leans on most: one clean row per order with revenue, fees, tax, and net payout already separated.
-
settlements — groups released transactions into the batch matching a deposit.
Because it understands those relationships, a plain-English question becomes the correct multi-table query. Exact column names live in the Data Hub Data Dictionary and stay current there — you never have to memorize them, and neither do your prompts.
Edge cases the AI handles for you
A few things make reconciliation queries tricky by hand — and are exactly what the MCP Server takes care of:
-
Fees bucketed in the reconciled view. Certain merchant-fulfilled shipping costs roll into a broader fee column. Ask for them “itemized” or “broken out separately” and it drops to the raw transaction ledger where each sits on its own line.
-
Tying orders to a specific deposit. The settlement identifier isn’t stored identically everywhere, so a naive match can miss. The MCP Server handles the linkage — you just ask to “reconcile this deposit back to its orders.”
-
Estimating when deferred money lands. Amazon doesn’t publish an exact release date, so ask “based on my history, when are these deferred orders likely to settle?” and it estimates from your own deferral pattern (typically ~7–14 days).
Prefer to write your own SQL?
Data Hub gives you standard MySQL credentials, so you can query these tables directly or connect a BI tool like Looker Studio or Tableau. Start from sl_transactions_pivot for the reconciled per-order rows, compare orders against it to find still-deferred orders, and group by settlements for deposit cycles — pulling exact field names from the Data Dictionary. For most people, asking the MCP Server is faster and there’s nothing to maintain.
Get started
The Seller Labs MCP Server connects Claude (and other AI assistants) to your Amazon data so you can ask questions in plain English. It’s powered by Data Hub — a centralized Amazon data warehouse that holds the full order lifecycle, fee breakout, and settlement history in one place, with 2 years of history. The MCP Server is available on the Genius Bundle plan.