One deposit, many pupils
A school's bank statement doesn't arrive itemised by pupil. It arrives as a series of deposits — some from an online payment portal batching dozens of families into one daily settlement, some as individual bank transfers with a reference the parent typed themselves, some still as cheques. Behind every one of those lines sits a specific family, a specific invoice, and a specific answer to the question “has this been paid”.
Reconstructing that answer by hand — reading each deposit, guessing at a half-typed reference, cross-checking it against a pupil register — is the kind of task that's manageable for a handful of families and genuinely time-consuming for a whole school. This page describes how that matching happens automatically: what gets read from each payment, how partial payments and discounts are handled, and what happens when a reference simply doesn't match anything in the register.
The result doesn't chase unpaid fees or decide what a family owes — it turns a term's worth of bank activity into a reconciled, exportable record of who has paid, who is part-paid, and who needs a follow-up, so that judgement can be made by a person instead of reconstructed from a spreadsheet at the end of term.
Why the termly spreadsheet slips
The problem isn't reading one payment. It's that a school never gets one payment — it gets hundreds, arriving on different days, through different channels, each with its own reference format, and a school business manager or bursar is usually reconciling them alongside a dozen other responsibilities, not as a dedicated full-time task.
The volume compounds a precision problem, too: matching two hundred payments by eye against a pupil register means two hundred chances to attach a payment to the wrong sibling, miss a part-payment, or mark a family as paid when the deposit actually covered something else entirely. Any single mistake is small. Repeated across a term, and across every term in the year, it stops being small.
What gets read from each payment
| Field | Notes |
|---|---|
| Amount | The exact figure that landed, read from the statement or payment report |
| Payment reference | Whatever text accompanies the deposit — a name, an invoice fragment, a portal ID |
| Date | When the payment actually cleared, not when it was requested |
| Fee type | Tuition, trip, club, lunch — where the source document itemises it |
| Payment method | Bank transfer, card via portal, cheque — for audit and follow-up context |
| Source document | The statement or report line the payment was read from, kept linked for traceability |
Six fields, read from every payment line — not an approximation reconstructed weeks later, but what the source document itself states.
Tuition isn't the only fee
Most schools run several fee streams at once — termly tuition, one-off trip contributions, weekly club subs, daily lunch charges — and a single family's payment can easily cover more than one of them in a single transfer. Treating every deposit as one undifferentiated “payment” loses exactly the information a business manager needs to answer a specific question, like whether the Year 9 ski trip is fully funded.
Where the payment report or reference itemises what a deposit covers, each component is read and logged against its own fee type, so a single settlement that includes both tuition and a trip contribution splits into two tracked lines instead of one merged figure that hides what it's actually made of.
Partial payments and payment plans
Not every family pays a term's fees in one instalment. Payment plans, part-payments made while a bursary application is pending, and simple cash-flow timing on the parent's side all produce invoices that get settled across several separate payments rather than one.
Each payment is read and logged individually against the invoice it applies to, so a family paying in three instalments across a term shows three matched entries against one invoice — not a single lump figure that looks confusingly overpaid one month and underpaid the next.
Discounts, bursaries and sibling reductions
A sibling discount, a bursary adjustment, or a hardship arrangement all change what a family actually owes relative to the published fee schedule — and the reconciliation has to match against what's actually due, not the list price, or every discounted family shows up as permanently short-paying.
The match runs against whatever figure the invoice itself states as due. Where that figure already reflects a discount or a bursary adjustment, a full and on-time payment against it reads as fully paid — the adjustment is the school's decision, made once when the invoice is set, not something recalculated during reconciliation.
Seeing arrears before the term ends
An unpaid or part-paid invoice is far more useful to know about in week three of term than in the final week, when there's little runway left to send a reminder, arrange a payment plan, or simply have a conversation before the balance rolls into the next term unresolved.
Because the reconciliation runs against invoices as payments arrive, an unmatched or short-paid invoice is visible as soon as the relevant bank statement or payment report is read — not reconstructed retrospectively once someone finally sits down to total the term.
That early visibility changes the tone of the eventual conversation with a family, too. A reminder sent in week three reads as routine administration. The same reminder sent in the final week of term, after the family has effectively been carrying a balance they may not even realise is overdue, tends to land as more confrontational than anyone intended.
A term, matched
A mid-sized independent prep school, one term, 214 fee payments across tuition, a residential trip and the after-school club.
| Fee type | Payments | Matched |
|---|---|---|
| Tuition | 158 | 154 |
| Residential trip | 41 | 39 |
| After-school club | 15 | 15 |
210 of 214 payments matched automatically. The four unmatched — two with a garbled bank reference, one covering a sibling's invoice under the wrong surname, one genuinely unexplained deposit — took under fifteen minutes to resolve by hand, instead of being lost inside a term-end spreadsheet review that would otherwise have taken most of an afternoon.
How it works
Upload bank statements and payment reports
PDF, scan, or export from the online payment portal — for the period you're reconciling.
Each payment is read
Amount, reference, date, and fee type where the source itemises it.
Matching runs against your pupil and invoice list
Reference, amount and timing checked together, not on reference alone.
Export the reconciliation
Excel, CSV or JSON — matched, part-matched and unmatched payments clearly separated.
One payment run to a whole term
Reconciling a single day's payment run is a manageable task by hand. Reconciling every payment run across a full term — for a school with several hundred families — is a different problem, not because any one payment is harder to read, but because the volume changes what's actually practical to do manually.
At that volume, the value isn't just time saved — it's that the unmatched list becomes the entire remaining workload, instead of every single payment needing to be re-checked out of caution. Reviewing a handful of flagged payments is a fundamentally different task than re-verifying two hundred.
Matching against the bank statement
A payment portal report says what was collected. The bank statement says what actually landed in the school's account — and the two should agree, but confirming that requires reading both, not assuming the portal's total is what the bank shows.
Because FlowParse reads bank statements directly, portal settlements can be checked against the actual deposit that hit the account — catching a settlement that's delayed, split across two banking days, or short by a processing fee the portal deducted before paying out.
Into your MIS or finance system
The reconciled data has to land somewhere. For a school management information system or a finance package, exporting to Excel or CSV with stable columns lets you import without reshaping the file each time.
For a bespoke trust-wide dashboard or a custom import routine, JSON via API is the more direct route — every field separate and machine-readable, with pupil, fee type and invoice kept as distinct fields rather than concatenated into one description.
Whichever format you choose, the underlying data doesn't change — only its shape does. That means switching from a manual Excel import to an automated API feed later, as a school or trust grows, doesn't require re-reading a single historical statement.
Some finance teams start with a manual export while trialling the process, then move to an automated feed once they're confident in the results — a natural progression that costs nothing in re-work, because the underlying reading method is identical either way.
Whichever route a school takes first, it's worth revisiting the choice periodically rather than assuming it's fixed forever — a manual export that made sense for fifty families rarely stays the right choice at five hundred.
Who this is for
School business managers
A reconciled fee ledger without a term of manual cross-checking against the register.
Bursars
Multiple fee types and multiple accounts tracked separately, without merging into one confusing total.
Independent and international schools
High-value tuition and trip payments matched with the same rigour as any other revenue line.
Multi-academy trust finance teams
The same matching method applied consistently across every school in the trust.
Different sources, one method
A school's payment records rarely arrive in one consistent format. Some banks return a clean digital statement export. Others still produce a scanned or photographed statement, especially for smaller accounts like a trip or PTA fund held at a different bank than the main account. A payment portal adds its own report format on top of both.
None of that variation requires separate configuration. The reading is based on the structure and meaning of each field, not a fixed layout tied to one bank or one portal — a statement from the main account and a scanned statement from a smaller trip fund account are read the same way, because both follow a recognisable statement structure underneath their surface formatting.
Scans and photographs pass through OCR first, and automatically receive a closer level of scrutiny — fields on a photographed statement get flagged more often than the same fields on a clean digital export, which is the expected behaviour, not a flaw in the reading itself.
An archive across school years
Reconciling one term is a contained exercise. Building an archive that spans several school years changes what becomes possible with that data — not because any one term is harder to read, but because year-on-year comparison becomes the real goal, and that comparison only works if every year was read with the same consistency from the start.
A multi-year archive built this way makes it straightforward to answer questions that would otherwise mean reopening folders from different school years — how arrears trends have moved, which fee type generates the most part-payments, whether a given pattern of late payment repeats every autumn term.
What this doesn't do
Doesn't chase unpaid fees for you
It shows what's unpaid or part-paid. Sending reminders and arranging payment plans stays a human decision.
Doesn't set fee amounts or discounts
It reads what's stated on the invoice. Deciding fee levels, bursaries or sibling discounts remains the school's policy call.
Doesn't replace your MIS
It's the layer that turns bank and portal data into a matched reconciliation — not the pupil register or invoicing system itself.
Doesn't guarantee against every edge case
The matching logic catches most mismatches. An unusually formatted reference or a damaged scan still deserves a human look.
That boundary is deliberate. A tool that guessed which pupil a garbled reference belonged to would be making a financial decision about a family's account without anyone noticing — an unmatched line is less convenient than a guessed match, and for exactly that reason more trustworthy.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Statements and reports are never used to train AI models.
For a school handling families' financial data, that isn't a footnote — the details are on the security page.