The Month-End Exception Map: what is actually stopping your close

An exception is any item that stops a period being closed cleanly, because a fact, a determination, a decision or an act has not arrived. It is not an error. An error is an entry that is wrong; an exception is an entry that cannot yet be made correctly. Treating the two the same is how one becomes the other.

The families are numbered in dependency order, and the numbering doubles as the classification rule. Ask the questions in sequence — has the data arrived, is it evidenced, is it identified, is it allocated, is the ledger complete, is anything contested, is the treatment determinable, is a decision pending, is an outside act pending — and classify the item at the first question it fails. Where two families appear to apply, the lower code wins, because clearing it often dissolves the higher one.

Cite as: At Par, Month-End Exception Map v1 (29 July 2026), code MEX-x.y. Codes are stable across versions; changes are appended rather than renumbered.

The first five families share a shape: something factual is absent. None of them is an accounting judgement, and none is resolved by thinking harder about the ledger.

Sub-codes exist so an item can be named precisely enough to be actioned. They are not a severity scale.

MEX-3 has a page of its own, because it is the family most often resolved by guessing: what should happen when a bank transaction cannot be matched.

The last four families are different in kind. Nothing factual is missing. What is missing is a determination, a decision or an act — and in three of the four, it belongs to someone the provider cannot instruct.

The map earns its keep at the moment a close is late and nobody can say why in one sentence. Take the open items, give each one a code and an authority, then count — not by family, but by the column that says who can end it. The result is usually uncomfortable and immediately actionable.

Two second-order effects are worth naming. First, an exception that survives a close usually changes family: an unanswered MEX-2 becomes a MEX-4 when someone allocates it to keep the books moving, and later a MEX-7 when the treatment has to be defended. It gets more expensive at every step and less visible. Second, absorption is not neutral. Absorbing an exception converts a visible open question into an invisible wrong number, and the person who did it is rarely the person who will be asked about it.

This is also the mechanism behind two familiar complaints. Books get rebuilt from scratch each period because the exceptions were never named when they were cheap — described in full under why bookkeeping gets reconstructed at month-end. And a close stays difficult after the software is doing its job properly, because automation resolves the routine majority and leaves this residue untouched. If you want the procedural companion to this map, the month-end close checklist walks the same ground as a sequence of checks.

Basis. This is an authored classification scheme. It was derived from the operating structure of a close — the conditions that must hold before a period can be declared finished — and not from a survey, a market study, a dataset or a body of published research. No corpus was counted to produce it.

Derivation. The families are cut on one axis: what has not arrived (a fact, a determination, a decision or an act). Each candidate family was then tested against a second axis, resolution authority, and kept only where three conditions held: it can be stated as a precondition of close; it has a stable resolution authority rather than a case-by-case one; and it is not a sub-case of an earlier family under the first-failed-question rule. Candidates that failed the third test — “awaiting the client”, “query”, “pending”, “in progress” — were rejected, because they describe a status rather than a missing thing and so predict nothing about who can clear them.

Scheme and version. Nine top-level families, fifty sub-codes, one precedence rule, three resolution authorities. Version 1, dated 29 July 2026. Codes are stable: later versions append, and never renumber or reuse a retired code.

Bounded to. Owner-led service businesses — agencies, software and IT services, consultancies, professional-service firms — keeping a general ledger with bank feeds and an ordinary monthly close.

Known limitations. Mixed cases are real, and the precedence rule resolves them by convention rather than by nature — two careful people can disagree about a specific item and both be defensible. The map addresses whether a period can be closed, not whether the underlying accounting is right; an item can be free of exceptions and still be wrong. The resolution-authority column describes who can clear an item in the ordinary case, not who is at fault, and not who should pay for the delay. And the boundary above is narrow on purpose: a manufacturer’s close has exception families this map does not contain.

Version history: v1 — 29 July 2026, first publication. No prior version exists; no figures have been attached to any code.

At Par runs closes to this discipline. Every item that stops a period being finished is named, coded, given a resolution authority and a next action with a date, and shown to the client rather than absorbed — with a qualified accountant (ACCA) accountable for the work. The families the business owns arrive as one specific request, not as a monthly reminder to “send anything outstanding”.

That sits inside ordinary bookkeeping and month-end close, with management reporting on top and catch-up work where the books have fallen far enough behind that the exception list is the first deliverable. Where records and evidence are held, and how they are protected, is documented separately.

More on original research

All guides →