Data Lineage: Trace a Sales Report to Its Source

By Trellus Team · November 2, 2026

A report says that 75% of calls became conversations. A colleague asks where the number came from. The formula is only part of the answer: you also need the source used for that particular report, the records included and the rules applied to them.

Data lineage, in this guide, means the trail from a reported value back through the inputs and steps that produced it. A useful trail lets someone inspect the calculation without guessing which export or filter you meant. It can also show whether a later change came from new source information or a different calculation.

The W3C's PROV overview describes provenance as information about data, the activities that produced it and the people involved. The manual note below applies that basic idea to one sales report.

Start with one reported value

Pick a particular output: a card in a weekly review, a cell in a workbook or a number in a saved presentation. Write down what it says and which report version contains it. “The conversation rate” is too broad if the team has several reports with different periods or definitions.

Then work backward. Which calculation produced the value? Which records entered that calculation? Where did those records come from? If someone prepared or checked the report, record their responsibility too. An export's filename alone won't explain those steps.

Keep this task separate from deciding what the report should measure. The unit-of-analysis guide explains choosing calls, people or accounts. Here, assume the team has already chosen distinct call attempts. The job is to trace one output made with that definition.

Follow a fictional six-row export

Suppose a team keeps a fictional source copy called S1 for a weekly report. The reporting period runs from October 26, 2026 at 00:00 UTC up to, but not including, November 2 at 00:00 UTC. The rule includes distinct outbound call attempts starting within that period.

For this example, an attempt qualifies when the intended person participated in a live conversation. All outcomes in the included group are known. These six invented records contain no real prospect details:

The included attempts are A1, A2, A3 and A4. A5 is outside the chosen direction; A6 starts after the reporting window. The qualifying attempts are A1, A3 and A4. That produces 3 ÷ 4 = 75%.

The report note should retain those references and exclusions, not just “six rows processed.” A reviewer can then check why four attempts entered the denominator and which three entered the numerator. The example describes the selected fictional attempts; it does not establish meetings, sales or a representative result for another list.

Keep the source version and the calculation together

In this example, S1 means the particular source copy used for the first report. Give that copy an agreed reference in a place your team can access appropriately. Record when it was obtained, what it was supposed to contain and any source details needed to find it again.

Someone could replace the contents of calls-final.csv without changing its name. Keep the saved version using your team's version or document-history controls, and record what those controls preserve. The time you opened the file doesn't tell you when the underlying call records last changed.

Keep the calculation reference alongside the source. For a workbook, that might identify the saved workbook version, the relevant sheet and the formula cell. For a manual note, write the included IDs, qualifying IDs and arithmetic as above. If there was a cleaning or mapping step, describe what it changed and where its result is kept.

You don't need to copy names, phone numbers or call notes into a broadly shared presentation. Internal record references and a short explanation may be enough for the audience. Keep source access within the arrangements your team uses for that material.

What should happen when someone runs it again?

With S1 and the same rule, the fictional report should again include A1–A4 and count A1, A3 and A4 as qualifying. Getting 75% is necessary for that reproduction, but the percentage alone isn't a full check. Someone could accidentally count different records and arrive at the same fraction.

Compare the intermediate result: the actual included IDs, exclusions, classifications and counts. If the new result differs, first establish whether both people used the same source and definition. Avoid changing a filter merely to make the final numbers agree.

A failed reproduction doesn't by itself tell you which step is wrong. The stored source might differ, a date boundary might have changed, or the calculation might be using another set of rows. The trail gives you specific places to inspect.

When the question concerns a dialer export and a separate CRM activity report, use the call-count reconciliation guide. Keep the lineage of each report so the comparison doesn't depend on a moving source.

Record a correction without rewriting the earlier result

Now suppose the fictional source is corrected: A2's recorded outcome changes from voicemail to an intended-person conversation. A later source copy, S2, contains that correction. All six IDs, directions and start times remain the same, and the inclusion rule is unchanged.

S2 therefore still includes A1–A4, but all four now qualify. The result is 4 ÷ 4 = 100%. Record that the reported difference comes from A2's changed source classification. It is not evidence that the team's calling improved between the two reports; they concern the same attempts.

Keep the earlier report associated with S1. If the team issues a corrected report, identify it as a revision and explain what changed. Don't present a new source copy as the original one merely because it has the same filename.

In real work, retain only history you actually have. If an earlier input was overwritten and can't be recovered, record that gap. Reconstructing it from memory would not establish the exact earlier source.

Use a short lineage note

For the first fictional report, a usable note could read:

Output: weekly outbound-attempt conversation share, report R1, 75%. Input: the saved fictional source S1 shown above. Period: October 26 at 00:00 UTC up to November 2 at 00:00 UTC, 2026. Rule: distinct outbound attempts starting in the period; an intended-person live conversation qualifies. Included: A1, A2, A3, A4. Excluded: A5, inbound; A6, outside the period. Qualifying: A1, A3, A4. Calculation: 3/4 = 75%. No cleaning or mapping change in this exercise. Review responsibility and date: to be recorded when someone actually performs that check.

For the revised report, add the new source reference, the changed A2 classification and the new calculation. Keep the earlier note available rather than silently replacing its inputs.

A clear lineage doesn't prove that every source classification is accurate or complete. The outcome-completeness guide covers reviewing missing, conflicting and pending outcomes. Lineage helps someone find the data and decisions to inspect; those checks still need to happen.

When the next colleague asks where a number came from, hand them a particular source, rule and calculation. That's a useful answer even when the remaining finding is that a piece of the trail is missing.