How columns are matched automatically

Three signals — the header, the shape of the values, and whether the values are already names in your books.

The hard part of an import is knowing that the column headed Supplier is your vendor and Net GBP is the amount. Three things work that out.

1. The header. Matched against the words people actually use — supplier, payee, merchant, nominal, category, trans date — with fuzzy comparison, so "Trans Date" and "Transaction date" are the same thing.

2. The shape of the values. A column whose entries all parse as dates is a date column whatever it is called. This is what rescues files with no useful headers at all, or headers in another language.

3. Your own records. A column containing your actual vendor names is a vendor column — because those are your vendors. The same goes for account names and numbers, which is how a column headed only "Nominal" still finds its way to Account.

Every field shows how sure we are: confident, likely or unsure. Anything marked unsure is worth a glance. Nothing is inferred silently, and you can change any row of the mapping.

One column is never used for two fields. The whole grid of possibilities is scored at once and assigned best-first, so a column that fits one field poorly and another well goes where it belongs.

What it cannot guess is the genuinely ambiguous: 03/04/2026 is March 4th to an American bank and April 3rd to a British one. If any value in the column is above 12 we settle it from the data; otherwise you set the convention, and a saved format remembers it.

Amounts are read in the conventions spreadsheets actually use: currency symbols, thousands separators, parenthesised negatives, a trailing minus, and the European decimal comma. A bank file with separate Debit and Credit columns is recognised as such.