Finance Unified monthly platform finance

What Finance Unified is

Finance Unified is Netice’s monthly platform finance workflow for app businesses. It is built for the finance side of Apple App Store and Google Play reporting: Apple App Store Connect financeReports and Google Play monthly Earnings reports. The source mode is finance_unified, and the output uses source_kind = 'FINANCE'.

The purpose is to produce a source-aware finance output that keeps platform report family, finance period, native amount, report-currency presentation, event type, destination and data-quality context visible. Finance Unified is not a generic “revenue connector” and not a daily analytics table. It is a separate monthly finance layer that should remain distinct from Daily App Sales.

A typical customer uses Finance Unified when they want monthly platform-reported finance data in BigQuery, Snowflake, Google Cloud Storage or AWS S3, while preserving the difference between Apple financeReports, Google Play Earnings, daily sales analytics and raw provider-native reports.

When to use monthly platform finance

Use Finance Unified when the question is monthly and finance-oriented: what did the platform report for the finance period, how should native proceeds and report-currency values be read, which provider report produced the row, and whether the output is complete enough for finance review.

Apple Finance Reports source behavior

On the Apple side, Finance Unified reads App Store Connect financeReports, not Sales and Trends salesReports. This is the key Apple boundary. Apple Summary Sales is useful for daily operational analytics, but it should not be presented as the monthly finance source for this workflow.

Apple Finance uses Payments and Financial Reports vendor coverage. Sales and Trends vendor coverage does not prove finance coverage. In setup and documentation, Apple vendor identifiers, region choices and report scopes should be described at the category level only. Public examples should never include real vendor numbers or credential material.

Apple finance rows preserve Apple fiscal-period semantics. Apple fiscal labels and finance periods should not be flattened into ordinary calendar months without explanation. Finance Unified can expose Apple finance context such as finance report type, region scope, fiscal period, calendar period, settlement or transaction dates, and source lineage.

Google Play Earnings source behavior

On the Google Play side, Finance Unified uses monthly Google Play Earnings reports. It does not use Google Play Estimated Sales as finance truth. Earnings reports are monthly finance-style source artifacts, while Estimated Sales belongs to the daily analytics layer.

Google Play Earnings can preserve ledger-style rows. That means Google rows may include charges, refunds, platform fees, fee reversals, tax rows, rebills and adjustments when those are present in the source family. Finance Unified should not collapse those rows into only sale and refund rows if the provider has disclosed more detailed finance events.

Google Play Earnings should not be described as including chargebacks unless that is separately supported. Finance Unified preserves what the platform reports; it should not invent unsupported event categories.

Finance periods and replacement scope

Finance Unified is month and finance-period driven. It should not be explained as a daily date-window refresh. User-facing month inputs are finance months, and the output replacement scope is based on finance source scope such as platform, source, source report and fiscal period.

Native amounts, report currency and FX

Finance Unified preserves native platform amounts. Fields such as native_net_proceeds and native_customer_charge remain native. Report-currency fields such as report_net_proceeds, report_customer_charge and fx_rate are separate presentation values.

Same-currency conversion can use an FX rate of 1. Cross-currency conversion must have a resolvable rate. If a cross-currency rate is unavailable, report-currency values should remain null instead of being fabricated. Rows with native proceeds and configured report currency need valid report-currency values to be finance-useful.

This distinction is especially important when comparing Apple and Google. Apple finance and Google Earnings expose different components. Apple finance should not estimate separate Apple commission or tax rows when Apple does not disclose them. Google Earnings may provide explicit ledger rows for fees and taxes.

Null policy and unsupported values

Finance Unified follows a null-not-zero rule. Unknown finance values remain null. Real zero remains zero. Missing provider reports, unsupported fields or unavailable FX should not be turned into zero just to make a spreadsheet or dashboard look complete.

Destinations: BigQuery, Snowflake, GCS and S3

Finance Unified can produce monthly finance output for warehouse and object-storage destinations when configured. The semantic contract stays the same: finance_unified. The destination changes how the output is delivered and consumed.

Object-storage finance output can include same-stem artifacts such as manifest, schema, period status, calendar close, payout reconciliation, platform take, revenue recognition, SQL view definitions and README files. The manifest is part of the completion contract and should not be treated as optional if the bundle is expected to be complete.

Finance output should not be written into daily app-sales artifact names such as app_sales_enriched, combined_app_sales_enriched, app_sales or daily_app_sales. Destination separation protects downstream BI and finance models.

Setup requirements

A Finance Unified task starts by selecting the monthly finance source mode, then choosing Apple Finance Reports, Google Play Earnings or both. The task then needs provider access, destination access, report currency and finance month selection.

Status, quality and provider availability

Finance status should not collapse everything into one generic connector result. Source availability, source permission, parser or schema drift, destination write verification, output integrity and reconciliation diagnostics are distinct concepts.

Reconciliation diagnostics

Finance Unified can support reconciliation-style diagnostics, but those diagnostics should be understood carefully. They are monthly aggregate diagnostics, not exact row-level matching between daily sales rows and monthly finance rows.

A difference between daily app-sales analytics and monthly finance output can come from source report family, fiscal period, calendar period, FX, fees, tax, refunds, late data, provider availability or finality. The correct response is to preserve the source context and explain the difference, not to force the outputs into one number.

Safe synthetic examples

The examples below are intentionally synthetic and simplified. They show the shape of Finance Unified without using real app IDs, SKUs, buckets, tables, object paths, vendor numbers, source rows, source hashes, credentials, task IDs, logs, payment references or customer data.

Object-storage bundle example

Destination: s3://example_bucket/monthly-finance/
Report currency: EUR
Primary file: finance_unified_EUR.csv
Manifest: finance_unified_EUR.manifest.json
Schema: finance_unified_EUR.schema.json
Period status: finance_unified_EUR.period_status.csv
Calendar close: finance_unified_EUR.calendar_close.csv
Payout reconciliation: finance_unified_EUR.payout_reconciliation.csv
Platform take: finance_unified_EUR.platform_take.csv
Revenue recognition: finance_unified_EUR.revenue_recognition.csv

BigQuery table example

Project: example_project
Dataset: example_dataset
Table: finance_unified
Fully qualified table: example_project.example_dataset.finance_unified
Schema version: finance_unified_v3_event_grain
Replacement scope: platform/source/source_report/fiscal_period

Apple finance example row

platform,source,source_kind,source_report,report_grain,fiscal_period,apple_fiscal_label,period_calendar_type,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,APPLE_FISCAL_MONTH,com.example.app,premium_monthly,SALE,REVENUE,false,EUR,6.990000,9.990000,EUR,6.990000,9.990000,1,synthetic_finance_hash_apple_001

Google Earnings example rows

platform,source,source_kind,source_report,report_grain,fiscal_period,period_calendar_type,app_id,sku,event_type,event_category,event_subtype,commission_disclosed,native_currency,native_net_proceeds,native_customer_charge,report_currency,report_net_proceeds,report_customer_charge,fx_rate,source_row_hash
ANDROID,GOOGLE_PLAY,FINANCE,GOOGLE_PLAY_EARNINGS,GOOGLE_EARNINGS_LEDGER_LINE,2026-02-01,GOOGLE_PLAY_EARNINGS_MONTH,com.example.app,premium_monthly,SALE,REVENUE,,true,EUR,9.990000,9.990000,EUR,9.990000,9.990000,1,synthetic_finance_hash_google_001
ANDROID,GOOGLE_PLAY,FINANCE,GOOGLE_PLAY_EARNINGS,GOOGLE_EARNINGS_LEDGER_LINE,2026-02-01,GOOGLE_PLAY_EARNINGS_MONTH,com.example.app,premium_monthly,PLATFORM_FEE,DEDUCTION,COMMISSION,true,EUR,-2.000000,,EUR,-2.000000,,1,synthetic_finance_hash_google_002

In the Google fee row, blank customer-charge fields mean null. They do not mean zero. A platform fee row is not a customer sale row.

Finance query shape

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

This query demonstrates finance table shape. It is not accounting close evidence and not row-level reconciliation to daily sales.