Importing and matching bank transactions

The Bank tab is the cash evidence for Finance. Import statement rows, then allocate each row to a fund and the record or category that explains it.

Import a statement

Choose Import Bank Statement and upload a CSV or QIF export from the association bank.

Start in Financial > Bank. Complete finance setup first, and use a statement period after the opening balance date so that opening cash is not counted twice.

For CSV files:

Confirm whether the file has headers.
Match the date and description columns.
Choose a single signed amount column or separate Money In and Money Out columns.
Review rows parsed, rows skipped, money in and money out.
Check the sample rows before importing.

Nothing is saved until you confirm the import from the preview.

Duplicate handling

The importer can identify possible duplicates using date, direction, amount and description. Keep Skip transactions that already exist selected for normal repeated statement imports.

Possible duplicates can be held for Treasurer review rather than silently added. Import a held row only after confirming it is a genuinely separate bank transaction; otherwise dismiss it.

Add a transaction manually

Use Add Bank Transaction for a real money-in or money-out row that is not available in an import. Enter the bank date, amount and description exactly enough to reconcile it later. Do not create a manual row merely to make a ledger balance look right.

Match or allocate

Open an unmatched row and add an allocation line. Each line needs:

Amount: the part of the bank row explained by this line;
Fund: the money pot affected;
Type: resident charge, bill, category or resident refund, depending on whether money came in or went out; and
Target: the exact charge, bill, category or unit credit.

Money in can match a resident charge instalment or income category. Money out can match a bill, expense category or resident refund.

Split transactions

Use more than one allocation line when one bank transaction covers several targets. For example, a £1,000 receipt might contain payments for two units, or one supplier payment might settle several bills.

The allocated total cannot exceed the bank amount or the selected target's remaining amount. A row can remain partly allocated while more information is being checked, but reports will treat the unexplained part cautiously.

Why unmatched rows block PDF export

An unmatched row proves cash moved but does not say why. Including it as income or expenditure would risk a misleading report. Report previews remain available, but PDF export is blocked until all bank rows in the period are matched or allocated and bank details are complete.

Unpaid bills and overdue resident payments do not block export; they appear as liabilities or arrears instead.

Correcting a match

If the expected charge or bill is missing from the target choices, check the bank row's direction, the target type and whether the charge or bill still has an amount outstanding. A receipt cannot be matched as a supplier payment. Confirm the unit or supplier before selecting a similarly named record.

Use Unmatch on the allocation that is wrong, then allocate the bank row again. Unmatching disconnects the cash from its target; it does not delete the bank row, bill or demand.

Matched bank transactions must be unmatched before deletion. Paid or partly paid bills must also be unmatched before edits that would make the payment invalid.

Reconciliation routine

Import through the latest statement date.
Compare import totals with the source statement.
Review duplicate candidates.
Match every new row.
Check the Finance Overview bank balance and unfinished row count.
Generate a report for the period and investigate unexpected differences.