Apple Summary Sales vs Apple financeReports

The short version

Use Apple Summary Sales when you need daily operational app-sales analytics: recent revenue activity, products, countries, subscription context and daily trend reporting. Use Apple financeReports when you need monthly platform finance context: Apple finance periods, finance report type, native proceeds, report-currency presentation and finance source lineage.

In Netice, Apple Summary Sales belongs to the daily app-sales source mode google_apple_app_sales. It produces rows with source_kind = 'SALES' and source reports such as ASC_SUMMARY_SALES or ASC_SUBSCRIPTION_EVENT. When Google Play is enabled in the same Daily App Sales workflow, Apple and Google Play daily revenue can land in one clean analytics table with provider and source-report fields preserved. Apple financeReports belong to the separate finance_unified source mode for monthly platform finance review by finance teams.

What Apple Summary Sales is

Apple Summary Sales is part of App Store Connect Sales and Trends style reporting. In Netice daily app-sales workflows, Apple daily sales rows are read through Apple salesReports style requests, not through financeReports.

For daily Apple Summary Sales rows, Netice keeps the source context visible. The daily row uses source = 'APPLE_APP_STORE', platform = 'IOS', source_kind = 'SALES' and source_report = 'ASC_SUMMARY_SALES'. Apple subscription-event rows, when available, can use ASC_SUBSCRIPTION_EVENT. Those Apple rows can sit beside Google Play daily rows in the same Daily App Sales table when both providers are configured, without losing provider-specific meaning.

What Apple financeReports are

Apple financeReports are a different App Store Connect report family. In Netice, they belong to Finance Unified, not to the daily app-sales table. Finance Unified is represented by the source mode finance_unified and source_kind = 'FINANCE', and is the monthly platform-finance layer intended for finance-team review.

Apple finance rows can preserve finance-specific context such as finance report type, region scope, fiscal period, calendar period, transaction date, settlement date, effective revenue date and source lineage. The default Finance Unified BigQuery table is finance_unified, separate from app_sales_daily.

Summary Sales vs financeReports comparison

The two Apple report families may both contain revenue-related numbers, but they are not the same dataset. They differ in source API family, date semantics, currency/proceeds behavior, fee/tax visibility, output table and intended use.

Date and period differences

Apple Summary Sales is daily. It uses a daily reporting date in the Daily App Sales output, represented as revenue_date. That date is not payout date, settlement date or Apple fiscal period.

Apple financeReports are period-aware. Finance Unified can preserve fields such as fiscal_period, apple_fiscal_label, calendar_period, period_start, period_end, transaction_date, settlement_date and effective_revenue_date. Apple fiscal periods need to remain visible instead of being flattened into ordinary calendar months without context.

Currency, proceeds, fees and tax

Currency and fee interpretation is one of the biggest reasons not to collapse Apple Summary Sales and Apple financeReports into one mental model.

Daily App Sales can include report-currency fields such as estimated_gross, estimated_net, estimated_tax and estimated_fee. It can also include native/local values and Apple-specific proceeds fields such as apple_proceeds_currency and apple_proceeds_native. These are daily analytical fields with method context.

Apple Summary Sales does not itemize Apple commission and tax as separate source facts in the way a finance ledger might. That is why daily fields such as fee_method and tax_method matter. Finance Unified does not fabricate separate Apple platform fee or tax rows when Apple does not disclose them as separate finance facts.

Vendor and access-scope differences

Apple report access is report-family specific. Sales and Trends vendor coverage does not automatically prove financeReports coverage. Finance reports can require Apple-side Payments and Financial Reports context, so Netice separates daily Apple source access from Apple finance source access where the workflow requires it.

Apple source access is separate from destination access. Apple App Store Connect reporting access lets Netice read selected Apple report families. It does not give Netice permission to write into BigQuery, Snowflake, S3 or GCS. Destination access is configured separately for the customer-owned target.

Customer credential material for Apple source access and destination access is encrypted and handled through Netice secret management. Saved connections reduce repeated credential entry, but saved credential values are not shown back as private keys, tokens, vendor secrets or destination secrets.

Output destinations: app_sales_daily, finance_unified and raw reports

The cleanest Netice architecture keeps Apple daily sales, Apple finance and raw Apple report custody in separate outputs. Daily App Sales is the analytics layer and can unify Apple App Store and Google Play daily revenue in one clean table when both providers are enabled. Finance Unified is the monthly platform-finance layer for finance teams. Raw Reports preserve provider-native files when source custody is needed.

Why the two outputs do not reconcile row by row

A daily Apple revenue dashboard and a monthly Apple finance report can differ without either being “wrong.” They can differ because they come from different report families, use different period semantics, expose different fee/tax information, use different currency context, and stabilize on different schedules.

Netice keeps fields like source_report, source_kind, revenue_date, fiscal_period, method fields, native/report currency fields and source lineage visible so downstream teams do not have to guess which Apple report family produced a row. The same fields also let Apple and Google Play daily revenue coexist in one analytics table while preserving provider-specific meaning.

Safe synthetic examples

The examples below are synthetic. They are not provider source rows, not customer exports and not accounting examples.

Daily Apple Summary Sales example

revenue_date,platform,app_id,source_kind,source,country,report_currency,estimated_gross,estimated_net,estimated_tax,estimated_fee,native_currency,apple_proceeds_currency,apple_proceeds_native,net_method,fee_method,tax_method,data_completeness,source_report,event_has_revenue,item_id,source_row_hash
2026-02-10,IOS,com.example.app,SALES,APPLE_APP_STORE,US,EUR,9.990000,6.990000,1.500000,1.500000,USD,USD,7.690000,APPLE_PROCEEDS,APPLE_ESTIMATED_FEE_30PCT_OF_PROCEEDS,APPLE_ESTIMATED_TAX_RESIDUAL_AFTER_PROCEEDS_AND_ESTIMATED_FEE,MATURE,ASC_SUMMARY_SALES,true,premium_monthly,synthetic_hash_apple_daily_001

Apple financeReports example

platform,source,source_kind,source_report,report_grain,fiscal_period,apple_fiscal_label,calendar_period,period_calendar_type,transaction_date,settlement_date,effective_revenue_date,app_id,sku,event_type,event_category,commission_disclosed,native_currency,native_net_proceeds,native_customer_charge,report_currency,report_net_proceeds,report_customer_charge,fx_rate,source_row_hash
IOS,APPLE_APP_STORE,FINANCE,APPLE_FINANCE_DETAIL,APPLE_FINANCE_DETAIL,2026-02-01,FY26-M02,2026-02-01,APPLE_FISCAL_MONTH,2026-02-10,2026-02-15,2026-02-10,com.example.app,premium_monthly,SALE,REVENUE,false,USD,6.990000,9.990000,EUR,6.350000,9.080000,0.909000,synthetic_hash_apple_finance_001

Source-aware comparison query

SELECT
  'daily_app_sales' AS output_family,
  revenue_date AS reporting_date,
  source_report,
  SUM(estimated_net) AS net_report_currency
FROM `example_project.example_dataset.app_sales_daily`
WHERE source = 'APPLE_APP_STORE'
  AND source_kind = 'SALES'
  AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-28'
GROUP BY reporting_date, source_report

UNION ALL

SELECT
  'finance_unified' AS output_family,
  fiscal_period AS reporting_date,
  source_report,
  SUM(report_net_proceeds) AS net_report_currency
FROM `example_project.example_dataset.finance_unified`
WHERE source = 'APPLE_APP_STORE'
  AND source_kind = 'FINANCE'
  AND fiscal_period = DATE '2026-02-01'
GROUP BY reporting_date, source_report;

Unified Apple + Google daily analytics query

SELECT
  revenue_date,
  platform,
  source,
  source_report,
  report_currency,
  SUM(estimated_net) AS estimated_net_report_currency
FROM `example_project.example_dataset.app_sales_daily`
WHERE source_kind = 'SALES'
  AND event_has_revenue = TRUE
  AND source IN ('APPLE_APP_STORE', 'GOOGLE_PLAY')
  AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-28'
GROUP BY revenue_date, platform, source, source_report, report_currency
ORDER BY revenue_date, platform, source, source_report;

These queries are for source-aware comparison and unified daily analytics. They are not payout reconciliation, accounting close or row-level matching between Summary Sales and financeReports.