The six lines a validation report on an uploaded sales file should carry before any measure is computed: the period it detected, the row and value totals against what the source showed, the columns it mapped and the ones it dropped, the roll-up identity at every level, the identifiers it did not recognise from last time, and the exceptions it will exclude. What each line catches, what a pass looks like, and why a report that says only 'upload successful' has told you nothing.
A file is uploaded and a green tick appears. Nothing about the tick says whether the file was the right month, whether it was complete, whether the columns were understood, or whether the totals hold at every level. A validation report says all of that in six lines, before a single measure is computed. This guide sets out the six, what each catches, and what a pass looks like.
| # | Line | Catches | Pass looks like |
|---|---|---|---|
| 1 | Period detected | The wrong month; a file spanning two periods | One period, the one you exported |
| 2 | Rows and total against control | Filtered, truncated or duplicated exports | Match to the row and the cent, or labelled unreconciled |
| 3 | Columns mapped and dropped | A missing value column; a product column mapped as a level | Value, account and levels present; drops listed |
| 4 | Roll-up identity | Two owners for an account; revenue with no account | Equal at every level, or failures listed by row |
| 5 | Identifiers new or missing | A re-keyed rep; a merged account; a new region | A short, explainable list |
| 6 | Exceptions excluded | Bad dates, text values, subtotal rows, blank identifiers | Counted, listed, small |
Only after all six: the measures.
| Line | Result |
|---|---|
| Period | March 2026, 1st to 31st: 48,211 rows dated in period; 0 outside |
| Rows and total | 48,211 rows; $4,182,400.00; control $4,182,400.00: match |
| Columns | Value: InvoiceValue. Account: CustomerID. Person: SalesRep. Team: SalesTeam. Region: Territory. Product: ProductCode. Date: InvoiceDate. Dropped: 11 columns, listed |
| Roll-up | $4,182,400 at region, team, person, account: holds. 0 accounts with two owners |
| Identifiers | 3 new accounts; 1 rep not seen last month (R-19); 0 new teams |
| Exceptions | 14 rows excluded: 9 blank CustomerID ($2,100), 5 unparseable dates ($800). Listed |
Six lines, one minute to read, and the person who dropped the file knows the report that follows is built on the file they meant to send.
| Line | Result |
|---|---|
| Period | February 2026 (44,000 rows) and March 2026 (4,211 rows) |
Stop. The export was cut on the wrong date. Nothing below this line is worth reading until the file is re-exported.
It means the file parsed. It does not mean the file was the right one, complete, understood, or consistent. Every one of the six lines has caught a real error at a real company, and none of them shows in a green tick.
Only line 2. The total matches and the columns are mapped wrong.
Line 4 skipped. The report computes on a hierarchy that does not sum.
Exceptions silently dropped. Nine blank identifiers become nine accounts nobody covers.
Report not read. Six lines, and the reader goes straight to the dashboard.
Covirage runs the six on every file, before any measure, and shows them first. The export preparation guide covers what makes line 2 pass, and the data map guide covers line 3.
Because a file of the wrong month passes every other check and produces a report that is entirely, plausibly wrong. Detecting the period from the dates in the file and stating it is the cheapest check and the one most often skipped.
Then the report says unreconciled beside the total, and every figure downstream inherits that label. It is better than a silent pass, and it is a reason to go and get the control total next month.
A row the computation will not use and why: no account identifier, an unparseable date, a value that is text, a line with a subtotal marker. Counted and listed, so that the person who dropped the file knows what did not go in and can decide whether it matters.