App purchases, in-app purchases and sales tax

Digital products are rarely sold “directly” from the developer to the end customer. In app ecosystems, there is almost always an app store between the developer and the user: it provides the interface, curates content, manages customer accounts, processes payments and issues terms of use. From a VAT perspective, this is not just decor. The decisive question is who is considered the supplier to the end customer and where the service takes place for tax purposes. This is precisely where the latest ECJ case law on the service commission/supply chain comes in – and not only for the period from 2015 (since the introduction of Art. 9a VAT Regulation and Section 3 para. 11a UStG), but also expressly for old years before January 1, 2015.

The ruling provides a clear guideline for small studios, indie developers and app/games providers: If the app store acts in its own name during the purchase process and controls/authorizes the payment, the store is deemed to be the supplier for VAT purposes. In this case, the developer provides its service to the app store (B2B) and the store to the end customer (B2C). This is the core of the service chain – and the reason why invoicing, place of performance, tax burden and GTC architecture are different from direct sales.

The old legal situation until 31.12.2014: Art. 28 of the VAT Directive and Section 3 (11) UStG

Even before 2015, the principle of service commission (usually referred to as a “chain of services” in VAT law) applied: If an entrepreneur acts in his own name but for the account of another, it is deemed for tax purposes that there are two similar supplies. Under civil law, the store may “only” act as an intermediary – under tax law, it buys and sells.

The system:

• First turnover: Developer (commissioner) → App store (commissioner).
• Second turnover: App store (commission agent) → end customer.

Each of these two fictitious supplies follows the general rules independently (place of supply, time, assessment basis, tax liability). In the case of services, the B2B basic rule regularly applies to the first transaction (developer → store): the place of performance is the registered office of the app store; Art. 44 of the VAT Directive/§ 3a para. 2 UStG (reverse charge logic or relocation) therefore typically applies. The second transaction (store → end customer) is taxed where the end customer is located (B2C regime for electronically supplied services).

The sticking point in the pre-2015 legal situation was often the distinction: is the store acting in its own name or in the name of another? And: are later references (e.g. in order confirmations) sufficient to assume a third-party name? These uncertainties characterized many proceedings – and were taken up and resolved by the ECJ in the “Xyrality” case.

ECJ “Xyrality” (C-101/24): Consistent application of the benefit chain also for old years

In the original case (years in dispute 2012-2014), the app was distributed free of charge via an Irish app store; in-app purchases (digital content) were initiated within the app via a store pop-up with a store logo, payment was made in full via the app store and the store collected the payment. Only after completion did end customers receive emails in which the developer was named as the service provider and (incorrectly) German VAT was shown.

The ECJ confirms three practical points:

1. Service chain affirmed: The app store is deemed to be the supplier to the end customer if it is not expressly acting on behalf of a third party at the time of performance. A subsequent reference to the developer in the order confirmation is not sufficient to justify acting on behalf of a third party. The customer’s perception in the checkout and the factual sovereignty over payment/billing are decisive.
2. B2B place of performance: The fictitious developer→store service remains B2B. The place of performance is based on Art. 44 of the VAT Directive/§ 3a Para. 2 UStG – i.e. generally at the registered office of the store. This means that no German VAT is regularly incurred for this turnover if the store is located in another EU country/third country.
3. § Section 14c UStG/Art. 203 VAT Directive The incorrect VAT statement in the confirmations sent to private customers does not give rise to a tax liability by virtue of the invoice because there is no risk to the tax revenue (private customers have no input tax deduction). Whether the confirmations are invoices at all within the meaning of the regulation could be left open; the decisive factor is the lack of fiscal damage.

The bridge to the period from 2015 is noteworthy: The ECJ emphasizes that Art. 9a VAT Regulation (since 1. 1. 2015) is not a new concept, but clarifies the content of Art. 28 VAT Directive. In other words: Even before 2015, the supply chain was to be applied in the case of platform intermediation and the store’s own appearance in the purchasing process – this is exactly what the decision supports.

The legal situation since 1.1.2015: Art. 9a VAT Regulation and Section 3 (11a) UStG

Since 2015, a clear fiction has applied to electronic services via interfaces/portals (app stores, digital marketplaces): the platform is deemed to be the supplier if it is involved in the provision of the service and typically controls payment authorization/billing. In practice, this means that in B2C constellations, the store is almost always to be regarded as the provider – unless the platform demonstrably and clearly acts “in the name of a third party” and leaves the conclusion of the contract and payment processing to the developer.

For developers, this means

• Standard case with Apple/Google: Store is B2C provider; developer provides B2B to the store. Invoice to the store usually net; no German VAT if place of performance is at the store’s registered office (Art. 44/§ 3a para. 2).
• Direct sale/external payment (e.g. via own website/payment link): Developer itself becomes a supplier to end customers; then the OSS/MOSS mechanisms and national B2C rules apply (country of destination principle for e-services), including obligation to provide proper receipts and VAT payment in the Member State of consumption.

In short: if the platform controls the checkout, it becomes the tax provider; if the developer controls the checkout, it becomes the tax provider. There are hardly any “hybrid models” in between, without roles, contracts and user guidance being completely clearly aligned.

“In your own name or in someone else’s” – what really counts

Whether a store is acting in its own name or in the name of a third party is not determined by subsequent documents, but by the purchase process itself: Who is the customer’s recognizable contractual partner? Who authorizes the payment? Who sets the general terms and conditions for the provision of services? Who decides on refunds and fraud? Who enables or denies access to the digital content?

Practice shows a pattern:

• Store self-presentation is obvious if the user initially requires a store account, accepts store terms and conditions, dominates the store UI in the checkout and uses store payment. A subsequent note “Provider: Developer X” does not change this – the simultaneous external presentation at the time of the service is missing.
• The presence of a third-party name presupposes that the developer is already a recognizable contractual partner in the checkout, whose terms and conditions apply and whose payment channel (checkout/invoice) is used. The platform is then – legally – more of a technical infrastructure (e.g. listing/distribution), but not a provider.

The threshold for “in someone else’s name” is high. It is not enough to mention the developer later in emails or PDFs. The initial communication at the moment of purchase is decisive.

Consequences for developers and small app companies: Invoices, tax, organization

Invoicing:

• If the store is acting on its own behalf, the store issues its invoice/receipt to the end customer and pays the VAT in the country of purchase. The developer invoices the store (billing/settlement; if applicable, own invoice to the store without German VAT, with reference to B2B/Art. 44).
• In the case of direct sales (own cash register/external payment), the developer issues the end customer vouchers, takes into account the country of destination principle (OSS) and documents the place of performance.

Place of performance/tax liability:

• Developer→Store (B2B): Art. 44/§ 3a para. 2; regularly no German VAT statement.
• Store→Individual customer (B2C): Country of destination; store deducts local VAT.
• § Section 14c UStG/Art. 203 of the VAT Directive: An erroneous German VAT statement in receipts to private customers does not constitute a tax liability as long as there is no input tax risk.

Contract/AGB architecture:

• In the case of a store’s own presence, developer T&Cs must be clearly geared towards B2B services to the store (service description, usage rights/keys/API calls, termination/chargebacks, assignment/collection, reporting/audit).
• Direct sales require end customer T&Cs (B2C/B2B), geo-control logic (OSS), invoicing/receipt obligations, withdrawal/digital content rules, customer service and refund processes under your own control.

Accounting/Compliance:

• Store-only models are tax-efficient (payment to the store), but require clean accounting of net revenue (after commission and tax deduction).
• Hybrid/direct models require VAT know-how (OSS, third-country sales, B2B delimitation), systems for issuing receipts and geo-price control.

Apple App Store & Google Play – how the big stores solve this

Apple and Google themselves act as providers in the end customer business when services run via their cash registers. Prices and taxes are displayed gross; the stores pay the applicable VAT in the country of purchase and settle net (less commission) with developers. This reduces the tax and invoice burden on the developer side, but shifts contractual and liability issues (refunds, fraud, chargebacks, GTC sovereignty, delistings) to the platform.

If, on the other hand, an external payment method is opened (e.g. “purchase via the developer’s website”), the VAT role changes: the developer becomes the supplier to the end customer – with OSS obligations and the creation of receipts. Accordingly, general terms and conditions, checkout texts and customer communication require clear role models: Who is selling? Whose terms and conditions? Whose invoice? The more ambiguous, the higher the risk of tax and civil roles falling apart.

Practical guide: The most important decisions

Determine procedure: Who controls the cash register? Who authorizes the payment? Who sets the terms of service? If you answer “Store” three times, there is a high probability that there is a service chain and that the store is the fiscal provider.

Communication in the checkout: Clear, early naming of the contractual partner is mandatory. “Hiding” the developer/store until the order email does not create a third-party name.

Synchronize terms and conditions and contracts: Developer T&Cs for B2B services to the store vs. end customer T&Cs for direct sales. In store T&Cs, ensure that chains of rights (licenses, keys, DLC, virtual currency) are transferred/rendered usable in full to the store.

Invoice logic:

• Store’s own performance: Developer creates B2B receipts to the store (often only billing documents of the store, possibly own invoice without VAT; Art. 44).
• Direct sales: end customer document with OSS logic (e.g. VAT rates per member state, proof of customer location).

§ Section 14c control: In the event of incorrect VAT disclosure to private customers – no automatic tax liability; nevertheless provide for documentation and correction in order to avoid later discussions.

Technology & evidence: Archive store UI, payment flows, GTC screens and checkout screens in a verifiable manner. In the event of a dispute, the time of purchase counts – not subsequently submitted PDF notes.

Additional practical section (≈ 500 words): Platform provider without compulsory payment

Not every platform is Apple/Google. Many digital marketplaces – such as SaaS hubs, app stores for store systems (e.g. themes/plugins), add-on marketplaces for tools, CMS or game mods – do not force developers into a centralized payment system. It follows from this: The VAT role can be shaped, but is also prone to errors.

Target scenario 1: Pure intermediary (listing/discovery platform)
If a platform does not want to be considered a tax provider, it must consistently play the role of a pure intermediary:

• Checkout ownership by the developer: The entire payment process takes place outside the platform – for example via an external checkout of the developer or a direct payment link. The platform does not provide its own wallet/credit system.
• Clear third-party presence: Before payment is made, it must be clear that the developer is the contractual partner: The developer’s general terms and conditions, data protection information and revocation instructions are displayed; the platform clearly indicates that it is purely an intermediary.
• No de facto control of the service: The platform does not authorize the payment, does not check refunds in its own name, does not approve the provision and does not determine the general conditions of the service provision. Where moderation/quality assurance is essential, the platform should document procedurally that this does not constitute a provider role (e.g. purely curatorial, without influence on price, tax or delivery obligation).
• Billing: The platform only receives the agency fee from the developer (B2B). The developer invoices the end customer directly (B2C/B2B) – including OSS/VAT in the country of destination.

Target scenario 2: “Light reseller” (gets involved but does not want to be the seller)
Many marketplaces want control or convenience functions (e.g. one-click buy, uniform refund policy, “buyer protection”) without becoming a taxable provider. Danger: The more the platform “owns” the checkout, authorizes payments, specifies terms of use or approves deliveries, the more likely it is to act on its own account – and thus the service chain is at the expense of the platform (it is then considered a provider). Those who choose this middle ground must make a strict distinction:

• Payments as pure PSP pass-through with technical pass-through and clear invoice in the name of the developer.
• T&CS: Platform T&Cs only regulate marketplace rules (e.g. admission, listing, support standards), not the terms of service between the developer and the end customer.
• UX texts: Visible in the checkout: “Contractual partner: [developer]”. Platform logo may be present, but not appear as a seller.
• Refunds/chargebacks: are processed on behalf of the developer; the platform does not make the “final” decision on service disruptions.

Target image 3: Full reseller (conscious provider)
Anyone who – for reasons of convenience, trust or monetization – consciously wants to act as a provider (e.g. to issue standardized invoices) should actively take on this role:

• Own checkout, own invoices to end customers, VAT payment in the buyer country (OSS).
• B2B purchasing from the developer (developer→platform: Art. 44/§ 3a para. 2), clear reseller clauses (licenses, warranty, IP assignment, export controls).
• Tax engine for B2C/B2B (validation of VAT ID number, location determination, rates/exemptions), compliance with e-invoicing obligations.

Pitfalls and to-dos:

• Avoid gray areas: Mixed models (“Sometimes reseller, sometimes intermediary”) are possible, but must be separated crystal clear per product/sales transaction. Inconsistent UX texts (“Buy now from [platform]” vs. invoice by developer) invite tax risk assessments.
• Documentation: Archiving checkout screens, general terms and conditions, payment flows, refund policies in an audit-proof manner. The question “Who was the recognizable seller at the time of purchase?” decides the case.
• § 14c/Art. 203-Risk Incorrect VAT disclosure to entrepreneurs can – in contrast to purely private customer cases – very well lead to tax liability. In B2B ecosystems, clean invoices are essential (correct rates, correct issuers, reverse charge notices).
• Pricing & commission: For reseller models, the basis of assessment is the end customer turnover (less price components according to the law, not “commissions at will”).
• T&C consistency: Platform T&Cs (marketplace rules) vs. end customer T&Cs (contractual partner). For brokerage: end customer T&Cs of the developer visible; for resale: end customer T&Cs of the platform.

Bottom line: If you don’t operate an Apple/Google-like “checkout monolith”, you can control the tax role – but only with consistent role decisions, clear terms and conditions, unambiguous UX and verifiable payment logic.

Common misunderstandings – briefly debunked

• “If the developer is named somewhere, isn’t he also selling?” – No. The decisive factor is the external effect at the moment of purchase. Later references are irrelevant.
• “Art. 9a of the VAT Ordinance has only been in force since 2015, so no supply chain before that.” – Wrong. The ECJ classifies Art. 9a systematically: It only clarifies what is contained in Art. 28 of the VAT Directive.
• “Incorrect German VAT statement always leads to § 14c debts.” – Not for private customers without input tax deduction. But be careful with B2B.
• “Reseller vs. intermediary is a matter of taste.” – From a tax perspective, it’s a result of the actual design. The UI, the checkout, the GTC and the actual control are decisive – not the label.

Implementation steps for developers (app/games)

1. Set model: Store checkout only or additional external payment? Each model needs its own GTC/tax and receipt logic.
2. Update AGB:
   • Store model: B2B service to the store (license and IP chains, liability, billing, inspection and audit clauses).
   • Direct sales: End customer T&Cs (digital content, updates, warranty, revocation/digital content), VAT rules (OSS) and invoicing/invoicing obligations.
3. Invoicing & booking: Clearly book store invoices as B2B sales (commission deduction, fees, currency conversion, time).
4. Evidence: Photograph/archive checkout flows and screens. In case of doubt, the screenshot decides.
5. § 14c crisis plan: Define procedures for document correction and communication (customer service) if incorrect VAT appears somewhere.

Conclusion

The service chain is not a niche topic in digital sales, but the rule as soon as a platform visibly dominates the purchasing process. The ECJ ruling “Xyrality” confirms this for old and current cases alike: Anyone who appears in their own name and controls the checkout is deemed to be a service provider. For developers, this means: with store checkout, B2B is billed to the store; with your own checkout, your own VAT engine is mandatory. Platform providers outside of the Apple/Google model can shape the role – but only if the checkout, terms and conditions and billing consistently prove that the developer (and not the marketplace) is the seller. A clear decision for resellers or intermediaries saves discussions with the tax authorities, protects against Section 14c risks and creates robust processes – in games, apps, SaaS ecosystems and beyond.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.