The FBA Fee Preview report is Amazon's own answer to "what will you charge me to sell this?" for every FBA offer in the account. One row is one offer: a sku in one amazon_store. The same SKU listed in two stores is two rows, and each row names its own store, because the file is not filtered to the marketplace you requested it from — it covers the whole region at once.

The columns fall into five groups. Identity: sku, fnsku, asin, amazon_store. Catalogue attributes: product_name, product_group, brand, fulfilled_by. Pricing: your_price and sales_price, in the row's currency. The physical inputs Amazon priced the offer from: the three sides sorted by size, length_and_girth, item_package_weight, their units, and the product_size_tier those add up to. Then the fees themselves, twice over.

The first set of fee columns is prefixed estimated_ or expected_ and describes the current fee schedule: the referral fee per unit, the variable closing fee, order handling per order, pick and pack per unit, weight handling per unit, expected_fulfillment_fee_per_unit and estimated_fee_total. The second set carries future_ in the name and repeats the fulfilment components — order handling, pick and pack, weight handling, the fulfilment fee and a total — under the schedule that takes effect next. There is no future referral fee or future variable closing fee column; the future set is fulfilment-only.

Note what is not here: a date. The file describes the estimates as of the moment it was generated. Nothing in it says when a fee changed or what it used to be, so a history of a SKU's fees is something you build by keeping each pull, not something you can request.

Through the Selling Partner API, this is the Reports API report type GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA. You call createReport with that type, poll the report until Amazon marks it done, and download a tab-separated file. Amazon's report-type entry tells you to set dataStartTime to at least 72 hours before now and dataEndTime to now; both are optional parameters on createReport, which notes that not all report types use them, and a request that passes no range at all still returns a file. Either way what comes back is the current estimates — there is no date column in the output to select on.

The trap is the marketplaceIds filter, which Amazon ignores for this report. Whatever marketplace you name, the file holds every FBA offer the seller has across the endpoint's region, one row per SKU per store, with each row naming its own store in amazon_store. Requesting one account's report from the US and from Canada on the same day returned the same 13,524 rows in the same order, byte-identical in every column the two files shared.

What the filter does change is the column set. Only the request made against the US marketplace comes back with all 31 columns; a request from elsewhere in the region drops three, product_size_tier among them. So: request it once per region, from the US, and treat amazon_store as the marketplace column. Requesting it once per marketplace does not give you per-marketplace files — it gives you the same region-wide file several times, each stamped with a marketplace that accounts for only a fraction of its rows, and it burns a createReport call each time against a published rate limit of one call a minute.

In Seller Central the same file is the Fee Preview report: from the main menu choose Reports → Fulfillment, then Fee Preview under Payments in the left-hand list, and pick a file type to download.

Seeing an announced fee change before it lands. estimated_fee_total against estimated_future_fee, and the current against the future_ versions of pick and pack, weight handling and order handling, is the per-SKU delta of the next fee schedule. Sort by the gap, weight it by how much you sell of each, and you have the list of SKUs whose price or packaging needs a decision before the date.

Finding SKUs that are one measurement away from a cheaper tier. product_size_tier sits next to the exact longest_side, median_side, shortest_side, length_and_girth and item_package_weight that put the item there. An offer a fraction of an inch or an ounce over a tier boundary is paying the higher tier's estimated_weight_handling_fee_per_unit on every unit, and this is the only place both the tier and the inputs appear in one row.

Catching wrong dimensions or weight on file. If item_package_weight or the sides are not what your packaging actually measures, the fulfilment fee is being computed from a phantom package. Comparing this file to your own measurements is how you find the SKUs worth a re-measurement request.

Working out margin per SKU before COGS. your_price less estimated_referral_fee_per_unit less expected_fulfillment_fee_per_unit is what Amazon expects to leave you per unit, in the row's currency. Those are two of the row's fee columns and not all of them — the variable closing and order handling fees sit outside that subtraction, and estimated_fee_total is Amazon's own headline number if you would rather not assemble one. It is an estimate, but it is Amazon's estimate, which is a better input to a pricing decision than a fee calculator.

Auditing one account across a region. Because the file is region-wide, grouping on amazon_store gives you every store's fee exposure from a single request — and shows you which SKUs are listed in one store but not another.

The marketplace filter does nothing to the rows. Request from any marketplace in the region and you get the same rows in the same order. If your pipeline requests once per marketplace and stamps each file with the marketplace it asked for, you have three copies of the region and every copy is mislabelled — Canadian offers filed under the US and vice versa. The store is amazon_store, and only amazon_store.

The marketplace filter does change the columns. Only the US request returns all 31; a request from another marketplace returns 28, and product_size_tier is one of the three that vanish. Code that takes "whichever marketplace comes first" will silently lose the size tier for any account whose marketplace list does not start with the US.

Amazon does not publish where this report is available. Its report-type entry gives an Availability line naming a seller type — FBA sellers — and no Amazon store availability line, which is the field the same page uses to pin the FBA Multi-Country Inventory report to Europe and the FBA Promotions report to North America. Everything on this page about the file was measured on North American accounts. Whether a seller elsewhere gets the same file, or the report at all, is not something Amazon states, so this page does not.

These are estimates, not charges. The columns say estimated and expected, and mean it. What Amazon actually deducted is in your settlement and finance reports; this file tells you what Amazon expects to deduct at today's price, dimensions and schedule.

Per-order and per-unit fees do not add without an assumption. estimated_order_handling_fee_per_order is per order; every other fee component is per unit. Adding them together prices a one-unit order, which is fine only if that is what your orders look like.

Money is not converted. A region-wide file carries several currencies. Sum fees without grouping on currency and you are adding Canadian dollars to US dollars to pesos.

There is no date column. The file is a snapshot. If you want to know when a fee changed, you need yesterday's file as well as today's.

createReport is rate-limited. Amazon publishes the default usage plan for createReport as 0.0167 requests per second with a burst of 15 — one call a minute, and the plan is on the operation, so every report type you request draws on the same allowance. Given the file is identical for every marketplace in the region, requesting it more than once per region spends those calls to write the same rows again.