App Store Connect financial reports: how to read proceeds, taxes, and territory breakdowns

Apple's financial reports contain the definitive settled-payout figures your Sales and Trends dashboard doesn't show. Here's how to read, download, and automate them.

Most iOS developers spend their analytics time in the Sales and Trends section of App Store Connect: interactive charts, filterable by product and territory, updated daily. It is the right tool for day-to-day operations. But when you need to know exactly what Apple will pay you — after commissions, after exchange-rate conversion, after any applicable tax withholdings — you are looking in the wrong place. That data lives in Financial Reports, a separate section of App Store Connect that generates one tab-delimited report per reporting region per month and has no dashboard view at all.

This post explains what financial reports contain, how to read them, and how to automate their download with the App Store Connect API so your reconciliation workflow does not depend on manual exports.

Financial reports vs Sales and Trends: the key differences

Sales and Trends and financial reports are built on different data pipelines and serve different purposes. Understanding the distinction prevents a common class of reconciliation confusion that affects developers at every scale.

What's inside a financial report file

Financial reports are delivered as UTF-8 tab-delimited text files compressed as .gz. Each row represents a single aggregated line item: one product, in one territory, for the reporting period. Multiple transactions of the same type — same product, same customer price, same period — are rolled into a single row with a Quantity count rather than appearing as individual transaction lines.

The columns you will use most often:

• Partner Share — your gross revenue share for this line item, in the local storefront currency, before any withholding tax. This is the figure that flows into the settlement calculation.
• Partner Share Currency — the ISO 4217 currency code for the territory (BRL for Brazil, INR for India, EUR for Eurozone storefronts, and so on).
• Extended Partner Share — the equivalent value converted into your settlement currency (typically USD or EUR, depending on your banking entity) using Apple's fixed monthly exchange rate for this period.
• Sales or Return — S for a sale, R for a refund or chargeback reversal. Refunds appear as positive Partner Share amounts on R rows, not as negative values on S rows, so you must handle them separately in any aggregation.
• Quantity — the number of transactions aggregated into this row. Multiply by unit price only if you need to cross-check; use Partner Share for revenue totals.
• Apple Identifier — your app's numeric App Store ID. Useful when one vendor number covers multiple apps and you need to isolate revenue by product.
• Product Type Identifier — a code distinguishing paid downloads, consumable in-app purchases, auto-renewing subscriptions, and other transaction types. Apple's documentation lists all current codes.

To compute settled proceeds for a month: sum Extended Partner Share for all S rows, then subtract the sum for all R rows. The result should reconcile to within rounding tolerance of your bank deposit for that settlement cycle.

Apple's fixed monthly exchange rate and what it means for forecasting

Apple does not convert your proceeds at the live mid-market rate on each transaction date. Instead, Apple publishes a fixed exchange rate for each currency, set around the beginning of each reporting month, and applies that rate uniformly to every transaction in the period. The rate approximates the interbank rate at the time of publication but will diverge from live rates throughout the month.

The practical consequence: revenue in currency-volatile markets — Brazilian reais, Turkish lira, Indian rupees — carries exchange-rate uncertainty that only resolves when Apple locks its monthly rate. If you are modeling expected USD proceeds from an INR price point, you are making an assumption about Apple's rate that may differ from reality by several percentage points. The definitive figure only appears when the financial report is published.

Apple publishes its exchange rate reference file alongside each month's financial reports in App Store Connect. Download it alongside the revenue data to retain a reconcilable audit trail. If you are making pricing decisions that depend on currency dynamics, our post on where Apple's currency conversion silently costs you revenue covers the mechanics in detail, and our primer on PPP-adjusted pricing explains the strategic layer.

Downloading financial reports via the App Store Connect API

App Store Connect lets you export financial reports manually through the web interface. Any workflow that runs more than once a quarter will be better served by the API. The /v1/financeReports endpoint returns the same compressed files as the manual download, accessible from any script or scheduled function that can generate a signed JWT.

Prerequisites:

• An API key with Finance access. Finance is a separate permission from Admin — you must grant it explicitly when creating the key in App Store Connect under Users and Access → Integrations → App Store Connect API. Existing Admin-only keys cannot be upgraded; you will need to create a new key.
• A signed JWT. The full setup — issuer ID, key ID, .p8 private key, and token construction — is covered in our guide on App Store Connect API JWT authentication.
• Your 8-digit vendor number, visible on the Payments and Financial Reports page in App Store Connect.

Request parameters:

• filter[reportType]: FINANCIAL
• filter[regionCode]: a two-letter code — US, EU, WW for worldwide aggregate, or territory-batch codes
• filter[reportDate]: YYYY-MM format (e.g., 2026-05)
• filter[vendorNumber]: your 8-digit vendor number

A minimal Python example that fetches the US financial report and prints each line's title, partner share, and currency:

import requests, gzip, io, csv

url = "https://api.appstoreconnect.apple.com/v1/financeReports"
params = {
    "filter[reportType]": "FINANCIAL",
    "filter[regionCode]": "US",
    "filter[reportDate]": "2026-05",
    "filter[vendorNumber]": "YOUR_VENDOR_NUMBER",
}
headers = {"Authorization": f"Bearer {your_signed_jwt}"}

response = requests.get(url, headers=headers, params=params)
with gzip.open(io.BytesIO(response.content)) as f:
    reader = csv.DictReader(
        io.TextIOWrapper(f, encoding="utf-8"), delimiter="\t"
    )
    for row in reader:
        print(row.get("Title"), row.get("Partner Share"), row.get("Partner Share Currency"))

Territory breakdowns: reading your real revenue geography

The worldwide report (regionCode=WW) gives a single rolled-up total useful for top-line reconciliation. For territory-level analysis, download the regional variants. Apple groups storefronts into reporting regions rather than individual countries, so the granularity is coarser than a per-country breakdown:

Once you have per-region data, aggregate Partner Share by currency to build a revenue-by-currency map. Research published by RevenueCat and analysis from Phiture have both pointed to a consistent pattern: apps without localized pricing tend to see their revenue heavily concentrated in the US and Western Europe — not because users in India, Brazil, or Southeast Asia are not installing the app, but because the local price-to-purchasing-power ratio is too high to convert at comparable rates. The financial report is the data that makes this argument in a language every stakeholder understands: actual settled cash.

Connecting territory revenue data to PPP-adjusted pricing analysis is one of the highest-leverage exercises a subscription app operator can run. The AppsOps pricing tools are built to support exactly that workflow — mapping settled financial report data to optimized local price points.

Reconciling reports against bank deposits

Summing Extended Partner Share for S rows and subtracting R rows should produce a figure close to your actual bank deposit for the settlement period. When the numbers diverge beyond rounding, the most common explanations are:

• Period boundary timing — Apple's financial month does not align with the calendar month. Sales from the last few days of a calendar month sometimes roll into the next financial period. If you are missing revenue in one month's report, check the following month before assuming an error.
• Tax withholdings — In some territories, Apple withholds local tax at source and remits it directly to the tax authority. Your net payout is reduced even though the Partner Share column shows the pre-withholding amount. Some report formats include a separate column for withheld amounts; check the header rows of the report file for territory-specific tax columns.
• Rounding — Apple rounds per-row values before aggregation, which can produce small cent-level discrepancies versus independently computed totals. These are expected and do not indicate a payout error.
• Bank fees — Wire transfer and currency-conversion fees charged by your bank reduce the deposit below the settled amount. These appear on your bank statement, not in the financial report.

Building an automated pipeline for recurring reconciliation

For a single-app indie developer, a monthly manual export and spreadsheet calculation is a workable approach. For anyone managing multiple apps, running a subscription analytics stack, or wanting audit-grade accuracy with minimal manual work, automation is straightforward to implement with the API.

A minimal automated pipeline has four stages:

1. Scheduled pull — a cron job or serverless function fires on approximately the 5th of each month (after Apple makes the prior month's reports available), downloads all regional financial reports and the exchange rate reference file, and stores the raw .gz files indexed by month and region code.
2. Parse and normalize — decompress and parse the tab-delimited rows; compute settled proceeds per app, per region, and per currency; accumulate S totals and R totals separately before netting.
3. Bank reconciliation check — compare computed Extended Partner Share totals against the actual deposit amount for the settlement period. Flag discrepancies above a threshold — small rounding differences are expected; larger ones warrant investigation.
4. Subscription analytics join — if you are tracking MRR, churn, and LTV separately via RevenueCat or a StoreKit 2 backend, join financial report proceeds to your subscription data to build a reconciled LTV view that ties back to actual settled cash rather than estimates.

The same API key and JWT used for financial reports also authenticates Sales and Trends requests. Building both into one pipeline gives you daily estimated visibility and month-end accounting accuracy from a single connection — a cleaner architecture than maintaining two separate data-pull workflows.

Sources and further reading

• App Store Connect API documentation — Apple Developer (developer.apple.com)
• App Store Connect Help Center — Apple (help.apple.com)
• Finance Reports: regions and currencies reference — Apple Developer Help
• RevenueCat Blog — subscription app revenue data and benchmarks (revenuecat.com)
• Phiture Mobile Growth Stack — ASO and subscription monetization research (phiture.com)