---
title: "Accounting periods and where the billing numbers come from"
description: "Which table each Billing and fee figure is read from and how often it is refreshed, how fee impressions and header-bidding fills are bucketed and billed, why Billing and an analytics report round differently, and how an advertiser's days move through the confirmation statuses up to Finalized and back."
type: "reference"
audience: [admin, network-manager]
keywords: [accounting period, confirmation status, Incomplete Data, Up-to-Date Data, Preliminary Confirmed, Confirmed, Finalized, preliminary confirm, confirm, finalize, undo finalize, reopen, Changed after confirmation, Changed after finalization, aggregate data, 14 days, placement type bucket, Desktop, Mobile, Video, HB fills, header-bidding fills, rounding, six decimals, sharing type requirement, Manage Completeness Delay]
ui_path: "Account → Analytics → report grouped by Advertiser → period buttons"
---

Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# Accounting periods and where the billing numbers come from

Reference for [Billing, ad-server fees and referral billing](https://epom.com/ad-server/docs/guides/admin/finances-and-billing.md): the
source and refresh cadence of every money figure, the three things that cause most
reconciliation tickets, and the confirmation statuses an advertiser's day moves through.

## Where the numbers come from

Every money figure on the Billing and fee screens is a sum over the same daily table the General
analytics report reads. Nothing here has hour resolution and nothing here is current as of now.

| Figure | Source | Refreshed |
|---|---|---|
| Advertisers charged, and the advertiser grid's **Charges** | The sum of *Gross* per advertiser per day, kept in a daily advertiser summary | Scheduled job every 4 hours, rewriting the last **14 days** |
| Publishers net revenue, and the publisher grid's balances | The sum of the Publisher-family *Revenue* per site per day, each row floored at its minimal revenue, kept in a daily publisher summary — the same figure the referral commission base reads | Scheduled job every 4 hours, rewriting the last **14 days** |
| Network net revenue | Derived on read: Advertisers charged − Publishers net revenue | With the two above |
| Ad server fees impression counts | A General analytics report for the calendar month, grouped by placement type, run as the network user | Nightly |
| Ad server fees **Traffic (gb)** | What your network's CDN zones report themselves — CDN77 and BlazingCDN, every zone of the network summed, in GB of 1024³ bytes. A network with no CDN credentials configured falls back to an estimate: each creative's file size × its impressions. When a CDN cannot be read, the month keeps the figure it already had. See [CDN usage](https://epom.com/ad-server/docs/guides/admin/cdn-usage.md) | Nightly for the current month; the previous month is re-read on the first four days of the next one |
| Ad server fees **HB fills** | Header-bidding fills won by Google or another partner, from the Header Bidding fill log, bucketed by placement type like impressions. Fills of your own campaigns are not in it — they are already impressions — and neither is a Google Ad Manager line item that serves one of your own Universal JS or Mount JS tags | With the above |
| Referral commission base | The sum of the Publisher-family *Revenue* for the referred user's sites, each row floored at its minimal revenue, read straight from the daily statistics | Live at generation time — no aggregate in between |

Three things follow from that table and they cause most reconciliation tickets.

### Fee impressions are bucketed by placement type

The mapping is not obvious:

| Bucket | Placement types counted into it |
|---|---|
| Desktop | Site Placement, Non-standard Placement, Email Placement, Click-through Placement, **Native Placement** |
| Video | Video Placement |
| Mobile | Everything else — Mobile Site Placement, Application Placement, and any placement type added in future |

### Header-bidding fills of other demand are billed too

When Google or another partner fills a slot through a header-bidding tag, no impression of yours
is recorded, so the fee counts these fills separately. By default the billing plan counts them as
impressions of the same bucket, at the plan's own prices and packages; a plan can instead charge
them at a flat CPM (default $0.01). They come from a beacon in the visitor's browser, so expect
them to run a few percent below Google's own count — ad blockers drop the beacon, not the ad.

Two renders that reach the page through Google Ad Manager are yours and are not counted a second
time: a line item whose creative is one of your own **Universal JS** or **Mount JS** tags — the tag
tells the header-bidding tag that the render is yours, and the impression it serves is billed like
any other — and your own Prebid win whose confirmation reaches the page late. A **Simple Iframe**
or **Direct URL** tag cannot tell the page anything, so a line item carrying one is billed as a
header-bidding fill on top of the impression the tag serves; put Universal JS in Ad Manager
creatives. When your tag inside the line item has no ad of yours to serve — it comes back empty,
or with the placement's **Default code** — no impression is counted, and the render stays a
header-bidding fill — the one charge for that slot.

### Money is rounded once, analytics rounds per row

**Money is stored at six decimals and rounded once, at the end.** Every summary and balance figure
is kept to six decimal places; the fee charge is computed at full precision and scaled to six
decimals, half-up. The screens then format to exactly two decimals for display. Nothing is rounded
before it is summed.

**Analytics rounds in the opposite order,** which is why a report and a balance can differ by
cents. An analytics report rounds *each result row* to the report's funds precision (2 decimals on
screen; the network's export precision, or 8 decimals, in an export) and then recomputes Profit
from the already-rounded Gross and Net. Group a report by day and you accumulate one rounding per
day; Billing subtracts at full precision and rounds once. When the two disagree by small amounts,
this is almost always why.

### The 14-day window

The scheduled fills only rewrite the **last 14 days**. A correction to a day older than that will
never reach Billing on its own: ask Epom support or your account manager to rebuild the aggregates
from the first day of logs, then click **Recalculate balances** on the Billing page. Days older
than the window keep the figure they were summarised with. Before release 153 that was *Net* rather
than the Publisher-family *Revenue*, so on a network that populates the split advertiser/publisher
columns a month that closed earlier can still differ from the referral ledger until the publisher
aggregates are rebuilt.

The advertiser and publisher aggregate fills are switched separately. The publisher fill is a
server-side setting that is off by default (ask Epom support or your account manager to turn it
on), while the advertiser fill always runs. The symptom is distinctive: *Advertisers charged*
climbs normally, *Publishers net revenue* stays at 0.00, and *Network net revenue* therefore equals
*Advertisers charged*. If you see that shape, the data is not missing — the publisher job never
ran.

## Accounting periods

An **accounting period** is one advertiser's revenue for one day, carrying a *confirmation status*
that says how settled that day's money is. You move a day up the ladder as you reconcile it, and
**Finalized** seals it.

The controls are not on the Billing page. They are per-row buttons on an **Analytics** report
grouped by **Advertiser** alone, or by Advertiser + Advertiser owner — see
[Run a report](https://epom.com/ad-server/docs/guides/analytics/run-report.md). Select advertiser rows there, and the buttons act on
those advertisers across the report's whole date range.

### The states

| Id | State | How a day gets there |
|---|---|---|
| 0 | Unidentified | No status recorded |
| 1 | Incomplete Data | The day is still accruing |
| 2 | Up-to-Date Data | Tracked data for the day is complete |
| 3 | Preliminary Confirmed | **Preliminary confirm** |
| 4 | Confirmed | **Confirm** |
| 5 | Finalized | **Finalize accounting period** |

Only the last three transitions have buttons. Nothing on the report moves a day from *Incomplete
Data* to *Up-to-Date Data*. Saving an advertiser re-evaluates that advertiser's days against its
own confirmation-delay setting — days up to the setting's cut-off become *Up-to-Date Data*, the
days after it *Incomplete Data* — but only when the user saving it holds the *Manage Completeness
Delay for Advertisers* permission. The re-evaluation moves only the first three states: a day at
*Preliminary Confirmed*, *Confirmed* or *Finalized* keeps its status. A row still at *Incomplete
Data* shows every period button greyed out.

Each forward step needs its own permission, and each button additionally checks the **share
level** of every selected advertiser against the network's sharing-type requirement for that step.
Those requirements are set in the **Accounting period management** card on **Admin → Inventory &
campaigns settings**, as three separate lists: *Sharing type requirement for preliminary
confirming*, *…for confirming* and *…for finalizing*.

A period button acts only on rows that are all at the same status. Select a mix and the button
greys out. If you force the request anyway it is refused rather than partially applied, and days
inside the range that are not at the expected status are silently left alone — there is no
per-row report of what did or did not move.

### Reopening a finalized period

Step the period back down with the paired **Undo** buttons on the same report: **Undo finalize
period** takes Finalized → Confirmed, **Undo confirm** takes Confirmed → Preliminary Confirmed,
**Undo preliminary confirm** takes it one step further back. An undo needs the permission of the
status you are leaving, so reopening a finalized day needs the finalize permission, exactly as
sealing it did. Once the day is below Finalized, run your correction and climb the states again.

The undo buttons are the only reopen mechanism — there is no separate "reopen period" screen.
Each click moves the stored status by exactly one level.

## Related

- [Billing, ad-server fees and referral billing](https://epom.com/ad-server/docs/guides/admin/finances-and-billing.md)
- [Run referral billing](https://epom.com/ad-server/docs/guides/admin/referral-billing.md) — the *Analytics status* column reads these states
- [See where the CDN traffic goes](https://epom.com/ad-server/docs/guides/admin/cdn-usage.md)
- [Run a report](https://epom.com/ad-server/docs/guides/analytics/run-report.md)
- [Rules and default settings](https://epom.com/ad-server/docs/guides/admin/rules-and-defaults.md) — the Accounting period management card