Core Close Activities: Part 1

2026-08-22

I started this topic wanting more than a checklist. This first part covers the ground I needed before any of the individual activities made sense, and then walks through the first three items on the actual close checklist: close calendar and ownership, cut-off procedures, and accruals.

Continuous business, periodic reporting

A business doesn't pause at month-end. Transactions keep happening, a sale on the 28th, a delivery on the 30th, while reporting demands a hard boundary: here is where July ends and August begins. Close is the machinery that forces a continuous stream of activity into that artificial boundary.

The clearest way I found to see this was a delivery-timing question. If goods are delivered on 28 July but the invoice for them isn't raised until 3 August, and payment doesn't land until 10 August, which month does the revenue belong to?

Reversing an estimate versus reclassifying it

Say a company accrues ₹100 for something in July, and the actual invoice that arrives in August turns out to be ₹110. There are two equally valid ways to close that gap:

• Reversal, then re-book. At the start of August: debit Revenue ₹100 / credit Accrued Income ₹100 (undo the estimate completely). Then process the real invoice normally: debit Receivable ₹110 / credit Revenue ₹110. Net effect on August's revenue: +₹10, correct, since the ₹100 was already recognised in July.
• Direct reclass, one entry. Debit Receivable ₹110 / credit Accrued Income ₹100 / credit Revenue ₹10. Same net effect, one entry instead of two.

Both are arithmetically correct. Companies tend to prefer the reversal method not because reclass is wrong, but because most ERP systems can automate a reversal, the day the new period opens, the system flips the entry without anyone having to remember which accrual belongs to which eventual invoice. That automation is a control against forgotten accruals, not a statement that reclass entries are improper.

Automatic, calendar-triggered reversal isn't universal practice, though, and it isn't the only correct way to run this. My own organisation reverses accruals manually, triggered by the invoice actually arriving rather than by the calendar, because some invoices take up to three months to show up, reversing an estimate every month regardless, only to immediately re-book the same estimate again, is redundant work for no benefit. Auto-reversal suits short-cycle accruals where next month's invoice is a safe bet; manual, invoice-triggered reversal suits longer, less predictable cycles. Both are the same underlying idea, reverse the estimate once the real number shows up, with a different trigger.

RTR is bigger than close

RTR splits cleanly into two halves. Record is the continuous, daily side, a vendor invoice posted on an ordinary Tuesday, with no calendar boundary attached to it. Report is the periodic side, triggered by period-end, and this is where close lives. Close isn't the whole of RTR; it's only the second half.

That split has a sharper edge than it first looks. A transaction that arrives late doesn't automatically become a "close" activity just because it's late. Take a travel expense claim for a 25 July trip that an accounts team doesn't get around to posting until 2 August. If someone realises, before books close, that this claim is pending and books an estimate for it, that's still fundamentally a Record activity, it just moved slowly, and its lateness was caught and estimated around. But if nobody realises it's pending, and no estimate is made, July closes with that expense simply missing. That's a cut-off error: not a naming problem, but a case where close's basic purpose, an accurate snapshot of the period, has actually failed.

The sequence is a dependency chain, not a checklist order

The published close lifecycle, pre-close, cut-off, accruals/adjustments, reconciliations, review, reporting, post-close, looks like an arbitrary order until you break it on purpose and watch what happens.

Reconciliation before adjustment. Take a prepaid insurance policy: ₹1,20,000 paid up front for the year, amortised at ₹10,000 a month through an adjustment entry. If reconciliation runs before that month's adjustment is posted, the GL still carries last month's higher balance while the supporting schedule already reflects the new, lower expected balance. The two won't match, not because anything is wrong, but because one step ran out of order. The team either wastes time investigating a "missing entry" that isn't missing, or has to redo the reconciliation once the adjustment finally posts. Nothing was actually broken; the work was simply duplicated.

Review before reconciliation. Suppose Accounts Payable shows ₹5,00,000 this month, against ₹4,80,000 last month and a ₹5,10,000 budget. A manager reviewing that trend would reasonably sign off, it looks sensible. But review is a reasonableness check, not a tie-out check; it can't see a vendor invoice that was posted twice, inflating the real liability from ₹4,50,000 to a reported ₹5,00,000. Reconciliation against the vendor's own statement is what catches that, and once it does, the earlier sign-off is void, not because the manager was careless, but because reasonableness and source-document accuracy answer two different questions, and one can't substitute for the other.

The shape underneath both examples: each step in the sequence produces something the next step depends on as an input. Skip that dependency, and the next step either produces a false alarm or signs off on something it never actually verified.

"Ready to report" is three claims, not one

It's tempting to describe a closed set of books as simply "accurate" or "authentic." That's too loose. Two statements can both be built from entirely real, unfabricated transactions and still both be wrong in different ways:

• A statement where a real June sale gets booked in July, a cut-off failure.
• A statement where a real expense is simply never accrued at all, a completeness failure.

Add the AP double-posting case from above, a real transaction, correctly timed, but posted for the wrong amount, and that's an accuracy failure.

"Ready to report" turns out to be a compound claim across all three: everything that belongs in the period is there (completeness), every amount is right (accuracy), and everything sits in the correct period (cut-off). Reconciliation is largely what verifies completeness and accuracy against source documents; review is a reasonableness layer on top of that, and as the AP case shows, review alone can't carry that weight by itself.

With that scaffolding in place, here's where the actual fourteen-item checklist starts. This part covers the first three.

The calendar and the close window

A close calendar takes the dependency sequence above and pins real dates to it, inside a fixed window, the gap between period-end and the day financials are actually reported. Two companies can run the identical sequence and still close in very different amounts of time: one in three business days, another in ten. Watching how the fast one manages it comes down to three levers, not to working harder:

1. Pre-close whatever is already predictable. Prepaid insurance amortising at a fixed ₹10,000 a month has no gap between estimate and actual, the number was locked in the day the policy was signed. There's no reason to wait for period-end to book it; it can be finalised days early.
2. Estimate now, true-up later, for late-but-predictable variable costs. An electricity bill that's run ₹85,000, ₹92,000, and ₹93,000 over the last three months can be estimated at the ₹90,000 average and booked on day one of close, rather than waiting for the actual bill (which might not land until the 5th). Whatever the true bill turns out to be, say ₹94,000, the ₹4,000 gap gets absorbed into next month's close, not this one.
3. Set a materiality threshold for small variances. A ₹500 mismatch doesn't need to hold up a close; it can be flagged and cleaned up next cycle. Chasing every rupee is what makes a ten-day close a ten-day close.

None of these levers touch completeness or cut-off, the fast close isn't cutting corners on what belongs in the period, only on how precisely small, low-risk numbers get pinned down before something more certain (the real invoice) arrives.

Ownership: names, priority, and evidence

A calendar says when. It says nothing about who, and that gap is where things quietly fail. Compare a reconciliation task assigned to "the AP team," five people, no name attached, against the same task assigned to one named person. Both hit an unexplained ₹25,000 gap on day three.

A name alone isn't sufficient either. If that same named person is juggling eight other tasks with no indication of which one matters most this week, the reconciliation can still slip, not from confusion about ownership, but from competing priorities nobody ranked. The fix isn't daily check-ins; it's a single upfront statement, this task is priority one this cycle, ahead of the other eight, so the owner can self-manage the rest of the week.

Ownership also extends past doing the task into proving it was done properly. A reconciliation that comes back as a verbal "it matches" gives the reviewing manager only two bad options: trust it blindly, or redo it from scratch, both of which defeat the point of having an owner at all. A reconciliation worth reviewing quickly comes with four things attached: the tie-out document itself, a reference to the actual source document used (a vendor statement, dated), the preparer's own sign-off and date (the maker-checker principle, the person who built it isn't the only one who checks it), and a one-line trend comparison against the prior period. A ₹5,00,000 AP balance, tied to a matching ₹5,00,000 vendor statement, signed "3 August," with last month's ₹4,80,000 alongside it for context, is something a manager can actually review in two minutes rather than having to take on faith.

Escalation: from awareness to a slipped date

Ownership eventually runs into the case where the named owner still misses the deadline, illness, competing fires, or simple underestimation. Escalation is the mechanism for what happens next, and it works best when it doesn't depend on anyone happening to notice.

Practically, that means status tracking tied to the calendar itself, a task marked Not Started, In Progress, or Complete against a due date and time, with an automatic alert firing the moment that time passes without completion, rather than waiting for a manager to remember to check. From there, response scales in tiers: simple awareness first, then reallocating help if that's useful, then reassigning the task outright, and only as a last resort, sliding the whole reporting date, rare, and expensive.

Which tier actually helps depends on why the deadline was missed. If the cause is internal, the owner is behind, or made an error, adding help can genuinely speed things up. If the cause is external, waiting on a vendor statement that simply hasn't arrived, adding people does nothing, because the bottleneck isn't headcount.

Only once that active chase genuinely fails, and the reporting date itself arrives with the gap still open, does materiality become the right next question, is the unresolved amount (say ₹40,000, against a ₹5,00,000 threshold) small enough to report as-is and correct in a post-close adjustment, or large enough that the reporting date itself needs to move? The shift from day three to day six isn't just "less time, so hurry," it's a genuine change in mode, from solving the problem to managing around it once solving is no longer possible.

Cut-off as enforcement, not just a rule

Knowing the rule, recognise revenue when the substantive event happens, not when the invoice is raised, isn't the same as enforcing it. An accounting team never witnesses the event itself; it relies on whichever document was created by someone who actually saw it happen, at the time it happened.

Take a company selling on FOB Shipping Point terms, where ownership transfers the moment goods leave the seller's warehouse (as opposed to FOB Destination, where it transfers only on arrival at the customer). A truck leaves the gate at 11:50 PM on 31 July, logged by the security guard in the gate register. The system-generated invoice for that same shipment isn't created until 12:20 AM on 1 August, thirty minutes later, but the next calendar day. The revenue still belongs to 31 July, and the gate register, not the invoice timestamp, is the authoritative record, because it was made by the person who was actually there when the goods left, at the moment they left. A verbal recollection of the same event the next day, with no timestamped record behind it, isn't sufficient evidence on its own: if it isn't documented, it effectively didn't happen for cut-off purposes.

Every transaction stream has its own trigger

The same logic, find the document closest to the real event, made by whoever witnessed it, plays out differently depending on what's actually moving.

Purchases mirror sales in reverse. Goods arriving in the warehouse on 31 July, logged in the receiving register, get booked immediately even though the vendor's invoice doesn't turn up until 2 August: debit Inventory / credit GR/IR Clearing on the 31st, then debit GR/IR Clearing / credit Accounts Payable once the invoice lands. GR/IR Clearing (sometimes called an accrued liability) is the exact mirror of accrued income, the goods-received note plays the role the gate register played for sales.

Cash and bank work on a different mechanism entirely, because two genuinely independent records exist, the company's own cash book and the bank's own statement, with a natural lag between them from ordinary banking mechanics, not error. A cheque issued to a vendor is deducted from the cash book the moment it's written, but the bank won't reflect that until the vendor deposits it and it clears; in the interim, the cash book understates what's actually still sitting at the bank. A cheque received works the other way, with the cash book overstating the position until the deposit clears. In a case where the cash book showed ₹8,00,000 and the bank statement showed ₹8,50,000 on 31 July, the gap traced to a ₹50,000 cheque issued 29 July but not yet presented, the number that belongs on the financial statements is ₹8,50,000, because that's what's physically at the bank on the reporting date. The cash book figure reflects a commitment already made, not a present fact; the bank reconciliation statement exists purely to document that the gap is timing, not error.

Physical inventory counts raise a different risk altogether, because a count isn't a single timestamped event, it's a snapshot, taken while the warehouse may still be moving. If dispatch and receiving don't stop for the count, the same item can end up recorded on both sides at once. In one case, a count starting at 6:00 PM came with a rule that no further dispatch would happen until counting finished, but a truck whose loading had wrapped up at 5:40 PM didn't actually clear the gate until 6:10 PM, ten minutes into the freeze. The counting team, reaching that loading bay at 6:02 PM, quite reasonably counted those goods as on-hand, since they were still physically inside. But the dispatch itself, recognised at the moment the truck left the gate (per the company's own rule), still fell on 31 July. The result: that shipment shows up both as inventory on hand and as a recognised sale, reported stock comes out higher than what's physically true, because the same goods are effectively counted twice. The standard fix is a genuine operational freeze, stopping dispatch and receiving entirely for the duration of the count, rather than a freeze that exists on paper but still allows a truck to roll ten minutes late.

Cut-off memos: communicating the exception

The underlying rule can stay stable for years, a midnight dispatch cut-off, say, right up until a specific period needs an exception, such as auditors requesting a 6 PM freeze the evening before a physical count. The risk here isn't that anyone disagreed with the exception; it's that the people who decided on it (finance) and the people who have to execute it (the warehouse) are different people, and the decision doesn't automatically reach the second group. A dispatch at 9 PM that evening would be entirely correct by the warehouse's own, unchanged understanding of the rule, and still break the agreed exception nobody told them about.

The practical fix is a short, standardised memo, date, the normal rule, today's exception, and how long it holds, paired with an explicit confirmation from the receiving side, not just a one-way notice. In a scenario where a memo went out at 10 AM with confirmation expected by noon, and noon passed with no reply, a follow-up call at 12:15 PM turned up that the intended recipient was on leave and a junior colleague hadn't seen the email at all. Without that follow-up, the exception would have quietly failed and the normal-rule dispatch would have gone ahead regardless, sending the memo isn't the same as confirming it landed.

Cut-off testing (where this left off)

Cut-off testing applies the same authoritative-document logic retroactively, after close, to check whether it actually held. An invoice dated 30 July with revenue booked in July, whose underlying gate register shows the truck didn't actually leave until 2 August, means that revenue genuinely belongs in August, its presence in July overstates July and understates August by the same amount.

I left this thread mid-way: I hadn't yet worked through whether finding that same pattern across ten separate invoices, all from the last two days of July with gate registers dated in early August, should be read any differently from a single isolated case, and hadn't started on cut-off manipulation risk more broadly, the reason auditors pay particular attention to this area. Both remain open for the next part.

Trigger documents when there's no physical goods movement

Where a GRN plays the anchor role for goods, services need their own equivalent, since there's no warehouse gate to log against. An IT consultant finishing a small project on 29 July, with the company's own IT manager confirming completion by email that same day, has an invoice that doesn't arrive until 6 August. The IT manager's email, not the consultant's own invoice, is the authoritative document, for the same reason the gate register was authoritative for goods: it was created by someone who personally verified the event, at the time it happened. In a more mature system this typically takes the form of a formal Service Entry Sheet rather than an email thread, but the underlying logic doesn't change.

The completeness problem: catching what nobody remembered

A recurring service accrual is easy to get right once someone remembers it's due. An annual maintenance contract, ₹12,00,000 a year, invoiced quarterly at ₹3,00,000 but delivered continuously every month, needs a ₹1,00,000 accrual in the two months between invoices, even though nothing about the contract changes month to month.

The harder question isn't calculating a known recurring accrual, it's catching the one nobody remembered to add in the first place. An accrual register, a master tracker of what's accruing, how the amount was derived, what document supports it, and when it reverses, solves the problem of remembering what's already on the list, but by definition can't surface something that was never entered. A small illustrative version, built around this discussion, looked like this:

The genuine completeness risk sits outside this table, a new contract, signed mid-quarter, that never made it into the register at all. Catching that needs a source entirely independent of the register itself: a Legal or Procurement contract log, or an open purchase-order report, compiled for reasons that have nothing to do with accounting. A new security-agency contract with a purchase order raised at signing would show up on an open-PO report regardless of whether anyone remembered to log an accrual for it. But that, too, has a blind spot: services in particular are often engaged verbally, with no purchase order raised at all, precisely because there's no physical checkpoint, no warehouse gate, forcing the paperwork the way there is for goods. A control can only see what actually feeds it; an engagement that never entered the procurement system is invisible to any report built from that system.

The last line of defence is a completeness certification, a named department head explicitly signing off that every pending obligation from their area is reflected in the register. It's accountability-based rather than system-based, and it, too, can fail if the signer isn't diligent. Taken together, a register, an independent contract log, and a certification each reduce the risk of a missed accrual, but none of them, even stacked together, eliminates it entirely. That's the same conclusion the "ready to report" discussion pointed toward from the start: completeness is reasonable assurance, never an absolute guarantee.

Building the number: three estimation methods

A new digital marketing contract, signed 15 July on a time-and-material basis at ₹2,000 an hour, with no invoice yet and no history with this vendor to average against, forces the question of what number actually goes into an accrual when even historical averaging isn't available. The vendor's own proposal quoted a typical range of ₹1,50,000 to ₹2,00,000 a month.

That gives three distinct methods, each suited to a different situation:

A judgement-based range guess is the fallback, used only when none of the three structured approaches are available.

Reviewing an accrual: trend, not tie-out

Reviewing a reconciliation works by tying a GL balance to an external document. An accrual, by definition, has no such document yet, if it did, it wouldn't be an accrual, so that kind of review simply doesn't apply here. What replaces it is a comparison across time: how has this specific accrual line's estimate tracked against its own actual, month after month?

Random variance either way is ordinary estimation noise. A variance that runs the same direction, month after month, points to something wrong with the method itself. The electricity accrual made this concrete:

Cut-off procedures still has an open thread, what a repeated pattern of near-miss invoices should mean, and cut-off manipulation risk more broadly, and eleven more items remain untouched: prepaids, fixed assets, payroll, tax balances, revenue and expenses, inventory, debt and equity, intercompany, FX, journal entries, and post-close adjustments. That's Part 2.