Month-End Close

Why month-end close takes so long to start

Most of a slow close isn't slow work. It's waiting. The first days go to AR finishing billing and applying cash, and to a bank reconciliation that keeps finding things AR and AP missed and sending them back. Until that loop settles, most of the team is either waiting or working on numbers that will change.

What actually holds up the start of the close

A lot of close work depends on revenue and receivables being final: cost of goods sold, commissions, deferred revenue, the allowance for doubtful accounts, AR flux. So the first gate is usually AR and revenue cutoff: every shipment or service for the month billed, nothing from next month billed early, and customer payments applied to the right invoices.

The bank reconciliation is often treated as the gate, but the statement is available on day one and most teams start other work alongside it. What makes it feel like the gate is what it turns up. The bank rec is where the cash side of AR and AP gets checked against what actually hit the bank, so it's where their misses surface.

The loop

Here's the pattern in closes I've worked:

1. AR closes out its month: invoices out, payments applied.
2. Whoever does the bank rec matches the bank activity to the books and finds items that don't match: a deposit nobody recorded, a customer payment applied to the wrong invoice, a vendor auto-debit nobody booked in AP, a wire posted to the wrong date.
3. Each item goes back to its owner. AR or AP researches it, books it, and tells the reconciler.
4. The reconciler reruns the match, and maybe finds the next one.

Every pass through that loop is a handoff between two people who are both busy with their own close tasks, so most of the elapsed time is waiting, not working. And the reconciler's month depends on AR's: a clean month on the AR side makes the bank rec quick, and a messy one makes it slow, with AP adding its own share on the disbursement side.

Timing items aren't the problem; exceptions are

Not everything on a bank rec needs chasing. Deposits in transit (recorded in the books, not yet at the bank) and outstanding checks (written, not yet cashed) are timing items. They're expected, and they should clear in the next few days. The items that cost time are the real exceptions:

• On the bank, not in the books: unrecorded deposits, auto-debits, bank fees, interest.
• In the books, wrong: a payment applied to the wrong customer or invoice, an amount keyed incorrectly, a duplicate.
• Unapplied cash: money received and recorded but not matched to any invoice, often a lump payment or a short-pay with no remittance. The cash is right; the AR aging isn't, and everything built on the aging waits on it.

Separating the two keeps the reconciler from spending the morning re-explaining deposits in transit that will clear on Tuesday.

Cutting the round trips

The fixes are mostly about timing and ownership, not new software:

• Apply cash daily during the month. Most exceptions are easier to resolve the day they happen, while the remittance email is still in someone's inbox. Then month-end only covers the last few days.
• Reconcile the bank weekly. A weekly match turns one large month-end pile into four small ones, and the exceptions surface while they're still fresh.
• Define "AR is closed" as a check, not a feeling. For example: billing complete through the last shipment date, no unapplied cash older than a set number of days without a note, and the AR subledger tied to the general ledger. When the checks pass, people downstream can start.
• Keep one shared exceptions log. One list, one owner per item, instead of a chain of emails.

What a shared exceptions log looks like

It can be a plain spreadsheet. Every unmatched bank item gets a row, an owner (AR, AP or GL) and a status, so nobody has to ask who has what.

Below it, a summary by owner, calculated from the rows rather than typed:

The useful check is the last line. The total of open items should equal the unexplained difference on the bank reconciliation. If it does, every difference has an owner. If it doesn't, something unmatched isn't on the log yet. Either way, AR and AP can see their own open items without waiting to be told.

How long should the close take?

There's no single right number. It depends on the number of entities, transaction volume, how much is reconciled during the month, and what the close has to produce. A more useful question is how much of the first few days is spent waiting. If the team can't start most of its work until AR and the bank rec have gone back and forth two or three times, that's the time to go after first.

It's also why the order of the close matters more than its length. Work that doesn't depend on revenue or cash, like prepaid and fixed asset schedules, payroll accruals and most balance sheet reconciliations, can start on day one while the AR side settles. For working out what can start when, see what can I flux right now?, which tracks those dependencies.

Most of this surfaces again at flux review. The free flux template flags which balances moved enough to explain. The CloseOps Flux & Variance System ($79) starts from your trial balance instead: confirm each account's classification and it builds the income statement and balance sheet flux statements, then ranks what to investigate.

Related: month-end flux, start to finish, late entries after commentary is written, and what happens when the fix has to wait until next month.

Found something wrong or missing? Tell me here — anonymous, thirty seconds.