What a data map is and how to build one from any sales export: the six roles a column can play, region, team, person, account, product, value, plus date, how to tell which column is which when the headers do not say, the columns to drop, the roll-up check that proves the map is right before anything is computed, and the mistakes that produce a map that looks fine and rolls up wrong.
An export has twenty columns and a coverage report needs six of them, in the right roles. The data map is the step between: which column is the account, which is the value, which are the levels above, and which are noise. This guide sets out the roles, how to identify each column, the drop list, and the check that proves the map before anything is computed.
| Role | Kind | Rule |
|---|---|---|
| Region | Level 1 | Every team belongs to one region |
| Team | Level 2 | Every person belongs to one team |
| Person | Level 3 | Every account belongs to one person |
| Account | Level 4 | Every row belongs to one account |
| Product | Dimension | Cuts across accounts; not a level |
| Date | Dimension | Sets the period |
| Value | Measure | The amount that sums |
Levels nest. Dimensions cut across. The value sums.
| Column looks like | Probably | Check |
|---|---|---|
| Numbers with decimals, sums to a plausible total | Value | Matches the control total |
| Dates, one format | Date | Parses; range is the period |
| Codes with few distinct values, one per person | Team or region | Each person under one of them |
| Codes with many distinct values, one per row or few rows | Account | Each under exactly one person |
| Names of things sold, repeating across accounts | Product | Appears under many accounts |
| Free text, notes, addresses | Drop | No role |
Σ value by region = Σ by team = Σ by person = Σ by account = total
And the nesting checks: no account under two people, no person under two teams, no team under two regions. A map that passes all of them describes a hierarchy. One that fails has a column in the wrong role, and the failing level says which.
Export: 18 columns.
| Column | Role | Note |
|---|---|---|
| InvoiceValue | Value | Sums to $4,182,400; matches control |
| CustomerID | Account | 1,204 distinct |
| SalesRep | Person | 24 distinct; every customer under one |
| SalesTeam | Team | 6 distinct; every rep under one |
| Territory | Region | 3 distinct; every team under one |
| ProductCode | Product | 310 distinct; appears under many customers |
| InvoiceDate | Date | March 2026 |
| CustomerName, RepName, Notes, Address… | Dropped | 11 columns, no role |
Check: $4,182,400 at every level; no nesting failures. Mapped.
Product as a level. The roll-up has one row per product per account and the person level double-counts.
Amount as a level. One row per amount.
Two columns for one role. Rep code and rep name both mapped as person; nothing nests.
Map saved without the check. It looked right. Run the identity.
Mapped once and checked, the same export maps the same way every month, and the roll-up check runs before any measure does. Covirage's data map does this on upload, guesses each column's role, and refuses the ones that cannot hold it. The Excel analysis solution describes the setup, and the roll-up hierarchy guide covers why the levels nest and product does not.
Then the hierarchy has three levels and the map says so. Missing levels are allowed; a level mapped to the wrong column is not. Region can be derived later from a person-to-region lookup uploaded as a second file.
Only if it is an identifier that happens to be numeric, like an account number. A column of amounts cannot be a level, and a map that assigns one produces a roll-up with one row per amount. The map should refuse it.
Account is a level: every row belongs to exactly one account, which belongs to one person, one team, one region. Product is a dimension: the same product appears under many accounts, so it cannot sit in the hierarchy. Mapping product as a level is the commonest way a roll-up goes wrong.