Reconciling bank payments without breaking your records
Many studios take the bulk of their fees by bank transfer. Every week or two, a run of deposits lands in the account, and someone has to work out which invoice each one belongs to. Done by hand, that means opening invoices one at a time, reading bank descriptions that were never written to be read by anyone, and trusting that nothing gets recorded twice. It is slow, and it is exactly the kind of task where small mistakes accumulate into a family being chased for money they already paid.
Bank reconciliation in Octavia is built to remove that manual matching without putting your billing records at risk. You export a CSV of transactions from your bank, upload it, and Octavia proposes which sent invoices those transactions pay. You review the proposals, confirm the ones that are right, correct the ones that are not, and only then does anything get written. Where a family has overpaid or paid twice, you can turn the extra amount into an account credit rather than forcing it against an invoice it does not belong to.
What the feature is actually solving
A bank statement and an invoice ledger are two separate records that have to be brought into agreement without corrupting either one. The bank knows an amount, a date, and a scrap of description text. Octavia knows who owes what. Reconciliation is the work of connecting those two views safely, and the risk in any automated version of it is that a wrong or repeated match silently rewrites your payment history.
The design starts from that risk rather than from convenience. The guiding decision is that matching and writing are two different acts. Uploading a statement never creates a payment. The system stages the rows, proposes matches, and waits. Nothing touches your billing records until you confirm, and confirmation revalidates every row again at the moment you commit it, because an invoice may have changed since you first previewed it.
The architectural decisions behind it
Three choices shape the feature.
The first is that confirmed matches write into Octavia's existing billing records, not a separate reconciled-payments store. A reconciled bank transfer becomes an ordinary payment and allocation, the same shape a manually recorded bank transfer would take. Invoice balances and payment status stay derived from those records, exactly as they were before. This avoids the trap of a parallel money system that has to be kept in sync with the real one.
The second is that matching is deterministic, not a guess. Octavia scores candidate invoices on concrete signals: the amount, an invoice number appearing in the bank text, family or student clues in the description. It is biased toward asking for review rather than confirming on its own, which is the correct posture for anything that moves money. Matching is also constrained to invoices that are genuinely safe to pay against, so drafts and voided invoices are kept out of the candidate set.
The third is duplicate protection, enforced before and during confirmation. Each bank row is fingerprinted. If a row has already produced a confirmed outcome, re-importing the same CSV will not create a second payment for it. Those rows are surfaced as already imported rather than offered for confirmation again. The same real deposit should never become two payments in your records, and this holds even if you import an overlapping statement by accident.
Around those decisions sit the practical parts. Octavia recognises the likely date, amount, description, and reference columns on upload, and you can adjust that mapping if a particular bank exports its CSV in an awkward shape. Mappings can be saved per school, so a bank whose format never quite auto-detects only needs correcting once. Overpayments can be approved as a full invoice payment plus an account credit for the remainder, and an incoming amount that does not belong against any invoice can be turned into a credit directly.
What it deliberately does not do yet
The first version reconciles invoice payments, and only that. It is not a general ledger import. It does not yet split one bank row across several invoices, so a single lump transfer meant to cover three siblings' invoices still needs handling one invoice at a time. It does not yet offer an unreconcile or reversal step once a row has been committed, and it reads CSV only, not PDF or other bank formats. These are known boundaries, chosen to keep the first version narrow and trustworthy rather than broad and fragile.
How to use it
Reconciliation is a school admin tool. You will find it in the teacher app under Money, as Reconciliation. The page is organised into three tabs: importing a new CSV, reviewing imports, and browsing all imported transactions. The usual path is to export a statement from your bank, upload it on the first tab, check the proposed matches on the review tab, correct anything that needs it, and confirm. The all-transactions view keeps a deduplicated record across imports, which is where you go to trace what a given deposit became.
The point of the feature is not speed for its own sake. It is that you can clear a week of bank transfers in one pass and still end up with billing records that are exactly as reliable as if you had entered every payment by hand.