Once a source CSV is edited mid-reconciliation, the current result is no longer trustworthy. The edit may be visible, such as a deleted row, or silent, such as Excel stripping leading zeroes from references. Either way, the comparison has lost its baseline.

Do not repair the working CSV and continue. Preserve it as evidence, obtain an untouched export for the same scope, compare the versions, and rerun from the clean file. That is how you recover reconciliation source CSV edited mid-process without carrying an unproven change into the final report.

Classify the failure before changing another file

First determine whether the changed result comes from source-file damage, an incorrect comparison boundary, or a legitimate timing item. These classes require different actions.

A settlement delay or deposit in transit can remain as an explained timing difference. A changed source row cannot. Edited source data is an integrity failure, not a reconciling item.

Freeze the failed state

Stop working in the edited CSV. Save copies of every file involved before anyone makes another change:

• The edited source CSV
• The other file used in the comparison
• The reconciliation workbook or working file
• The current reconciliation output
• Notes for manual matches, exclusions, or overrides

Rename the changed file so nobody mistakes it for an untouched source:

The edited CSV is still useful. It shows what the reconciliation consumed and helps prove what changed. It should not be overwritten, corrected in place, or used as the final source.

Also record the account, report name, date range, export settings, and approximate download time. You will need those details to recreate the same comparison boundary.

Recover the last trusted baseline

The preferred baseline is a fresh, untouched export from the original system. Download the same report for the same account and period. Use the same currency, status filters, accounting basis, and report settings.

Do not assume a new download is equivalent because the filename looks familiar. Confirm the boundary:

If the source system has changed since the first download, the fresh export may contain a late adjustment or a newly posted transaction. Treat that as a source-version difference. Document it and decide whether it belongs in scope. Do not confuse a legitimate new source record with a manual edit to the CSV.

If an untouched prior copy exists in an email attachment, download folder, document history, or backup, preserve that too. It may be closer to the exact file used when the reconciliation began.

Compare structure before comparing individual rows

Structural checks narrow the break faster than row-by-row review. Put the clean baseline and edited file side by side:

Each failed control points to the next check. A lower row count means search for missing records. A lower key count means inspect the reference column. A changed total means compare amount values and signs. A shifted date boundary means inspect filters and date conversion.

CSV changes can be hard to see:

• Long transaction IDs become scientific notation
• Leading zeroes disappear
• Day-month dates are interpreted as month-day dates
• Negative values lose their sign
• Debit and credit columns are combined incorrectly
• Blank rows appear above the header
• Columns move and break an existing mapping
• A filtered subset is copied into a new file
• One column is sorted without the rest of the table

Sorting one column alone is especially destructive. The row count and total can stay unchanged while references, dates, and amounts become attached to the wrong transactions. No cell-level patch can prove the original row relationships. Replace the file.

Identify the changed records

After the clean file passes the structural checks, find the exact row changes. Search from the strongest identifier to the weakest:

1. Unique transaction ID or source reference
2. Exact amount and exact date
3. Exact amount and nearby dates
4. Description, customer, or memo
5. Position between surrounding records

Use a comparison table that keeps the evidence visible:

This converts “someone changed the CSV” into a defensible finding: one date changed, one amount changed, and one row disappeared.

If one row remains missing, follow the reference-first search order in how to find a missing transaction between two financial files fast. Do not start with descriptions unless stronger identifiers have failed.

Decide whether any previous work survives

Assume the existing reconciliation must be rerun if an edit touched a field used for matching, scoping, or totaling. Those control fields include:

• Transaction ID or reference
• Date
• Amount
• Currency
• Account
• Debit or credit indicator
• Status
• Customer or vendor ID
• Report period

Some changes are harmless. A filename change does not alter the data. A note column added outside the imported range may not affect the result. A full-table sort may preserve the data if matching uses unique references rather than row position.

Those cases still need proof. Compare the integrity controls and confirm the reconciliation logic did not depend on column position or row order.

Rows deleted or inserted, IDs reformatted, dates changed, amounts edited, filters applied, or columns shifted invalidate the old result. Keep the old workbook for evidence, but do not carry its matched status or exception list into the recovered report without checking each decision against the clean baseline.

For a broader breakpoint investigation, use the same last-known-good method described in why your reconciliation was wrong and how to find where it broke.

Rerun the reconciliation from the beginning

Load the untouched source export and verify its row count, key count, date range, total, duplicates, and blank keys. Run the same controls on the comparison file. If that file also changed, replace it with its own trusted export.

Then rerun in this order:

1. Confirm both files cover the intended account and period.
2. Confirm the match key, starting with a unique source reference where available.
3. Run the comparison from the two verified files.
4. Keep matched, missing, duplicate, amount-difference, and date-difference statuses separate.
5. Compare the recovered output with the failed output.
6. Explain every material change between those outputs.
7. Save the recovered report separately from the failed version.

Recheck every manual override. A row marked “matched by amount and date” against the edited file may not be a valid match against the clean source.

The recovered report should identify both source files and show their integrity controls. It should also separate true timing items from errors. Timing items move according to the accounting cutoff. Missing, duplicated, or altered source records require correction or escalation now.

Reconstruct only when a clean export is impossible

Sometimes the original portal no longer offers the period, the source system has changed, or the only file came from a client. In that case, treat the edited CSV as damaged evidence.

Look for independent records:

• A bank PDF statement
• An accounting ledger export
• A processor transaction report
• A prior attachment or saved copy
• Download or document version history
• Output from the last trusted reconciliation

Build a controlled replacement only from evidence. Label it as reconstructed, not original, and record every restored field:

This is the fallback because it introduces judgment into the source. The reconstruction needs independent review before it becomes the comparison baseline.

Close with a recovery record

The final note should state what changed, how it was detected, which baseline replaced the edited file, what was rerun, and what remains open.

For example:

The recovery is complete when the final result traces back to a trusted source, not when an edited file has been adjusted until the totals agree. Preserve the failed version, identify the clean baseline, rerun every affected match, and document the remaining timing items. That creates a result another reviewer can reproduce and defend.