Until 2 November 2026, the Amazon VAT Transactions Report, AVTR, worked on a single fixed schedule: every taxable transaction from a given month landed in one file that only became available on the third day of the following month, and not a day sooner. A seller reconciling September's VAT waited until 3 October to see September in full, whether the file was needed for a bookkeeper, a VAT return deadline, or just to catch a misclassified return before it compounded into a filing error. Starting 3 November 2026, Amazon changed that cadence directly: the AVTR can now be requested at any point during the month it covers, for data up to three days before the request date, and requesting it again later in the same month pulls in whatever has been added or changed since the last download. Two new columns arrived in the same update, one that timestamps exactly when a transaction last changed and one built specifically for Poland's mandatory e-invoicing system, KSeF. This guide works from Amazon's own seller forums announcement and the AVTR reference pages for the UK and EU stores to walk through what actually changed, the report's existing transaction scope that the update does not touch, a worked comparison of how many days earlier a seller can now catch a transaction problem, and who the live-reporting change genuinely matters for.
Since 3 November 2026, Amazon's VAT Transactions Report can be requested at any point during the month it covers, for data up to 3 days before the request date, instead of waiting until the 3rd of the following month. Re-requesting later in the same cycle returns only what changed, tracked by a new TRANSACTION_UPDATED_DATE column, and a new GOV_INVOICE_ID column carries Poland's KSeF e-invoice number. The report's underlying scope, sales, refunds, returns and fee transactions, is unchanged; only the timing and these two columns are new.
What does the AVTR actually report?
Amazon's own description of the AVTR has not changed: it is a report with detailed data for every taxable transaction across Amazon's European stores and fulfilment network, built for a seller's own VAT bookkeeping and filing, not a tax return Amazon files on a seller's behalf. The report covers two separate transaction families. Goods transactions carry the actual commercial movements: a SALE when a customer buys, a REFUND when a seller issues money back (with a distinct code when goods are physically returned versus when they are not), plus cross-border movements between Amazon's own fulfilment centres that a seller never directly initiates but that still carry VAT consequences in each country involved. Fee transactions carry the other half of the picture, the fees Amazon itself charges the seller, and Amazon's own documentation is explicit that fee data for a given month is only added to the report once that month's fee invoices have actually been issued, which can trail the goods-transaction data for the same period. Nothing about this transaction scope changed on 3 November 2026; what changed is purely how often and how early a seller can pull the file that contains it.
Transaction family
What it captures
Who initiates it
Goods: SALE
A customer buys a product
The customer
Goods: REFUND
Full or partial money returned to a buyer; a distinct code applies when goods come back physically
The seller, after a return or claim
Goods: cross-border movement
Amazon moves inventory between its own fulfilment centres in different countries
Amazon's own fulfilment network
Fee transactions
Fees Amazon charges the seller; added once that month's fee invoices are issued
Amazon, on its own invoicing schedule
The actual change: on-demand access instead of one fixed date
Before 3 November 2026, the AVTR ran on a single cadence for every seller: data for a given month became available on the third day of the following month, full stop, and a seller who needed an earlier look at September's transactions for any reason, a bookkeeper's deadline, a suspiciously large refund, a VAT return due sooner than Amazon's own schedule allowed, had no official way to get it ahead of that date. The 3 November 2026 change, announced by Amazon's own News_Amazon account in the Seller Forums and backed by a matching reference-page update, replaces the single fixed date with an on-demand request: a seller can now request the AVTR at any point during the month it covers, and the data returned reaches up to three days before the exact request date. Requesting again later in that same reporting window returns the latest state of everything, including rows that did not exist, or looked different, the last time the file was pulled. The old fixed monthly deadline has not been removed; it still marks when a month's figures are considered settled and complete, but a seller is no longer limited to viewing that month only once it closes.
Before 2 Nov 2026
From 3 Nov 2026
When could a seller first see October's data?
3 November 2026 only
Any day during October, data up to 3 days before the request
Re-downloading the same month
Returned the same finalized file again
Returns the latest state, including anything added or changed since the last pull
How to spot what changed since the last download
Re-read the whole file and compare by hand
Filter on the new TRANSACTION_UPDATED_DATE column
Poland e-invoice reference in the report itself
Not present
GOV_INVOICE_ID column, populated for Poland (KSeF) at launch
The two new columns, and what each one is actually for
Both new columns solve a specific, narrow problem rather than adding general detail. TRANSACTION_UPDATED_DATE records the date each individual transaction row was last updated, independent of when the underlying sale or refund itself originally happened; Amazon's own guidance points sellers at this column directly as the way to identify anything added or changed since a previous download, which only matters once on-demand, repeated requests are possible within the same month, a column like this on a report that only ever existed in one finalized version per month would have had no use case. GOV_INVOICE_ID carries the government-assigned e-invoice number for a transaction, and at launch it is populated only for Poland, tied to that country's mandatory KSeF (Krajowy System e-Faktur) e-invoicing system; Amazon states support for additional countries will be added later, so a seller selling into other EU markets with their own e-invoicing mandates should expect this column to stay empty for those transactions for now, not to assume the column is broken or the data missing in error.
This is a Beta feature
Amazon's own help page for live AVTR updates is marked explicitly as a Beta feature being rolled out gradually; it states the capability might not be available on every seller account yet. A seller who requests the report mid-month and still only receives the old fixed-date behaviour should check again after the rollout reaches their account rather than assuming the forum announcement does not apply.
A worked comparison: how many days earlier can a seller actually see a problem now
The scenario below applies Amazon's own stated rules (report available up to 3 days before the request date; the pre-update fixed date of the 3rd of the following month) to a constructed request, built to make the timing concrete, not a real account's filing history. A seller wants to check October 2026's transactions for a VAT reconciliation. Under the fixed-date rule that applied before 2 November 2026, the earliest that seller could see any part of October's data was 3 November 2026, after the month had fully closed. Under the live-reporting rule in force from 3 November 2026, the same seller can instead request the report on 15 October 2026, while October is still open, and receive data covering every transaction through 12 October 2026, three days before that request date. The gap between the old earliest-possible look, 3 November, and the new earliest-possible look, 15 October, is 19 days, computed directly from the calendar, not an estimate; those 19 days are the real head start a seller gets on catching a misclassified return, a VAT rate applied to the wrong country, or a duplicate fee line, before the month even closes rather than after. Requesting the report again on 20 November, once October has fully settled and November is itself underway, now returns the latest state of everything through 17 November, three days before that second request, picking up any rows Amazon added or corrected since the October check, each flagged with its own TRANSACTION_UPDATED_DATE.
Request
Request date
Data covers through
Days earlier than the old fixed date (3 Nov)
Old rule (pre-2 Nov 2026)
3 November 2026 (earliest possible)
All of October
0 (this was the baseline)
New rule, 1st check
15 October 2026
12 October 2026
19 days earlier
New rule, 2nd check
20 November 2026
17 November 2026
n/a (checking a later cycle, not October again)
What this update does not change
It is worth being precise about the boundary here, because a timing-and-columns update is easy to mistake for a bigger policy shift than it actually is. The VAT rates applied to a sale are unchanged, those are set by each country's own tax law and Amazon's own tax calculation service, not by the report that documents them after the fact. A seller's actual VAT filing deadlines with their own tax authority are unchanged too; the AVTR is a data source a seller or their accountant uses to prepare a return, not the filing itself, and no filing due date moves just because the underlying report can now be pulled earlier. The One Stop Shop (OSS) and Import One Stop Shop (IOSS) simplified EU VAT schemes, which many sellers use to cover distance sales across multiple EU countries from a single registration, are untouched by this change as well; a seller on OSS or IOSS still reconciles against the same scheme rules, just with earlier visibility into the Amazon-side transaction data that feeds that reconciliation. And the core transaction categorization inside the report, which code a SALE gets versus a REFUND, how a cross-border fulfilment movement is tagged, has not been restructured; the new TRANSACTION_UPDATED_DATE and GOV_INVOICE_ID columns are additions to the existing row structure, not a redesign of it.
Mistakes the on-demand change makes easy to fall into
Assuming the Beta is live on every account because the forum post is public. Amazon's own help page states this is a gradual rollout; a seller whose mid-month request still returns the old fixed-date behaviour most likely has not reached it yet, not hit a bug.
Re-reading an entire re-downloaded file line by line to find what changed. That is exactly what TRANSACTION_UPDATED_DATE exists to avoid; filter on it instead of comparing two full exports by eye.
Treating an empty GOV_INVOICE_ID as a data error outside Poland. At launch the column is only populated for KSeF transactions; an empty value for a German or French sale is the expected, current state, not a defect to report.
Expecting fee transactions to appear on the same early timeline as goods transactions. Fee data for a month is only added once Amazon issues that month's fee invoices, a separate schedule the on-demand request timing does not accelerate.
Pulling a mid-month report and treating it as the final, settled figure for that month. It is explicitly a partial, up-to-3-days-ago snapshot; the month's transactions can still change before it closes.
Skipping the AVTR Live Reporting survey when something looks off. Amazon is actively collecting Beta feedback through it; an edge case reported there is more likely to get fixed than one never reported anywhere.
Who does this live-reporting change actually matter for?
Not every seller will notice this change in their own workflow; a seller who only ever opened the AVTR once a month after it was already final, purely as an archive, gets little practical benefit from being able to request it earlier. The sellers who do feel the difference are the ones whose own process was previously bottlenecked by Amazon's single fixed release date, not by anything in their own control.
A seller with a VAT filing deadline that falls before Amazon's own 3rd-of-the-month release date. The old fixed schedule simply could not serve a filing due earlier in the month; the new on-demand request can.
Pan-EU or multi-marketplace sellers reconciling across several VAT registrations at once. More, earlier checkpoints during a month reduce the chance a cross-border movement or a mismatched refund sits unnoticed until the file closes.
A bookkeeper or VAT agent working from a seller's own account, not Amazon's filing. The report is explicitly a data source for the seller's own process; faster access shortens their own close cycle.
Anyone who downloaded the report twice a month before, by hand, just to catch errors early. The new TRANSACTION_UPDATED_DATE column replaces a manual full-file comparison with a single filtered column.
A seller selling into Poland. The GOV_INVOICE_ID / KSeF column is populated today; sellers elsewhere in the EU should expect it empty until Amazon extends support to their country.
Where do you actually request it, and what survey is Amazon running?
The report is requested from the same place it always was, the VAT Transaction Report screen inside Seller Central's report centre; the on-demand behaviour is a change to what that screen will now generate, not a new menu location. Amazon's own announcement links the request page directly and, separately, invites feedback through an AVTR Live Reporting survey while the Beta rolls out; a seller who hits an edge case, a column that stays empty when it should be populated, a request that still returns only the old fixed-date file, has a direct channel to flag it rather than guessing whether it is a bug or a rollout-timing gap.
The simplest way to find out whether the Beta has reached a given account is to just try it once, deliberately, rather than waiting for a second forum post confirming a wider rollout: request the current, still-open month on the report screen and check whether the file that comes back covers data up to roughly 3 days before that request, or whether it instead comes back empty or restricted to the previous, already-closed month. If it is the latter, nothing is broken; the account is simply on the old fixed-date behaviour until the gradual rollout reaches it, and the correct next step is to keep the existing monthly-after-the-fact habit in place for now rather than building a new on-demand process around a capability the account does not have yet.
Checklist for using the new on-demand AVTR
How to use the on-demand Amazon VAT Transactions Report
Confirm the Beta has reached your account before relying on it - Amazon's own help page states this is a gradual rollout; if a mid-month request still only returns the old fixed-date file, it may not be available on your account yet.
Request the report as early in the month as your process needs, not only after the month closes - Data returned covers up to 3 days before your request date, so an early request still gives a real, usable window.
Re-request later in the same cycle instead of re-reading the whole file by hand - A second request returns the latest state of everything, including anything added or changed since the first pull.
Filter on TRANSACTION_UPDATED_DATE after a repeat request - This isolates exactly what changed since your last download, rather than forcing a full re-comparison.
Do not expect GOV_INVOICE_ID populated outside Poland yet - Amazon states support for more countries is coming later; an empty value elsewhere is expected, not an error.
Remember fee transactions still trail goods transactions - Fee data for a month is only added once that month's fee invoices are issued, independent of the new on-demand timing for goods transactions.
Use the AVTR Live Reporting survey for anything that looks broken - Amazon's own announcement runs this specifically to collect Beta feedback.
What SellerMagnet can and cannot do about this
Requesting, downloading and filing from the AVTR all happen inside Seller Central and the seller's own VAT process end to end; no third-party tool, including SellerMagnet, requests this report or files a VAT return on a seller's behalf. Where a dashboard like SellerMagnet's Analytics genuinely helps alongside it is on the commercial side the AVTR does not cover: a VAT reconciliation surfaces tax-relevant totals, but it will not tell a seller whether a given month's refund volume or fee pattern is unusual for their own business, which is a question that needs the seller's own order and margin history lined up next to it, not just the government-facing figures.
A margin check through the Fee Calculator is a separate, worthwhile step for a related reason: VAT itself is collected and remitted on top of a sale, it does not change the referral or fulfillment fees charged on that same order, so reconciling VAT figures correctly is not a substitute for confirming the underlying sale still clears the real fee stack before a seller assumes a given month's numbers are healthy just because the VAT file balances.
What changed with the Amazon VAT Transactions Report on 3 November 2026?
The report can now be requested at any point during the month it covers, for data up to 3 days before the request date, instead of only becoming available on the 3rd of the following month.
Can I still get the old, fully finalized monthly file?
Yes. The fixed monthly close date still exists; the change adds the ability to request earlier, on-demand looks during the month, it does not remove the final file.
What does the new TRANSACTION_UPDATED_DATE column show?
The date each transaction row was last updated, so a seller who re-requests the report later in the same month can filter for exactly what changed since the previous download.
What is GOV_INVOICE_ID for?
The government-assigned e-invoice number for a transaction. At launch it is populated only for Poland's KSeF e-invoicing system; Amazon says more countries will be added later.
Does this change what transactions the AVTR covers?
No. The report still covers goods transactions (sales, refunds, returns, cross-border movements) and fee transactions exactly as before; only the request timing and the two new columns are new.
Why would fee data still lag behind sales data in the same report?
Amazon adds fee transactions for a month only once that month's fee invoices are actually issued, a separate schedule from the sales and refund data, unaffected by the on-demand timing change.
Is the new on-demand reporting available to every seller already?
Amazon's own help page describes it as a Beta feature rolling out gradually, and states it might not be available on every account yet.
Does SellerMagnet file VAT returns or submit this report for me?
No. Requesting and filing from the AVTR happens entirely inside Seller Central and the seller's own VAT process; SellerMagnet's dashboards work alongside it on the commercial side, not the filing itself.
Stop Juggling Tools. SellerMagnet Combines Everything You Need.