CSV before and after compare

Use two exports that should cover the same history

Your before file might be the bank's CSV or a converter's output. Your after file might be a fresh export from the app you imported into. You provide both files here; the tool does not connect to the bank or destination app. Choose the same accounts and date range, including the same posted-versus-pending basis, before interpreting a difference as a problem.

Map each file separately because its columns, separators and money direction may differ. Choose the source's date order and number separators explicitly. A signed amount column or separate debit and credit columns can be used. Check a purchase, a deposit or refund, and the first and last rows in the preview before confirming the settings.

Every row needs an account and currency. Map those columns in a multi-account file, or enter a single label when the whole file belongs to one account and currency. Labels are compared exactly, including spaces and letter case. If one file calls the same account Checking and the other calls it Current account, prepare consistent labels in a working copy. The tool will not silently decide they are the same account.

One occurrence matches one occurrence

The default match uses the parsed date, signed amount and exact description within the same account and currency. Two identical coffee purchases in Before need two matching occurrences in After. One cannot stand in for both. Source order does not affect how many exact matches exist; equal occurrences are paired in source order only to provide line references.

Normalized text is optional. It uses Unicode NFKC normalization, lowercase, trimmed ends and collapsed whitespace, while retaining punctuation and digits. This can treat a line break as a space, but it cannot reconstruct a missing payment reference. Date + amount only deliberately ignores descriptions, so a row can be marked unchanged even when all its text disappeared.

After exact matches are removed from consideration, remaining rows become change candidates when they share either the same date and amount or the same nonblank comparison text. A connected candidate group containing exactly one row on each side is shown as Changed (possible). For example, a unique date-and-amount pair can reveal shortened text, while a unique description can suggest an amount or date change. This is a review suggestion, not proof that the two records represent the same transaction.

If several rows connect through those candidate fields, every row stays Ambiguous with a shared group label. No pairing is chosen, even if a more aggressive rule could force one. Missing in after and Added in after mean no remaining counterpart was found under these rules. If the date, amount and text all changed, a real counterpart may appear as separate missing and added rows.

Equal sums, different transactions

Load example uses fictional checking and savings records. Checking has seven USD rows before and six after, but both signed sums are 105.00. Savings has one EUR row worth 2.00 on each side. The currencies are not combined into a grand total.

In Checking, one of two -5.00 coffee purchases survives, an invoice description is shortened, Power changes from -40.00 to -45.00, and an old -25.00 purchase disappears. A new -20.00 purchase and a -15.00 adjustment appear. Two -10.00 shop rows face one shortened shop row on the same date, so all three are ambiguous rather than arbitrarily paired.

The result has two unchanged pairs, two possible changed pairs, two missing rows and two added rows. The remaining two before rows and one after row are ambiguous. Independent sums still agree. That is why equal totals do not prove completeness, and why a balance check alone cannot find lost descriptions.

What this comparison cannot decide

This checks only the dates, amounts and optional descriptions you mapped, partitioned by account and currency. Categories, references, running balances, attachments and other columns are not matching fields. Original cells remain in the review export so you can inspect them separately. No currency conversion, split recombination, transfer elimination, fuzzy spelling match or automatic repair is performed.

Each input accepts UTF-8 CSV or text up to 5,000,000 bytes and 10,000 data rows, with comma, semicolon, tab or pipe separators. Both files use your chosen precision of 0-6 decimal places. Extra precision is rejected rather than rounded. A header-only file can represent an empty export after you confirm its settings; an entirely blank input is not treated as an empty account.

Malformed dates or amounts, inconsistent columns, blank records, repeated headers, subtotal-like rows, blank mapped account or currency cells and replacement characters block comparison. The tool lists the issues and retains readable source records for inspection. No partial totals are reported by silently excluding those rows. Blank descriptions are allowed, and exact duplicate transactions are retained. Calendar dates remain calendar dates; removed time or weekday labels are reported for review.

Counts and sums are calculated independently from all parsed rows, not inferred from matching. They describe only these supplied files. Missing pages, missing periods or rows absent from both exports remain unknown. This is neither bookkeeping reconciliation nor document authentication, and it does not establish fraud, import acceptance or the correct accounting treatment of a transaction.

For the wider review, use the before-and-after import checklist. If source text disappeared, the missing descriptions guide explains what to compare against the PDF.

Keep the originals and save a review copy

Your file and the values you enter are processed in this browser tab. They are not uploaded or sent to analytics. We do not save them between visits. Downloads you choose to save remain on your device.

Clear resets both inputs and settings. It is not a secure memory wipe, and navigating away is not a substitute: Back may restore uncleared input. A download creates a new file and does not overwrite either source.

The differences CSV includes every difference class regardless of the visible filter, before and after physical line numbers, comparison values, original cells encoded as JSON text, ambiguity groups and settings. Formula-like text receives an apostrophe; parsed numeric negatives retain their sign. This is a spreadsheet-review copy, not a destination-app import file or a byte-for-byte original. Review private details before sharing. Spreadsheet save-and-reopen can remove formula protection, so no universal safety guarantee is made.

Method and checks

CSV quoting follows the shared parser's RFC 4180 approach, with additional line-ending and separator support described above. Export protection uses the shared formula-neutralization helper, informed by OWASP's CSV injection guidance. Both sources were opened on 18 October 2026; RFC 4180 was published in October 2005, and the OWASP page showed no update date.

The mint-to-simplifi-csv README, also opened on 18 October 2026, describes a personal pre-link and post-link export comparison after a split-transaction migration. It illustrates why a second export is useful, not a current specification for Simplifi. Its scripts were not run here. The fictional totals above were independently recomputed with exact decimals. No live bank connection or destination-app import was tested.

If your before file is still a PDF