NETICE DOCUMENTATION
Google Play Estimated Sales vs Earnings
Reviewed
Google Play Estimated Sales and Google Play Earnings are different source reports. In Netice, Estimated Sales feeds Daily App Sales; Earnings feeds Platform Finance. Use the daily output for operational trends and the finance output for monthly charges, deductions, refunds and adjustments.
The distinction matters when you sum revenue. A daily net estimate uses an estimation method. In finance output, Google Earnings contributes separate signed ledger rows: retaining the charge while discarding the fee and tax rows overstates the proceeds represented by that ledger.
Estimated Sales and Earnings in Netice
| Property | Estimated Sales | Earnings |
|---|---|---|
| Netice output | Daily App Sales | Platform Finance |
| Output report label | GP_ESTIMATED_SALES |
GOOGLE_PLAY_EARNINGS |
| Time context | revenue_date |
Report-file month in fiscal_period, plus separate period and transaction-date fields |
| Amounts to read | estimated_gross, estimated_net, estimated_fee and estimated_tax, with method fields |
Signed native_net_proceeds and report_net_proceeds across the ledger |
| Quantity | Daily units where applicable | quantity remains null; Netice does not infer units from finance ledger rows |
| Cross-provider analysis | Can share the daily schema with Apple sales | Can share the separate finance schema with Apple financial reports |
Google describes Estimated Sales as buyer-local sales information before fee and tax deductions, and recommends Earnings for accounting-related reporting. See Google’s report definitions and field reference.
What a daily Google Play amount means
Netice retains the source report label so Estimated Sales rows remain distinguishable from subscription lifecycle rows in Daily App Sales. For revenue analysis, select revenue-bearing rows using event_has_revenue; a lifecycle event is not automatically a sale.
A common report currency makes daily amounts easier to compare across stores. It does not change their evidence: a Google daily fee estimate remains an estimate after conversion. Use the method columns to distinguish source-reported amounts from calculations and fallbacks.
| Amount | Interpretation field | Question to check |
|---|---|---|
estimated_gross |
gross_method entry in meta_json |
Was the value taken from a charged amount or assembled through a fallback? |
estimated_net |
net_method |
Which deductions and assumptions produced this analytical net amount? |
estimated_fee |
fee_method |
Which fee estimation method was used? |
estimated_tax |
tax_method |
Was tax reported by the source, derived, or assumed zero? |
Daily report-currency amounts can be derived or assigned a method-labelled zero when unavailable. For example, GOOGLE_TAX_UNAVAILABLE_ASSUMED_ZERO does not mean that Google reported zero tax. Finance fields follow a different missing-value contract. See missing values and zero.
Keep the Earnings ledger intact
Netice maps the signed merchant-currency amount on each Earnings line to native_net_proceeds. Charges, refunds, fees, tax and adjustments remain distinct finance events. The shared field name describes each line’s contribution to net proceeds; it does not mean every individual line is a complete net sale.
| Event | native_net_proceeds |
native_customer_charge |
|---|---|---|
| Sale | 10.00 |
10.00 |
| Platform fee | -2.00 |
NULL |
| Tax | -1.00 |
NULL |
| Total contribution | 7.00 |
Sum charge fields only for a customer-charge question |
Filtering this example to sales before summing proceeds produces 10.00 rather than 7.00. For a net ledger total, retain the relevant deductions and adjustments. Group native totals by native_currency; use report_net_proceeds and group by report_currency when working in the configured report currency.
native_customer_charge is populated for sale and refund events. It remains null on fee and tax rows because those rows are not customer charges. This is a structural null, not a zero-value sale. The Platform Finance schema defines the complete field contract.
The report month and transaction date are separate
For Google Earnings, Netice sets fiscal_period to the first day of the report-file month. It preserves transaction_date separately and identifies the period as a Google Play Earnings month. Despite the shared schema name, this field is not an Apple fiscal label.
Google’s Estimated Sales charged-date field uses UTC. Its Earnings transaction-date field uses Pacific Time, and issue timing can place a transaction in a different report month. Do not derive every Google finance period by truncating the transaction date. The distinction is documented in Google’s export field reference.
Netice’s finance settlement_date for these rows is the period end used by the normalization model. It is not evidence that money reached a bank account on that date.
A monthly source file changes during daily refresh
Google updates the current month’s Estimated Sales file daily, and new transactions can take several days to appear. A daily ingestion therefore reads from a changing monthly source file. Google’s sales and payout report guidance explains this delay.
Earnings normally becomes available by the fifth of the following month; Google can issue additional adjustment files. Report availability is distinct from the payment date. See Google’s Earnings availability guidance.
Use recurring refresh and reruns to understand how Netice revisits reporting windows. Before interpreting a missing day as no sales, check whether the report was available and the requested window was delivered.
Connect the report family to your analysis
Follow Google Play reporting access setup, then choose the Daily App Sales schema or the Platform Finance schema. Use Raw Reports when you need provider-native files alongside normalized output.