VAT for Mobile Apps: App Store and Google Play Revenue in 2026

Indie developers and mobile-first SaaS companies regularly ask the same question: do I owe VAT on my App Store or Google Play revenue? The short answer for most: not on the platform-billed revenue itself, because Apple and Google act as the deemed supplier in most jurisdictions and handle VAT for you. The longer answer is that the platforms cover roughly 70% of what a global mobile business owes, and the remaining 30% is what gets indie developers in trouble. This guide explains where the platforms collect VAT for you, where they don't, and what to do about the gaps.

1. Apple and Google as deemed suppliers

The legal mechanism that makes mobile apps simpler than typical SaaS is the "deemed supplier" rule. Under EU VAT Directive Article 9a, the platform that controls the transaction (sets the price, processes the payment, delivers the digital product) is treated as the supplier for VAT purposes, even if a third-party developer is the underlying creator of the product. The customer's contractual relationship is with the platform; the platform handles VAT.

The same principle is implemented in:

• UK (HMRC's "intermediary supplier" guidance for app stores)
• Australia (GST inbound intangible consumer supplies, ATO ruling 2017/3)
• New Zealand (remote services GST framework)
• Singapore (Overseas Vendor Registration regime)
• Japan (JCT framework)
• South Korea (Simplified Business Operator regime)
• Türkiye (electronic services VAT)
• Most Latin American jurisdictions (Mexico, Chile, Colombia)

For B2C in-app purchases and subscriptions in any of these countries, Apple and Google:

1. Charge the customer the gross price including local VAT.
2. Collect the VAT and remit it directly to the local tax authority on the developer's behalf.
3. Pay the developer the net amount (price minus platform commission minus VAT).
4. File the periodic returns required in those jurisdictions.

The developer doesn't register, doesn't file, doesn't see the VAT cash flow. Apple's App Store Connect and Google's Play Console each publish tax tables showing exactly which countries they handle and how the calculation works. For developers who only ever sell through these stores in covered countries, the compliance burden for app revenue is approximately zero.

2. Where the platforms do NOT act as deemed supplier

The coverage is broad but not universal. Specific gaps to know about as of 2026:

India

India has a foreign-supplier regime (OIDAR) that should logically capture App Store and Play Store sales, but enforcement has been inconsistent. Apple and Google currently collect Indian GST on B2C transactions where the buyer does not provide a GSTIN (treating them as consumers), but the responsibility for B2B transactions (buyer with GSTIN, claiming reverse charge) sometimes falls back on the developer. Combined with India's DGGI enforcement chasing nonresident OIDAR registrations since 2023, indie developers with meaningful Indian revenue should not assume the platforms have it fully covered. See India OIDAR compliance.

Eastern European candidate countries

Serbia, Albania, Moldova, Kosovo, Bosnia, North Macedonia have introduced foreign digital-services VAT regimes more recently. Apple and Google's deemed-supplier coverage in these markets is partial or under negotiation. Developer revenue from these countries may not be fully VAT-handled by the platform. Volume is small for most apps, but a viral hit in any of these markets can create unexpected exposure.

Direct B2B sales

If your app has a B2B component (enterprise sales, team subscriptions billed off-platform), those sales are not deemed-supplier covered. The developer is the direct supplier and owes standard VAT compliance: registration, calculation, filing.

App-Store-pricing edge cases

Promotional pricing, refunds processed outside the platform, and certain marketing arrangements can fall outside the deemed-supplier coverage even within otherwise-covered countries. Apple and Google's tax handling assumes the standard transaction shape; deviations can leave residual VAT obligations on the developer.

3. The biggest gap: web revenue paired with app revenue

The most common compliance gap for mobile apps is the web subscription. Many modern apps offer the same subscription on both iOS/Android (in-app purchase) and the web (direct billing through Stripe, Paddle, or similar). The two channels have completely different VAT treatment.

An app that sells $500k/year through the App Store and $200k/year through the web has roughly $200k of revenue that requires standard VAT compliance just like any SaaS. EU OSS registration, customer-location evidence, quarterly filings. The App Store revenue does not insulate the web revenue.

Most indie developers running a hybrid model assume "the platforms handle my VAT" and miss the web-side compliance entirely. This is the most common reason for HMRC and Irish Revenue audit notices on mobile-first companies.

4. Ad revenue is separate

If your app monetises through advertising (AdMob, Unity Ads, AppLovin, Apple Search Ads, ironSource), the revenue is a separate VAT supply from any in-app purchases. You are supplying advertising services to the ad network. Most ad networks treat developers as B2B partners, applying reverse charge in the EU and equivalent treatment in other jurisdictions, but you need to provide them a valid VAT number to claim that treatment.

Without a valid VAT number on file, the ad network may treat you as a B2C developer and either withhold VAT from your payouts or require you to handle the destination-country VAT yourself. Both outcomes are operationally bad. The fix is straightforward: get a VAT registration (most easily through EU OSS Non-Union scheme), provide the number to every ad network you work with, and verify their invoices apply reverse charge.

5. The "ad-supported app with no in-app purchases" pattern

An app that monetises purely through ads (no in-app purchases, no subscriptions) has a simpler VAT shape: the only VAT-relevant supply is your relationship with the ad network, which is B2B. A US developer with a US LLC selling into AdMob can usually operate without any nonresident VAT registrations, because every cross-border supply is B2B reverse-charged.

The complication: if the ad network is in a jurisdiction with a foreign-supplier regime that treats you as having "presence" through your app's user base, registration may still be required. As of 2026 this is rare for ad-only revenue, but worth checking. Run an exposure check against your ad-network revenue by jurisdiction.

6. What an indie developer should actually do

For a typical hybrid indie app (App Store + Play Store + web subscription):

1. Audit your revenue split. Pull last 12 months of revenue by channel: iOS IAP, Android IAP, web subscription, ads. The web and ad portions are where compliance lives.
2. Run an exposure check on the web revenue only. Sync your Stripe (or Paddle, etc.) account to the free exposure dashboard. The dashboard will tell you which jurisdictions your web revenue has crossed thresholds in.
3. Register for EU OSS Non-Union. If your web revenue includes any EU consumer sales, OSS registration is required from the first euro. Single registration covers all 27 EU member states with one quarterly return through Irish Revenue.
4. Validate your B2B customer VAT numbers. If you have any team or enterprise customers, validate their VAT numbers via VIES at the time of supply. Reverse charge only applies if you actually verified.
5. Verify your App Store Connect and Play Console tax data. Both require the developer's tax residency information for platform commission and tax-form purposes. Mismatches cause withheld payouts.
6. Provide your VAT number to your ad networks. Once you have an EU OSS number, give it to AdMob, Unity, AppLovin, etc. so they apply reverse charge correctly.
7. Don't worry about the App Store / Play Store revenue itself. In countries where Apple or Google act as deemed supplier, the platform handles it. Spend your compliance budget on the parts they don't cover.

7. Use cases by app shape

Indie B2C app, no web subscription, no ads

If 100% of your revenue is in-app purchases or subscriptions through Apple or Google in countries where they act as deemed supplier, you may not need any nonresident VAT registrations at all. Verify this by reviewing the latest App Store Connect and Play Console tax tables. The most common case where this works cleanly: a paid app with no consumable IAPs sold to consumers in the US, EU 27, UK, Australia, NZ, Singapore, Japan.

Hybrid app: IAP + web subscription

Standard digital-services compliance applies to the web revenue. EU OSS Non-Union registration is the highest-value first step. UK VAT NETP if your UK web revenue is meaningful. Add APAC nonresident regimes (Australia, Singapore, Japan) once revenue in each crosses the threshold.

Mobile-first SaaS with team subscriptions

Team and enterprise sales are B2B and reverse-charge eligible. Make sure your billing flow validates buyer VAT numbers via VIES at signup and at every billing cycle. The free tax-ID validator handles batch checks.

Ad-supported only

Probably the simplest VAT shape. The ad networks are your B2B customers. Provide each one a valid VAT number; verify they apply reverse charge on their invoices to you.

8. Frequently asked questions

9. Related reading

• EU OSS scheme explained
• VAT for Stripe users
• India OIDAR compliance for SaaS
• Customer location evidence for digital services
• Merchant of Record vs self-remitting VAT
• VAT & GST questions answered