The rows are not disagreeing because Wave is broken. They are disagreeing because a Wave export and a bank statement download describe the same money at different layers, with different date rules, different sign rules, and often different column roles.

When Wave accounting CSV exports mismatch bank statement downloads, the problem usually starts before any formula runs. One file may be a filtered bank-account report. The other may be a raw bank statement. One date column may be real Excel dates. The other may be text. One side may show money into the account as a debit. The other may show it as a positive deposit.

The fix is to choose the right Wave CSV first, normalize dates and amounts into one storage rule, and compare only the rows that should match directly. Once those three decisions are made, most "unmatched" lines stop being mysterious.

Read the mismatch before you edit anything

Start by identifying what kind of mismatch you are looking at. A date-storage problem is not fixed the same way as a sign problem. A report-scope problem is not fixed the same way as a description mismatch.

This table tells you what the mismatch is made of before you start fixing it. That matters because the correct next step depends on the diagnosis.

If you want one quick check before anything else, use =TYPE(A2) on the fields you plan to match.

• 1 means Excel stored a number.
• 2 means Excel stored text.

That answer is more useful than the way the cell looks on screen. A date that looks correct but returns 2 is still text. An amount that displays with commas but returns 2 will not behave like a real amount.

Choose the Wave CSV that can actually match a bank statement

Many Wave mismatches start with the wrong export.

A bank statement download is narrow. It shows one bank or credit-card account, one date range, and cleared cash movements. A Wave export is not always that narrow. If you export the full accounting data for the business, you are pulling journal entries and transactions across the account set, not a statement-shaped file for one bank account.

That distinction matters more than people expect.

If you export all of Wave and compare it to one bank statement download, row counts will be wrong before you inspect a single date or amount. Internal transfers, non-bank accounts, opening entries, and unrelated journals can all sit in the Wave file even though the bank statement knows nothing about them.

So the first question is not "which column should I match?" It is "did I export the same scope from both systems?"

For this job, the cleanest starting point is usually:

1. A Wave account-transactions style export filtered to the exact bank account under review.
2. The same statement period as the bank download.
3. One currency and one account only.

If any of those differ, the rest of the cleanup work becomes unreliable.

Normalize dates before you compare any row

There are two date problems here, and they are different.

The first is storage. One side may be a real date. The other may be text. The second is meaning. Wave may be showing the transaction date for the accounting entry, while the bank statement is showing the posting or statement date for the cleared cash movement.

Handle storage first.

If the bank file contains a text date in dd/mm/yyyy, convert it explicitly with:

=DATE(RIGHT(B2,4),MID(B2,4,2),LEFT(B2,2))

If the bank file contains a text date in mm/dd/yyyy, use:

=DATE(RIGHT(B2,4),LEFT(B2,2),MID(B2,4,2))

If a Wave export gives you an ISO-style text date like 2026-05-01, use:

=DATE(LEFT(C2,4),MID(C2,6,2),RIGHT(C2,2))

Those formulas do the extraction directly. They do not ask Excel to guess the format from your locale settings. That is the safer move when you are holding CSVs from different systems.

Be careful with ambiguous dates like 01/05/2026. That string is not self-explanatory. It could mean January 5 or May 1 depending on the source file. Before you convert it, check:

• whether the file also contains a date like 31/05/2026, which confirms day-first format
• whether the bank export labels the field as Posted Date, Value Date, or Transaction Date
• whether the original source view in Wave or the bank portal confirms the format

Then handle meaning.

Even after both files contain real dates, the dates may still be different for a valid reason. The Wave side may reflect when the transaction was recorded. The bank side may reflect when the bank posted it. That difference is common around weekends, month-end, and processor settlements.

So if the amount matches but the date is one or two days apart, do not mark it missing yet. First ask whether you are looking at a transaction-date versus posting-date difference. That is an explanation category, not a failure category.

If the bigger issue is that the files do not even agree on which columns play the same role, bank CSV files with different column names is the adjacent problem pattern.

Normalize amount signs and column structure into one rule

Amount mismatches are usually structure mismatches in disguise.

The bank statement may give you one signed Amount column. It may give you separate Deposit and Withdrawal columns. The Wave side may give you one amount column in some exports and separate Debit and Credit columns in others. Those are not interchangeable until you force both files into the same sign convention.

Pick one rule and apply it everywhere:

• money into the bank account = positive
• money out of the bank account = negative

If the bank file splits Withdrawal and Deposit, convert it inline with:

=IF(E2<>"",-VALUE(SUBSTITUTE(E2,",","")),VALUE(SUBSTITUTE(F2,",","")))

That gives you one signed amount column from two separate bank columns.

If the Wave report for the bank account splits Debit and Credit, convert it with:

=IF(G2<>"",VALUE(SUBSTITUTE(G2,",","")),-VALUE(SUBSTITUTE(H2,",","")))

For a bank asset account, that rule usually works because debits increase the bank balance and credits decrease it. Once both files follow the same sign logic, many false mismatches disappear immediately.

If one side already has a single amount column but Excel stored it as text, convert it directly:

=VALUE(SUBSTITUTE(D2,",",""))

Do not skip the SUBSTITUTE when the file contains thousand separators. VALUE("1,250.00") often works, but explicit cleanup is safer when the export format changes between months.

The point of this step is not cosmetic consistency. It is to make sure the same cash movement has the same numeric meaning in both files. Until that happens, matching on amount tells you almost nothing.

Match the rows that should match, not every field in the file

A bank statement and a Wave export do not owe you perfect row symmetry. Some fields are for direct matching. Others are only there to explain the row after the cash line is identified.

The strongest first-pass key is usually:

1. normalized signed amount
2. the correct date basis
3. a reference or memo check if one exists

Description should stay in the review layer. Bank memos are inconsistent. Wave descriptions may be cleaner, shorter, or edited after import. If you promote description to the main key too early, two correct rows can look unmatched because the words are different even when the money is the same.

This is also where one-to-many problems show up. A transfer entered in the books can create more than one accounting line in Wave, while the bank statement shows one cleared movement. A grouped payout or processor deposit can do the same. That does not mean the cash is wrong. It means the files are recording the event at different levels.

What the leftover mismatches usually mean

Once scope, dates, and signs are cleaned up, the remaining exceptions become much easier to read.

This is the point where the reconciliation becomes defensible. You are no longer saying "these CSVs do not match." You are saying "these three rows are posting-lag differences, this one is a sign-conversion issue, and these two belong to a transfer pair." That is a real answer.

Where the mismatch actually comes from in most Wave-to-bank comparisons

In practice, the recurring causes are usually these:

• The wrong Wave export was used, so the file scope is wider than the bank statement.
• One file stores dates as text and the other stores real dates.
• The two files use different date meanings: transaction date versus posted date.
• The bank file uses one signed amount rule while the Wave report uses debit and credit columns.
• A transfer or grouped entry creates more than one Wave row for one bank movement.
• The descriptions differ enough that text-based matching gives false exceptions.

Notice what is not on that list: the problem is rarely "Wave and the bank disagree about reality." The problem is that the files are structured differently and the comparison started before that structure was normalized.

If the real pain is rebuilding the same manual comparison each month, comparing two bank statement CSVs without formulas is the next step after you understand the mismatch pattern itself.