Help and user guide

This guide explains how to use App Sales Dash from first launch through everyday reading, sales and downloads, paid apps and one-time purchases, working across your apps, reconciliation, monthly statements, settings, and backup.

Menu and button names appear in bold. Paths such as Settings > Stores describe where to click in the app.

1. Before you begin

System requirements

• A Mac with Apple silicon or an Intel processor.
• macOS 15 or later.
• Access to the store accounts you want to connect. Each store requires a fairly senior role; the exact roles are listed below and in Chapter 4.
• An internet connection. The app talks to the stores’ own APIs and fetches daily exchange rates from the European Central Bank.
• Enough free storage for a local database and an archive of every report the app downloads.

Everything stays on your Mac. App Sales Dash keeps a local database and a raw report archive; credentials go into the macOS Keychain and are sent to the three stores’ own APIs and nowhere else. There is no account, no server, and no analytics. Every store connection is read-only: the app writes nothing to any store account.

What you need from each store

Collect these before you start. Chapter 4 walks through creating each one, and the app carries the same walkthroughs behind Guide on the first screen or Setup guide… in the store’s ··· menu in Settings.

• App Store: an Issuer ID, a Key ID, a .p8 private key file, and the Vendor Number. Created by the Account Holder or an Admin. About 5 minutes.
• Google Play: a service-account JSON file and the reports bucket URI. Needs a Google account that can make a Cloud project, and a Play Console owner or admin. About 20 minutes.
• Stripe: one restricted, read-only API key. Created by a Stripe administrator. About 5 minutes.

You can connect the stores in any order, and you do not need all three. A store with no credentials simply contributes no figures, and the app says so on every affected screen rather than quietly leaving it out of the totals.

The two layers in every figure

Two kinds of number reach you, and every figure on screen tells you which one you are looking at:

• Estimates are the stores’ daily figures. They arrive fresh, usually the next day, and they are provisional: the store itself will restate them.
• Finals are the stores’ own settled reports. They are authoritative and they are late: Apple and Google publish them after the month closes.

Every figure on screen carries a label saying which layer it rests on. When a period’s finals land, the period switches to them and the app tells you on the screen where the figure sits, so if a number you have already sent to your accountant moves, you hear about it.

All money is shown in your consolidation currency, by default the one your stores pay out in, converted with ECB daily reference rates. If no store states a currency, as with an App Store-only account, the app uses your Mac’s region until you choose one. Settings says where the currency came from. Chapter 2 explains both layers, the labels, and the conversion in detail.

2. How App Sales Dash treats your numbers

This chapter is how to read any figure in the app: how firm it is, what it left out, and when it will change. The rest of the guide uses this vocabulary. Every monetary figure in App Sales Dash carries a basis label, every gap is named instead of drawn as zero, and every restatement is announced.

The five basis labels

Charts and totals are labelled with one of five words. Hover any label for the app’s own explanation:

• Final: the store’s own settled figure for these days. It will not change.
• Allocated: a settlement total spread across its days. Exact for the period as a whole, an inference for the individual day. Unlike an estimate, it will never be restated. Apple settles over spans that start and end mid-month, so a calendar view of Apple is nearly always allocated.
• Estimate: no finals have landed for these days yet, so the figure comes from the daily estimate rows. Drawn in a lighter shade, because it will be restated once the store settles the period.
• Part estimate: the days span settled and unsettled periods. The unsettled part will still change.
• No figure: nothing was reported for these days, so a money figure reads No data, never 0. A quiet day inside a reported period reads 0, so you can tell a day with no sales from a day the store has not sent yet.

Two chart conventions follow from this:

• The faded stretch of a chart is labelled Will be restated. Its shape is the best reading available, and the figures behind it will change when the finals land.
• A day no store reported is a hole labelled Not reported: the bar is absent and the line is broken rather than drawn through zero. A gap in the chart means no store sent figures for that day, not that you sold nothing that day.

When finals arrive

“Provisional” on its own tells you a figure will change without telling you when to come back. App Sales Dash puts a date on it, per store:

• App Store publishes a financial report per settlement period, by roughly the first Friday after that period closes. The app reads the exact expected date and shows it: “App Store publishes its final figures for this period on Aug 7, 2026.”
• Google Play writes its earnings file for a calendar month into the reports bucket in the first days of the next one. The app treats it as due five days after the month ends.
• Stripe has no second version of a settled transaction. What the app stored is what Stripe will still say next year, so Stripe figures are final immediately.

When an expected report has not arrived by its date, the app says that too, and plainly: a period whose finals are weeks overdue is no longer a matter of waiting. Something is wrong, and the screen names it instead of repeating “not final yet”.

Restatements are named

When a store’s finals land for a period, the period’s totals switch from estimates to the store’s own figures. The (i) of the Revenue chart names each restated period: “Finalised on <date>. The estimates for this period have been superseded.” When an app update re-reads your stored reports and figures move, Notifications says so. On the charts themselves the change is visible rather than stated: the faded Will be restated shading over a period disappears once its finals land. Nothing is changed silently, and the daily estimates are kept: they still draw the shape inside a finalised period, marked as such.

Notifications tells you when an app update re-reads your stored reports and figures move, and when a disregarded plan earns money again. An entry with a destination carries a button naming the screen, such as Open Overview.

The raw report archive

Every report the app downloads is archived verbatim, byte for byte. Every figure on screen can be traced back to the report it came from.

The archive is also why the app can correct itself. When an update teaches the app to read a stored report more accurately, the archive is re-read locally (a banner across the top of the window says so while it runs), and any figures that changed are announced in Notifications. Nothing is re-downloaded, and nothing is asked of the stores again.

The archive matters for one more reason: Apple keeps its daily reports for one year only, then deletes them. For older days, your archive is the only copy that exists anywhere. The Data section of Chapter 12 covers keeping it safe.

Everything is in one currency

Figures are normalised into a single consolidation currency using the European Central Bank’s daily reference rates. It is not fixed to any particular currency. It resolves in this order:

1. What you chose in Settings. The Currency row under Settings > General shows the currency in force and lets you pick another.
2. What your stores say they pay you in, where you have chosen nothing. Stripe states its payout currency and Google Play its Merchant Currency, so a single-store account or a set of stores that agree needs no decision from you.
3. Your Mac’s region, when no store states a payout currency, as with an App Store-only account. Settings shows where the currency came from, and you can choose another.

Where two stores pay out in different currencies and you have chosen none, cross-store totals show a dash and Settings says why rather than picking one. This is the case that still asks you to choose.

In the payout ledger, Stripe payouts stay in the currency Stripe pays you in. Expected App Store and Google Play payouts are shown in your consolidation currency, converted at ECB rates, which makes them estimates of what the bank will receive. Elsewhere, only totals across stores or countries are converted.

The conversion states where it falls short. A row whose currency has no published rate for its day is excluded from the total and counted, with a note: “Short by N rows whose currency had no exchange rate for their day. The total is missing whatever they were worth.” The ECB publishes no rates at weekends or on holidays, so a rate may carry over for up to seven days; conversions made at an older rate are marked. You would have no way to spot a wrongly converted amount on screen. It looks like any other figure. So rows the ECB published no rate for are left out of the total and counted for you, rather than converted at a guess.

The notes behind (i)

Read a figure’s limits before quoting it. The (i) buttons on groups and panels explain missing exchange rates, older counts, plans without measured rates, and figures a store cannot report. On Overview, use the button on the Revenue, Sales or Subscribers group; on Revenue and Subscriptions, use the button on the panel concerned. Notes about a missing figure stay beside it. View > Data Notes… collects the current screen’s qualifications in a separate window.

3. First launch

What you see first

On first launch, the window shows Connect your stores. It explains that sales, subscriptions and payouts come straight from App Store Connect, Google Play and Stripe, and everything stays on this Mac.

Each store has its own row with Connect…, Guide, who can issue its credentials, and roughly how long setup takes:

• App Store: the Account Holder or an Admin; about 5 minutes.
• Google Play: a Google account that can make a Cloud project, and a Play Console owner or admin; about 20 minutes.
• Stripe: a Stripe administrator; about 5 minutes.

Click Guide for the walkthrough, or Connect… if you have the credentials ready. Connect any store in any order. The first download runs on its own after saving; the App Store takes about ten minutes.

Explore with sample data lets you look through the screens with invented figures before connecting a store. Your own data is not opened, read or written while the sample is showing. The timeframe and amounts menus appear once there are figures to filter.

The credential prompt sequence

Connect… on the first screen or in Settings > Stores opens that store’s form. The form stays closed until you ask for it.

Fill it in and click Save. If another store still needs credentials, Save, then set up Google Play (or the next store’s name) saves this connection and opens that store’s form. You can stop partway; a missing store contributes no figures, and the screens say which totals that affects.

Chapter 4 covers each form, field by field.

What the history download does

Saving credentials starts that store’s history download immediately. The app works backwards, downloading and archiving every available report. While it runs, Downloading history shows a progress bar per store, a step count and an estimate of the time remaining. A store that has not started reads Waiting; a finished one reads Complete.

Apple keeps daily reports for one year only. The history download collects everything that still exists; older days cannot be recovered from anywhere. Connecting sooner preserves more history.

Quitting is safe. The history download resumes where it stopped and nothing is downloaded twice.

How long the first sync takes

Apple is the slow one: about a thousand throttled requests, roughly ten minutes for a year of daily reports. Google Play and Stripe finish sooner.

Screens fill in as data lands, and empty screens explain themselves rather than sitting blank. Some of what looks missing at first is simply the stores’ own timing:

• Apple’s daily subscription reports appear the day after; Google Play subscription statistics lag 3 to 7 days.
• Apple’s final figures arrive about a week after its own settlement period closes, and Google’s around the third of the month. Until then a period shows daily estimates only.

After the history download, the app refreshes when it opens, when your Mac wakes, and on a timer you choose in Settings, from Every hour to Once a day. Only when I ask turns the timer off; the catch-up when the app opens and when the Mac wakes still happens. A sleeping Mac loses nothing: each refresh picks up where the last one stopped.

4. Connect your stores

Settings > Stores shows each store’s connection and data status. Use Connect… for a store without credentials, or Test to check a connected one. A permission failure offers Fix permissions…, which opens the setup guide; Test is then in the ··· menu.

That menu also holds Change credentials…, Setup guide…, and Remove… where credentials are stored. Each row gives its test time, data date and next refresh when available. Failures stay visible with a remedy. An inconclusive test says Test could not run.

In a connect sheet, Setup guide… keeps what you typed; Enter the values returns to the form. The sheet’s (i) gives the permissions. Store consoles change, so follow the names as well as their positions.

Three ground rules apply to all of it:

• Credentials are kept in the macOS Keychain on this Mac. They are sent to the stores’ own APIs and nowhere else.
• Every request the app makes is a read, including Test and Stripe’s Detect. The keys you create below cannot write anything.
• Each secret is downloaded or shown only once. Have your password vault open before you press the button that creates them.

App Store

Who can do this: the Account Holder, or an Admin. You end up with: an Issuer ID, a Key ID, a .p8 file, and the Vendor Number. Takes about 5 minutes.

1. Sign in to App Store Connect and open Users and Access > Integrations > App Store Connect API. The first time, the Account Holder may have to accept the API terms before any key can be created at all.
2. Select the Team Keys tab, not Individual Keys. An Individual key belongs to one person, signs in perfectly, and is refused every report. This is the most common way this setup fails.
3. Press +, name the key something like App Sales Dash (read-only), and set Access to Finance, not Sales. Finance covers both the monthly financial reports and the daily Sales and Trends data; Sales reads the daily ones only, and the financial reports are what your payouts reconcile against.
4. Press Download API Key at the end of the new row. The .p8 downloads exactly once and Apple keeps no copy. If you lose it, the only remedy is revoking the key, which stops it working everywhere else at the same moment. Put it in your password vault before doing anything else, and keep Apple’s filename: the Key ID is in it, so you can compare it with the one you type.
5. Copy the Issuer ID (above the key list, with a copy button) and the Key ID (the ten-character value in the row).
6. Find the Vendor Number in a different section: Payments and Financial Reports > Reports, top left. Eight digits starting with 8. Not the Team ID, not the App ID.

In the app: in Settings > Stores, click Connect… beside App Store. The Connect App Store sheet has Issuer ID, Key ID, Vendor number, and Private key (.p8). Type or paste the identifiers. For the key, use Drop the .p8 file here, Choose file…, or Paste it instead. A loaded file is named with its character count; its contents are not shown back.

The sheet checks what you enter as you type: a certificate instead of a private key, or a .p8 pasted short of its closing line, is named under the field it is about, rather than as an authentication error during the history download.

Click Save, then Test in the store’s row.

Google Play

Who can do this: a Google account that can make a Cloud project, and a Play Console owner or admin. You end up with: a service-account JSON file and the reports bucket URI. Takes about 20 minutes.

Google is the fiddly one, because the credential is created in one product (Google Cloud) and the permission that makes it useful is granted in a completely different one (Play Console).

1. In Google Cloud (IAM & Admin > Service Accounts > Create service account), pick any project (it is only a container for the identity) and create a service account.

2. Google offers to grant it access to the project. Do not. Leave the role empty. No Google Cloud permission is needed at all: the reports bucket belongs to Google Play, not to your Cloud project. This is where people lose an hour.

3. On the Keys tab, add a key of type JSON. It downloads once. Then copy the service account’s email address. You need it in the next step. The part after the @ is the Cloud project’s name and has no bearing on which apps it can read.

4. In Play Console, open Users and permissions at the developer-account level, not inside an app, and choose Invite new user. Paste the service-account email. Service accounts accept the invitation automatically; no confirmation mail is sent.

5. Open the Account permissions tab, not App permissions, and tick both of:

   • View app information and download bulk reports (read-only)
   • View financial data, orders, and cancellation survey responses

   Then press Invite user. Granting the same two permissions for a single app produces a service account that looks perfectly configured and is refused every request: the reports bucket is account-wide.

6. Go to Download reports > Financial and press Copy Cloud Storage URI. Paste it exactly as Google gives it, gs:// and all. Do not retype it or rebuild it from your developer-account ID: the app strips the prefix itself, and every other character has to survive untouched.

In the app: click Connect… beside Google Play in Settings > Stores. Connect Google Play has three fields: Service account JSON, Cloud Storage URI, and Package name (optional). Use Drop the JSON file here, Choose file…, or Paste it instead for the JSON, and paste the URI exactly as Play Console copied it. The package name is a label for your own reference; leaving it empty does not change which apps the reports cover.

The sheet checks for the wrong JSON type or a paste that lost its outer braces. Save, then use Test in the store’s row.

Two waits are normal and are not credential problems:

• Play access can take up to 36 hours to take effect, and usually takes minutes. If Test says the key is not allowed to read that shortly after the invitation, wait and retry before assuming anything is wrong.
• Google Play generates these reports only once the account has financial activity. Before the first sale there is nothing in the bucket to download, so a new Play account shows no Google figures until Google writes its first reports, even with valid credentials and a green test.

Stripe

Who can do this: a Stripe administrator. You end up with: one restricted, read-only API key. Takes about 5 minutes.

1. Sign in to the Stripe Dashboard and check the mode switch before creating anything: you must be in live mode, not test mode or a sandbox. A test key authenticates happily and returns an empty, irrelevant world, which looks like an account with no sales.
2. Go to Developers > API keys and, in the Restricted keys section, not the standard secret key, choose Create restricted key. Name it something like App Sales Dash (read-only).
3. Set exactly these seven resources to Read, and leave everything else at None: Balance, Charges and Refunds, Payouts, Invoices, Subscriptions, Prices, Credit notes. Seven toggles, all Read. The app never writes anything to your Stripe account.
4. Credit notes is the one people leave off, and it is not optional. Without it the whole Stripe source stops rather than skipping that feed. That is deliberate, because a silently skipped credit-notes feed overstates revenue. Permissions on an existing key can be edited later without re-creating it.
5. Create the key and copy it. Stripe shows a live restricted key exactly once; a lost one has to be re-created, not looked up. Put it in your password vault before pasting it anywhere.

In the app: click Connect… beside Stripe in Settings > Stores. Connect Stripe has Restricted key and API version. The key field is secure and checks for a publishable key, a webhook secret, a full secret key, or a test key.

To fill in the API version:

1. Paste the key into Restricted key.
2. Leave API version empty.
3. Click Detect.

The app makes one read-only request and pins the version Stripe answers with. A refused key is reported as a key problem. If the key field is empty, it says “Enter the restricted key first: the version is read from the account it belongs to.”

The pinned version is sent on every request, so an upgrade clicked in the Stripe dashboard can never change the API underneath the app. If you already know your account’s version, you can type it and skip Detect.

Click Save, then Test in the store’s row.

Test, and its results

Use Test in a connected store’s row. If the row offers Fix permissions…, find Test in its ··· menu. Testing reads from the store and writes nothing to its account.

Hover the connection line for the test’s detail. Failures and remedies stay below it.

Before the first test, the hover text reads Not tested yet.

Two caveats on a green verdict, both of which the detail states in as many words:

• App Store. A settlement period with no activity looks exactly like a key without the Finance role. When that happens the app falls back to a daily sales report, and if that succeeds it says the key authenticates and can read reports, but that the Finance role specifically is not proven.
• Stripe. The test proves the key and the Prices permission. The other six permissions are not exercised, so a green Stripe row does not mean all seven toggles are on. And a rk_test_ key passes this test and still fails every sync. The detail flags it.

The macOS keychain dialog

The footer of Settings > Stores names where credentials are kept. Its (i) gives the keychain details.

When credentials are in the login keychain, macOS may ask permission to release each credential after an app update. Choose Always Allow. Plain Allow grants a single read, and the next unattended sync, which is not permitted to put a dialog on your screen, fails instead of prompting. Background refreshes deliberately suppress the dialog rather than parking a modal on an unattended Mac; until you allow the app again from Settings, that surfaces as a credential needing attention, not as a broken key.

Changing credentials later

Use Change credentials… in the store’s ··· menu. The title names the store, such as Change App Store credentials. Identifiers are filled in; secrets are kept without being shown back. A line such as “Stored · 241 characters · leave empty to keep it” stays visible while you type. You can correct a Vendor number without finding the private key again.

To replace a key file, drop it onto the field, use Choose file…, or use Paste it instead. For Stripe, paste the replacement into Restricted key. An empty secret field keeps the stored value.

Remove… in the store’s menu deletes its credentials from the Keychain. Its figures stop updating; downloaded history stays on this Mac.

5. Learn the main window

The main window has three areas:

1. Left sidebar: the eight screens, listed under Dashboard as Overview, Revenue, Sales, Subscriptions, Reconciliation, Notifications, Diagnostics, Settings. Notifications carries a badge with the unread count, and only when there is one. Diagnostics holds the Activity log: what each store did and what went wrong.
2. Toolbar: the app picker, the Timeframe menu and the Amounts menu on the left; the three store health chips and Refresh Now on the right. Each chip shows the store name and a coloured status dot; hover for its state and detail.
3. Content area: the selected screen. The window subtitle shows the selected dates. On Overview, Revenue, Sales and Subscriptions it also names the comparison period, for example Sep 22 to Oct 21, 2026 · compared with Aug 23 to Sep 21.

The app choice, timeframe and amounts basis are global. Choose All apps, one app or Unassigned once and the choice is remembered. Change the timeframe or amounts basis once and every screen answers for the same days on the same basis. Reconciliation always covers the store account; its app filter does not apply. Settings and Diagnostics have no filter menus. On Reconciliation the app menu is greyed; hover it for the reason. The payout ledger covers every period, whatever timeframe the toolbar shows.

Choose a screen

Click a screen name in the sidebar. What the content area shows depends on where the app is in its life:

• Before any store has credentials, it shows Connect your stores (Chapter 3).
• During the history download, it shows Downloading history. Once the first data is in, the screens appear and a compact progress banner sits above them until the history download finishes.
• After that, each screen shows its own panels.

Settings and Diagnostics are reachable in every state. You can also open Settings… from the application menu with Command-comma.

The (i) buttons

Click (i) beside a figure, group or panel for its explanation and limits. Overview has a button on every tile and shared qualifications on the group. Revenue and Subscriptions explain each panel through its button. Missing figures keep a reason beside them. Set rates… opens Plans and rates.

Set the timeframe

1. Click the Timeframe menu in the toolbar. Its label always shows the current selection.
2. Choose a preset: Last 7 days, Last 30 days, Month to date, Last month, Quarter to date, Year to date, or All time.

Last 30 days is the default. Ranges include both end days, so Last 7 days is today and the six days before it. All time starts at the first day any data exists for.

There is no date-picker preset. A custom range comes from the chart on the Overview screen: drag across the revenue trend and click Zoom to selection (Chapter 6). While a custom range is active, the Timeframe menu shows its dates and gains a Clear selection item that returns to the default.

Choose an app

See one app’s numbers across the screens without setting a filter in each one:

1. Open the app picker to the left of Timeframe.
2. Choose All apps, one app, or Unassigned for figures not yet assigned to an app.

The choice is remembered across launches. If the saved app disappears, the app says Showing All apps. The same app on the App Store and Google Play is recognised as one app when its bundle id and package name match. Rename, merge or split apps and assign Stripe prices in Settings > Apps. A caveat tells you when a figure includes unassigned rows. Reconciliation keeps showing the whole store account; choose an app separately when you export a statement.

Choose what the amounts mean

The Amounts menu switches every money figure in the window between two readings:

• Proceeds: what the stores pay out, before your own VAT. This is the default, because it is what the bank credit will say.
• Customer spend: what customers paid, including store commission and tax.

The two are different claims about the same sales, and App Sales Dash never mixes them in one total.

App Store customer spend

Compare all three stores on what customers paid. Apple’s customer price arrives as an estimate from the daily report and becomes final with the monthly financial report. Apple does not split its commission and tax, so the App Store shows no fee or tax figure, and the app says so.

Read the health chips

One chip per store (App Store, Google Play, Stripe) sits in the toolbar of every screen. The toolbar shows its store name and a coloured dot. Hover to read the state and last refresh details:

A chip can also replace its dot with an exclamation mark: Needs attention. That means retrying will not clear it. The store is waiting for you to re-issue or re-grant the credential in Settings. The distinction matters: a red dot says something is wrong; the exclamation mark says it is wrong and waiting for you.

Hover over a chip for the full sentence: the state, the last sync time (Last sync 22 minutes ago, or Never synced), the last error if there is one, and what would clear it. A spinner on the chip means that store is syncing right now. Click any chip to open Settings.

One deliberate exception: a locked screen does not turn a chip red. macOS may withhold Keychain credentials while the Mac is locked, and that resolves itself at unlock, so the chip judges the store on how fresh its data is instead.

Refresh

Click Refresh Now in the toolbar to sync all configured stores immediately. Otherwise the app refreshes on the schedule set in Settings > General > Refresh every: Every hour, Every 3 hours, Every 6 hours, Every 12 hours, Once a day, or Only when I ask.

A Mac that was asleep has missed nothing permanently. The next refresh picks up where the last one stopped.

When a store is missing

A store you have not connected is named on every screen its figures are missing from:

Google Play has no credentials yet, so its figures are missing from every total on these screens.

The totals are real for the stores that are connected; the note is what keeps them from being mistaken for the whole picture. Google Play has a second, store-side condition worth knowing: Play publishes reports only once the account has financial activity, so a connected but brand-new Play account contributes nothing yet.

6. The Overview screen

Overview answers “how is the business doing over the selected timeframe” in one screen: eleven figures in three group panels, Revenue, Sales and Subscribers, the revenue trend, revenue by store, and a Sources panel. Revenue and Sales sit side by side when the window is wide enough; Subscribers sits below. The (i) buttons explain each figure and the qualifications shared by a group.

The KPI tiles by group

What is this number?

Every tile has an (i) button. It opens a selectable explanation: what the figure measures, Keep in mind, and Right now when there are live qualifications, such as an estimate or an older count. Based on names the included stores, the data dates, the reports and the currency conversion. The group’s (i) collects qualifications shared by its figures.

The panels are deliberately short. This chapter is where the detail lives; the button is there so nobody has to come here first.

The estimate pill

The Revenue figure carries a lower-case estimate pill while any part of the range still rests on daily estimates. MRR carries measured rate. If all three Sales figures are estimates, the header says estimate until the stores settle once for the group. Otherwise an estimate pill stays on each affected figure.

If subscriptions are missing from MRR because their plans have no rate, the tile names the count left out and offers Set rates… to open Plans and rates.

The comparison line

Under most figures sits a change against the preceding period of equal length, shown as an arrow and percentage, such as ▲ 6.1%. The comparison dates appear once in the window subtitle and in full on hover over the change or the timeframe menu.

Green means the move is good news, red bad. For Cancellations and Churn, a rise is the bad direction. Changes under half a percent stay grey. All time has no preceding period. Where an earlier figure is missing, the tile can say no earlier period yet; MRR without a previous figure says rate × count, no comparison.

The “as of” date

Point-in-time tiles (MRR, Paid subscriptions, Trials) can carry a small as of Aug 28 line. It appears only when the count was measured earlier than the last day of the timeframe, and its hover text says exactly what it means:

A count in force, measured on Aug 28, 2026, the newest day every configured store has reported. It is not a figure for the end of the timeframe.

Google Play’s subscription statistics lag 3 to 7 days by design, so an “as of” a few days back is normal. A count whose newest report is more than 14 days old is not shown at all. At that point the feed has stopped, and you would be reading a two-week-old figure as today’s.

When a tile shows no figure

A tile the app cannot answer shows a dash with a label such as No data and a reason. When several figures lack the same store’s report, the group header names the affected figures once; its (i) holds the full explanation. A quiet day inside a reported period reads 0. The short labels you will meet, here and in every table of the app:

In tables, narrow cells show the dash alone; hover over it and the full sentence appears.

The revenue trend

Revenue trend draws total revenue across the timeframe as one line. Its header holds the legend and an (i) button. Two marks help you read it:

• Will be restated: a shaded band behind the stretch of days no store has settled yet. The line’s shape there is the best reading available, and the figures behind it will change when the finals land. The legend entry explains itself on hover.
• Not reported: a day no store reported is a dashed hairline and a break in the line, not a dip to zero. A gap in the chart means no store sent figures for that day, not that you sold nothing that day.

The trend chart is also how you set a custom timeframe: drag across a stretch of it, read the selected dates beneath the chart, and click Zoom to selection. The whole window switches to that range. Clear selection in the Timeframe menu undoes it.

Revenue by store

Revenue by store stacks each store’s contribution per day (or per week or month on longer ranges; see Chapter 7 for granularity). The bars carry the same basis language as everything else:

• solid bars are final;
• solid bars are also Allocated: exact for the settlement period, apportioned to days;
• bars in a lighter shade are Estimate or Part estimate and will be restated;
• a dashed hairline marks a day with nothing reported.

The header legend names stores, estimate and refunded as applicable. Click (i) for the explanation. Refunds appear below zero in red, in the period reported.

Range total lists each store before refunds, Refunded when present, then Net. An orange warning counts rows left out for lack of an exchange rate.

The Sources panel

At the foot of the screen, Sources repeats the three health chips at full size, each with its status line beside the name: Last sync 22 minutes ago, Never synced, Not connected. Any store’s last error is printed beneath in full, and when a store is waiting on you the panel spells out the remedy rather than leaving it to a red dot:

Retrying will not clear this. Open Settings and re-issue or re-grant this store’s credential.

Clicking a chip opens Settings. Read qualifications through the (i) buttons on the figures, groups and charts concerned.

When the screen is empty

Before the first sync finishes, Overview shows Nothing to show yet: This screen fills in once the first sync finishes. If no store is configured at all, an Open Settings button sits beneath it.

7. The Revenue screen

Revenue shows the same revenue as Overview in three panels: Revenue over time, Fees and taxes, and By country. Where a panel has notes on its figures, its (i) explains them.

Revenue over time

The main chart stacks revenue across the timeframe. Its header offers Store, Plan and Type, followed by Day, Week and Month.

• Store gives each store its own colour.
• Plan gives each product its own colour and uses its public name where one is known. Set your own name in Subscriptions > Plans and rates > Plan names. Stripe’s account-level fees appear as Not tied to a product.
• Type compares subscriptions with one-time sales.

The chart offers Day for ranges up to 120 days and Week up to 800 days; longer ranges use Month. A note explains a limit. The same day, week or month choice applies to the Sales and Subscriptions charts.

The legend names each series, estimate, will be restated when relevant, and refunded when refunds are drawn. Open (i) in the panel header for the explanation of daily estimates and settled totals. The App Store settlement note stays visible as one line; its (i) gives the boundary dates and their qualification.

Revenue split by type

See what subscriptions and one-time sales each earned. Choose Type in the chart header. Stripe’s account-level fees and refunds appear as Other.

Refunds on the Revenue screen

See what reduced the total. The chart draws each series before refunds, with refunds as red bars below zero in the period reported. Hover a bar to read the period’s figures. Fees and taxes lists refunds per store, and Range total ends with Refunded and Net when refunds are present.

The basis legend

The legend distinguishes the series, estimates and refunds. The chart’s (i) explains the basis; whole-range totals keep their basis where needed. Read the treatments as follows:

Range totals

Range total lists each series before refunds, Refunded when present, then Net. Entries wrap to fit; a shared Part estimate is said once.

Totals use the full range’s figures, rather than adding the displayed bars. An orange warning names rows left out because their currency had no usable exchange rate.

Fees and taxes

The Fees and taxes table breaks each store’s range into Customer spend, Fees, Tax, Refunds and Proceeds. Fee and tax figures are negative, because that is what they are (reductions of what the customer paid). Read refunds beside those figures to see what reduced the period’s earnings; they are already included in the totals.

The App Store row includes customer spend: an estimate from the daily report, then a final from the monthly financial report. Apple does not split its commission and tax, so the App Store shows no fee or tax figure, and the app says so. The row stays in the table with its customer spend and proceeds; dropping it would leave a table that silently claims the remaining stores are the whole picture.

Google Play and Stripe report their fees, so their rows fill in: Google’s fee rows from its earnings reports, Stripe’s from its balance transactions.

By country

By country lists each country’s units and money for the range: Country, Paid, Free, Proceeds (or Customer spend), Share. Country names appear with their codes, such as Switzerland CH. The money column follows Amounts and shows the store’s currency, with a consolidation figure beside it where the currencies differ.

Units come in two columns for a reason. The stores report a free download, a free-trial start, and a paid subscription as rows of the same shape, so a single units column would put 134 units beside 26.85 for a country where 128 of those units were free downloads. Paid counts the units the proceeds actually came from, net of refunds; Free counts downloads and trial starts.

Countries that earned nothing in the range are left out rather than listed at zero. A download-only market is a fact about distribution, not about revenue, and twenty of them above the one country that pays would bury the answer in its own noise. One exception, on purpose: a country whose total is zero because rows could not be converted stays in the table. That zero is a gap, not an absence, and hiding it would hide exactly what this screen promises to disclose. A row whose country the store never named is labelled Not reported.

Share is the row’s percentage of the range. It shows a dash in two honest cases, each explained on hover: when the range’s total is zero (a share of nothing is undefined), and when the row’s own converted total is short of rows no exchange rate could value. A share computed then would understate the country. A percentage would look as solid as every other row’s, so the dash tells you not to quote it.

Notes on the Revenue figures

Read qualifications through (i) on the panel they affect. The revenue chart explains missing rates, estimates and settlement boundaries; the country panel explains limits on country totals. View > Data Notes… collects the current screen’s qualifications. These are the kinds of note you may meet:

A missing figure keeps its reason beside it; read that as well as the panel’s explanation.

When the screen is empty

With no revenue in the timeframe, the screen explains the calendar instead of showing a bare zero: No revenue in this timeframe. Apple’s final figures arrive about a week after its own settlement period closes, and Google’s around the third of the month. Until then a period shows daily estimates only.

8. The Sales screen

See how many people installed your app, how many paid for it or bought a one-time unlock, and what that earned over the span you choose. Open Sales in the sidebar, between Revenue and Subscriptions. It follows your app choice, Timeframe and Amounts.

Downloads and sales over time

The Sales panel brings together three figures, their comparisons with the preceding period, and three small charts on one time axis. Use Day, Week or Month in the header to choose the detail.

• Downloads counts first installs, free and paid from the App Store, paid from Google Play. A refund does not remove a download. Updates, re-downloads and restores do not count; Google Play does not report free installs and Stripe has no install count.
• Net units sold counts paid app purchases and one-time purchases after reported unit refunds. Its chart is labelled Units sold and shows sales above zero, refunds below zero in red.
• Sales revenue gives what those sales earned on the chosen money basis. Its Revenue chart separates sales above zero from refunds below zero.

The shared legend reads sold, refunded, and final, faded = estimate. Hover a bar to read its figures. Choose one app to see its release history, or All apps for the catalogue.

By version and By country

Under the charts, By version and By country show Downloads, Units sold, Refunded units, Net units, Refunded amount and Sales revenue. You can read sold, refunded and net units side by side. When Stripe refunds are included, the refund column reads Refunds (count): Stripe reports an amount rather than unit refunds, so these refunds do not reduce Units sold or Net units.

With several apps in view, By version puts the app’s short name before each version and keeps each app’s versions separate. Rows whose figures are all known zero are left out. The (i) on By version explains qualifications such as a refund amount missing exchange rates.

Where else you see these figures

The Overview’s Sales group shows the same three measures; the line under Net units sold reads N sold · M refunded. On Revenue, choose Type to compare subscriptions with one-time sales. Monthly statements give one-time sales their own lines and list every refund.

When the screen is empty

With no sales data yet, the screen reads No sales data yet: “Connect a store and sync its reports to see downloads and sales.”

9. The Subscriptions screen

Subscriptions covers the subscriber side of the same timeframe: active counts, starts and cancellations, the trial funnel, MRR movements, By plan, and Plans and rates.

Active subscriptions

Active subscriptions shows Paid and Trials side by side on their own scales. Each chart’s caption gives its latest count and date, followed by own scale. Compare changes over time within each chart; their line heights are not comparable.

Use Day, Week or Month in the header. Days without a count are gaps marked on the axis; a missing count is not a count of zero. The header legend names not reported and provisional (Google Play lags 3 to 7 days) only when those marks are drawn. The (i) gives the reporting limits and the date from which Google Play figures remain provisional.

New and cancelled

New and cancelled draws new subscriptions as upward green bars, cancellations as downward red bars (because that is what they do to the business), and the net as a line. A free trial that ends before its first payment counts as a trial ending, not a cancellation. Open the panel’s (i) for the timing explanation:

Apple reports a cancellation when the paid period ends, not when the customer opted out, so a cancelled yearly subscription appears on its expiry date.

A chart that did not say this would look broken every January. When a bucket is missing any day’s figure, the panel’s (i) says so:

A bucket missing any day’s New or Cancelled figure is drawn as a gap rather than as a smaller bar: the total would be short by an amount nobody can know.

Trial funnel

The Trial funnel panel counts Started and Converted in the timeframe and computes Trial conversion. When the configured stores cannot see trials at all, the panel shows dashes with the reason rather than disappearing. An absent panel would read as “no trials happened”, which is a different claim. The rate is undefined, not 0%, when no trial started: a rate needs something to divide by.

Remember from Chapter 6 that this is a period ratio: conversions counted in a short window mostly belong to trials that started before it.

MRR movements

MRR movements breaks the period’s MRR change into New, Expansion, Contraction, Churned, and Reactivation, each valued at measured plan rates.

Expansion and Contraction can come back as dashes with a reason: an upgrade event records the plan it went to, not the one it came from, so unpaired plan changes cannot be valued and the app refuses to guess. Google Play adds its own limitation, explained behind the panel’s (i):

Google Play does not distinguish upgrades from downgrades, so its plan changes are absent from the movements below.

The plans table

By plan lists plans with figures in the timeframe, leaving out disregarded plans:

• Plan: the public plan name, with the store’s raw identifier kept in small type underneath rather than replaced. The identifier is what a store console, an export, and a support conversation all use, so hiding it would trade one kind of unreadable for another. Names come from the store where it publishes one (Stripe nicknames, for instance), from a linked store selling the same plan, or from your own override in Plan names, in Plans and rates at the foot of this screen.
• Sold on: which stores sell the plan. This column is what explains a missing figure on the same row: a plan sold partly through a store that cannot split its events cannot be split either.
• Active: active paid subscriptions on the plan. When some of them could not be given a measured rate, an orange note on the row says 3 not rated, with the full explanation on hover: they are counted here and left out of the MRR figure rather than priced at a guess, so the plan’s MRR covers fewer subscribers than its Active column shows. The usual cause is a plan whose billing period nothing states, and the hover text says where to fix it: “Give the plan a billing period, or a rate of your own, in Plans and rates at the bottom of this screen.”
• New and Cancelled: event counts for the timeframe. A cell the stores cannot answer shows a dash with its label, Not reported or No data, in the cell itself, because a plan sold through a store that cannot split its events is missing these columns permanently, and the reader should not have to hover to learn that.
• MRR: the plan’s share of MRR, from measured rates. A dash here means no rate could be measured; zero would claim the plan earns nothing, which is a different statement entirely.

When the screen is empty

With nothing in the timeframe, the screen explains the reporting delays instead of implying you have no subscribers: No subscription data yet. Apple’s daily subscription reports appear the day after, and Google Play subscription statistics lag 3 to 7 days. Nothing has arrived for this timeframe. A brand-new Google Play account additionally publishes nothing until it has financial activity.

Each panel’s (i) explains its qualifications and any remedy. If subscriptions have no measured rate, use Set rates… or scroll to Plans and rates.

Plans and rates

At the foot of Subscriptions, Plans and rates brings together the full-width Plan names and Rates panels. The heading summarises rate coverage, subscriptions left out of MRR, MRR, the measurement date and window, and the count date. Its (i) explains how names and rates affect the figures.

Click the heading to fold or open the section; the choice is remembered. It remains available when there are no subscription figures to show.

The section follows the toolbar’s app choice. With one app chosen, the heading, both panels and the disregarded list show that app’s plans; its MRR agrees with that app’s Overview. An app without plans says so. All apps shows plans across the catalogue.

Plan names

The Plan names section decides what a subscription plan is called everywhere in the app. Most rows arrive already named, because a Stripe price usually carries the nickname you gave it in the Stripe dashboard, and a metadata key recorded on a Stripe price can name the App Store product it corresponds to. This section exists for the rest (a store that publishes no name, a plan sold somewhere the link was never recorded) and for the case where the published name is not the one your business uses.

Linked plans share one row with store symbols, Name from the store and Your name. Open a linked row to name a store’s plan separately; Mixed marks a group with differing names. Google Play base plans are shown under their product identifiers.

Leave Your name empty to use the store’s name shown in grey. A name you type is used throughout the app and saves on Return or when you leave the field. Before reports arrive, the panel says No subscription plans have been imported yet.

Rates

MRR is a rate times a count, and the Rates panel is where the rate side is visible and, where necessary, supplied. The rate is measured from what each store actually paid over a trailing window, never read off a price tag, because Apple’s proceeds move with the commission tier and the buyer’s tax treatment, so a list price would be wrong even where one exists.

Measuring needs one thing the reports do not always give: how long a billing period runs. The section is honest per store about why:

• App Store states the billing period on every subscription row of the daily sales report, so these are read rather than set.
• Stripe’s catalogue states the interval outright, so nothing normally needs setting.
• Google Play publishes no billing period at all. A base plan named p1y is a name somebody chose, not a field the store defines. Reading a period out of it would be right most of the time and wrong by a factor of twelve the rest. So for Play, the period is set here, once per base plan.

A plan whose period nobody has established shows Not set in its Billing period picker, is marked in orange, and its subscriptions are left out of MRR entirely rather than counted at zero. The heading’s summary counts how many plans cannot be rated and how many subscriptions that leaves out. Choose the period and the rate is measured from the ledger straight away.

Every measured rate states its provenance: when the rates were last measured, over how many days, and per plan how many payments it was averaged over and since when. First payments are left out, so introductory pricing cannot drag the rate below what a renewal earns. A rate from too few payments carries a warning to treat it as approximate. And a figure you type is never drawn like a figure the app measured: the Override box is empty unless you have overridden (never the measured figure greyed in), Set commits it, it is marked as yours wherever it appears, and the Reset button puts the measurement back. The caption states what to enter: what one billing period earns after the store’s commission and tax, not the price on the store listing.

Plans with no subscribers sit in a disclosure below the active plans. An unrated plan without subscribers holds nothing back from MRR.

Disregard a plan

For an unused plan, open its ··· menu in Plan names or Rates and choose Disregard plan. It leaves those panels, By plan and MRR. Revenue, sales, subscriber counts and charts still include its activity.

The footer under Plan names lists disregarded plans. Click Show, then Regard again to restore a plan with its name and rate. Disregarding applies across the app, whichever app is selected in the toolbar. The choice survives refreshes, history downloads, backups and restores.

If a disregarded plan earns money or gains subscriptions or trials from the month it was disregarded, Notifications tells you. Regard it again to bring it back into the plan figures and remove that notice.

10. Notifications

Notifications sits in the sidebar between Reconciliation and Diagnostics. It collects everything the app has to tell you while it is open, in one list instead of a banner across whatever you were reading. When the list is empty the screen says so: “Nothing to report”, with the explanation “Anything the app needs to tell you turns up here: a store refusing a feed, or figures being restated after an update reads your stored reports more accurately.”

What arrives here

Each notification carries a symbol for its kind:

• Circling arrows: figures moved because a corrected reader ran over your stored reports, typically after an app update; see the section below.
• An (i) in a circle: something worth knowing, such as activity on a disregarded plan. Read the detail to decide whether to regard that plan again.

A store that refuses a request shows where you fix it: its dot in the toolbar turns red, its row in Settings > Stores says what went wrong, and the Activity log on Diagnostics has the details (Chapter 13).

A recurring notice does not become a wall of cards: it keeps its one place, and it returns to unread only when its text changes, because a different message is different news.

Read a notification card

Each card shows a title, the detail text, and when it was raised. Below the text are up to two buttons:

• Open Overview, Open Subscriptions or another named screen: opens the destination the notice concerns, when it has one.
• Dismiss: removes that card.

The header of a non-empty list carries Mark all as read and Clear all, which removes every card.

The unread badge

The sidebar’s Notifications row carries a count of unread notifications, and only when there is one; there is no badge reading zero. Opening the screen marks everything on it as read: anything on screen has been seen, and a badge that survives being looked at is a badge people learn to ignore.

Notifications do not outlive the launch

The list is deliberately per-launch. It describes what happened to your figures on this run of the app; a list of them from three weeks ago would be a log, and the app already keeps those where logs belong: the Activity log on Diagnostics, and Keychain activity under Settings > Stores (Chapter 12). Quitting the app clears the list.

For what qualifies the figures currently on screen (counts from an older day, rows left out of a total), there is a separate Data Notes window: View > Data Notes…, or Shift-Command-D. Its contents are replaced each time a screen reloads.

When an update corrects stored reports

App Sales Dash archives every downloaded report verbatim (Chapter 2). When an update ships a corrected report reader, the app notices at the next launch and re-reads the affected files from the archive, locally, before the launch sync runs. While that happens, a banner under the toolbar reads Correcting stored reports and states what is going on: how many reports, from which stores, that nothing is being downloaded, and that figures for the periods involved may change while it runs.

The result does not stay in the banner. It becomes a notification titled “Archive re-read with a corrected reader”, so it keeps. The notification says how many reports were read again, that nothing was downloaded and nothing was lost, and that some figures may have changed as a result. Two honest additions when they apply: a count of files that still could not be re-read (those periods keep the previous reader’s rows, and the archived bytes are untouched), and a count of archived reports that belong to a store you have not set up yet, which come in when you add that store’s credentials.

11. Reconciliation and statements

The Reconciliation screen is where the app’s figures meet your bank statement, and where the monthly statements for your accountant are produced. It has two panels: the Payout ledger and Statements. The ledger header states its scope: all store accounts and every period since the ledger began, independent of the toolbar’s timeframe. The greyed app menu explains why its filter does not apply.

What you export from this screen goes to your accountant. So the app shows you every status change before it takes it, and warns you about provisional figures before it writes a file rather than after.

Read the payout ledger

The ledger has one row per expected payout, with columns Period, Store, Expected, Received, Received on, Difference, and Status.

• Expected is what the store is expected to send, in the row’s currency: the currency Stripe pays you in for Stripe, your consolidation currency for the App Store and Google Play, converted at ECB reference rates. The stores pay at their own rates, so a small difference against the bank credit is normal. Without a rate, an App Store or Google Play row uses the store’s own currency if the whole month was in one; otherwise no row appears. Where your consolidation currency differs from the row’s, a converted figure sits below it in small type and shows a dash with no rate published when no rate reaches it.
• Received and Received on come from the bank credits you record, or from Stripe when it reports a payout paid; such a row reads Matched, dated with Stripe’s arrival date. Until a credit is there, both show a dash.
• Difference is what the bank credited less the expected amount, in the row’s currency. FX drift and any intermediary bank charge live here; the ledger records the gap rather than forcing the two sides to agree.

Before any payout is expected, the screen explains the waiting: “A row appears once a settlement period closes. Google pays around the 15th of the following month, Apple about 33 days after its own settlement period ends, and Stripe on each payout’s own arrival date.”

Rows then fill in by themselves. The App Store’s appears once Apple’s monthly financial report arrives and shows proceeds, with an estimated amount and, in the row’s note, the day Apple usually pays. Google Play’s appears the same way once it has earnings. Stripe’s come from Stripe, and a payout Stripe reports paid arrives received and Matched on its arrival date. The expected amounts and days are estimates, not promises from the stores.

A refresh never overwrites what you entered: recorded credits, value dates and statuses stay, and a row with a recorded credit keeps its currency. If Stripe later reports a payout failed or cancelled, the credit Stripe reported is taken back; a credit you entered stays.

A month with no sales can become final without a payout row: for Stripe once the app has read the whole month, for the App Store once Apple confirms there is no financial report and the month’s estimates come to zero. A missing Google Play report never counts as an empty month.

The five statuses

One status can carry a claim the app did not check, and it says so on the row, in a tooltip behind a small info symbol. A row marked Matched with no recorded credit reads Matched by hand. Its info symbol explains: “Marked reconciled by hand. No bank credit is recorded against this row, so this app has not compared anything.”

Record a bank credit

App Store and Google Play payouts need you to record the bank credit; Stripe’s usually arrive already recorded. To correct a Stripe credit because the bank shows a different amount, use the same steps. Enter the credit in the row’s currency.

1. Select exactly one row. The Record bank credit button waits for exactly one, because one credit belongs to one payout.
2. Click Record bank credit (also in the row’s context menu).
3. The sheet opens with the amount pre-filled from the expected figure, the cursor in the Credited field, and today in Value date. Type what the bank actually credited.
4. Optionally fill Bank reference with what appears on the bank statement. Stripe writes its payout trace id there, which is the fastest way to find the line again.
5. Press Return, or click Record credit.

The whole entry is designed to take about thirty seconds, and the sheet spends that time telling you what will happen before it does. The Difference is computed and shown while you type, together with the tolerance that decides the status: within it, “Within the … tolerance, so this row will read Matched.”; outside it, “Further than the … tolerance, so this row will read Mismatch and keep the difference on it.” The tolerance is one unit of the row’s currency, or half a percent of the expected amount, whichever is larger, and the sheet prints the actual allowance so the colour in the table and the sentence on the sheet cannot disagree.

One honest case the sheet handles by refusing to guess:

• A period that is not final yet says so on the sheet: “This period is not final. The expected figure can still be restated, and a difference recorded now will move with it.”

After saving, the ledger confirms in a footnote what was written: “Recorded … against … on …”, with the difference.

Mark several rows at once

Select any number of rows and use the Mark selected menu, or the context menu, to set a status in one action: Matched, Carried forward, Ignored, or back to Expected. A footnote confirms the result: “3 rows now read Matched.” A row marked matched without a bank credit reads Matched by hand, with the explanation described above.

The ledger start rule

The ledger starts with the first full month after installation. Earlier periods downloaded with the history arrive Ignored. Open the ledger’s (i) for the start rule, bulk-marking help and qualifications.

Ignored rows are hidden by default. The header counts them and offers Show ignored; the app remembers the switch. Turn it on to see or select those rows. Select before Jul 2026 (using your ledger’s start month) selects the visible history before the ledger start, ready for Mark selected. It is disabled while that history is hidden, with the reason on hover.

Actions exclude hidden rows; hiding drops them from the selection. The action line counts selected and hidden rows, or says Select one row to record its bank credit. Hover an ignored status for its reason.

Export monthly statements

The Statements panel writes the monthly statement set as PDF and CSV, for all your apps or for one app, with one-time sales and refunds included. Its header names the letterhead, or says Letterhead: none set. Click Change… to open Settings > Statements and edit it.

1. Choose the month in the Period picker.
2. Choose what the export covers in the Covering picker: Consolidated statement (the combined summary), App Store statement, Google Play statement, Stripe statement, or Whole month, every store (every store that has something to report, plus the consolidated page).
3. Choose All apps or one app in the Apps picker.
4. Click Export PDF, Export CSV, or Export PDF and CSV.
5. Choose a destination in the folder panel, titled “Choose a folder for the statement set”, and click Export here.

Nothing already in the folder is overwritten: a name that is taken gets a copy written beside it, and the result sheet says so file by file. That sheet lists everything under Written and (the part that matters) everything under Not written, with the exporter’s reason in words, so a set of three documents where four were expected cannot become a month nobody notices is missing. Show in Finder reveals the files. If a sync lands while the set is being written, the sheet says the ledger has since moved on; the files are one consistent instant of it. If an export stops partway, the sheet titled “The export stopped” states plainly: “Nothing was overwritten. Files written before this point are still in the folder.”

Each PDF and its CSV share a name built from the period and the store (Statement_2026-07_AppStore, for example), prefixed by your wordmark if you set one (Chapter 12).

Statements by app

Give your accountant one app’s lines and totals. Choose that app in the export’s Apps picker. The statement leaves out the payout and says why: stores pay the account, not the app. Per-app files use Statement_<period>_<Store>_<App>, prefixed by your wordmark if you set one. The payout ledger continues to show the whole account regardless of the toolbar’s app choice.

What a statement contains

Your accountant can see gross, refunds and net in one place. When the period has refunds, the totals show Gross sales, Refunds and Net proceeds. A Refunds section lists each refund’s date, store, product, country, units and amount.

One-time sales have their own lines, and the CSV has a product-kind column. Consolidated PDFs group sales by store, then currency, with each store’s subtotals and total before the totals across all stores. The CSV includes store subtotals and store totals as well.

Apple’s customer-spend column fills in from monthly finals; on provisional periods it is unavailable. A note explains any exchange-rate difference between a sale and its refund. Converted CSV figures are rounded to the cent, with a Rounding qualification; native amounts stay as reported.

What a period actually is

Read the two lines under the pickers before exporting:

• The first says which stores are still provisional and when their finals are due, and which are final. When the whole set is settled it reads Every figure in this set is the store’s own final. A store whose finals are overdue also keeps its full warning in orange.
• The second gives the Settlement span, with real dates, and says whether it is the calendar month. If its boundaries are unconfirmed, it says so.

Open the first line’s (i) for the calendar month, the full settlement dates, why they can differ, any unconfirmed boundaries, and each pending store’s publication date. The statement prints both month and span, so a settlement total need not equal a calendar-month total on the dashboard.

The provisional warning

When a period is not final, the export does not proceed silently. A dialog titled This period is not final yet appears first: “Some figures still rest on the stores’ own estimates and will be restated when the finals land. The document says so on its face, but an accountant who files it will be filing numbers that are going to change.”

The dialog lists each statement that is still provisional, with its basis label, and (because provisional without a date is a warning you can only obey by waiting indefinitely) a finalisation date per store:

• App Store: Apple publishes the financial report for a settlement period by roughly the first Friday after that period closes, and the app names the date: “App Store publishes its final figures for this period on …”.
• Google Play: the month’s earnings file appears in the first days of the following month; the app treats around the 5th as its due date.
• Stripe: never listed here. A settled Stripe figure has no second version; it is final on arrival.

A store past its date is called out in orange rather than politely: “… was due to publish its final figures for this period on …, … days ago. They have not arrived, which is no longer a matter of waiting.”

Two buttons, and each says what it does: Export the provisional set anyway, or Wait for the finals. An exported provisional document carries a Provisional marking on its face. On a provisional period, App Store customer spend is unavailable on the statement; it fills in from Apple’s monthly report.

12. Settings beyond credentials

Settings has four panels: Stores, General, Apps and Statements. In a wide window, Stores sits beside General and Apps beside Statements; a narrow window stacks them. Use (i) beside a panel or row for its explanation. Chapter 4 covers store connections.

Plan names and Rates are under Subscriptions > Plans and rates (Chapter 9). Diagnostics is a separate sidebar screen with the Activity log.

Statements

Settings > Statements controls the exported letterhead. Its (i) explains the policy: everything is optional; apart from the country, it starts empty. What you leave empty does not print. Every logo and name is one you supply.

• Company and Address print as one letterhead line above the statement title. Left empty, a statement names nobody and starts with its own title.
• Country: defaults to this Mac’s region. The statement’s VAT memo lists proceeds from buyers in that country. Choose None to leave that line out.
• Logo: click Choose… (later Replace…) and pick an image. It prints in the top-left corner of every page, 15 points high, on white; a PDF stays sharp at any size, and a PNG with a transparent background works too. The file is copied into the app’s own storage, so editing or moving the original afterwards changes nothing on the statements. Choose it again to take up a new version.
• Fonts: open the disclosure for Display face, Body face and Monospaced face: the fonts for titles, running text, and every figure and date. The list is the font families installed on this Mac; System is the default and always available. One honest caveat: a statement is drawn on the Mac that exports it. Export from another Mac without that family installed and the document falls back to the system face. The figures are identical, the document does not look the same.
• Wordmark: prefixes the filename of every exported statement, and prints in the corner in place of the logo when there is no logo. Letters, digits and hyphens survive into a filename; anything else becomes an underscore. The Files: line under the field shows an example of the resulting filename.

Prints like this previews the result on white, beside the fields where there is room. Restore defaults asks for confirmation before clearing your company, address, logo, chosen fonts and wordmark and returning the country to this Mac’s region.

General

Settings > General holds refresh, currency, data, backups and history:

• Refresh every offers Every hour, Every 3 hours, Every 6 hours, Every 12 hours, Once a day, or Only when I ask. Beneath it, the last refresh and next planned time appear when available; the next time depends on the Mac being awake. Refresh Now in the toolbar or Command-R refreshes immediately.
• Launch at login lets the app run when you sign in. The refresh row’s (i) explains that nothing is lost while the Mac sleeps: each refresh picks up where the last one stopped.
• Currency chooses the consolidation currency (Chapter 2). The picker names its source briefly, such as CHF, detected; (i) gives the full explanation. If connected stores pay out in different currencies and you have not chosen one, an orange message names the conflict and cross-store totals stay dashes until you choose.

The Data, Backups and History rows are described below.

Apps

Keep the same app together across stores, and make each name useful in the picker and on statements. Settings > Apps is where you manage those choices:

• Edit the app’s name beside its store symbols. Short names are used in the picker, tables and statement titles; open the row’s disclosure to read the full store name, identifiers and row counts.
• Merge selected: select two or more apps. A line names which app keeps its identity before you press the button.
• Split: open the row’s disclosure to remove an assignment and restore the store’s grouping. Stripe prices become Unassigned.
• Stripe prices and products: assign each Stripe price to an app. From Stripe metadata and Set by you show where an assignment came from.

Unassigned means figures do not yet belong to an app. You can leave a price there, and a caveat tells you when a figure includes unassigned rows. Before apps arrive, the section reads “No apps have reached the ledger yet.”

The Stores footer

The footer under Settings > Stores names the keychain in use. Its (i) gives the detail. On the login keychain, choose Always Allow when macOS asks (Chapter 13).

If credentials are found in the other keychain, Move them across brings them over without retyping. Migration notes and Keychain activity, a timestamped log, appear when there is something to show.

Data

The Data and Backups rows in Settings > General help you keep the database and raw report archive safe.

• Data shows the data directory’s path; Show in Finder opens it. Both the database and the archive live there.
• Back up… writes one zip holding both. The save panel is plain about why this matters: “The zip holds the database and every raw report ever downloaded. Apple deletes its daily reports after a year, so for older days this archive is the only copy that exists anywhere.” The Backups row’s (i) explains that these are business records which most countries require to stay readable for several years. A backup only counts once it is somewhere other than this Mac.
• Restore… opens a backup zip and shows what is in it before anything happens. The confirmation sheet is titled “This replaces the data in this install” and states the consequences: the data here is put aside, the backup’s data is put in its place, and until the next sync catches up, every figure in the app is the figures as they stood when the backup was taken. Nothing is deleted. What is here now is moved into a dated folder inside the data directory, where it stays until you remove it yourself. The buttons say what they do: Replace my data, or Keep what is here.

After a restore the app must be reopened: Quit App Sales Dash is the button, and the sheet explains why. The database the window was reading was moved while it was open. If anything fails, the sheet titled “That did not work” keeps to the same rule: “Nothing was deleted. If anything had to be moved, the message above says where it is.”

History

To fetch available reports again, choose Settings > General > History > Download available history…. The confirmation sheet names what each connected store still keeps, including the available App Store daily-report dates and its longer financial history. Days before the daily-report window cannot be fetched from anywhere. Click Download to begin, or Cancel to leave it alone. The button is disabled with no connected stores or while a history download is running.

The Diagnostics screen

Diagnostics is between Notifications and Settings in the sidebar. One Activity log panel fills the screen. It shows the last 200 lines per store, newest first, in Time, Store and Message columns; errors are red. Status lines above it show each connected store’s refresh timing, any statistics still awaited, or a need for attention.

Use All stores to choose a store, Errors only to narrow the list, and Search to find text in the messages or store names. Copy log copies the lines shown, in time order from oldest to newest, with a header; Copied confirms it. Save… writes the same selection to a text file you choose.

Read the log before sending it through the contact form. It can name your reports and connected stores.

Updates

App Sales Dash is distributed through the Mac App Store, and the store is what updates it. There is no Check for Updates… item in the application menu and no updater inside the app: updates arrive the same way every other App Store app’s do: in the App Store app, under Updates, or on their own if automatic app updates are turned on.

13. When something needs attention

When something needs you rather than another retry, the app says which store, what happened, and what will clear it. This chapter collects those situations.

The health chip reads Needs attention

The toolbar’s health chips show each store’s state on every screen. Needs attention means the store refused something that retrying will not fix; the chip’s own help text says so: “Retrying will not clear this. Open Settings and re-issue or re-grant this store’s credential.” Clicking a chip takes you to Settings.

A store’s test verdict

In Settings > Stores, use Test beside the store; when Fix permissions… is the main action, Test is in its ··· menu. Hover the connection line for the last test’s detail. A permission failure or refused key stays visible below it with the remedy.

A connected store can still be waiting for its first financial activity. Read the hover detail for what a successful or empty test actually proved. Chapter 4 explains each result. Setup guide… in the store’s menu opens its walkthrough. For a failed refresh, filter Diagnostics’ Activity log to the store, then copy it for the contact form.

The keychain asks again after an update

When credentials live in the login keychain, macOS may ask permission once per credential after an app update. The footer under Settings > Stores names the keychain.

Choose Always Allow. Plain Allow grants a single read, and the next unattended sync, which is deliberately not permitted to park a dialog on your screen, fails instead of prompting. That failure surfaces as a credential needing attention, not as a broken key: open Settings, use the credential once with the app in front of you (press Test), and answer Always Allow when asked. Nothing needs to be re-entered.

Google Play shows nothing at first

A Play account contributes figures only once it has financial activity to report. Google writes a month’s estimated-sales report once the month has its first order, and publishes the month’s earnings file from about the 3rd of the following month; before the first sale, the reports the app fetches simply do not exist yet. The app treats a report that has not been written as not yet available, not as a failure, so a correctly configured Google Play connection with empty screens is not a credential fault. The app says a store contributed nothing rather than drawing a zero, and the figures begin with the first report Google writes.

Why a figure changed

If a figure you quoted last week reads differently today, you can find out why. There are three causes, and each leaves a visible trail:

• A period finalised. Daily estimates are superseded by the store’s own final report, and the period says so where the figure is shown: “Finalised on …. The estimates for this period have been superseded.” Until then, charts mark the estimate-based stretch as Will be restated (Chapter 2).
• An update corrected the report reader. Stored reports were re-read locally and the result arrived as a notification (Chapter 10). Nothing was downloaded; some figures may have changed.
• A restore replaced the data. Every figure is the figures as they stood when that backup was taken, until the next sync catches up (Chapter 12).

If a figure looks off, open (i) on its tile, group or panel. Read the qualifications about older counts, missing exchange rates or subscriptions without measured rates. View > Data Notes… (Shift-Command-D) collects the current screen’s list. On Revenue and Subscriptions, the panel’s (i) also explains how its figures are put together.

The raw archive, and rebuilding from it

Every downloaded report is kept verbatim in the raw archive. Open Settings > General > Data > Show in Finder to find the data directory. A figure can be traced back to the report behind it.

The archive lets an update rebuild figures from stored reports on this Mac without asking the stores again. Apple deletes its daily reports after a year, so for older days the archive is the only copy. Keep it safe with Settings > General > Backups > Back up…, which saves the database and archive in one zip (Chapter 12).