Connect your bank

Go to Banking in your sidebar and choose Connect a bank to link your account with Open Banking. Transactions then arrive automatically, and you'll be asked to reconsent every 90 days, as UK banking rules require.

If you'd rather not connect a live feed, choose Add a manual account and keep it up to date yourself, or Import a statement, upload a CSV (mapping your bank's columns the first time) or a PDF statement instead.

However transactions arrive, they land in Review. From there you can confirm our suggestions one by one or in bulk, and set up rules so the same kind of transaction is explained automatically next time. If a transaction matches a payment you already recorded by hand — rent entered on a tenancy, or an invoice payment you logged yourself — confirming the suggestion links it to that payment instead of recording it a second time.

If your business is VAT-registered, explaining a transaction as a new expense or as income asks you to choose the VAT rate — there's no default, so you always see and choose what's actually sent to HMRC. The same choice appears when explaining several transactions at once from Review. A suggestion BusyBee Hub can't confidently rate (or a rule saved before you registered for VAT) is left for you to review rather than confirmed automatically.

Connecting a bank, adding a manual account and importing statements can all be used together, so you can mix and match to suit each account you hold.

Importing the same file twice

If two transactions on the same day are genuinely identical — two £2.80 TfL fares, say, or two coffees from the same shop — BusyBee Hub keeps them both instead of treating the second as a duplicate of the first. The preview shows them as Identical row kept, separately from any row it recognises as already imported.

One effect of this: re-importing an old CSV or PDF file may now bring in rows that used to be silently dropped. If you're not sure whether that's happened, check the imported total against your bank's own statement for the period.

Checking a PDF statement's balances

When you import a PDF statement, BusyBee Hub reads the running balance next to each transaction (when the statement prints one) along with the statement's own opening and closing balance, and checks that they all add up — in whichever order the statement lists transactions. Before you commit the rows, you'll see one of three messages:

• Statement balances match — the rows read from the file add up to the statement's own opening and closing balance.
• Balances don't match — something doesn't add up, and the row (or rows) it couldn't reconcile are flagged with why. You can correct a row's date, description or amount before importing, or tick Import anyway to go ahead regardless — useful if you're confident the flagged row is fine and the mismatch is elsewhere on the statement.
• Couldn't check against balances — the statement doesn't print an opening or closing balance, so there's nothing to check the rows against; this isn't itself a sign of a problem.

Decimal separator and card statement signs

Most UK bank exports use a full stop for the decimal point ("12.50") and either a single amount column (negative for money out) or separate paid-out/paid-in columns. Some European or card-provider exports differ:

• Decimal separator — a file that uses a comma instead of a full stop ("12,50" meaning twelve pounds fifty) is detected automatically when your file uses semicolons between columns; otherwise choose Decimal separator: , yourself on the mapping step so amounts aren't read 100 times too large or too small.
• Amounts are positive for spending — some card statements show a purchase as a positive number and a payment or refund as negative, the opposite of BusyBee Hub's own convention. Tick Amounts are positive for spending on the mapping step to flip the sign; it's ticked automatically for an account you've marked as a credit card.
• Zero-filled columns — if your export always fills in both a "Paid out" and a "Paid in" column, writing "0.00" in whichever doesn't apply to a row, that's handled automatically: a zero in one column is treated as blank and the other column's value is used.

Possible duplicates between your bank feed and a statement

If you import a CSV or PDF statement covering the same period a connected bank feed also fetched, BusyBee Hub compares the two by account, amount and date (allowing a day either way, since the two sources don't always agree on which day a transaction posted) — not by narrative, since a bank feed and a statement often describe the same payment differently ("CARD PAYMENT TO TESCO STORES 1234" versus "TESCO STORES 1234"). A likely match is never deleted automatically: it's flagged as a Possible duplicate on both the transactions list and the review queue, showing the other row's date, description and amount, with two choices:

• Keep one — removes whichever of the two hasn't been explained yet (if both are still unexplained, the statement row is removed and the bank feed's own row is kept). If you've already explained both rows, you're asked to sort it out by hand instead — BusyBee Hub won't guess which explanation is the right one to lose.
• They're different — dismisses the flag and keeps both rows; genuinely separate transactions that happen to share an amount and a nearby date are common (a season ticket and a coffee on the same fare, say).

Once you've resolved a pair, the same transaction won't be flagged again if your bank feed or a later statement re-delivers it.