Skip to content
NeticeStart free

NETICE DOCUMENTATION

Recurring refresh, backfills and reruns

Reviewed

A recurring refresh revisits recent reporting automatically. A backfill retrieves a historical scope. A rerun reprocesses a selected scope, including periods already delivered. In Netice, the replacement boundary depends on the output family: Daily App Sales uses reporting dates; Platform Finance uses report periods and source scope.

Rerunning changes the current managed representation of that scope. It does not make the source report immutable, guarantee that all late activity has arrived, or create an accounting snapshot.

Behavior Daily App Sales Platform Finance
Recurring default Recent 7-day reporting window Latest two closed eligible report months
Configurable scope Daily recurring window supports 1–70 days; historical scope depends on source availability Selected report months or ranges; recurring refresh covers up to two months
Replacement boundary Relevant source/reporting-date window Relevant source and fiscal/report period
Outside the scope Existing managed history is retained Other periods and source scopes are retained

Why a recent window needs repeated reads

Provider files can arrive late or change after their first publication. Google Estimated Sales, for example, accumulates recently charged and refunded transactions in a monthly file. A daily reporting date inside that file is not the same as the date the file was last updated.

A wider refresh window can revisit more of that recent activity, but no finite window guarantees coverage of every future correction. When an older adjustment falls outside the recurring scope, rerun the relevant historical dates or finance periods deliberately.

Provider publication and retention limits

Source family Provider timing Operational implication
Apple daily Sales and Trends Normally next day, generally by 08:00 Pacific; daily downloadable history retained for one year. A too-early read may precede availability. Expired reports cannot be regenerated by Netice.
Apple finance Monthly on Apple’s fiscal calendar, available by the first Friday of the following fiscal month; reports retained for ten years. Select fiscal periods, not an assumed calendar-month daily range.
Google Estimated Sales Monthly files updated daily; new transactions can take several days to appear. Revisit recent dates rather than treating the first read as final.
Google Earnings Normally available by the fifth of the following month; additional adjustment files can occur. Reprocess relevant report months when newer source information becomes available.

These are source availability rules, not Netice delivery-time guarantees. See Apple sales availability, Apple finance availability and Google monthly exports.

Run a backfill without confusing downstream totals

  1. Choose the reporting family and source before the date range.
  2. Confirm the provider still exposes the required history and your source connection can read it.
  3. Record the current row coverage and totals for the chosen period and currency.
  4. Run the selected historical scope and confirm the destination write completed.
  5. Compare coverage, amounts and quality fields. A changed source report can legitimately change the total.
  6. Refresh dependent models for the affected scope. Do not append a second copy of an already managed period.

Missing data is not a zero-revenue result

Distinguish “report not available,” “source access failed,” “destination write failed,” and “report contained no relevant activity.” A lack of rows cannot, by itself, identify which state occurred. Inspect run status and source availability before assigning a business meaning.

Also distinguish missing rows from missing amounts inside a row. Platform Finance preserves unknown monetary values as null. Daily estimates have method-aware fallback behavior. The missing-amount reference explains what can safely be concluded.

Keep your own snapshots when you need them

Warehouse output and managed files represent refreshed reporting. If a finance process needs “what we knew at close,” retain a dated snapshot in your own environment. A later rerun should update the operational source layer without silently rewriting your approved close record.