NETICE DOCUMENTATION

Report currency, source currency and FX

Reviewed 24 September 2026

Netice keeps source-currency context and report-currency presentation separate. A configured report currency makes compatible amounts easier to aggregate; it does not turn daily estimates into monthly finance proceeds or a platform settlement rate.

The distinction is especially important for Apple Daily App Sales. Customer gross and developer proceeds can use different currencies. Read apple_proceeds_native with apple_proceeds_currency, and read each estimated_* amount in report_currency. The shared native_currency label does not describe every possible source component on that row.

Daily App Sales currency fields

Which amount belongs to which currency?
Amount	Currency context	Reading rule
`estimated_gross`, `estimated_net`, `estimated_tax`, `estimated_fee`	`report_currency`	Analytical amounts; retain method fields when comparing them.
`gross_local`, `net_local`, `tax_local`, `fee_local`	`native_currency`	A component is null here if it belongs to another currency. Null does not necessarily mean the source amount is missing.
`apple_proceeds_native`	`apple_proceeds_currency`	Apple proceeds component at row level, retained separately from the shared native-currency projection.

For the shared native label, Netice selects the gross component currency first, then the available net, tax or fee currency, with report currency as the final fallback. The separate component FX fields record conversions into report currency. In a mixed-currency Apple row, net_fx can therefore apply to the Apple proceeds currency even though net_local is null.

A mixed-currency Apple example

Consider an illustrative row with USD customer gross and EUR developer proceeds, reported into EUR. These values are fictional and show field relationships, not a fee schedule.

Two source currencies in one daily row
Field	Illustrative value	Interpretation
`native_currency`	USD	Selected from the gross component.
`gross_local`	10.00	USD customer gross row amount.
`net_local`	NULL	Proceeds are not labelled USD.
`apple_proceeds_currency`	EUR	Currency of the proceeds component.
`apple_proceeds_native`	6.00	EUR proceeds row amount.
`report_currency`	EUR	Selected common reporting currency.
`net_fx`	1	EUR proceeds need no cross-currency conversion.
`estimated_net`	6.00	Analytical net presented in EUR.

Summing net_local alone would miss this row’s proceeds. Substituting zero for that null would hide the reason. Use the Apple proceeds pair for Apple native-proceeds analysis, or the report-currency amount for a common-currency daily view.

A conversion factor needs context

Daily amounts can use resolved historical rates or available fallback rates. The meta_json field can carry the requested date, effective date, resolution source and degraded-rate details. A non-null FX value is not by itself proof of an exact-date rate or the rate used for a platform payout.

Keep net_method, fee_method and tax_method with their amounts. Gross-method detail is stored inside meta_json. Missing daily report amounts can be derived or given a method-labelled zero assumption. See nulls, zeros and estimates before turning currency normalization into a quality guarantee.

Platform Finance uses a separate conversion contract

In Platform Finance, native_net_proceeds and native_customer_charge stay in native_currency. Netice writes separate report_net_proceeds, report_customer_charge and fx_rate fields. The report currency is configurable.

Same-currency conversion uses a factor of 1. An unavailable cross-currency rate is not silently replaced with 1: the converted amount remains unavailable. When report currency is configured and a row has native proceeds but no converted proceeds, the finance quality check blocks publication rather than allowing the main proceeds measure to undercount.

Finance conversion is period-oriented. Keep the provider period, native currency and report currency together when comparing totals. Converting an Apple fiscal-period total does not make it a calendar-month total.

Three reliable aggregation choices

Daily cross-store trends: sum estimated_net, grouped by report_currency, retaining provider, day and method context.
Apple daily native proceeds: sum apple_proceeds_native, grouped by apple_proceeds_currency. Inspect method/fallback context before treating the result as wholly source-disclosed.
Monthly finance proceeds: sum report_net_proceeds across relevant events, grouped by provider period and report currency; or sum native proceeds grouped by native currency.

Never add USD, EUR and JPY native amounts into one unlabeled total. Never add daily estimates to monthly finance proceeds: they are separate views of provider reporting, not incremental revenue streams.

Use the exact output fields

See the complete Daily App Sales data dictionary and Platform Finance data dictionary, then choose BigQuery delivery or Snowflake delivery.