AWS Marketplace Listing Fee VAT: Same Sale, Different Invoice

Two customers bought the same product from our AWS Marketplace listing in the same month. AWS charged us its listing fee on both. On one of those fee invoices there was 24% VAT. On the other there was none at all.

Nothing about the two sales explained it. Same product, same seller account, same week. The difference turned out to sit in a single field in the seller data feeds, and it decides whether the tax on that fee is money you reclaim or money you self-account for on your VAT return.

This post covers what that field is, why the two treatments exist and the four ways the data feeds will quietly give you a wrong number if you aggregate them naively. It also covers where the tax-compliant invoice PDFs actually live.

Seller Revenue Has No API

The first obstacle is that you cannot query any of this. AWS Marketplace exposes a catalog API for writes and an agreement API for reads, but revenue, fees, tax and disbursements are not in either. They arrive as seller data feeds: daily CSVs that AWS drops into an S3 bucket you own, which you then query with Athena or read yourself.

There are thirteen of them. The one that carries money is BillingEventFeed, and it lands partitioned by month:

BillingEventFeed_V1/year=2026/month=09/data.csv
AgreementFeed_V1/year=2026/month=09/data.csv
TaxItemFeed_V1/year=2026/month=09/data.csv
AccountFeed_V1/...  AddressFeed_V1/...  OfferFeed_V1/...

Latency is the other thing to know. Marketplace EventBridge events reach you in seconds; the data feeds take 15 to 32 hours, and which end of that range you land on is luck. For tax reconciliation the lag does not matter. For anything operational it does.

The One Field That Decides the VAT

Every row in BillingEventFeed carries a broker_id. It names the AWS legal entity behind the transaction, and it is the whole answer:

AWS documents the rule, though only in a column description most sellers would never think to check: when a subscription transacts through the EMEA SARL, Japan or Australia entity, the operator must charge the seller VAT on the listing fee and issue a tax-compliant invoice. Transactions from AWS, Inc. have no listing fee invoice ID, because it does not apply.

Across our full history the split is absolute. Every non-zero fee line from the EU entity carried tax at exactly the local rate; not one line from AWS, Inc. carried any. The single exception was a zero-value credit note, which correctly had zero tax.

Which entity handles a sale follows the buyer's tax jurisdiction. Yours has no say in it, as AWS's own seller guide confirms. That is why our two customers diverged. One was a German company billed by the EU entity. The other was a UK-registered company whose AWS billing address is in Texas, so the whole transaction ran through AWS, Inc. You cannot influence this, and both entities will invoice you in the same month.

Why Local VAT Instead of Reverse Charge

This part surprised us. An EU supplier billing a VAT-registered business in another member state normally applies the reverse charge and charges nothing. So why was there VAT on the invoice at all?

The PDF answers it. The supplier is the Luxembourg entity's local branch, registered for VAT in the same country as the seller, with its own registry code and VAT number printed on the document. That makes it a domestic supply between two locally registered businesses. Local VAT applies in the ordinary way, and being a proper tax invoice, it supports a deduction.

We had assumed the opposite first: that VAT was being charged because no VAT number was on file. Checking beat assuming. We were wrong. The registration was on the account all along. That is exactly why the tax is reclaimable.

One more surprise sits underneath all of this. Estonia, where our seller account is registered, is not on AWS's own published list of countries where AWS Europe applies VAT to the listing fee. That list names Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Ireland, Italy, Luxembourg, Netherlands, Poland, Portugal, Romania, Spain, Sweden, Switzerland, Norway and the UK. Our invoices tell a different story. The published page and our own BillingEventFeed disagree, and the feed is the one with real money deducted from our disbursements, so that is what we go by. If your seller account sits in a country the public list leaves out, check your own feed before assuming the page has the final word.

Four Ways the Feeds Will Give You a Wrong Number

The data is complete and accurate. It is also shaped in ways that punish a naive query. Each of these inflates a total quietly. None of them throw an error.

1. Every File Is a Cumulative Snapshot

A delivered CSV is not a change set. It restates every row inserted that month, so today's file contains yesterday's rows again. Treating a delivery as a delta is the single most common mistake, and it also means any daily notification built on these feeds needs a watermark or it will repost the same records for days.

2. Rows Are Re-emitted Across Partitions

The same billing event reappears in later monthly partitions, some of them seven times over. In our bucket around 2,900 raw rows collapse to fewer than 1,000 real events. Any cross-partition aggregation has to deduplicate on the business key first, keeping the newest version of each. The feeds are bi-temporal, so changing an entity appends a new row version. It never updates the old one in place.

3. One Movement Arrives as Three Rows

A single fee is emitted three times with different sign and balance flags. Only the one flagged as balance-impacting is a real movement. The fee and its tax are separate rows that share a line item ID, which is how you join them:

transaction_type    charge_side   balance_impacting   line_item_id
AWS_REV_SHARE       BUYING        1                   93a57e77...   <- the fee
AWS_TAX_SHARE       BUYING        1                   93a57e77...   <- its VAT
AWS_REV_SHARE       BUYING        0                   93a57e77...   <- ignore
AWS_REV_SHARE       BUYING        0                   93a57e77...   <- ignore

Note also that the signs track your AWS balance, and only your AWS balance. Revenue is positive when invoiced and negative when disbursed, because the disbursement is money leaving the balance on its way to you.

4. The Feed's Currency Is Not the Filing Currency

This one nearly cost us a wrong figure. Most EU fee invoices are issued in USD even though the VAT is assessed in euros. Summing the feed's amount column across currencies produces a number that appears on no return. The fix is to let AWS do the conversion: the Invoicing API returns a TaxCurrencyAmount holding the same invoice restated in the tax jurisdiction's currency using AWS's own rate, which is what the PDF shows and what you file.

Where the Invoice PDFs Actually Are

The feeds only give you invoice numbers. The documents live somewhere else, and your accountant needs the actual tax invoice to claim a deduction. Here is where to find both, per AWS's own invoice management guide.

• Console: AWS Partner Central, then Tax details in the left navigation, then Listing fee invoices. Filter by invoicing entity or date range, tick the rows and download as a zip.
• API: list the invoices, then fetch each PDF. The response is a presigned URL valid for fifteen minutes.

aws invoicing list-invoice-summaries \
  --selector ResourceType=ACCOUNT_ID,Value=<seller-account-id> \
  --filter 'ReceiverRole=SELLER,TimeInterval={StartDate=2026-01-01T00:00:00Z,EndDate=2026-09-01T00:00:00Z}' \
  --region us-east-1

aws invoicing get-invoice-pdf --invoice-id <invoice-id> --region us-east-1

One hard limit: AWS retains no invoice data before 1 June 2025, for the console, the API and the PDFs alike. Anything older needs a support request. If you have been selling for years, check this before assuming you can reconstruct the history.

What We Automated

We already run a Lambda that watches these feeds and posts real activity to Slack. VAT is deliberately not part of it. A tax schedule is something you hand to an accountant once a quarter. It has no business being a chat notification.

It lives instead as a separate offline report. That report reads the full billing feed and joins the Invoicing API. Then it writes out a CSV plus the PDFs.

The important column is the treatment, derived from broker_id, because that is the field an accountant sorts on:

month    cur  treatment           lines      fee     vat
2026-06  EUR  RECLAIM_INPUT_VAT       4   193.33   46.40
2026-06  EUR  REVERSE_CHARGE          1    39.00    0.00
2026-06  USD  REVERSE_CHARGE          2   100.20    0.00

WARNING: 6 line(s) have no filing figures - AWS retains
invoice data from 2025-06-01 only.

That warning line matters more than it looks. A report that silently drops what it cannot cover reads as complete coverage when it is not. If a tool bounds its own scope, it should say so in the output.

What to Check in Your Own Account

1. Group your listing fee invoices by invoicing entity. If any come from the EU entity, VAT has been charged and deducted from your disbursements already.
2. Confirm your tax registration number is on the seller account. Without it the invoice will not support a deduction.
3. Take the filing amounts straight from the invoice. It already carries AWS's own exchange rate, so there is nothing left to calculate.
4. Ask whether the AWS, Inc. fees have been reverse-charged. There is no VAT to reclaim there, but it is still a filing obligation, and on most seller accounts it is the larger number by volume.
5. Download the PDFs now if you have been selling since before June 2025, because that history is not retained.

On our own volumes the recoverable amount is modest. That is not really the point. It is a filing obligation either way, it accrues on every sale, and the only reason it went unexamined for months is that AWS never sends an invoice you have to pay. We are engineers, and the tax treatment itself is a question for your accountant. Finding the numbers and proving which rule applies to which invoice is an engineering problem. That part is entirely tractable.

Need Your AWS Billing Data to Actually Reconcile?

We build the pipelines and reporting that turn AWS billing and Marketplace data into numbers your finance team can file against.

Book a Discovery Call

Explore AWS Managed Services

Eugene Orlovsky

CEO & Founder @ Perfsys | Serverless architect with 10+ years of hands-on experience designing cloud-native architectures on AWS, backed by multiple AWS certifications. His writing bridges deep technical expertise with real-world business strategy, covering topics from AWS best practices to scaling tech-driven organizations.