A financial transaction is one posted entry in Amazon's ledger for your account: a charge, a fee, a payment or an adjustment, posted on a date, in a marketplace, with a total. This report is the Finances API's listTransactions feed, and one row of it is one transaction, identified by transaction_id, posted at posted_date, carrying transaction_type, transaction_status, description, total_amount beside total_amount_currency_code, the marketplace (reported_marketplace_id, marketplace_name), selling_partner_id and account_type. A transaction Amazon is holding back also carries deferral_reason and maturity_date.

Each transaction document nests four collections, so the file lands as six tables, and the field reference below is grouped under one heading per table — which is why transaction_id and posted_date appear once under each of the six. After the transactions table come:

- Items — one row per item in the transaction, keyed by transaction_id and item_index, with the item's own description and total_amount, and its product context flattened on: asin, sku, fulfillment_network, quantity_shipped. Every item has exactly one. - Item-level breakdowns and transaction-level breakdowns — the recursive tree of what an amount is made of. Each node is a row with its level, its slash-joined breakdown_path (Expenses/AmazonFees/Commission), its breakdown_type and its breakdown_amount. Four levels were observed in production, Sales down through ProductCharges to Base, and parents are written before children. - Item identifiers and transaction identifiers — name/value pairs Amazon attaches, related_identifier_name and related_identifier_value, at both levels.

Two facts about the shape matter more than any column. A breakdown parent's amount already sums its children, so a breakdown table is a tree, not a list to total. And every child row carries posted_date copied from its transaction, because posted date is the axis the whole report is filtered and re-stated on.

Transactions arrive in three statuses — RELEASED, DEFERRED and DEFERRED_RELEASED — and a deferred one changes status in place, to DEFERRED_RELEASED, when it is released; maturity_date is the date Amazon is due to release it. Amazon also sends an address context on transactions, but it arrives with no fields at all without a restricted data token, so it is not carried here. The column set was established from 2,500 production transactions in the US marketplace.

There is no Reports API report type for this data. It comes from the Selling Partner API Finances API, version 2024-06-19, through the listTransactions operation on GET /finances/2024-06-19/transactions — a synchronous, paginated live endpoint. The posted-date window is postedAfter and postedBefore, the store is marketplaceId, and pagination is nextToken; transactionStatus, relatedIdentifierName and relatedIdentifierValue narrow the result further. Amazon marks every parameter optional, but postedAfter is required unless you pass a related identifier, both dates must be more than two minutes older than the request, and you have to follow nextToken until it comes back null because the operation can return empty pages in the middle of a result. The response is JSON, and each transaction document nests the four collections that become the six tables.

The nearest thing in Seller Central is the Payments dashboard's Transaction View tab. Amazon's own seller site gives two ways to it — Reports → Payments, then the Transaction View tab, or Payments → Payments, which opens the dashboard on Statement View. Amazon does not say what that tab carries, so treat it as where to eyeball a transaction, not as an export of this feed.

Unlike the region-wide flat-file reports, the marketplaceId parameter here is honoured: a response is one marketplace, and in 2,500 of 2,500 validated transactions the document's own marketplace matched the one requested. So to cover an account you make one call per marketplace, and you can trust reported_marketplace_id on each row.

The window is a posted-date filter, and the rows it returns are their current state. One request's span is capped: if postedAfter and postedBefore are more than 180 days apart the response comes back empty, so a backfill has to be walked in windows rather than asked for in one call. Amazon also warns that the response "might not include orders from the last 48 hours", which makes the newest two days of any window provisional. And because a deferred transaction's status flips when it is released, a day you pulled once is not final, so a rolling window of posted days has to be re-pulled and re-stated rather than read once and kept.

The trap that stops the call working at all is authorization vintage. An older refresh token, granted before this operation existed for your app, answers 403 Access to requested resource is denied on listTransactions — even while the same credential's v0 listFinancialEvents works. The grant is per operation, not per API version; the same old credential is refused on v0 listFinancialEventGroups too. The fix is for the seller to re-authorize the app, and nothing in the request changes.

Main table

items

item_level_breakdowns

item_related_identifiers

transaction_level_breakdowns

transaction_related_identifiers

Getting the real fee on a single order item. Filter the item-level breakdowns to one transaction_id and item_index, then to the leaf you want by breakdown_path — for example Expenses/AmazonFees/Commission — and read breakdown_amount. The item row beside it gives the asin, sku and quantity_shipped the fee applied to.

Knowing how much cash Amazon is holding. Transactions with transaction_status of DEFERRED are money that has posted but not released. Sum their total_amount grouped by total_amount_currency_code, and use maturity_date to see when each is due and deferral_reason to see why it is held.

Building a per-SKU net from the ledger. The items table carries sku and asin on every item, and the item-level breakdowns split each item's amount into sales and fees. Joining the two on transaction_id and item_index, and keeping one level of the tree, gives net proceeds per SKU per posted day without a settlement file.

Keeping marketplaces apart in a multi-country account. One call is one marketplace and every row carries reported_marketplace_id, so a European or North American account can be reported per country from this feed without the currency guesswork the account-level event groups require.

Tracing a transaction back to its source record. The identifier tables hold the name/value references Amazon attaches at transaction and item level, related_identifier_name beside related_identifier_value. Amazon's reference enumerates the transaction-level names as ORDER_ID, SHIPMENT_ID, FINANCIAL_EVENT_GROUP_ID, REFUND_ID, INVOICE_ID, DISBURSEMENT_ID, TRANSFER_ID, DEFERRED_TRANSACTION_ID, RELEASE_TRANSACTION_ID and SETTLEMENT_ID, and gives items a separate, shorter list — ORDER_ADJUSTMENT_ITEM_ID, COUPON_ID, REMOVAL_SHIPMENT_ITEM_ID and TRANSACTION_ID. These are the hooks to match a ledger entry to the order, refund or payout it came from.

Summing a breakdown table double-counts. Each node's breakdown_amount already includes its children — the Sales node includes ProductCharges, which includes Base. Totalling a breakdown table across all rows counts every leaf once per ancestor. Filter on level, or on a path prefix, before you add anything.

Statuses change in place. RELEASED, DEFERRED and DEFERRED_RELEASED all appear, and a DEFERRED transaction's status changes when its maturity_date passes, on a row you may already have stored. Anything that pulls a posted day once and keeps it will hold stale statuses. Re-pull a rolling window of posted days and overwrite.

Six tables share column names. transaction_id, posted_date, description, total_amount and item_index each appear in several tables. A join on transaction_id alone fans out across items; anything below an item needs item_index as well.

Money is not converted. Every amount carries its own currency code, and nothing is converted. Group on the currency code before summing.

Address data is absent. The address context Amazon attaches arrives with no fields at all unless the call carries a restricted data token, so it is deliberately not part of this report.

Old authorizations get 403. A seller who authorized your app before listTransactions was part of its grant is denied on it until they re-authorize, even when other Finances calls succeed for them. It looks like a permissions bug in your code and is not one.

Some vocabularies are open-ended, and some are just unpublished. breakdown_type Amazon states outright is "an open-ended string" with no published list of values, added to as needed — so Sales, ProductCharges and Base are examples, and anything reading a breakdown table has to tolerate a type it has never seen. The rest is silence rather than openness: the reference settles the three status values and both identifier-name lists, but documents transaction_type with a single possible value, Shipment, which plainly is not the whole set, and gives account_type and fulfillment_network no value list at all. Amazon also publishes no earliest date for the operation — only the 180-day cap on one request's span — so how far back it answers is unknown until a real backfill is run.