Automating an Accounting Practice: The Books, the Spreadsheets and the Month-End

Most accounting practices in Mauritius do not have a software problem. They have a handoff problem. The ledger works, the reporting pack works, and between them sit fourteen spreadsheets, an email folder of client documents and one senior person who knows how it all fits together.

This is a stage-by-stage account of what we actually automate when we work with an accounting practice, in the order we usually do it, and what we deliberately leave alone.

Stage 1: getting the documents in

Nearly every practice loses more time here than anywhere else, and almost nobody measures it. Bank statements arrive as PDFs, some of them scanned. Invoices come by email, WhatsApp and occasionally on paper. Receipts arrive in a shoebox in the fortnight before a deadline.

What we build first is a single intake point: one route in, whatever the client actually uses, with everything landing in one place, timestamped and attributed to the right client and period. This is unglamorous plumbing and it usually produces the largest single time saving in the whole engagement, because chasing documents is pure overhead that bills to nobody.

Stage 2: extraction and coding

Once documents land reliably, extraction is the obvious next step: supplier, date, amount, VAT treatment and currency, pulled off the document rather than typed.

Coding is where it gets interesting. A system can learn a practice's coding conventions from history, and for recurring suppliers it will be right almost always. Our rule is that the system proposes and, above a materiality threshold or below a confidence threshold, a person confirms. What matters is that the thresholds are yours and visible, not buried in a vendor's defaults.

Stage 3: the spreadsheet layer

Every practice has one: the workbook that does the thing the accounting system cannot. Fee allocation, intercompany schedules, a consolidation the software will not handle, a client-specific management pack built over nine years by someone who has since left.

The instinct of most technology providers is to replace these. We usually do not, at least not first, for three reasons:

• They encode real knowledge. A workbook that has survived nine years of use has absorbed a great deal of judgement about how this practice actually works. Deleting it discards that.
• They are load-bearing. Something downstream depends on the exact shape of that output, often something you will only discover by breaking it.
• Replacing them is the expensive option. Feeding them clean data automatically, and pulling their outputs onward automatically, captures most of the value at a fraction of the risk.

So the first pass is usually to automate the inputs and the outputs of the spreadsheet layer, and leave the middle alone. Rebuilding the workbook itself, if it is worth doing at all, becomes a separate and much better-informed project later.

Stage 4: reconciliation

Bank reconciliation is the classic case, and the number that matters is not the match rate but the exception count. Routine matching has been solved for years; the cost sits in the items that do not match and need somebody to work out why.

What we build surfaces exceptions with the context already assembled: the candidate matches it considered, the reason it rejected them, and the related transactions around the same date. An analyst opens an exception with the investigation already done rather than starting from a line item and a question.

Stage 5: trial balance and the close

With intake, coding and reconciliation running, the close stops being an assembly exercise and becomes a review exercise. Accruals and prepayments can be prepared from prior-period patterns and flagged for confirmation. Intercompany positions can be checked automatically for the mismatches that otherwise surface late.

We would not automate the judgement calls. Provisions, cut-off decisions and anything requiring a view on recoverability get prepared, not decided. The difference is that the preparer is now a system and the decider is still a person, with the working visible.

Stage 6: client reporting and filing preparation

Management packs are highly automatable because they are the same shape every month, and the labour is in assembly rather than analysis. Once the underlying data is clean and reconciled, producing the pack is close to free, which changes the economics: monthly reporting becomes viable for clients who previously received it quarterly.

On the filing side, VAT and tax return preparation can be assembled and cross-checked automatically against the ledger, with variances flagged for attention. The submission itself, and the responsibility for it, stays with the practitioner.

What we leave alone

1. Judgement. Anything requiring a professional view is prepared, never decided.
2. Client relationships. The conversation about why a number moved is the service. Automation buys time for it; it does not conduct it.
3. Working papers you can defend. Everything automated has to leave a trail a reviewer can follow. If a step cannot be evidenced, we do not automate it.

How an engagement actually runs

We start with one client file end to end rather than one process across all clients. A single file exposes every handoff and produces a working result in weeks, which tells you whether the approach fits your practice before you have committed to anything wide.

Measure the close on that file before and after. It is a number you already have, which makes it the honest test. More on why that matters in where the return in finance AI actually comes from, and our wider work on the finance automation page.

Common questions

Do we have to replace our accounting software?

Almost never, and we would treat a proposal that starts there with suspicion. Most of the recoverable time sits in document intake, coding and the handoffs between systems rather than inside the ledger itself. We build around whatever you already run, and a core system replacement stays a separate decision with its own business case.

What happens to our spreadsheets?

In the first pass, usually nothing. We automate what feeds them and what they feed, and leave the workbook itself alone. Those spreadsheets encode years of accumulated judgement about how your practice works, they are frequently load-bearing for something downstream, and rebuilding them is the expensive and risky option. If a rebuild is warranted it becomes a later and far better-informed project.

Can it code transactions automatically?

Yes, and for recurring suppliers it will be right nearly all the time, because it learns from your own coding history. We set it to propose rather than decide above a materiality threshold or below a confidence threshold, with those thresholds set by you and visible rather than buried in vendor defaults.

Will this work for a practice handling many small clients?

That is usually the strongest case. The economics of automation improve with repetition, and a practice running the same monthly cycle across forty clients has far more repetition than one running four complex engagements. The intake and coding stages in particular scale extremely well.

Can it prepare VAT and tax returns?

It can assemble and cross-check a return against the ledger and flag variances for review, which removes most of the preparation labour. Submission, and the professional responsibility attached to it, stays with the practitioner. We would not build anything that files without a person signing off.

How long before we see a result?

We work one client file end to end rather than one process across every client, which usually produces something usable within weeks. Measure the close on that file before and after; it is a number you already keep, which makes it a test the result cannot flatter.

Related: Finance AI returns

Talk to the people who build it →