App Store Connect reports to Snowflake

What Netice sends to Snowflake for Apple App Store reporting

In Netice, App Store Connect reports to Snowflake means loading Apple daily app-sales reporting into a customer-owned Snowflake table. The workflow belongs to Daily App Sales, using Apple App Store as the selected provider.

The customer-facing Snowflake table is not a raw App Store Connect file archive. It is an enriched daily analytics table. The default Snowflake table for Daily App Sales is APP_SALES_DAILY. Apple rows keep source fields such as source, platform, source_kind, and source_report so downstream users can tell whether a row came from Apple Summary Sales or another Apple daily reporting source.

The most important modeling rule is simple: Apple Sales and Trends / Summary Sales is not Apple financeReports. The daily Snowflake table is useful for trends, product analysis, subscription visibility, country reporting, and BI. It should not be treated as final payout, settlement, accounting close, tax advice, audited revenue, GAAP, IFRS, ASC 606, or bank reconciliation truth.

When to use this workflow

Use App Store Connect reports to Snowflake when your team wants Apple daily app-sales reporting available in the same warehouse where analysts, finance operations, product teams, and BI tools already work.

This workflow is useful for daily revenue dashboards, country and product reporting, subscription visibility, recurring refreshes, backfills, and downstream modeling. It is not meant to replace Apple financeReports or final accounting workflows.

Apple daily source reports used by Daily App Sales

The Apple daily path uses App Store Connect Sales and Trends style reporting. That means daily sales reporting, not App Store Connect /financeReports.

Apple Summary Sales rows are represented in the daily table with Apple source labels. Apple subscription event rows can also appear as lifecycle-style rows where supported. Those lifecycle rows should not automatically be interpreted as money rows unless the relevant revenue fields and event_has_revenue context support that interpretation.

The APP_SALES_DAILY Snowflake table

The default Snowflake table for Apple daily app-sales analytics is APP_SALES_DAILY. Public examples use synthetic fully qualified names such as EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY.

The table is an enriched daily output, not a raw file copy. It includes source identity, app/product context, report-currency fields, native/local values, Apple proceeds context, method fields, lifecycle flags, data-completeness context, and safe provenance fields.

Apple proceeds, report currency, fee and tax method fields

Apple daily Snowflake rows can include Apple-specific proceeds context through fields such as apple_proceeds_currency and apple_proceeds_native. They can also include report-currency estimated amounts for analytics and BI.

But Apple Summary Sales should not be described as itemizing commission or tax as settled finance facts. That is why method fields matter. net_method, fee_method, and tax_method explain how values were sourced or estimated. They are part of the meaning of the row, not decorative metadata.

Snowflake destination setup

Apple source access and Snowflake destination access are separate. Apple source access lets Netice read selected App Store Connect reporting inputs. Snowflake destination access lets Netice write the managed table into the customer’s Snowflake environment.

Snowflake setup uses a secure destination access method with account, user, role, warehouse, database, schema, table, and stage context. Netice’s public examples use synthetic values only, and customer-specific Snowflake identifiers should be treated as sensitive operational details.

Examples in this guide do not contain real Apple account details, Snowflake account names, credentials, source files, logs, app identifiers, customer data, task IDs, run IDs, or production destination names.

Staged loads and scoped refresh behavior

The Snowflake daily output is a managed table, not a blind append-only pile of exported files. Candidate rows can be staged, checked, and then used to refresh the relevant date/source slice of the managed table.

This is important for backfills, reruns, and recurring refreshes. Apple daily reporting can be unavailable or delayed for a requested date. A rerun should not create uncontrolled duplicate rows, and an empty candidate window should not be interpreted as zero revenue without context.

Summary Sales vs Apple financeReports

This Snowflake article is about Apple daily reporting in APP_SALES_DAILY. Apple financeReports are different. They belong to Finance Unified, use source_kind = 'FINANCE', and land in a separate finance table such as FINANCE_UNIFIED where configured.

The daily table uses revenue_date and daily app-sales fields. Finance Unified uses finance/fiscal period semantics, source reports such as APPLE_FINANCE_DETAIL or APPLE_FINANCIAL, and native/report-currency finance fields. These outputs can support related business questions, but they should not be treated as row-equivalent or interchangeable.

Raw Apple reports and Snowflake

Raw Apple reports are a separate output family. They preserve provider-native Apple report artifacts and should not be described as the managed daily Snowflake table. Raw reports do not normalize into the Daily App Sales schema by default, do not apply report currency, and do not become Finance Unified rows just because they came from Apple.

For raw-report use cases, see the raw reports guide. Keep the distinction clear: daily Snowflake analytics, monthly Finance Unified, and raw provider artifacts are separate workflows.

Safe synthetic examples

The examples below are synthetic. They are safe shapes for explaining Snowflake table usage, not real customer output, real Snowflake targets, or real Apple source rows.

Safe Snowflake target example

Account: EXAMPLE_ACCOUNT
Database: EXAMPLE_DATABASE
Schema: EXAMPLE_SCHEMA
Table: APP_SALES_DAILY
Fully qualified table: EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY
Workflow: Daily App Sales
Provider selected: Apple App Store

Apple-only Snowflake query

SELECT
  revenue_date,
  source_report,
  item_id,
  report_currency,
  SUM(estimated_net) AS estimated_net_report_currency,
  SUM(units) AS units
FROM EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY
WHERE source = 'APPLE_APP_STORE'
  AND platform = 'IOS'
  AND source_kind = 'SALES'
  AND event_has_revenue = TRUE
  AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-29'
GROUP BY revenue_date, source_report, item_id, report_currency
ORDER BY revenue_date, source_report, item_id, report_currency;

Apple subscription event rows

SELECT
  revenue_date,
  transaction_type,
  COUNT(*) AS lifecycle_events
FROM EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY
WHERE source = 'APPLE_APP_STORE'
  AND source_report = 'ASC_SUBSCRIPTION_EVENT'
  AND event_has_revenue = FALSE
GROUP BY revenue_date, transaction_type
ORDER BY revenue_date, transaction_type;

These examples do not show raw Apple reports, Apple financeReports, payout reconciliation, accounting close, tax logic, audit evidence, customer credentials, source files, production destination names, or internal Netice merge SQL.