Prepaid AI Credits and Wallets: The Tax Treatment Nobody Agreed On
AI
Read time: 3 min
Anthropic, OpenAI and Mistral sell the same thing: a prepaid balance that your API calls draw down. They don't agree on when it is taxed. Anthropic and OpenAI charge tax when you buy the balance. Mistral charges it when you use it.
We found this out the practical way, by buying credits on all three platforms and reading the invoices. Anthropic's checkout prices a top-up as credits plus "Estimated tax". When we switched a test account's billing address to Dublin, a $20 top-up came back with $4.60 of Irish VAT, charged on the spot. Mistral does the opposite. A top-up arrives as a French facture d'acompte (an advance-payment invoice) with no VAT on it, whatever we told Mistral about ourselves. The VAT turns up on the monthly usage invoice, and the prepaid balance is netted against the VAT-inclusive total.
Anthropic | OpenAI | Mistral | |
|---|---|---|---|
Tax invoice issued at | Wallet top-up | Wallet top-up | Month-end based on draw-down |
Wallet holds | Net money (no tax due) | Net money (no tax due) | Gross money (tax still due) |
Tax treatment at draw down | No tax at draw down | No tax at draw down | Tax applied at draw down |
Are expired credits taxed | Yes | Yes | No |
The billing stack is the clue. Anthropic and OpenAI bill through Stripe, which applies credits "after discounts, but before taxes". Mistral bills through an open-source billing system, which deducts wallet credits "from the post-tax subtotal". The three vendors didn't reach three tax opinions. Their billing systems made the choice for them.
Two models, one euro
Strip away the vendors and there are two ways to design a prepaid wallet. In a net wallet, tax is charged when the money comes in, and the wallet holds what is left. In a gross wallet, the money comes in untaxed, the wallet holds all of it, and tax is charged on each usage invoice that the wallet then pays.
On a credit that gets used, both models collect the same tax. They differ on timing, on which document is the tax invoice, and on credit that is never used. In the net model that VAT has already been paid; in the gross model it never falls due.
The correct way? it depends...
You might expect tax law to have a clear answer by now. It has two, and they point in opposite directions.
In the EU and the UK, the pull is towards the top-up. Since 2019, a balance that can only be spent with one supplier counts as a voucher. If the customer's country and the VAT rate are known when the balance is sold, it is a single-purpose voucher, and VAT is due on the sale (CJEU, M-GbR, C-68/23, 2024). That is what Anthropic and OpenAI do. The VAT on credits that later expire is final. Mistral's approach only holds if the balance is a multi-purpose voucher, which requires real uncertainty about place or rate when it is sold. The alternative is a prepayment for services not yet identified, the narrow BUPA exception. In France, where Mistral is based, both arguments are thin: the tax authority taxes advances on receipt, and an invoice titled facture d'acompte concedes the point. The prize is real, though. On the multi-purpose route, unused credit never carries VAT at all.
In the US, the pull is towards the draw-down. States treat a stored-value balance like a gift certificate: no sales tax when it is sold, and tax when it is spent, according to whether that state taxes the thing bought. That is a patchwork. Washington and Texas tax AI inference, Indiana has ruled it isn't taxable, and California starts taxing remotely accessed software on 1 January 2027. Charging sales tax at top-up means guessing which state's rule applies before the customer has used anything. The trade-off is unclaimed-property law. A credit that expires after 12 months falls outside the statutory gift-card exemption and can escheat to the state after three to five years, unless a business-to-business exemption applies.
Accounting sides with the draw-down. Under IFRS 15 and ASC 606, a top-up is a liability until it is used. A vendor that charges VAT at top-up remits tax on revenue it hasn't earned yet.
And underneath all of it sits payments regulation. A 12-month expiry and "non-refundable" terms are only lawful because a single-vendor balance isn't electronic money, which would have to be redeemable at par on demand. That is why OpenAI's terms say the balance "is not a bank account, digital wallet, stored value account, or other payment device".
Why it isn't a setting
If the right answer differs by country, why not just make the tax point configurable? Because the two models disagree about what the wallet is, and a billing engine builds everything on top of that.
What the wallet holds. In the top-up model the balance is net money with the tax already settled. In the draw-down model it is gross money whose tax isn't known yet. A €100 balance is a different asset in each, and you can't convert one into the other without choosing a tax rate at the moment of conversion.
Where the credit sits in the invoice maths. Every engine applies the wallet at a fixed point in its calculation: before tax (Stripe, and Solvimon's credit wallets) or after tax (an open-source billing system, and Solvimon's money wallets). Move it across the tax line and the result of every invoice changes: the taxable base, how partly covered lines split, and whether a free promotional credit reduces the customer's VAT.
Which document is the tax invoice. In one model the top-up is the VAT invoice and the usage invoice is a statement. In the other the top-up is a receipt for money on account and the usage invoice carries the VAT. Numbering, mandatory wording, e-invoicing fields and the month the VAT is reported all flip.
Which customer profile applies. Tax at top-up freezes the customer's country and VAT status for that grant. Tax at draw-down needs the current profile at every invoice.
Credits also live for a year. Switching models means running both side by side for a full credit lifetime and tracking, grant by grant, which money has already been taxed. That is why Anthropic and OpenAI can't simply become Mistral, and why Mistral can't simply become Anthropic.
What this means for billing system design
The vendors in this story each picked one model and lived with its weak side. A billing system for AI companies selling internationally needs both, chosen per customer.
The driver is the place of supply. For AI services that is almost always where the customer is: where a business customer is established, where a consumer lives, or the US billing address. So the customer's tax country, known when the wallet is created, decides the wallet regime. Customer status (business or consumer, VAT number or not) changes the rate and the reverse charge on each invoice, but not the regime.
The design rules that follow:
Net wallets for VAT countries, gross wallets for the US. In the EU and the UK, tax the top-up and let the wallet hold the net amount. In the US, leave the top-up untaxed and let the tax engine price each draw-down by state. Check other countries before assuming: Australia's voucher rules tax at redemption.
Collect the country before taking money. Billing country, and the VAT number for businesses, belong in the top-up flow. You need them anyway as VAT evidence and for the reverse charge, and an "unknown" customer is an open door to an unplanned tax position.
One regime per wallet, never mixed. If a customer moves country, the existing balance keeps its regime until spent, and new top-ups go to a new wallet.
Make the invoice say what the tax engine does. A taxed top-up gets a VAT invoice. An untaxed one says it is money on account and why. An advance-payment invoice with no VAT on it is the wrong document for either.
Ledger purchased, promotional and tax-remitted value separately. One balance figure can't produce a correct breakage number, taxable base, escheat report or reverse-charge statement.
Treat expiry as a tax event. Close the liability to revenue or to an unclaimed-property reserve, and record that VAT paid at top-up is final.
Keep the wallet closed. Spendable only with you, non-transferable, no cash-out, one category of services. Add refunds at par or third-party sellers and the balance starts to look like electronic money, with the licence that comes with it.
The takeaway
Nobody agreed on the tax treatment of prepaid AI credits, and nobody has to: the EU and the US genuinely want different things. What a vendor can't afford is to let its billing stack make that decision by accident. Choose the regime per customer, deliberately, before the first credit is sold. That is the design we're building Solvimon's wallets around.
Sources
Anthropic Supplemental Credit Terms and OpenAI Service Credit Terms
CJEU, M-GbR v Finanzamt O, C-68/23 and BUPA Hospitals, C-419/02
BOFiP BOI-TVA-BASE-20-20 (French VAT on advance payments)
Washington WAC 458-20-15503 (stored value) and California SB 122
EMD2, Directive 2009/110/EC (electronic money)
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.
