Independent school with nursery · London · roughly 200 children
An Automation Plan for an Independent School's Finances
One bursar ran all of finance at this London school and nursery, and that bursar had resigned. Invoices, direct debits, bank lines and supplier bills all depended on a single person's hands and memory. We documented each process, designed automation to link their systems, and handed the directors a plan to keep month-end running after the bursar left.
- Industry
- Education
- Function
- Finance & Accounting
- Region
- United Kingdom
- Duration
- 3 weeks
Results
- 20 h → 1 h
- of finance work each week
- Projected: only review and exceptions remain.
- 780 h
- freed every year
- Projected, with payback in roughly a year.
- 200
- children invoiced and matched each term
- Spanning two systems without a usable API.
01
The challenge
The client is a London pre-prep school and nursery, independently run. It has roughly 200 children and a staff of 45. The school already used modern software, but nothing talked to anything else. Connect Childcare held sessions and parent billing. Pegasus did the accounting. GoCardless ran direct debits, Barclays handled banking and spreadsheets filled the gaps. Joining it all together by hand was the bursar's job.
Where the hours went
| Process | Day-to-day reality |
|---|---|
| Parent billing | Roughly 180 invoices a term, each created, checked and sent individually; any session change meant recalculating and sending again |
| Collections | Direct debit plans entered manually, the bank reviewed once a month, payments matched by hand, late payers followed up one at a time |
| Supplier bills | Over 50 invoices a month pulled out of email, typed in, reconciled and paid by hand |
| Statutory deadlines | Quarterly VAT, HMRC, Teachers' Pension and the year-end certificates, tracked on a calendar kept by hand |
- One person holding everything. Illness, holiday or a resignation would halt finance. The bursar had in fact resigned.
- Growth hit a wall. Another fifty families would need more bursar time, not a settings change.
02
What we did
The engagement was paid and had three parts: an assessment of digital transformation, a strategy for automation and a complete solution design. It ended with a build plan, priced, that the directors could put into action.
Assessment: how much of the work a system could take
We walked through income and expenditure as they ran today, one step at a time. We produced as-is maps, as-is maps by cadence and to-be maps. Then we rated eight opportunities on potential, effort and value:
| Opportunity | Share that can be automated |
|---|---|
| Move to Xero (foundation) | Enabler |
| Supplier payments (accounts payable) | 80% |
| Invoicing parents | 85% |
| Tracking payments and collecting what is owed | 90% |
| Self-service portal for parents | 75% of queries |
| Payroll and Teachers' Pension | 65% |
| Getting more from grant funding | 60% |
| Supplier contracts and renewals | 70% |
Strategy: 12 months, five phases
- Foundation. Move from Pegasus to Xero with a bank feed, an import of vendor history and native integrations. We recommended this together with the school's own advisors.
- Expenditure. Automate accounts payable.
- Income. Automate billing and reconciliation.
- Self-service. Give parents a portal.
- Intelligence. Add forecasting, governance reporting and prediction of late payments.
What the core build does
- Termly billing and grants. It updates child records and funding allocations, loads grant confirmations and picks the children eligible for the funding period. Exceptions go to a person instead of being guessed.
- The direct debit run. It generates and exports billing, adds any extra items, then uploads the collection file and validates it before a single charge is made.
- Reconciliation engine. It matches bank lines to each child, deals with returned direct debits and sends anything unmatched to review. Reconciliation is not available through the accounting package's API, and its bank rules cannot cope with 200 families, so we do the matching in code.
- Supplier invoices. Document AI reads each bill. The school's matrix of 70 vendors sets the account, cost centre and VAT treatment, and the bill is entered for review.
- No integration surface, automated regardless. Our Python and Robot Framework desktop engine drives Connect Childcare. Our Playwright-based nodes in n8n drive Xero. n8n orchestrates the full cycle.
- Controls. A queue for human review, reports and alerts on every run, and one supervised month running in parallel with the bursar before anything goes live unattended.
Stack
| Layer | Design choice |
|---|---|
| Workflow orchestration | n8n |
| Web automation | Playwright-based n8n nodes of our own (Xero) |
| Desktop automation | Python with Robot Framework (Connect Childcare) |
| Documents | OCR and document AI for supplier bills |
| Finance systems | GoCardless, Xero, an open banking feed, DocuSign, migration from Pegasus to Xero |
03
The outcome
Every figure here is a projection based on the assessment and on the school's own data.
| Now | Once automated (projected) | |
|---|---|---|
| Weekly finance work | ~20 hours | ~1 hour checking results |
| Monthly finance work | ~70 hours | ~5 hours on review and exceptions |
| Annual hours freed | ~780 | |
| Month-end relies on | A single bursar | A process that is written down and repeatable |
| Adding 50 families | Extra bursar time | A settings change |
- Weekly finance work drops from about 20 hours to 1 hour of checking, freeing close to 780 hours a year.
- The build pays for itself in roughly a year.
- Month-end stops depending on one individual. It is documented, repeatable and auditable.
- The full-time bursar post turns into a part-time coordinator who deals with exceptions, approvals and planning.
- Growing means changing a setting, not making a hire.
What teams usually overlook
When a process works, the dependence on one person stays invisible. It surfaces in the week they leave, and at that point no one remains who can write it down.
Built with
The platforms and tools this engagement runs on.
More case studies
Similar problems, measured the same way.
Accounting and advisory practice · Bulgaria · major clients in pharma, healthcare and R&D, some US-listed
On-Premise RPA for Bank Statement Entry
- working days returned each month
- ~9
- working days returned each month
- statement lines keyed in by the robot
- 200-300
- statement lines keyed in by the robot
Bulgarian accounting practice · 10-15 people · bookkeeping for 100+ companies
AI That Reads and Posts Accounting Invoices
- of documents go through uncorrected
- 97%
- of documents go through uncorrected
- less data entry every year
- 576 h
- less data entry every year
Bulgarian accounting firm · 10-15 people · bookkeeping for 100+ client companies
Hands-Free Bank Statement Retrieval
- client companies handled twice a month
- 70+
- client companies handled twice a month
- bank portals driven by RPA
- 3
- bank portals driven by RPA