The ultimate guide to mastering Apple App Store, Google Play for Revenue Recognition ASC 606

November 21, 2024
Cody Leach
Finance

This comprehensive guide demystifies the process, offering platform-specific insights and step-by-step instructions for extracting critical data, formulating precise journal entries, and conducting thorough margin analyses.

Introduction

Mastering subscription revenue accounting in the digital marketplace is challenging for finance professionals. Platforms like Apple App Store and Google Play add complexity with unique data extraction and opaque and incomplete reports. This guide simplifies the process with platform-specific insights, step-by-step instructions for data extraction, journal entry formulation, and margin analysis. Use these strategies to ensure ASC 606/GAAP compliance, streamline accounting, and gain valuable insights into subscription revenue streams across digital ecosystems.

Figure 1. Summary of accounting that can be achieved by various systems used in the Subscription/SaaS industry.

Apple App Store

Apple holds the data needed to do accounting for subscription revenue and the order-to-cash cycle in 2 reports (Summary Sales and Financial Report) and requires understanding your Apple Contractual Obligations. 

Apple maintains only a portion of the necessary data to record revenue according to ASC 606 correctly. Some deficiencies on the standard reports available to the accounting team through the App Store UI include:

  1. VAT/GST Revenue Gross Up and Withholding - The Apple Summary Sales Dashboard includes VAT/GST collections on behalf of your company. As such, if this is being recorded into revenue, a manual adjustment for an estimate of this tax needs to be made each month and trued up as payments are received.
  2. Subscriber Level Granularity - The Apple Summary Sales and Financial Transaction Reports do not contain subscriber level detail nor a link to reconcile sales/refunds to payouts. This data only lives within the API. If you need this level of granularity - automating with HubiFi is the only option and happy to chat. 
  3. Foreign Exchange - The data needed to calculate accurate FX Gain and Loss does not exist in the Summary Sales and Financial Transactions reports (the direct comparison of the sale and payment amount is not available.)  If you need this level of granularity - automating with HubiFi is the only option and happy to chat. 

This guide will walk through how to calculate the revenue recognition as closely as possible manually. 

Data Extraction

To compile all necessary data for as accurate accounting as possible, the Summary Sales and Financial reports need to be downloaded from Apple’s website. They have not been changed in almost ten years, and Apple’s Customer Support does not generally respond to queries about the reports. 

Summary Sales Report 

The Apple Summary Sales Report is highly opaque, but it contains the needed information to do subscription revenue accounting except for settlement entries (which are on the Financial Report). 

Some nuances to keep in mind about the Apple Summary Report to do ASC 606 accounting:

  1. This is a daily report, though it can be run monthly.
  2. No unique identifiers - Subscription transactions are aggregated by date and stock-keeping unit (SKU). At this time, Apple does not provide transaction-level reporting, and it is not possible to split transactions into individual invoices and line items. As such, a unique identifier has to be created through concatenation and use of the row number, SKU, and report date.
  3. Implicit fees - Apple fees have to be derived. Instead of an actual fee amount or %, they provide a “Proceeds Reason” (Rate After One Year or NULL) - and you have to determine what % it is based on your agreement (typically 30% in year one, 15% thereafter, but could be different depending on your organization). 
  4. No direct connection between Subscriptions and related Refunds if issued. This makes getting direct allocation for reversing/offsetting subscription revenue difficult.
  5. Developer proceeds/costs must be inferred: proceedAmount = Developer Proceeds * Units.
  6. To determine if the line is a Sale vs. Refund, it is more accurate to follow that the customer price field >= 0 is a sale, and < 0 is a refund (rather than the Sales / Return flag on the report)
  7. No Bad Debt: Only successfully paid subscriptions are populated on the report, so bad debt isn’t a concept for Apple transactions in this regard. 
  8. Apple limits data retention to 12 months. 
  9. Backdated Summary Sales Reports: As of 1/1/24 - Apple began backdating the summary sales reports for additional sales and refunds. As such, if the report reconciles for, say, January 2024, if you pull down the January report again in March and re-reconcile, there is a chance that new sales were added or refunds reversed without notification. This can be up to 10-15% of adjustments to the past month’s revenues from Apple. 

Financial Report

  1. This is a monthly report that comes out 4-5 days after the last day of the month. This makes it impossible to reconcile your cash account until then, but you can get close using the Summary Sales Report data.
  2. The Settlement Date for accounting has to be inferred from the settlement date on the report. Apple settles 35 days after the settlement date on the report. Apple’s Settlement Policy can support this in the App Store Agreement.
  3. To determine if the line is a Settlement vs. Refund, it is more accurate to follow that customer price >/= 0 is a sale, and < 0 is a refund (rather than the Sales / Return flag on the report)

Accounting - Journal Entries

Summary Sales Report

Journal Entries:

  • Revenue Deferral: Dr. Accounts Receivable (AR), Cr. Deferred Revenue
  • Revenue Recognition: Dr. Deferred Revenue, Cr. Revenue
  • Customer Pays: Dr. Cash in Transit (Apple), Cr. AR 
  • Developer Proceeds Liability: Dr. AR, Cr. Developer Proceeds Liability

Steps:

  1. Create a unique identifier for each row of the report by concatenating Report Name - Row Number - Apple Identifier.
  2. Filter the report for Customer Price >= 0 (this determines what is a sale vs refund)
  3. Calculate revenue to the company by backing out developer proceeds: Developer Proceeds * Units ) / proceedsRatio
  4. If volume is manageable, maintain each subscription on a line in Excel to create a detailed waterfall report; otherwise, summarize entries to a summarized waterfall.
  5. Note: Because Apple only populates the report with paid items, the Revenue Entries and Payments can be posted from the same report.

  • Payment Processor Fees: Dr. Payment Processor (PSP) Fees, Cr. Cash in Transit (Apple) 

Steps:

  1. Calculate the fees by taking the inverse of the amount calculated for revenue for each line: (amount *(1 - proceedsRatio) and putting it into its own column.

Refunds

  • Dr. AR, Cr. Cash in Transit (Stripe)
  • Dr. Revenue/Contra Revenue, Cr. Deferred Revenue
  • Dr. Cash in Transit (Stripe), Cr. PSP Fees 

Steps:

  1. Filter the report for Customer Price < 0 (this determines what is a sale vs refund)
  2. Calculate refund to the company by backing out developer proceeds: Developer Proceeds * Units ) / proceedsRatio
  3. If volume is manageable, maintain each subscription on a line in Excel to create a detailed waterfall report; otherwise, summarize entries to a summarized waterfall.
  4. Note: The refunds also have fees refunded; as such, refunds also need to have the fee amount calculated and accounted for.

Financial Report

Journal Entries:

  • Apple Settlements: Dr. Cash - Bank, Cr. Cash in Transit (Apple)

Steps:

  1. Apple’s settlement report comes out on day 4-5 after month end. Users can determine which payments were settled using VLOOKUP on the concatenated unique identifier discussed above. 
  2. The actual settlement date for accounting purposes is the settlement date on the report + 35 days. 

What accounting cannot be done with Apple data

Journal entries:

  • Sales Tax Accrual: Dr. AR, Cr. Sales Tax Liability
    • Apple Reports do not capture this data
  • Refunds - Contra-Revenue - Dr. Revenue/Contra Revenue, Cr. Deferred Revenue
    • Because Apple does not allow users to connect a refund with the related subscription, accountants have to determine how to handle refunds (either taken immediately or over time, as well as the mix of contra-revenue to offset)
  • Subscription Upgrades/Downgrades
    • Because Apple does not allow users to connect a refund with the related subscription, it is impossible to account for upgrades and downgrades outside general refunds/subscription accounting.
  • Disputes Dr. Revenue/Contra Revenue, Cr. Deferred Revenue
    • Apple does not process disputes; all sales on the report are held until paid. 
  • Credit Issuances: Dr. Deferred Revenue, Cr. Credit Payable
  • Credit Applications: Dr. Credit Payable, Cr. AR

Key Insights and Best Practices

Revenue Completeness

The best identifier for revenue lines in Apple is the SKU or Apple Identifier on your reports. These should map to a revenue stream. Review monthly to ensure all are accounted for.

Low-Quality Data and Audit

Unfortunately, Apple provides very low-quality data on which to do accounting. As such, be prepared to provide documentation and supporting assumptions regarding allocation methodologies and estimates to compensate for the data shortfall for audit preparation. 

Conclusion

Accurately accounting for subscription revenue through Apple is not actually possible manually and is highly manual. By following this guide, finance teams can get as close as possible. 

Hubifi can significantly simplify and improve this process by automating the data gathering, data cleaning, reconciliation, and eliminating the need for all the manual file creation entirely - automatically generating your journal entries and enrichment needed to analyze the data at a level not available manually.

 Contact us to learn more about automating this process, or schedule a demo with your Apple data to get started today. For Apple connections, this takes about 2 weeks to implement. 

Google Play

Google holds the data needed to account for subscription revenue and the order-to-cash cycle in two reports (Estimated Sales and Earnings Report). 

Google maintains only a portion of the necessary data to record revenue according to ASC 606 correctly, unlike some other billing/payment tools. See Figure 1 for a summary of accounting that can be achieved from Google, compared to other common Billing and Payment systems used in the Subscription/SaaS industry.

Data Extraction

To compile all necessary data for accurate accounting, the Estimated Sales and Earnings reports need to be downloaded from your Play Console. 

  1. Estimated Sales Report: Contains the data needed to account for invoices, refunds, taxes, and payments. This is a daily report.
  2. Earnings Report: Contains the data needed to account for payment processor fees, refunded fees, and payouts/settlements. This is a monthly report.

Accounting - Journal Entries

Estimated Sales Report

Note: This is a daily report.

Journal Entries:

  • Revenue Deferral: Dr. Accounts Receivable (AR), Cr. Deferred Revenue
  • Revenue Recognition: Dr. Deferred Revenue, Cr. Revenue
  • Sales Tax Accrual: Dr. AR, Cr. Sales Tax Liability

Steps:

  1. Identify the invoices that need deferral and recognition by filtering for Financial Status = Charged; Best practice is to use the SKU as the driver for GL mapping. Use the Item Price as the amount to recognize.
  2. You can utilize the Taxes Collected field to drive the Sales Tax Accrual entries. 
  3. If volume is manageable, maintain each subscription on a line in Excel to create a detailed waterfall report; otherwise, summarize entries to a summarized waterfall.
  4. Sales tax jurisdictions can be found by using the Country of Buyer field.

  • Customer Pays: Dr. Cash in Transit (Google), Cr. AR 

Steps:

  1. Identify the payments that need recognition by filtering for Financial Status = Charged, Use the Charged amount as the amount to record.
  2. Only successful payments will be on this report. 

  • Refunds:
    • Dr. AR, Cr. Cash in Transit (Stripe)
    • Dr. Revenue/Contra Revenue, Cr. Deferred Revenue
    • Dr. Sales Tax Liability, Cr. AR

Steps:

  1. Identify refunds by filtering for Financial Status = Charged, Use the Item Price as the amount to recognize.
  2. You will need to VLOOKUP using the Order Number to determine which order the refund relates to and the correct revenue and deferred revenue accounts to offset.
  3. You can utilize the Taxes Collected field to drive the Sales Tax Accrual Reversal entries. 
  4. If volume is manageable, maintain each subscription on a line in Excel to create a detailed waterfall report; otherwise, summarize entries to a summarized waterfall.

Earning Report Report

Note: This is a monthly report and only available 4-5 days after the end of the month.

Journal Entries:

  • Google Settlements/Payouts: Dr. Cash - Bank, Cr. Cash in Transit (Google)

Steps:

  1. Identify settlements by filtering for transaction type =/= Fee; use the Amount (Merchant Currency) as the amount to recognize.
  2. Note this report contains settlements for payouts and refunds. As such, Transaction Type = Charge is a standard settlement, and Transaction Type = Refund is a refund settlement.

  • Payment Processor Fees: Dr. Payment Processor (PSP) Fees, Cr. Cash in Transit (Google) 
  • Fee Refunds: Dr. Cash in Transit (Stripe), Cr. PSP Fees 

Steps:

  1. Identify settlements by filtering for transaction type = Fee; use the Amount (Merchant Currency) as the amount to recognize. Negative values are fee refunds and positive standard refunds.

Key Insights and Best Practices

Revenue Completeness

The best identifier for revenue lines in Google is the SKU on your reports. SKU should map to a revenue stream. Review monthly to ensure all SKUs are accounted for.

Settlement Dates

Although Google provides the settlement date for payouts/settlements on the Earnings report, the actual settlement date of the record is the 15th day of the following month from the report date. As such, the Report Date + 1 month + 15 days is the way to derive the correct accounting date for settlements. This is supported by Google’s Payment Policy found in the Play Console. 

Conclusion

Accurately accounting for subscription revenue through Google requires a comprehensive approach to data extraction and journal entries and is highly manual. By following this guide, finance teams can ensure compliance with ASC 606/GAAP and achieve as detailed a margin analysis as possible. 

Hubifi can significantly simplify this process by automating the data gathering, data cleaning, reconciliation, and eliminating the need for all the manual file creation entirely - automatically generating your journal entries and enrichment needed to analyze the data. Contact us to learn more about automating this process, or schedule a demo with your Google data to get started today.

This white paper is designed to serve as a practical guide for accounting professionals navigating subscription revenue accounting.

Cody Leach

Accounting Automation | Product | Technical Accounting | Accounting Systems Nerd

A technology and automation focused CPA helping finance leaders bring their processes into the 21st century.If you're interested in talking finance systems - https://calendly.com/cody-hubifi Feel free to set up some time on my calendar. I like talking about this stuff too much

Book a demo

Learn how we cut accounting close timelines by 75% and identified 6% of revenue margin erosion opportunities for one of the fastest growing companies.

Get Started