A bank file changed dates or amounts when opened in a spreadsheet

If dates or amounts look wrong after opening a file, preserve that working copy and retrieve the original export. Compare the raw values with the bank statement or transaction detail. A spreadsheet can interpret text according to local settings, so a value that looks neatly formatted may already represent the wrong date or amount.

Identify the exact change before editing. A day and month may have switched, a decimal separator may have been treated as a thousands separator, or an account reference may have lost leading zeros. Each problem requires a different correction. Avoid applying a global format change until the underlying values are understood.

A date such as 04/05 is ambiguous without the source convention. Compare it with an unambiguous date later in the month and with the bank's own record. Confirm the year and whether the file uses transaction, posting or value dates. Do not infer the correct month solely from the order of rows, since some exports sort newest first.

Intuit's CSV guidance requires a consistent date format for imports. Choose the format supported by the target system and preserve the original date in the working data where practical. Document the conversion explicitly, especially when staff in different countries use different spreadsheet settings.

Check boundary transactions around month-end after conversion. A correctly formatted but wrongly interpreted date can move a payment into another reporting period without changing the file's total amount. Review the accounting cutoff with the accountant when an earlier import used the wrong dates.

Compare several large and small amounts with the statement, including values with fractional currency units. Inspect thousands separators, decimal marks, parentheses and minus signs. Confirm that currency symbols or spaces have not turned some values into text while other rows remain numeric.

Recalculate incoming, outgoing and net totals after the transformation. Check the number of transaction rows as well. A conversion that drops rows containing unusual characters can produce plausible totals while omitting actual payments. Also inspect quoted descriptions containing commas: a broken delimiter setting may move part of the description into the amount field. Correct the import settings from the original file before making individual row edits.

Treat account numbers, check numbers and transaction references as identifiers. Preserve leading zeros and full characters. They should not be rounded, expressed in scientific notation or used in arithmetic. Losing a reference can make two otherwise similar payments impossible to distinguish during reconciliation.

Save the original file, transformation instructions and final import file together. Record the source account, period and reviewer. If a repeatable import process exists, update its mapping instead of relying on someone to remember a manual spreadsheet repair each month.

Inspect the target system's preview using known transactions from different parts of the file. Confirm dates, amounts, direction and account assignment before accepting the batch. Reconcile the imported activity with the external statement and document any excluded rows.

If a malformed file was previously posted, identify those entries and use an approved correction process. Consider related invoices, payments and closed periods before deleting or reimporting records. Retain the explanation so the next reviewer can distinguish a corrected format problem from a genuine change in bank activity.