Want a downloadable, PDF version of the guides? Click here.

Introduction

Navigating the intricacies of subscription revenue accounting in the digital marketplace can be a daunting task for finance professionals. With major platforms like the Apple App Store and Google Play each presenting unique challenges in data extraction and interpretation, achieving accurate revenue recognition per ASC 606/GAAP standards has become increasingly complex. 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. By leveraging the strategies outlined in this white paper, finance teams can ensure compliance, streamline their accounting processes, and gain valuable insights into their subscription-based revenue streams across multiple digital ecosystems.

‍

Apple App Store

Apple holds the data needed for accounting for subscription revenue and the order-to-cash cycle in two reports: Summary Sales and Financial Report. However, understanding your Apple contractual obligations is necessary. Unlike other billing/payment tools, Apple only maintains a portion of the necessary data to correctly record revenue according to ASC 606. See Figure 1 for a summary of accounting that can be achieved from Apple 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 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 according to GAAP, except for settlement entries (which are on the Financial Report).

‍

Key nuances for ASC 606 accounting:

‍

1. Report Frequency: 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). Apple does not provide transaction-level reporting, making it impossible to split transactions into individual invoices and line items. A unique identifier has to be created by concatenating the row number, SKU, and report date.
3. Implicit Fees: Apple fees must be derived. Instead of an actual fee amount or percentage, they provide a "Proceeds Reason" (Rate After One Year or NULL), requiring you to determine the percentage based on your agreement (typically 30% in year one, 15% thereafter, but it could differ depending on your organization).
4. No Direct Connection Between Subscriptions and Related Refunds: This makes direct allocation for reversing/offsetting subscription revenue difficult.
5. Developer Proceeds/Costs: Must be inferred: proceedAmount = Developer Proceeds * Units.
6. Sale vs. Refund: It is more accurate to consider the customer price field (>= 0 for sales, < 0 for refunds) 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.
8. Data Retention: Apple limits data retention to 12 months.
9. Country Codes: Apple maintains country codes on this report for segmentation, but they are not always captured by Apple API integrations. Work with your team to ensure this is captured if needed for FP&A.
10. Backdated Summary Sales Reports: As of 1/1/24, Apple began backdating the summary sales reports for additional sales and refunds. If the report reconciles for January 2024, pulling the January report again in March and re-reconciling could show new sales added or refunds reversed without notification. This can account for 10-15% of adjustments to the past month’s revenues from Apple.

Financial Report

1. Report Frequency: This is a monthly report that comes out 4-5 days after the last day of the month. It makes it impossible to reconcile your cash account until then, but you can get close using the Summary Sales Report data.
2. Settlement Date: 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. Sale vs. Refund: It is more accurate to consider the customer price (>= 0 for sales, < 0 for refunds) 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
  Apple does not issue credits.

Key Insights and Best Practices

Revenue Completeness:

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

‍

Low-Quality Data and Audit:

‍
Unfortunately, Apple provides very low-quality data for accounting. 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 requires a comprehensive approach to data extraction and journal entries, and it 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 data gathering, data cleaning, reconciliation, and eliminating the need for 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 Apple data to get started today.

Google Play

Google holds the data needed to account for subscription revenue and the order-to-cash cycle in two reports: the Estimated Sales Report and the Earnings Report. However, Google maintains only a portion of the necessary data to record revenue according to ASC 606 correctly, unlike some other billing/payment tools. Refer to Figure 1 for a summary of accounting that can be achieved with data 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, download the Estimated Sales Report and Earnings Report 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. 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 into a summarized waterfall.
4. Sales tax jurisdictions can be found 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 appear 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. Use VLOOKUP with the Order Number to determine which order the refund relates to and the correct revenue and deferred revenue accounts to offset.
3. 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 into a summarized waterfall.

Earnings Report

‍
Note: This is a monthly report, 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 that this report contains settlements for payouts and refunds. 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 values are standard refunds.

Key Insights and Best Practices

• Revenue Completeness:
  ‍
  The best identifier for revenue lines in Google is the SKU on your reports. SKUs 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 formula to derive the correct accounting date for settlements is Report Date + 1 month + 15 days. 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 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.

‍