Proving App Revenue: App Store, In-App Purchases and the Indie Developer File
Indie app developers and small mobile studios face a verification puzzle no other income type has: your revenue is generated by millions of small transactions, aggregated by two gatekeepers (Apple and Google), paid out monthly, and invisible to anyone who can't read a developer dashboard. The income is real and auditable — but only if you know which reports to pull and how to reconcile them with your bank account. Here's the complete file.
Why app revenue needs its own approach
App income has characteristics no salaried verifier expects:
- Platform-held funds. Apple and Google collect user payments, hold them, take their cut, and pay you ~30 days later. Your revenue month and payout month never align.
- Multi-layer deductions. Gross sales minus platform commission (15–30%), minus refunds/chargebacks, minus withholding tax for cross-border payouts, equals what lands in your bank. Each layer confuses verifiers who expect paychecks.
- Two platforms, two reports. If you're on both App Store and Google Play, no single document shows total revenue — you must reconcile both.
- Volatile by nature. Feature placements, seasonal spikes, and product launches produce swings that dwarf typical salary variance.
The developer dashboard exports (your primary evidence)
Both platforms produce the documents verifiers trust:
- App Store Connect: Payments and Financial Reports → monthly statements showing gross, Apple's commission, taxes, and net proceeds. Also the Sales and Trends report for unit sales by app and country.
- Google Play Console: Payments and payouts → monthly statements and revenue reports; Downloadable payout summaries.
Export 12–24 months of these as PDFs. They are issued by Apple and Google — institutions verifiers already trust — which makes them the strongest documents in your file despite describing your own account.
The gross-to-net bridge: mandatory for app developers
Every app developer's file must contain one reconciliation table:
| Month | Gross sales (both stores) | Platform commission | Refunds | Withholding | Net payout |
|---|---|---|---|---|---|
| Jan | $12,400 | $3,720 (30%) | $310 | $1,120 | $7,250 |
| Feb | ... | ... | ... | ... | ... |
Attach the store statements that support each row. The verifier should never have to ask "why is the bank deposit smaller than your claimed revenue?" — the bridge answers before the question forms.
The monthly equivalent: recognized vs. received
App revenue recognized in a month typically pays out the following month. For verification purposes:
- Use recognized revenue (store statements by sales month) for your income figure — it reflects the business.
- Use the payout trail (bank statements) as supporting evidence that the money arrives.
Present the 12-month average of recognized revenue as your headline number, with the payout trail attached. State the one-month lag explicitly so deposits never look mismatched.
Subscriptions and in-app purchases deserve separate lines
If your app has subscriptions (renewing IAPs), that's recurring revenue — the verifier-friendly core of your business. Break your file into:
- Subscription MRR — active subscriber count × price, with churn noted. Show the subscriber trend chart from the dashboard.
- One-time purchases — variable, averaged over 12 months.
- Ad revenue in-app (if applicable) — treat per the ad-revenue framework.
"Monthly recurring revenue of $6,800 with 2,900 active subscribers" underwrites far better than "$9,000/month app income" — even when both are true.
Failure modes and fixes
Failure 1: Payments from Apple/Google entities. "APPLE DISTRIBUTION INTERNATIONAL" deposits need the dashboard payout rows to be meaningful. Fix: always pair deposits with statements.
Failure 2: Multi-entity payouts. Apple pays from Ireland, Luxembourg, or regional entities depending on your banking. Note this once in the cover letter to pre-empt confusion.
Failure 3: Developer account in a company name. If App Store Connect is under "StudioName LLC" but you're applying personally, you need the ownership document plus a bank trail from the studio account to your personal account — the same business-linkage chain as any company-owned income.
Failure 4: Family-member or shared accounts. Revenue paid to a spouse's or parent's developer account isn't your income unless there's a documented transfer arrangement. Verifiers count what lands in your name.
Failure 5: Refund storms. A month with heavy refunds produces net payouts below gross — sometimes negative swings. Disclose refund rates; a 4% refund rate is healthy, and saying so beats letting the verifier wonder.
The letter formula
State: what your app(s) do and on which platforms, gross-to-net monthly averages, the subscription MRR block with subscriber count, the 12-month trend, and one line on the payout lag. Attach the store statements and the bridge table. The verifier should finish with one number they can defend — net monthly proceeds — and a clear picture of the recurring revenue underneath it.
App revenue is among the most auditable income types that exists: every transaction is logged by two of the world's largest companies. The file's job is simply to translate that audit trail into the verifier's language.
Related guides
- https://dev.to/blusguo/mrr-is-beautiful-and-nearly-useless-to-a-verifier-proving-subscription-income-khd
- https://dev.to/blusguo/proving-ad-revenue-when-youtube-adsense-and-sponsors-pay-your-bills-g12
- https://gist.github.com/GuoXiaoWeiY/f307398d83373140265708cbea70c831
Need an income letter built from App Store and Play Console data? ProofLetter turns platform statements into verifier-ready income letters.
Top comments (0)