Daily App Sales vs Platform Finance Reports

The short decision rule

In Netice, Daily App Sales is the operational app revenue analytics layer. It can write daily output such as app_sales_daily in BigQuery or app_sales_enriched_EUR.csv in object storage. Platform Finance is the separate monthly finance layer. When configured, it writes finance-period output such as finance_unified in BigQuery or finance_unified_EUR.csv in object storage.

The two outputs can both be useful to finance, analytics and data teams, but they are not interchangeable. Daily sales is not payout reconciliation. Finance output is not a daily product analytics table. The safest architecture keeps both layers separate and lets downstream users choose the right table or file for the question they are answering.

For technical readers, the internal Daily App Sales source mode is google_apple_app_sales and the Platform Finance source mode is finance_unified. Those identifiers are useful when reading technical documentation, but the buyer-facing distinction is simpler: daily analytics layer vs monthly platform finance layer.

Source family comparison

The core difference is the source report family. Apple and Google Play each have daily sales-style reporting and monthly finance-style reporting. Netice keeps those families separate through source modes, source kinds, report labels, period fields and destination artifacts.

Daily App Sales layer

Daily App Sales is the source-aware daily app revenue layer. It keeps provider context visible through fields such as source, platform, source_report and source_kind. The daily schema uses source_kind = 'SALES' and a daily revenue_date.

Apple daily rows come from App Store Connect Sales and Trends style reporting, especially Summary Sales, and use source-report labels such as ASC_SUMMARY_SALES. Subscription-event rows may appear when available. Google Play daily rows come from Estimated Sales reporting and use source-report labels such as GP_ESTIMATED_SALES.

The daily layer is designed to be refreshed. Recent completed days can be rerun because app-store reports may arrive late, stabilize or change. The field data_completeness helps describe daily source-readiness context. It should not be read as settlement finality.

Platform Finance layer

Platform Finance is the separate monthly finance output. In Netice, this is represented by the finance_unified source mode and source_kind = 'FINANCE'. Its job is not to become a daily analytics table. Its job is to preserve platform finance report semantics in a customer-owned destination.

Finance output uses period fields, source-report fields, event fields, native amount fields, report-currency fields and finality context. It can include fields such as report_grain, fiscal_period, calendar_period, period_calendar_type, effective_revenue_date, event_type, event_category, native_net_proceeds, report_net_proceeds, fx_rate, is_final and source_row_hash.

Finance output also has a stricter null interpretation. Unknown finance amounts remain null. A blank, unknown or unsupported finance amount is not the same as zero. Real zero remains zero. This distinction matters because fake zeros look authoritative in finance tables and can corrupt reconciliation logic.

Apple Summary Sales vs Apple financeReports

Apple daily sales and Apple finance are different source families. Apple Summary Sales belongs to Sales and Trends style daily reporting. Apple financeReports belong to the monthly finance side. The same Apple app can appear in both contexts, but the rows do not mean the same thing.

Google Play Estimated Sales vs Google Play Earnings

Google Play also has a daily-versus-finance distinction. Google Play Estimated Sales is useful for daily app-sales analytics. Google Play Earnings is the monthly finance report family. They differ in period shape, event meaning, fee visibility, tax treatment and expected use.

Date, period and finality semantics

Daily and finance outputs use different time logic. Daily App Sales uses revenue_date as the daily reporting date. Finance output uses monthly/report-period fields such as fiscal_period, calendar_period, period_start, period_end and effective_revenue_date.

This is why a daily dashboard total and a monthly finance report total can differ without one of them being “wrong.” They may come from different source families, different period calendars, different FX treatment, different fee/tax visibility, different refund timing and different finality assumptions.

Daily source-readiness context is not settlement finality. Finance output can include finality context through fields such as is_final, but that should be read as finance-period status rather than as a substitute for the customer’s accounting process.

Currency, FX, fee and tax boundaries

Report currency is a presentation layer, not a reason to overwrite native source truth. Daily App Sales can include report-currency fields such as estimated_net and method fields such as net_method, fee_method and tax_method. Finance output preserves native amount fields and report-currency presentation fields in its own monthly finance schema.

Apple Summary Sales does not itemize commission and tax like a finance report. Google Play Estimated Sales does not itemize service fee like a monthly earnings ledger. That is why method fields and source report fields matter. A number without its source family and method context is easy to misuse.

Finance null handling is stricter: unknown finance amounts remain null, not zero. A blank or unknown finance field should not be coalesced to zero for close or reconciliation logic unless the source actually reported zero. Zero means known zero. Null means unknown, unsupported, absent or not disclosed.

Destination table and file separation

Daily and finance outputs should land in separate destination artifacts. This makes downstream models easier to reason about and prevents daily dashboards from accidentally consuming finance-period rows or finance workflows from accidentally consuming daily estimates.

These examples are synthetic. Real project names, datasets, buckets, prefixes, app IDs, SKUs, source row hashes, task IDs, logs and credentials should never appear in public examples.

Backfills, refreshes and reruns

Daily and finance tasks refresh different kinds of windows. Daily App Sales refreshes daily reporting windows. Platform Finance refreshes monthly finance periods. Both can support repeatable updates, but their replacement scopes and interpretation rules are different.

The safe rule is: refresh daily sales for daily analytics, refresh finance periods for monthly finance review, and do not expect exact row-for-row reconciliation between them.

Safe synthetic examples

The examples below show why the two outputs should not be collapsed into one interpretation. Values, dates, app identifiers, hashes and table names are synthetic.

Daily App Sales example

revenue_date,platform,app_id,source_kind,source,report_currency,estimated_net,net_method,data_completeness,source_report,event_has_revenue,item_id,transaction_type,source_row_hash
2026-02-10,IOS,com.app.example,SALES,APPLE_APP_STORE,EUR,6.990000,EXAMPLE_NET_METHOD,EXAMPLE_COMPLETENESS_STATUS,ASC_SUMMARY_SALES,true,premium_monthly,NEW_SALE,synthetic_hash_daily_apple_001
2026-02-10,ANDROID,com.app.example,SALES,GOOGLE_PLAY,EUR,6.990000,EXAMPLE_NET_METHOD,EXAMPLE_COMPLETENESS_STATUS,GP_ESTIMATED_SALES,true,premium_monthly,PURCHASE,synthetic_hash_daily_google_001

Platform Finance example

platform,source,source_kind,source_report,report_grain,fiscal_period,effective_revenue_date,event_type,event_category,native_currency,native_net_proceeds,report_currency,report_net_proceeds,fx_rate,is_final,source_row_hash
IOS,APPLE_APP_STORE,FINANCE,APPLE_FINANCE_REPORT,APPLE_FINANCE_PERIOD,2026-02-01,2026-02-15,SALE,REVENUE,USD,6.900000,EUR,6.250000,0.905000,false,synthetic_hash_finance_apple_001
ANDROID,GOOGLE_PLAY,FINANCE,GOOGLE_PLAY_EARNINGS,GOOGLE_EARNINGS_PERIOD,2026-02-01,2026-02-28,PLATFORM_FEE,DEDUCTION,USD,-3.000000,EUR,-2.715000,0.905000,false,synthetic_hash_finance_google_fee_001

Daily trend query

SELECT
  revenue_date,
  platform,
  source_report,
  SUM(estimated_net) AS estimated_net_report_currency
FROM `example_project.example_dataset.app_sales_daily`
WHERE revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-29'
  AND source_kind = 'SALES'
GROUP BY revenue_date, platform, source_report
ORDER BY revenue_date, platform;

Monthly finance query

SELECT
  fiscal_period,
  platform,
  source_report,
  event_category,
  SUM(report_net_proceeds) AS report_net_proceeds
FROM `example_project.example_dataset.finance_unified`
WHERE fiscal_period = DATE '2026-02-01'
  AND source_kind = 'FINANCE'
GROUP BY fiscal_period, platform, source_report, event_category
ORDER BY platform, source_report, event_category;

Do not subtract the daily query from the finance query and call the difference an error without understanding source families, period semantics, FX, fees, taxes, refunds, late data and finality.

How to choose in Netice

Choose Daily App Sales when your first question is about recent app-store activity. Choose Finance Unified when your first question is about monthly platform finance reports. Both can land in customer-owned destinations, but they should remain separate tasks and separate artifacts.