A financial event group is one of Amazon's settlement periods: the window in which financial events accumulate before Amazon disburses the balance to your bank. This report is the list of those groups for the account — one row per group, identified by financial_event_group_id, bounded by financial_event_group_start and financial_event_group_end.

The columns fall into three sets. The status pair — processing_status and fund_transfer_status — say whether the group has closed and whether its money has moved; the second lags the first, because a group closes and only then does its transfer settle. The money columns are beginning_balance, original_total and converted_total, each a decimal sitting beside its own currency code. The transfer columns — fund_transfer_date, trace_id and account_tail — describe the payout itself: when it went, the reference Amazon attached, and the last digits of the account it landed in.

The file belongs to the account, not to a marketplace. The payload carries no marketplace at all, and a single North America response mixes USD and CAD groups, so the currency code is the file's only geography. The column set is established from 108 production groups.

It is a snapshot, not a date-ranged extract. Rows change in place as a group closes and then settles, and a response is the full current picture of the groups its window matches rather than a slice of new ones.

There is no Reports API report type for this data. It comes from the Selling Partner API Finances API, version v0, through the listFinancialEventGroups operation — a synchronous, paginated endpoint. You call it with a marketplace and a date window, follow the pagination token until the last page, and combine the pages yourself.

Two things about the request catch people. First, the operation has no marketplace parameter at all — Amazon's reference lists only MaxResultsPerPage, FinancialEventGroupStartedBefore, FinancialEventGroupStartedAfter and NextToken — so the marketplace you pass selects the regional endpoint and nothing else; the groups that come back are the account's, whatever the marketplace. Pulling once per marketplace in the same region gets you the same groups several times over. Second, the date window is a retrieval filter with overlap semantics, not a data range: it matches groups whose period overlaps the window, and the rows it returns are their current state, not their state during the window. Re-pull the whole window; do not treat one pull as the delta since the last.

The trap that stops the call working at all is authorization vintage. An older refresh token, granted before the Finances operations existed for your app, answers 403 Access to requested resource is denied on listFinancialEventGroups even while the same credential's other Finances calls work — the grant is per operation. The fix is for the seller to re-authorize the app; there is nothing to change in the request.

Reconciling a bank deposit to an Amazon settlement. A deposit arrives and the question is which period it covers. Match the deposit to fund_transfer_date and account_tail, confirm the amount against converted_total in converted_total_currency_code, and use trace_id as the reference. financial_event_group_start and financial_event_group_end then tell you which sales the deposit is paying for.

Knowing what has been paid and what is still owed. Groups whose processing_status shows them closed but whose fund_transfer_status is not yet settled are money Amazon holds but has not sent. Their original_total, grouped by original_total_currency_code, is the receivable.

Splitting payouts by currency in a multi-country account. A North America account gets USD and CAD groups in the same response. Grouping on original_total_currency_code is the only way to separate them, because no marketplace column exists to do it.

Anchoring transaction-level analysis to a settlement period. financial_event_group_id is the key that the individual financial events post against. Pull the groups first to find the period you care about, then fetch its events, rather than guessing at date boundaries.

Spotting a payout that did not happen. If a closed group comes back with no fund_transfer_date long after its financial_event_group_end, that is worth a look at your bank details on file — a failed transfer sits here before it shows anywhere else you will notice.

Rows mutate. The same financial_event_group_id returns with a different processing_status, fund_transfer_status, fund_transfer_date and totals as the group moves from open to closed to disbursed. Anything that stores the first version of a row and never revisits it will hold stale statuses and provisional totals. Overwrite by id on every pull.

The date window is not a data range. It filters which groups come back by overlap with their period; it does not filter or restate the values inside them. A window covering last month returns groups that touched last month, in their current state.

One response is one account, not one marketplace. There is no marketplace column, and the marketplace parameter only chooses the regional endpoint. Pulling per marketplace duplicates the groups; summing money across rows without grouping on the currency code mixes currencies. In Europe the disbursement currency does not even identify a country — EUR spans too many marketplaces to place.

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

Status values are half documented. Amazon gives processing_status two values, Open and Closed, and its use-case guides filter on exactly that pair. It gives fund_transfer_status no value list at all, and its own sandbox example returns strings matching neither field's documented vocabulary. Which columns are empty while a group is open is also unstated — the response schema marks no property required and says nothing about when one is absent — so the blank transfer columns on the open group in the sample read the column meanings, not a documented rule.

One request spans at most 180 days. Amazon states that if the window's two dates are more than 180 days apart, no financial event groups are returned — not an error, just an empty list. Whether the endpoint answers older windows walked backwards in 180-day steps, and how far back it holds groups at all, Amazon does not publish, and it has not been tested against a real pull.