Apple Small Business Program: the proceeds math

The program in one paragraph

The App Store Small Business Program (launched January 2021) reduces Apple's commission to 15%on paid apps and in-app purchases (including year-one auto-renewable subscriptions) for developers who earned up to $1 million USD in proceeds across all their apps in the prior calendar year. You must enroll (an Account Holder does it on Apple's program page); it is not applied automatically, and crossing $1 million mid-year moves the remainder of that year's earnings back to the standard commission.

The math: what 15% actually changes

Proceeds are what's left of the customer price after Apple's commission (in territories where Apple collects VAT or similar taxes, the commission applies after those are deducted). The number that matters is the ratio between the two shares, not "15 vs 30":

0.85 / 0.70 ≈ 1.2143: membership is a ~21.4% raise on every affected sale, not a 15% one. A distinction worth getting right before you estimate anything. (Figures above ignore territory tax deductions and rounding, which is exactly why price-derived numbers stay estimates.)

What your daily reports actually show

Better news than the folklore: Apple's daily Sales reports (the ones you download from the App Store Connect API or view in Sales and Trends) state the Developer Proceeds column at your actual commission rate: enroll, and rows after your effective date carry the 85% share (as of 2026-07-12). There is nothing to recompute on report-derived numbers, and re-adjusting proceeds Apple already stated at 85% inflates them by another ~21%. Per-unit amounts round and territory taxes are deducted before the commission, so Payments and Financial Reports stays the exact record of what Apple pays you. Reconcile a month if you want certainty about your own account.

The real trap lives elsewhere: pipelines that derive proceeds from the customer price with a hard-coded 70%. The most common case is real-time data (App Store Server Notifications carry the price the customer paid, never your proceeds), so any live view has to estimate, and a flat price × 0.70 silently under-shows a member's share on every event (the real number is ~21% higher).

Estimating correctly when all you have is a price

When a source only gives you customer prices (a server notification stream, a paywall event log), the estimate is one multiplication with one guard. Multiply by your share, using the share that applied on the event's date: enrollment isn't retroactive, so events before your effective date were at the standard rate, and applying 85% to them inflates history that was correct:

// estimate.ts: estimate proceeds when a source only carries prices.
// Apple's daily SALES reports already state Developer Proceeds at your
// actual rate. Never re-adjust those. But real-time sources (App Store
// Server Notifications) carry the CUSTOMER PRICE, not proceeds, so a live
// view must estimate, with the share that applied on the event's date.
const STANDARD_SHARE = 0.7;
const SBP_SHARE = 0.85;

export function estimatedProceeds(
  customerPrice: number, // the notification's price field
  eventDate: string, // ISO yyyy-mm-dd
  enrolledSince: string | null, // your SBP effective date, or null
): number {
  const share =
    enrolledSince && eventDate >= enrolledSince ? SBP_SHARE : STANDARD_SHARE;
  return customerPrice * share;
}

// Sanity check: a $9.99 renewal after enrolling on 2026-01-01 →
// estimatedProceeds(9.99, "2026-07-01", "2026-01-01") → 8.49 (net 15%).

Caveats that keep this an estimate, not a payout figure:

• ▸Year-two subscriptions. Subscriptions past one year of paid service are at the 85% share for everyone, so a flat standard-rate estimate under-counts those rows even outside the program. Reconcile a month against your reports to see how your mix behaves.
• ▸Mid-year exits. Cross $1M and the standard rate returns for the rest of the year: a second effective date your estimate window needs if it happens.
• ▸Taxes and rounding. Commission applies after VAT-style deductions in some territories, and the notification carries the storefront price. Price-derived numbers get close; your daily reports state real proceeds, and only Payments and Financial Reports is exact.

Whatever you build, keep the honest hierarchy: price-derived estimates are for watching the business live; daily reports state your actual proceeds; Apple's payout reports remain the source of truth for what you were actually paid.

The managed version

RevenueHog draws exactly this line. Revenue and every other report-derived number use Apple's Developer Proceeds figures as-is. They already carry your actual rate, so no adjustment is applied and none is needed (stored proceeds are verified against Apple's reports to the cent, per proceeds currency). The live feed is the estimated side: events arrive as server notifications with prices, so each event's detail shows estimated proceeds: net 30% by default, or net 15% once you enable the Small Business toggle in Settings. The metrics methodology documents which numbers are Apple's and which are estimates.