Why RevenueCat and Apple Disagree About When a Subscriber Crosses Into the 15% Rate

This page is a decision tree, not a single answer. Apple pays 70% of a subscriber's price for their first year of paid service and 85% after (Apple Developer, "Auto-Renewable Subscriptions", checked 2026-09-02). That much every source agrees on. What they disagree on is the date a specific subscriber crosses that line, because "one year" is not a calendar measurement here — it is an accumulated count of paid days that excludes trials, can reset, and is tracked per subscription group — and RevenueCat's dashboard estimates that count differently than Apple's own per-subscriber report states it. Four sections follow, each a specific, documented reason the two dates can differ. Work through them in order against your own numbers: each either explains the gap or rules itself out, and you move to the next.

Every mechanic below is checked against current vendor documentation, cited inline with the date checked. Where RevenueCat's own docs do not say how a case is handled, that is stated plainly rather than guessed at.

Not sure which of these applies to your numbers? send me the subscriber's original purchase date and what each source shows → and I'll tell you which section below to start with.

"One year" is a day count, not an anniversary#

The 15% rate is not a subscription's first birthday. It is the day a subscriber accumulates 365 days of paid service, and several categories of time do not count toward that total at all.

Apple's own description of the rule: "During a subscriber's first year of service, you receive 70% of the subscription price at each billing cycle, minus applicable taxes. After a subscriber accumulates one year of paid service, your net revenue increases to 85% of the subscription price, minus applicable taxes" (Apple Developer, "Auto-Renewable Subscriptions", checked 2026-09-02). Four qualifications sit underneath that sentence, each one a way the accumulated-day count can diverge from simple calendar time since purchase:

• Free trials and renewal extensions don't count. "Free trials and renewal extensions are excluded from days of paid service" — a subscriber who took a two-week trial does not hit 365 paid days two weeks earlier just because the trial started earlier (same source).
• It's per subscription group, and a cross-group switch resets it. "Days of paid service are specific to each subscription group," and upgrading, downgrading, or crossgrading within the same group doesn't reset the count — but "if someone cancels a subscription in one group and then purchases a new subscription in a different group, the renewal date will change and the days of paid service will reset" (same source).
• A lapse of more than 60 days resets it. "If a subscription expires due to a cancellation or billing issue, the days of paid service stop accumulating. If the subscription is renewed within 60 days, the days of paid service resume from the recovery date." Recovery inside Apple's Billing Grace Period causes no interruption at all — "there won't be any interruption to the days of paid service." But "if someone resubscribes after 60 days, the days of paid service reset and you'll receive the standard one-year subscription rate until the next year of paid service passes" (same source).
• A manual renewal-date extension doesn't count either. Using the Renewal Date Extension endpoint to compensate a subscriber for an outage moves their renewal date forward, but "any days included in an extension won't count toward the one year of paid service needed to receive an 85% proceeds rate" (same source).

A developer enrolled in the App Store Small Business Program skips all of this: "you receive 85% of the subscription price at each billing cycle (minus applicable taxes), regardless of whether or not the subscription has accumulated one year of paid service" (same source) — covered in its own section below, since it introduces a second, independently-tracked date.

What to check: before comparing any two sources on this, confirm the subscriber didn't take a free trial, switch subscription groups, or lapse and resubscribe at any point — each one moves the true 365-paid-day mark later than a naive count from the original purchase date would suggest.

Where Apple states the answer, per subscriber#

Apple publishes one report that states, per transaction, which rate applied: the Subscription Report. Its Proceeds Reason field is defined as: "For Renew events, if the subscription has been active for more than a year then you receive 85% of the customer price, minus applicable taxes, and this field equals 'Rate After One Year'. Otherwise, you receive 70% and the field is blank" (Apple Developer, App Store Connect Help, "Subscription Report", checked 2026-09-02). That field, not a date arithmetic exercise, is the ground truth for whether a given renewal billed at 70% or 85%.

Two details about that report matter for reconciling it against anything else. First, it is timestamped in Apple's own frame, not necessarily yours: reports of this kind are "based on Pacific Time (PT)," with a reporting day running "from 12:00 a.m. to 11:59 p.m. PT" (Apple Developer, App Store Connect Help, "Download and view reports", checked 2026-09-02). Second, this level of detail does not exist in Apple's monthly Payments and Financial Reports at all: those are "intentionally anonymized," aggregated so that "we can only know that some purchase had certain rates and deductions — but not which customer or transaction they applied to," in RevenueCat's own description of working with them (RevenueCat, "Reconciling with App Store Financial Reports", checked 2026-09-02). If you are trying to confirm one specific subscriber's rate, the Subscription Report is the source that can answer it; the Financial Reports cannot, by design.

What to check: pull the Subscription Report for the subscriber in question and read Proceeds Reason directly, rather than inferring the date from Developer Proceeds alone or from a monthly financial report, which was never built to answer this at the individual-subscriber level.

Why RevenueCat's estimate can land on a different day#

RevenueCat does not read Apple's accumulated-paid-day counter — Apple doesn't expose it. Instead, by RevenueCat's own account: "To determine the commission of a given transaction, we look at the original purchase date of the transaction, your presence in the App Store Small Business Program, and your Apple Alternative EU Terms Addendum dates, when applicable" (RevenueCat, "Taxes and Commissions", checked 2026-09-02). That is a calendar-time estimate anchored to one date, not the day-count Apple actually accumulates and excludes trial time, extensions, and lapses from.

I could not confirm, from RevenueCat's published documentation, whether that estimate independently accounts for a free trial's length, a renewal-date extension, or a lapse-and-resubscribe when computing the 365-day mark — the "Taxes and Commissions" page states the inputs (original purchase date, Small Business Program status, EU Alternative Terms status) without describing how, or whether, trial and lapse time are subtracted from the count. Where that is true of a specific subscriber, RevenueCat's estimated cutover date and Apple's actual Proceeds Reason-backed date have a concrete, checkable reason to diverge: RevenueCat is estimating from a start date, Apple is counting paid days. The broader estimation caveat is RevenueCat's own: proceeds figures are "based on Apple's pricing schedule," used to "estimate the amount deducted from the gross revenue of the transaction," not read from Apple's internal accounting (RevenueCat, "Reconciling with App Store Financial Reports", checked 2026-09-02).

What to check: for a subscriber whose commission rate you need to confirm precisely — not just estimate — pull the Subscription Report's Proceeds Reason field rather than RevenueCat's Revenue chart. RevenueCat says as much of itself in the adjacent case of financial reconciliation generally: "Use RevenueCat for trend analysis, real-time insights, and estimating future earnings. Rely on Apple's financial reports for accurate payout data, financial reporting" (same source).

Small Business Program and EU Alternative Terms: a second date, tracked by hand#

A developer enrolled in the App Store Small Business Program receives 85% "regardless of whether or not the subscription has accumulated one year of paid service" (Apple Developer, "Auto-Renewable Subscriptions", checked 2026-09-02) — eligibility is "developers who earn under $1 million in App Store revenue per year," and Apple confirms enrollment by email once an application is reviewed (Apple Developer, "App Store Small Business Program", checked 2026-09-02; RevenueCat, "App Store Small Business Program", checked 2026-09-02). That changes the commission rate on a date that has nothing to do with any individual subscriber's tenure, which is why RevenueCat tracks it as a separate, manually-entered field per app: "Enter the effective date of entry for your membership in the Small Business Program" (RevenueCat, "App Store Small Business Program", checked 2026-09-02).

The mismatch risk here is not just picking the wrong date — it's that correcting the date does not uniformly correct everywhere the data already went. RevenueCat states two different outcomes for backdating that entry: "Charts will correctly calculate proceeds even if the entry date is in the past, but it will take up to 24 hours for your charts to recalculate past data." Its webhooks and integrations do not get the same treatment: "if you set it to a date in the past, we won't re-send webhooks and integration events with correct pricing data for transactions that have already occurred" (same source). A data warehouse, a BI tool, or any other downstream system fed by RevenueCat webhooks can keep the pre-correction 30% commission baked into historical records indefinitely, even after RevenueCat's own dashboard has recalculated and shows 15% for the same period.

What to check: if the app is enrolled in the Small Business Program, confirm the entry date was set in RevenueCat's app settings before or at the time of enrollment, not backfilled later — and if it was backfilled, treat any RevenueCat webhook-fed system (not the dashboard itself) as carrying stale commission data for transactions before the correction was made.

Even the two Apple reports don't share a calendar#

Confirming a rate with the Subscription Report and confirming the corresponding payout with the Financial Reports means comparing two reports on two different clocks. Financial Reports are batched by Apple's own fiscal calendar, "which almost never identically matches a calendar month" — RevenueCat's own reconciliation guide gives a concrete example: "their January 2025 fiscal month runs from December 29, 2024, to February 1, 2025" (RevenueCat, "Reconciling with App Store Financial Reports", checked 2026-09-02). They are also grouped by settlement date, not transaction date: "a subscription renewal that was due on November 29, but fails to renew, and then later succeeds on December 4 during its grace period will appear in Apple's financial reports based on the settlement date of December 4," while a transaction-date-based view — which is what RevenueCat's Revenue chart uses — would show it on November 29 (same source).

Applied to the 15%-rate transition specifically: a renewal that happens to be the subscriber's first at the new rate, and that also happens to hit a billing retry before it succeeds, can be dated one way in the Subscription Report (by when the renewal event occurred) and a different way in that month's Financial Report (by settlement date, possibly in the following fiscal month). Neither figure is wrong; they answer different questions, the same distinction this cluster's pillar article covers in full for revenue reconciliation generally: why your revenue numbers don't match.

What to check: when tying a specific 85%-rate renewal back to a payout, use the fiscal-month date range printed on the Financial Report itself, not the calendar month with the same name, and confirm whether you're looking for the renewal's transaction date or its settlement date before concluding a number is missing.

Get this checked for your app#

If you've worked through the sections above and still can't tell which rate should have applied to a specific renewal, or you'd rather not track four separate reset conditions by hand every time a subscriber lapses, that's what the diagnostic below is for.

Send me the subscriber's history → and I'll tell you which of the causes above explains the date you're seeing.