Duplicate handling and reverse amounts

The Import Options box in the wizard has two settings that change how the import behaves: duplicate handling and reverse amounts. This page explains what each does and when to change it.

Duplicate detection

Before anything is imported, LedgerBear compares each row in the CSV against transactions already in the account and tries to identify duplicates. A duplicate is a pair of transactions that probably represent the same real-world activity.

The matching is more forgiving than a straight equality check. To be a duplicate, two transactions must:

• Be on the same date.
• Have essentially the same amount (within a fraction of a cent).
• Have memos where one is a prefix of the other — this handles the common case where an early export shows a terse memo (AMAZON.COM) and a later export shows the fuller version (AMAZON.COM AMZN.COM/BILL WA).

When multiple candidates fit, the one whose Payee is closest to the incoming row wins (using edit-distance on the payee text).

In practice this means it's safe to re-import overlapping date ranges — you won't end up with double entries.

The duplicate handling setting

• Leave existing transactions unchanged (ignore duplicates) — the default. For every row in the CSV that matches an existing transaction, the CSV row is skipped. Only truly new rows get added.
• Update existing transactions — for every matched duplicate, LedgerBear updates the existing row with data from the CSV. Specifically, the Memo is replaced wholesale, and Payee and Category are overwritten with the CSV's values (but only if the CSV has a non-empty value; empty values don't clobber). Date and Amount are left alone — those are the identity fields for the match.

Use Update when your bank's exports get richer over time — for example, when memos fill in more detail a few days after a charge posts, or when you re-download a month's history after the bank cleaned up payee names.

Reverse amounts

Some banks (especially some credit cards) export their data with the sign flipped from what you'd expect. A purchase that reduces your cash shows up as a positive number instead of a negative one, because from the bank's point of view it's a positive entry in their ledger.

Turning on Reverse amounts negates every imported amount as a last step. It's a one-toggle fix for those banks.

The easy way to tell if you need it: do a small test import (a week or two of data) and check the signs on the resulting rows. If your rent payment shows up as +1,800 instead of -1,800, turn on Reverse amounts and re-import with Update existing transactions to flip them.

Like the column mappings, this setting is remembered per account. Once you've set it correctly for a given bank, future imports will keep using it.