Bank Reconciliation

Bank reconciliation takes a statement you export from your bank, works out what each line probably settles, and lets a person confirm it. Confirming is where money is actually recorded, and it goes through exactly the same paths a payment recorded by hand does.

A statement is a file you export from your bank and upload. Runnit does not connect to a bank, a card issuer or an aggregator.

Reading a statement needs both finance:view_prices and finance:view_cost, because one page mixes money in with money out and no figure can honestly be shown under only half of that. Creating a mapping, importing and reverting need finance:manage_settings. Confirming needs the capability that matches the action.

Describing your bank’s format

A mapping describes one bank’s export once: which column holds the date, the description, the reference, the amount and the balance, and how to read them. Runnit needs to be told the date format, the decimal and thousands separators, whether money out is a negative number, an inverted sign (as a card statement usually writes a charge) or a separate debit and credit column, how a negative is written (a minus, brackets, or a DR and CR marker), the delimiter, how many rows to skip before the header, and whether there is a header at all.

A mapping is versioned rather than edited in place, so an import always records which reading of the file it was taken under.

Open Finance > Bank statements > File formats.
Choose Create a file format, then start blank or copy a saved format.
Enter the format name, date and amount conventions, and the bank’s column headings. For a file without headings, enter positions starting at zero.
Choose Save file format. Saving an existing name creates a new version.

Only CSV is supported. There is no OFX, QIF, CAMT.053 or MT940 import.

Importing, and what counts as the same transaction

Two things about bank exports drive everything here.

The same file twice is refused, and Runnit names the import it already has.

Overlapping exports are the normal case. Last month’s file ends on the 31st, this month’s starts on the 25th, and the six days in common are the same transactions inside two different files. Runnit recognises the shared rows, marks them as duplicates of what it already holds rather than importing them again, and tells you how many overlapped.

Telling transactions apart matters as much as spotting repeats. Two coffees at the same cafe for the same amount on the same day are two transactions, not one, so identical rows are kept, and what separates them is their order within that day. Where your bank’s format carries its own transaction id, that is used instead and none of this applies.

For a format with no transaction id you can choose the stricter setting, which refuses a file containing same-day identical rows and names the days it could not resolve, rather than numbering them.

A row Runnit cannot read is a finding, not a failure. Unless you supplied both balances, the rest of the file still imports, and you get the row number, the line, the field and the value that stopped it. One unreadable row must not lose the other nine hundred.

When you supply both opening and closing balances, all rows must be readable and in the statement currency, and their total must reconcile the opening to the closing balance. A difference refuses the import so you can correct the file or its format. Overlapping rows still count in this file-level check. With only one balance, Runnit retains it without claiming reconciliation.

Reverting an import

Reverting removes the import’s lines and frees the file, so a corrected export of the same statement can be loaded. A transaction that another file also reported comes back rather than disappearing with the revert.

An import with a confirmed line cannot be reverted at all. The money it settled is real. Reverse the confirmations first.

How a match is proposed

Some things are facts rather than probabilities, and they are applied first. A different currency is a different account. Money going the wrong way cannot settle that kind of document. Something with nothing outstanding is not a candidate. And a document more than 21 days away from the posted date is a coincidence, measured from whichever of the document’s two dates is closer, so a 30 day term does not push every on-time payment out of the window.

What is left is scored:

Signal	Weight
The amount equals what is outstanding	Highest
The amount is within a small tolerance	High
The amount is less than outstanding (a part payment)	Low
The amount is more than outstanding (the excess becomes credit)	Low
Same day as the document, then within 3, 7 or 14 days	High down to low
The statement text carries the document’s reference	High
The statement text carries the document number only	Low
The counterparty names the same party	Low

Three thresholds follow from the score. Below the floor a candidate is not offered at all. Above the suggest threshold the line is marked as suggested and offered for one-click confirmation. Above the strong threshold it may be shown first.

A tie never picks. Two candidates on the same score are two answers, so both are marked as tied, nothing is suggested, and the line waits for you. Choosing the first by accident would settle real cash against whichever invoice happened to sort first.

Each candidate carries the evidence it was built from: the target’s balance, total, currency, date and party, and the statement line’s own amount, date and text. That evidence is what makes a stale suggestion detectable later.

What confirming actually does

“Accept this match” hides five different economic acts, and confusing them is how a receipt gets recorded twice. Runnit keeps them apart:

Action	What it does	Does it record cash?
Link an existing payment	The settlement is already recorded. This records the identity, so nothing settles it again	No
Record a client settlement	New client cash, through the ordinary payment path	Yes
Record a supplier settlement	New supplier cash, through the ordinary supplier payment path	Yes
Confirm a reimbursement run	Records that the payment file cleared on the chosen date	Yes, on first confirmation
Mark card spend paid	Company card spend the card already paid, and which already counted on its expense date	No

Which capability you need depends on which of those it is: finance:record_payments for linking and client cash, procurement:manage_bills for supplier cash, and expense:manage for reimbursement runs and card spend.

Before anything is recorded, Runnit locks the line and rechecks:

your authority for that specific action, not for confirming in general;
the line’s own state, since a duplicate line settles nothing and an ignored one has to be brought back first;
whether a confirmation already stands, in which case an identical request returns the existing result, while a changed target, amount split or date is refused;
that the match belongs to this line and names the target the action does;
the target as it is now. A document that is no longer open, or whose balance has moved since the suggestion was made, is refused and asks for a rescan rather than settling against a stale figure;
that the period the money belongs in is open; and
for client cash, whether that payment is already recorded, in which case Runnit points you at linking it instead, or says the possibilities are ambiguous and belong in reconciliation.

Only one live confirmation exists per statement line, so a second acceptance is refused rather than becoming a second settlement.

Splits, part payments and overpayments

Split one bank line across several documents by naming the amounts. They can total no more than the line.
Part payment leaves the document partly paid for the balance.
Overpayment becomes client credit through the ordinary settlement path, rather than an invoice settled for more than it was worth.

In the acceptance dialog, choose Add allocation. Enter each document and its amount in the displayed currency. Include the main document once. Each receipt can cover one client’s invoices; supplier payments cover one supplier. The documents must share the billing entity and currency.

A split across invoices records one receipt with multiple allocations. Any remainder becomes client credit. A supplier remainder stays unallocated.

Reversing a confirmation

Choose a Reversal date and enter a reason. The date must be in a writable period and cannot precede the settlement. Reversing cannot be done twice and returns the line to unmatched.

Action	What reversing does
Link an existing payment	Releases the identity. The payment is untouched, because this never recorded it
Record a client settlement	Reverses every payment it created, line by line, and re-settles the invoice
Record a supplier settlement	Posts the exact inverse of every allocation
Confirm a reimbursement run	Reverses the payment confirmation created by this match and returns the run to exported. An independently confirmed payment keeps its confirmation
Mark card spend paid	Restores the claim to what it was

Tax on a cash basis

Because both settlement actions go through the real payment paths, a confirmed settlement appears in your cash-basis tax figures with its net and each tax component, and reversing it takes the same components back out on the reversal date. Reimbursement exports contribute no cash; confirmation records the actual payment date and corrections preserve earlier periods. Marking card spend paid records no cash, because the expense already counted on the date it was incurred. See Finance Reports.

Removing a receipt that has already been used

A client settlement reversal needs a writable date on or after the receipt’s latest activity. Its remaining invoice payment is undone on that date. Unused credit is cancelled; credit already used or cash already refunded becomes a separate recovery balance. The original cash history remains visible. See Getting Paid.

Next step

Close the month once the account agrees: Month End.