The case model
A case is one client for one financial year. What that constraint buys you, how a case moves through its stages, and how last year's case seeds this year's.
A case is one client, one financial year. Everything — documents, review points, the workbook, the chase list — hangs off that pair.
The constraint is deliberate. A client folder that spans years cannot answer "what is outstanding for FY2025-26" without someone deciding which documents belong to which year, and that decision is exactly the one people get wrong at volume.
Finding a case
The financial year filter is the one to reach for first: at any point in a season you are working one year and glancing at another, and the list is sorted by priority, not by year.
It appears once your list spans more than one year — in a firm's first season there is nothing to choose between, and rolling last year's cases forward is what creates the second.
Search covers cases and the documents inside them — a client's name, a file name, or a phrase that appeared in a statement.
Stages are derived, not set
You do not move a case through a workflow. Its stage follows from what is true about it: documents present, a build finished, review points outstanding.
The one exception is completion. Mark complete is manual, because "this is finished" is a judgement about your own review, and nothing the system can see tells it that you are satisfied. A completed case carries the date it was marked.
Why a case can go backwards
Add a document to a completed case and it stops reading as complete. The figures on screen were computed from a smaller set than the case now holds, and pretending otherwise would be the most expensive kind of quiet wrong.
Next year
When the new year opens, last year's case is what seeds it: the client, the entity type, the shape of what they sent, and the list of what had to be chased. That is the payoff for the one-year-per-case rule — the roll-forward has a single, unambiguous prior to copy from.