LO
Accountant / Bookkeeper — tasks, one by one
The unit of analysis is the task, not the job title. Each one below carries its direction, whether the judgement rests on evidence or on platform inference, the reasoning, and what it does not establish.
Every task on this page#
Entering and coding transactions
Automating✓ Evidence-backedTaking invoices, receipts and bank lines and putting them into the ledger under the right account.
This is structured input with a fixed output schema and a clear correctness signal — the conditions under which both rule-based automation and document-reading models work well. Bank feeds and OCR have been eroding it for a decade; language models mainly removed the remaining edge cases.
Does not mean the headcount disappears. In small practices the same person does entry and advisory; automating the entry half changes the job's shape before it changes the job count.
Reconciliation
Automating✓ Evidence-backedMatching ledger entries against bank statements and sub-ledgers, and chasing the differences.
Matching is a solved computational problem when identifiers are clean. What is left for a person is the unmatched tail — and that tail is exactly where judgement lives.
The unmatched tail does not shrink in proportion to the matched volume. A practice that automates 95% of matching still needs someone who can chase the 5% — and that person needs to have seen the other 95% to recognise what is wrong.
Statutory filing and tax compliance
Being augmented✓ Evidence-backedPreparing and submitting filings that must be correct and on time, against rules that change.
Software has done the mechanics for years, but someone carries the liability for the submission being right. Liability does not transfer to a tool, so the human stays in the loop even when the work is largely automated.
The liability argument protects the sign-off, not the preparation hours behind it. Expect fewer hours per filing, not fewer filings needing a named person.
Explaining the numbers to decision-makers
Still human-led≈ Platform inferenceTranslating financial position into what a founder, manager or board should actually do about it.
Requires knowing the business, the person you are advising, and what they are not saying. Models can draft the analysis; they cannot hold the relationship or absorb the consequence of the advice.
Being hard to automate is not the same as being in demand. Advisory work is concentrated in the senior half of the profession; a junior whose entry work disappeared does not automatically arrive here.
Judging the ambiguous case
Still human-led≈ Platform inferenceDeciding treatment when the rule does not cleanly cover the transaction.
Ambiguous treatment is where accounting is a professional judgement rather than a lookup. Getting it wrong is expensive and the reasoning has to be defensible to an auditor or regulator.
The volume of ambiguous cases is a fraction of total transactions. This task protects the necessity of the role, not the number of hours it takes to do.
Supervising the automation itself
New task≈ Platform inferenceChecking what the tools produced, catching silent errors, and owning the result when a model got it wrong.
As more of the ledger is machine-produced, the scarce skill shifts from producing entries to knowing when the output is wrong. This task did not meaningfully exist ten years ago.
New work is not the same as new headcount, and this task is usually absorbed by people already there rather than hired for. It also requires the judgement built by doing the work that is disappearing.