A practical checklist for the analyst or operations person who refreshes a coverage report each month from exports: what to export, in what order, the control totals to note before uploading, the validation lines to read after, the three failures that stop the refresh and what to do about each, and what to send the team when it is done.
A monthly refresh is four exports and a checklist. Without the checklist it is an afternoon of finding out why the region total moved by a number nobody recognises. This guide is the checklist, in order, with the three failures that stop it and what to do for each.
| # | Do | Why |
|---|---|---|
| 1 | Fix the period: first to last day of the month | Every export on the same cut |
| 2 | Clear every filter in every source | A saved filter is the commonest cause of a short file |
| 3 | Note the control total from each source screen | The one check that tests the file against the world |
| # | Export | Control total to note |
|---|---|---|
| 1 | Customer master and any hierarchy | Customer count |
| 2 | Assignments: account to rep, with dates | Account count |
| 3 | Ledger: account, date, product, revenue | Revenue for the period; row count |
| 4 | Activities: account, rep, date, type | Activity count |
| 5 | Any stated wallets, contracts, targets | As applicable |
Identifiers, not names, in every file.
| # | Read | Pass looks like |
|---|---|---|
| 1 | Period detected | The month you exported |
| 2 | Row counts against your control totals | Match |
| 3 | Revenue against your control total | Match to the cent |
| 4 | Identity lines: region = team = person = account = total | All hold |
| 5 | Identifier changes: accounts or reps not seen last month | A short, explainable list |
| 6 | Exceptions: unassigned accounts, activities on unknown accounts | Short lists, or empty |
Only after all six: the movements.
An identity does not hold. An account under two reps, or revenue with no account. Usually assignments exported before a reorganisation was entered, or a new account with no owner. Fix the assignment file at source; re-upload from step 2.
The period does not match. The ledger is the calendar month and the activities are the last 30 days. Re-export the activities on the same cut.
An identifier changed. A rep was re-keyed, or an account merged. The exception list names it. Map old to new, dated, once, and it holds for every future month.
Three lines and a page:
Period: September 2026. Identities: all hold. Exceptions: 4 unassigned accounts, listed. Movements: attached.
The tables are there for anyone who wants them. Nobody has to open them to know the numbers are whole.
Control totals skipped. The one failure nothing downstream can catch.
Movements read first. A movement caused by a broken identity is worked as a finding.
Files adjusted by hand to pass. The check passes and the data is wrong. Re-export.
Everything sent to everyone. The tables go out, the summary does not, and nobody reads either.
Mapped once, the same four exports pass the same checks every month, and the person who drops the files reads six lines before they read anything else. Covirage runs the validation on every upload and produces the summary. The self-service analytics solution describes the setup, and the export preparation guide covers what makes the exports clean in the first place.
Because the masters and the assignments define the hierarchy the ledger and the activities roll up into. Loading the ledger first against last month's assignments attributes this month's revenue to last month's owners, and the identity fails in a way that looks like a data problem.
Stop. The export is filtered, truncated or double-counted, and everything computed on it will be wrong in a way that no downstream check can find. Re-export with the filter cleared; do not adjust the file.
The movements page and a three-line validation summary: period, identities held, exceptions listed. The tables are available; the message is short enough to be read on a phone.