The column we almost threw away
An original-column investigation shows how keeping list price, discount and staff attribution explains a $20 commission difference.
A compact transaction table is easier to scan, but it can omit the very field needed to explain a dispute. In this fictional export, the essential commission fields fit into eight columns. Three additional columns explain why the service belongs to Mia and why its basis is $150 rather than $200. We keep both the usable calculation and its source context.
Worked fictional example · amounts in AUD
The useful part
Normalise values for calculation, while preserving the parsed source columns and values for inspection. Keep the original file separately when its exact bytes matter.
Your working files
Download the complete fictional exportCSV · One row with useful unmapped attribution, discount and report-filter columns.One sale with more than one story
Source S210 describes a colour service dated 21 September 2026. Its gross amount is $165.00, supplied tax $15.00 and reported commission $60.00. Mia Chen appears as service provider; Noah Reed appears as the person who took payment. The list price is $220.00 and the recorded discount $55.00. The report filter says invoice date, itemised, all statuses.
The case uses a 40% service rate on the post-discount basis excluding supplied tax. That yields ($165.00 − $15.00) × 40% = $60.00. A minimal imported row can calculate that answer. It cannot, on its own, explain all the choices that led to it.
What a destructive cleanup would lose
Imagine reducing the file to date, staff, item, amount and commission. If “staff” was copied from the payment column, the $60.00 would appear under Noah. If “amount” was copied from list price, the same 40% excluding-tax calculation could be rebuilt on a $200.00 basis, producing $80.00. Those are two distinct errors, not one vague mismatch.
| Source field | Value | What it answers |
|---|---|---|
| Service provider | Mia Chen | Who performed the service? |
| Payment taken by | Noah Reed | Who handled payment? |
| List price / discount | $220.00 / $55.00 | Why is the charged amount $165.00? |
| Gross / supplied tax | $165.00 / $15.00 | Why is the basis $150.00? |
| Report filter | Invoice date; itemised | Which event and detail level were exported? |
Mapping is an interpretation, not a deletion
The importer maps source columns to the fields needed for reconciliation. It also retains the parsed header list and the parsed values for each row. Unmapped columns remain available in that source snapshot. This permits a focused ledger view without forcing every extra field into the calculation model.
For S210, “Staff” is mapped to the earning staff value, while service-provider and payment-taker columns remain supporting evidence. If a different file uses unfamiliar headings, the reviewer must inspect the mapping. A column’s position or a convenient auto-match cannot establish the business meaning of its contents. The accompanying report description can be as important as the data.
A $20 difference with a precise cause
The discount explains the difference between the $80.00 hypothetical list-price result and the $60.00 post-discount result. The gross reduction is $55.00; in this supplied example, its excluding-tax equivalent is $50.00. At 40%, the effect is $20.00. The charged amount already includes the discount, so subtracting $55.00 from $165.00 again would count it twice.
That arithmetic does not decide which basis a particular agreement requires. It narrows the investigation: compare the recorded arrangement against list price and charged price. A preserved discount column lets the reviewer ask a specific question instead of guessing whether the rate, tax or staff rule changed.
A parsed snapshot is not a byte-for-byte archive
The source snapshot preserves the values as interpreted by the CSV parser. The parser normalises line endings, handles quoted fields and trims surrounding whitespace. It does not retain the original file as an untouched binary attachment. The original filename and CSV record number provide a route back to the export, but they are not a cryptographic proof that the file is unchanged.
Keep the original export separately when exact formatting, signatures, file metadata or a complete unmodified record matters. A source inspection view is useful evidence within a reconciliation workflow. It should not be described as a forensic archive or a substitute for a business’s own record-retention process.
Extra context should earn its place
Preserving useful source fields does not mean collecting every available customer detail. The downloadable fictional file contains no customer names, phone numbers, appointment notes or payment credentials. Service attribution, discount and report filter are sufficient to answer this case. When preparing a real export or a support example, remove unrelated personal fields before importing or sharing a copy.
The practical test is whether a field explains a calculation, identifies a source line or supports a review decision. If it does none of those jobs, think carefully before carrying it into another file. Keep a full authorised original where appropriate; make the working copy deliberately suited to its purpose.
Follow S210 through the importer
Use the download to inspect the header mapping and import preview. After import, compare the stored calculation fields with the original-column view. You should be able to recover the $220.00 list price, $55.00 discount and Noah’s payment role without changing the $165.00 charged amount or Mia’s attribution.
The repository’s importer explicitly copies the parsed headers and each row’s parsed values into its source snapshot. This piece is based on that current behaviour and the supplied dataset. The design goal is simple to test: a reviewer should be able to explain why a number was used, as well as see which number was used.
Put it to work.
Inspect source rows, supplied rates and review decisions in the sample workspace.
Explore the sample close