Exceptions are the job: start an accounting exceptions log

Ask someone how a recurring task works and they will describe the normal case. The bank feed comes in, the items match, the report goes out. Then watch them do it, and most of the time goes somewhere else: the payment with no reference, the supplier invoice in the wrong currency, the payroll file with one extra line. In back office work, exceptions are not the interruption to the job. They are the job. Yet almost no team keeps an accounting exceptions log, so the handling of those cases lives in the heads of whoever met them last.

This post argues for writing them down, and shows a simple way to do it.

Why the hours sit in the exceptions

The normal case of most recurring tasks is already fast. Software has been matching, posting and formatting for years. What is left for people is the part that does not fit the rule.

In our earlier post on the cost of a bank reconciliation, an illustrative costing put 20 minutes on importing and matching, and around 140 on investigating, chasing, fixing and checking. Your numbers will differ, but the shape is common. The same pattern turns up in AP runs (the invoice without a purchase order), in VAT returns (the transaction that might be zero rated), in payroll checks (the starter added after cut-off) and in client reporting (the month a figure moves for a reason nobody wrote down).

So "it takes about two hours" usually means a few minutes of routine and the rest on whatever went wrong this month.

Why exception handling stays in one head

Exceptions have three habits that keep them out of every manual.

• They feel rare. Each one seems like a one-off, so nobody writes it up. But the same dozen kinds come back month after month, in slightly different clothes.
• They get solved under pressure. The person who finds the odd item fixes it close to the deadline and moves on. Writing it up feels like a luxury.
• The fix is a judgement. "I rang the client, they said it was a deposit, so I posted it to the balance sheet." That reasoning is the valuable part, and it is the part that never reaches the procedure.

The result is that a manual written in a quiet week describes the 20 minutes and is silent on the 140. A new starter, a colleague covering holiday, or an AI agent working from that manual will handle the normal case well and stall on the first exception. We made a similar point about SOPs nobody updates: a document that misses the hard cases looks complete right up until it is needed.

What an accounting exceptions log looks like

It does not need software. A shared sheet per recurring task, or a section at the bottom of each task's manual, will do. For each exception, capture six things:

1. Date and task. Which recurring task, which client or entity, which period.
2. What did not match. The symptom, in one line. "Receipt of £4,200 with no reference."
3. How it was found. The check that caught it, or that it was not caught until review.
4. What was done. The steps taken, including who was asked.
5. Why. The reasoning or rule behind the decision. This is the line that matters most.
6. Kind. A short label you reuse, such as "unreferenced receipt" or "late starter". You will only know the labels after a month or two, so start without them and add them later.

Take a hypothetical bookkeeping firm with a dozen staff that runs this on bank reconciliations for one quarter. A plausible outcome is a few hundred entries that fall into perhaps fifteen kinds, with four or five of those covering most of the volume. That is illustrative, not research, but it is the pattern to look for: a long list of unique-feeling cases that turns out to be a short list of repeating ones.

Turning the log into shared method

A log is only useful if someone reads it. Once a month, take each recurring task and look at its entries together.

Write the common kinds into the manual

Any kind that appears more than a couple of times becomes a section in the task's manual: how to spot it, what to do, who to ask, and what the decision depends on. The person who handled it most often writes the first draft. That is a good use of their experience, and it is usually a relief to them, because it means they stop being the only one who knows.

Fix the cause where you can

Some exceptions are not judgement calls at all. They are upstream problems: a client who never adds references, a supplier who sends invoices in the wrong format, a cut-off date nobody told the HR team about. The log gives you evidence for a polite, specific conversation that removes the exception instead of handling it forever.

Watch for the cases nobody can explain

Entries where the "why" is blank, or says "that's how we've always done it", are worth a closer look. Sometimes there is a good reason that only one long-serving person remembers. Sometimes there is not, and the step can go. Either way you want to find out while that person is still around to ask.

Why this matters for AI

When people ask whether a task is ready for an agent, they tend to look at the normal case and say yes. The honest test is the exceptions. An agent can draft the routine part of a reconciliation from good instructions. Whether it can handle the work depends on whether the common exceptions are written down, with the reasoning, so it can either deal with them or hand them back to a person with a clear note.

So the exceptions log is one of the most useful documents to build before bringing in any AI. It earns its keep without AI too: shorter training, safer holiday cover, and credit for the people who carry the hard cases. Capturing that reasoning against each recurring task, as the work happens, is part of what we are designing Beaks to do. A shared sheet will get you started.

Be open with the team about why you are keeping it. The aim is to share what experienced people know so the hard cases stop landing on the same desk, not to grade how often someone hit a problem. If the log feels like a record of mistakes, people will stop writing in it.

One thing to do this week

Pick one recurring task that runs before the end of the month, ideally one that always takes longer than people expect. Add a six-column sheet next to it and ask whoever runs it to log every exception this cycle, with a line on why they handled it the way they did. Read it together afterwards. Count how many entries are really the same kind of problem, and write the most common one into the manual before next month.