Decoding Your App Store Sales Reports: What the Numbers Actually Mean

App Store Connect gives you a lot of data. CSV exports, financial reports, proceeds breakdowns by territory — it can feel like staring into a spreadsheet abyss. But once you know what each report actually measures, and more importantly what it doesn't, you stop making decisions based on the wrong numbers. This guide cuts straight to what matters for indie iOS developers trying to understand where their revenue is coming from and why it moves.

Sales Reports vs. Financial Reports: Not the Same Thing

The first confusion most developers hit is treating 'Sales' and 'Financial' reports as interchangeable. They measure different things at different points in time.

• Sales Reports (available daily and weekly) show units, proceeds, and refunds as transactions happen. These are the numbers you see in the App Store Connect dashboard. They're denominated in the customer's local currency or in USD depending on how you pull them.
• Financial Reports (available monthly) show the actual amount Apple will pay out to your bank account. They're denominated in your payout currency, net of Apple's commission, taxes, and any adjustments. This is the real money.
• The two figures will never match exactly — currency conversion timing, tax withholding in certain territories, and the cut Apple takes all create a gap. Don't panic when they differ.

Understanding Proceeds vs. Revenue

Apple pays you 'proceeds', not 'revenue'. The distinction matters for accounting. Proceeds are what you receive after Apple deducts its commission — 30% for most transactions, 15% for developers in the Small Business Program and for subscriptions after the first year. When you export a Sales Report, the 'Developer Proceeds' column already reflects this deduction. The 'Customer Price' column is the gross amount the customer paid. Never confuse the two when forecasting or filing taxes.

The 'Developer Proceeds' column is your money. The 'Customer Price' column is Apple's starting point. Build your financial model around proceeds, not price.

The Columns You Actually Need to Watch

A raw Sales Report export contains over a dozen columns. Most of them you can ignore day-to-day. Focus on these:

• Units — the number of transactions of that product type. A unit of '1' for a subscription renewal is not a new customer; it's a renewal event.
• Product Type Identifier — this is the most overlooked column. Codes like '1' (paid app), '7' (auto-renewable subscription), 'F1' (free redownload) and 'IA1' (non-consumable IAP) tell you what actually happened. Filtering by '7' isolates subscription activity; filtering by '1' shows you new paid installs.
• Country Code — revenue is not evenly distributed across your install base. The US, UK, Australia, and Japan often punch above their weight on proceeds per user. Knowing which territories drive real revenue shapes your localisation priorities.
• Begin Date / End Date — for subscriptions, these columns tell you the exact period being billed. They're how you reconstruct your active subscriber count from a flat file.

Rebuilding MRR From a Sales Report

App Store Connect doesn't show you MRR (monthly recurring revenue) directly — you have to calculate it yourself. The method: filter your weekly Sales Report for Product Type '7' (auto-renewable subscription renewals), multiply units by the developer proceeds for each row, and sum by territory. Do this for the last four weekly reports to approximate a month. It's imprecise because weeks don't align to calendar months and trials show up with zero proceeds, but it gives you a directional number you can track week-over-week. Tools like Appolyn automate this calculation and surface it as a clean dashboard, so you're not wrestling with CSVs every Monday morning.

Refunds and Why They Disappear

Refunds appear in Sales Reports as negative unit entries with the same Product Type as the original purchase. The tricky part: they show up in the report for the date the refund was processed, not the date of the original sale. If you're summing proceeds by week, a refund processed this week for a purchase made two months ago will reduce this week's proceeds figure. That's not revenue volatility — it's just the reporting model. When calculating lifetime value or cohort revenue, always join refunds back to the original transaction date, not the refund date.

Territory-Level Proceeds and Currency Risk

If you sell globally, Apple collects in local currencies and converts to your payout currency at the time of payout, not at the time of sale. This means a strong quarter in Europe can yield lower-than-expected GBP or USD proceeds if the euro weakened between the sale and the payout date. There's no practical hedge for indie developers here, but being aware of it stops you from chasing ghost revenue swings. The Financial Report (monthly) is the definitive record for what actually landed in your bank account.

A Quick Workflow for Weekly Review

Rather than drowning in raw data, build a lightweight weekly habit around a few key questions:

• Are new paid units (type '1' or '7' first-time subscriptions) up or down versus last week? If down, look at your store listing — conversion may have slipped.
• Are subscription renewals (type '7') holding steady? A drop here signals churn, not acquisition problems.
• Are any territories showing unexpected spikes or drops? A spike might mean press coverage or a featuring; a drop might mean a competitor moved in.
• What's the refund rate this week? If it's suddenly elevated, check recent reviews for a bug report you haven't seen yet.

Appolyn pulls this data directly from App Store Connect and presents it alongside your metadata and review activity, so the context for a revenue shift — a keyword rank change, a new review trend — is right there rather than in a separate tab.