Amazon seller central Financial Events / listTransactions API: can it be used to automate reconciliation of Seller Fee Invoice CSV breakdowns?

[michelexport]

Hi everyone,
Amazon Seller Central's Tax Document Library now provides, alongside the PDF Seller Fee Invoices, a CSV with the transaction-level breakdown of each invoice (transaction ID, order ID, fee type, amounts). This is very useful for sellers who need to reconcile the invoices they receive from Amazon against their own accounting/order data, and it's one of the most frequent requests we get from businesses.
Looking at the finances/2024-06-19 listTransactions model, I see that relatedIdentifiers supports an INVOICE_ID value alongside ORDER_ID and others, and that each transaction includes a breakdowns structure detailing the charge types and amounts.
Could you confirm: is listTransactions (or the older Financial Events API v0) intended to be used to programmatically reconstruct the same transaction-level data shown in the Seller Fee Invoice CSV, e.g. by filtering on INVOICE_ID? If so, is there recommended guidance on how to reliably match listTransactions output to a specific invoice number, so sellers/developers can build automated invoice reconciliation without downloading the CSV manually from Seller Central?
Thanks for any clarification.

[gabrielbarretodev]

Yes — listTransactions (finances/2024-06-19) is the right API to build this on, and it's the one to commit to since the Financial Events v0 operations are deprecated on 28 Aug 2026.

For the Seller Fee Invoice reconciliation use case specifically, two things matter and they cut in opposite directions:

1. INVOICE_ID is in the response, so you can rebuild the invoice breakdown programmatically.
Every Transaction carries a relatedIdentifiers array, and INVOICE_ID is one of the relatedIdentifierName values (alongside ORDER_ID, SHIPMENT_ID, FINANCIAL_EVENT_GROUP_ID, REFUND_ID, DISBURSEMENT_ID, SETTLEMENT_ID, etc.). So for each transaction you read the INVOICE_ID out of that array and group by it — that reproduces the transaction-level breakdown the CSV shows, no manual download.

2. But you cannot filter the request by INVOICE_ID.
At the API level only ORDER_ID and FINANCIAL_EVENT_GROUP_ID are accepted as relatedIdentifierName query filters. Every other name in that enum — INVOICE_ID included — is informational: present in the response, not queryable. There is no "give me invoice X" call.

Approach that actually works:

• Page through listTransactions over the posting-date window (or per financialEventGroupId), following nextToken to the end.
• Bucket client-side on the INVOICE_ID found in each transaction's relatedIdentifiers.
• Sum amounts per bucket and compare to the invoice CSV/PDF total.

One gotcha that will break reconciliation if you miss it: watch transactionStatus — RELEASED vs DEFERRED vs DEFERRED_RELEASED. If you sum deferred and released together you double-count against a payout. Reconcile released amounts to the disbursement and keep deferred separate until they release.

I went through this exact settlement-to-payout matching in #5353 (Amazon's team confirmed the approach there) — happy to share the field map if it helps.