Recurring work is not a project, so stop managing it like one

Most finance teams have tried a project management tool at least once. Someone sets up a board, the team moves cards for a few weeks, and by the second month end the board is out of date and the real work has gone back to a spreadsheet, a shared inbox and one person's memory. That is not because finance people are bad at tools. It is because recurring task management is a different problem from project management, and most tools are built for the second one.

A project has a start, an end and a goal. Recurring work has none of those. The bank reconciliation is not finished in any lasting sense. It is finished for October, and it will be back on the second working day of December, and every month after that for as long as the client stays. Managing that work as if it were a project is the reason so many boards die quietly.

What project tools assume

Project tools are good at what they were designed for. They assume a few things that hold for building a product or running a marketing campaign:

• Work is new. Each task is created once, by someone, when it is needed.
• Work is unique. Every card is a little different, so a title and a description are enough.
• Work moves forward. The interesting question is how far along the project is.
• Work ends. When the last card is done, the board is archived.

None of those hold for a month end close. The tasks are not new, they are the same tasks as last month. They are not unique, they are near copies of each other across dozens of clients. The interesting question is not how far along the project is, but whether everything that should have happened this period has happened. And the work never ends.

What recurring work actually looks like

Take a hypothetical bookkeeping firm with 15 people and 80 clients. Its week is not a set of projects. It is a calendar of obligations, most of which were decided years ago:

• Bank reconciliations for every client, by the third working day.
• Purchase ledger runs every Tuesday and Thursday.
• VAT returns on each client's quarter, a month and seven days after the period end.
• Payroll checks before each client's pay date.
• Management accounts by the tenth working day for the clients who pay for them.

Each of those is one piece of work, defined once, that produces a new instance on a schedule. The definition carries the rules: who does it, how often, by when, which checklist, which manual. The instance carries what happened this time: who actually did it, when, what was odd, what was chased.

That split, a template that repeats and an instance that happens, is the core of recurring task management. A project tool collapses the two. Either you create every instance by hand, which nobody keeps up, or you set a card to repeat and lose the history of what happened each time.

Recurring task management needs four things

If you are choosing a tool, or building a spreadsheet, these are the parts that matter.

Calendar rules that match how finance works

"Every month" is not good enough. Finance runs on rules like the last working day, the third working day, the 7th unless it is a weekend, the first Monday of the quarter. If the tool cannot express those, someone has to adjust dates by hand every month, and that someone becomes a key person.

An owner, and a backup, on every task

Recurring work slips when it belongs to "the team". Every task needs one named owner, and ideally a second person who could do it. Counting the tasks that have only one name against them is the quickest way to find your continuity risk, as we described in the bus factor of a 40 person accounting firm.

The checklist and the manual attached to the task

The instructions belong next to the work, not in a shared drive three folders deep. When the manual lives on the task, it gets used, and when it gets used, people notice when it is wrong. Manuals kept anywhere else drift out of date, which is the problem in why SOPs nobody updates are worse than no SOPs.

History per instance

What happened last March matters this March. Which supplier statement did not agree, which client sent their bank feed late, how long the reconciliation really took. A project tool archives that. Recurring work needs to keep it, because it is the closest thing a team has to a record of how the work is actually done.

Why this matters more now

For years, the cost of managing recurring work badly was mostly felt inside the team: missed deadlines, late nights at month end, a scramble whenever someone was on holiday. That cost is still there. But there is a new one.

Every conversation about AI in finance eventually reaches the same question: which work could an agent take on? You cannot answer that from a project board, because the board never held the recurring work in the first place. You can only answer it from a list of what repeats, how often, under which rules, and how well it is written down. A team that manages recurring work properly has that list as a by-product. A team that does not has to build it from scratch before the conversation can even start.

That is the thinking behind Beaks: a work tool for teams whose work repeats, where the list builds itself from the work people already do. But the principle holds with any tool, including a well kept spreadsheet.

One thing to do this week

Open whatever your team uses to track work and count how many of your recurring tasks are actually in it, with a schedule, an owner and a checklist. Then list the ones that are not, from memory, with the people who do them. If the second list is longer than the first, your team is managing projects in its tool and recurring work in its head. Start by moving the five most frequent tasks across, with their calendar rules written out in full.