← Back to Field Notes
Storefront Reconciliation

Why App Store Proceeds Diverge from Internal MRR Dashboards

Published: August 08, 2026 9 min read Author: Kanya Ratanakul, Financial Telemetry Lead
Why App Store Proceeds Diverge from Internal MRR Dashboards

One of the most common friction points between mobile engineering and finance teams is the discrepancy between what internal telemetry dashboards report as Monthly Recurring Revenue (MRR) and what Apple actually deposits into the corporate bank account each fiscal month.

In our auditing practice at Dispatch Canvas Core, we frequently discover gaps between 10% and 25%. These differences do not indicate fraud or missing funds; rather, they stem from fundamental structural differences in how mobile stores calculate deductions, tax jurisdictions, and timing intervals.


1. The Fiscal Calendar vs. Gregorian Calendar Mismatch

Apple does not operate on standard calendar months (e.g. January 1 to January 31). Instead, Apple utilizes a 4-4-5 Fiscal Calendar divided into four 13-week quarters.

A standard fiscal month in Apple’s schedule may end on January 28, while your internal database aggregates transactions through midnight on January 31. This 3-day offset alone creates substantial month-over-month variances that distort short-term revenue comparisons.


2. In-Store Digital Services Tax & VAT Withholdings

When a customer in Germany purchases a €9.99 subscription on the iOS App Store:

  • The €9.99 retail price includes 19% German Value-Added Tax (VAT).
  • Apple deducts the €1.60 VAT directly at the point of sale and remits it to the German tax authorities on your behalf.
  • The remaining net amount (€8.39) is then subject to Apple’s 30% or 15% commission.

If your internal backend records a subscription_purchased event with an amount of €9.99 as gross MRR, you have overreported your revenue baseline by 19% on every European transaction.


3. Foreign Exchange (FX) Conversion Spreads

Apple reports payouts in your developer account’s designated settlement currency (e.g. USD, EUR, or THB), converting revenue from 175 storefront currencies at wholesale banking rates determined on specific clearing dates.

Internal analytics systems often convert transactions using daily real-time spot rates at the moment of purchase. Over a 30-day period with volatile currency swings (such as GBP/USD or JPY/USD movements), the resulting foreign exchange variance can create noticeable book discrepancies.


4. Refund Clawbacks and Retroactive Adjustments

When an end-user requests a refund directly through Apple Support (reportaproblem.apple.com), Apple deducts the full amount from your current monthly settlement.

If your backend does not properly consume and process the REFUND Server-to-Server Notification from App Store Connect, your database will continue to count that subscriber as active, creating cumulative phantom ARR over time.


How to Establish Reconciliation Parity

To eliminate these discrepancies:

  1. Align internal financial reporting scripts with Apple’s published fiscal calendar dates.
  2. Ingest net proceeds per SKU rather than retail gross prices.
  3. Maintain an active webhook listener for StoreKit 2 refund and revocation events.
  4. Conduct monthly three-way reconciliations between webhook logs, App Store Connect financial reports, and bank statements.
Author Note

Kanya Ratanakul, Financial Telemetry Lead

Senior Revenue Analyst at Dispatch Canvas Core, specializing in App Store fiscal reporting, subscription state machine audits, and multi-currency cohort reconciliation.

Discuss Your Telemetry