App Store Connect financeReports to BigQuery

What Apple financeReports to BigQuery means in Netice

In Netice, App Store Connect financeReports to BigQuery means writing Apple monthly platform-finance rows into a customer-owned BigQuery table through the Finance Unified workflow. The technical source key is finance_unified, the source kind is FINANCE, and the default BigQuery table is finance_unified.

This is not the daily App Store Connect reports-to-BigQuery workflow. Daily Apple app-sales analytics uses App Store Connect Sales and Trends style /salesReports data and lands in a daily analytics table such as app_sales_daily. Apple financeReports use the App Store Connect /financeReports report family and belong to the monthly finance output.

The practical reason is simple: daily app-sales reporting and monthly finance reporting answer different questions. Daily reporting is useful for trend visibility, product analytics and operational monitoring. Apple financeReports are platform finance source data with fiscal-period, report-type, source, native-currency and finance-finality context.

When to use this workflow

Use App Store Connect financeReports to BigQuery when your team needs Apple monthly platform-finance reporting in a queryable warehouse table. This is useful for finance review, monthly reporting support, platform-reported proceeds analysis, and comparing Apple finance-period data against daily app-sales analytics without mixing the two report families.

The workflow is especially relevant when finance, analytics and data teams need a shared warehouse representation of Apple financeReports while keeping daily operational analytics separate from monthly platform-finance semantics.

Apple financeReports source behavior

Apple financeReports use the App Store Connect /financeReports report family, not Sales and Trends /salesReports. In Finance Unified, Apple finance rows are normalized separately from daily sales rows so finance reporting keeps its own period, report type, source, currency and finality context.

Netice models Apple finance report-family details such as Finance Detail and Financial report rows inside the Finance Unified workflow. For readers, the important point is that Apple financeReports are monthly platform-finance inputs, while daily App Store sales reports are operational analytics inputs.

Vendor access and report-family coverage

Apple financeReports require App Store Connect access that can read Payments and Financial Reports. Access that works for daily Sales and Trends reports does not automatically prove financeReports coverage.

A team may already be able to fetch daily App Store sales reports and still not have the correct Apple financeReports access. Conversely, configuring Apple financeReports source access does not grant BigQuery destination write permissions. Source access and destination access are separate.

Examples in this guide are synthetic and do not contain customer identifiers, credentials, source files, logs, production destination names or real App Store Connect account details.

The finance_unified BigQuery table

The default BigQuery table for Finance Unified is finance_unified. Public examples use synthetic fully qualified identifiers such as example_project.example_dataset.finance_unified.

Finance Unified is event-grain. Each row represents a platform finance event after normalization. For Apple financeReports, rows can represent sale and refund events. Netice does not fabricate separate Apple platform fee or Apple tax rows where the source does not disclose those as separate finance facts.

Apple fiscal periods and date semantics

Apple financeReports preserve fiscal/report-period semantics. Finance Unified keeps fields such as fiscal_period, apple_fiscal_label, calendar_period, period_start, period_end and period_calendar_type so downstream users can understand the Apple period basis instead of treating finance reports as ordinary daily sales data.

Finance rows can also contain transaction, settlement and effective-revenue-date fields. The important modeling point is that these fields do not turn financeReports into daily Sales and Trends. They preserve finance semantics inside a monthly finance table.

Apple proceeds, fee/tax boundaries and null-not-zero

Apple Finance Unified rows preserve Apple finance source values without inventing unsupported rows. Apple finance rows can create SALE and REFUND economic events, but Netice does not fabricate separate Apple platform fee or tax rows where the supported Apple finance source does not disclose those as separate finance facts.

This matters because a finance table should not make unknown or undisclosed source details look like known facts. If Apple does not disclose a separate platform fee or tax row in the supported finance path, Netice should not generate synthetic PLATFORM_FEE or TAX rows. Unknown finance values stay null. Real zero stays zero.

Native currency, report currency and FX

Finance Unified keeps source-native finance values separate from report-currency presentation fields. Native fields such as native_currency, native_net_proceeds and native_customer_charge represent source/native finance context. Report-currency fields such as report_currency, report_net_proceeds, report_customer_charge and fx_rate provide a normalized reporting layer where valid conversion is available.

Same-currency conversion can use fx_rate = 1. Missing cross-currency FX should remain null rather than being silently converted. This preserves the difference between a known zero, an unknown value, a not-applicable field and an unresolved conversion.

BigQuery write and refresh behavior

Netice writes Finance Unified rows to BigQuery as a managed customer-owned output. Refresh behavior is scoped to finance source context and fiscal_period, not to the daily revenue_date windows used by Daily App Sales.

BigQuery may use internal staging during the write process, but the customer-facing output is the durable finance_unified table, scoped refresh behavior and verification result. The important boundary is that finance refreshes replace finance-period context, not daily sales windows.

Setup and access boundaries

Apple financeReports source access and BigQuery destination access are separate. Apple source access lets Netice read App Store Connect financeReports. BigQuery destination access lets Netice write the managed finance_unified table into a customer-owned BigQuery dataset.

Finance-capable App Store Connect access does not automatically grant warehouse access, and BigQuery destination permissions do not grant Apple source access. This separation helps teams reason about source coverage, destination write permissions and credential responsibilities clearly.

Safe synthetic examples

The examples below are synthetic and simplified. They show table and query shape only. They are not actual Netice API responses, not Apple source rows and not customer output.

Safe BigQuery target example

Workflow: Finance Unified
Selected provider: Apple financeReports
Destination: BigQuery
Project: example_project
Dataset: example_dataset
Default table: finance_unified
Fully qualified table: example_project.example_dataset.finance_unified
Report currency: EUR
Apple finance scope: Z1, FINANCE_DETAIL

Safe Apple finance row sketch

{
  "platform": "IOS",
  "source": "APPLE_APP_STORE",
  "source_kind": "FINANCE",
  "source_report": "APPLE_FINANCE_DETAIL",
  "is_final": false,
  "report_grain": "APPLE_FINANCE_DETAIL",
  "fiscal_period": "2026-02-01",
  "apple_fiscal_label": "FY26-M02",
  "calendar_period": "2026-02-01",
  "period_calendar_type": "APPLE_FISCAL_MONTH",
  "transaction_date": "2026-02-10",
  "settlement_date": "2026-02-28",
  "effective_revenue_date": "2026-02-10",
  "effective_revenue_date_basis": "TRANSACTION_DATE",
  "app_id": "com.app.example",
  "sku": "premium_monthly",
  "product_type": "SUBSCRIPTION",
  "country": "US",
  "apple_finance_region_code": "Z1",
  "apple_finance_report_type": "FINANCE_DETAIL",
  "event_type": "SALE",
  "event_category": "REVENUE",
  "commission_disclosed": false,
  "quantity": 1,
  "native_currency": "USD",
  "native_net_proceeds": "6.990000",
  "native_customer_charge": "9.990000",
  "report_currency": "EUR",
  "report_net_proceeds": "6.290000",
  "report_customer_charge": "8.990000",
  "fx_rate": "0.900000"
}

Safe BigQuery finance query

SELECT
  fiscal_period,
  apple_fiscal_label,
  source_report,
  event_type,
  native_currency,
  report_currency,
  SUM(native_net_proceeds) AS native_net_proceeds,
  SUM(report_net_proceeds) AS report_net_proceeds
FROM `example_project.example_dataset.finance_unified`
WHERE source = 'APPLE_APP_STORE'
  AND source_kind = 'FINANCE'
  AND source_report IN ('APPLE_FINANCE_DETAIL', 'APPLE_FINANCIAL')
  AND fiscal_period BETWEEN DATE '2026-02-01' AND DATE '2026-04-01'
GROUP BY
  fiscal_period,
  apple_fiscal_label,
  source_report,
  event_type,
  native_currency,
  report_currency
ORDER BY fiscal_period, source_report, event_type;

These examples use fake dates, fake amounts and a synthetic app identifier. They do not show real vendor numbers, source files, customer amounts, credentials, production tables, run IDs, logs or source paths.