Accounting periods and where the billing numbers come from
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.
Reference for Billing, ad-server fees and referral billing: 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 | 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. 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
- Run referral billing — the Analytics status column reads these states
- See where the CDN traffic goes
- Run a report
- Rules and default settings — the Accounting period management card
