The month-end close, in order

A close is a sequence, not a list

Most published month-end checklists are lists of things that ought to be true by the end. Reconcile the bank. Post accruals. Review the flash results. Each item is correct in isolation and useless as guidance, because the difficulty of a close is almost never in knowing what to do. It is in the order, in who is allowed to still be posting while you do it, and in what happens when step nine sends you back to step three.

The reason order matters is that every step consumes the output of an earlier one and can invalidate it. Revaluing foreign currency balances before the subledgers are closed revalues the wrong balances. Reconciling the bank while the cashier is still posting receipts for the period gives you a reconciliation that is stale before you save it. Running the depreciation charge before the fixed asset additions for the month have been capitalised understates the charge, and the difference will not be visible anywhere except in a schedule nobody rereads.

The sequence below is written as a working order rather than an exhaustive list. Not every business has intercompany balances or foreign currency, and a single-entity retailer will move through it in a day. But the dependencies are the same at every scale: transactions stop, subsidiary systems close, subledgers agree to the ledger, judgemental entries go in, the result is reviewed against something, and only then does the period lock. Skipping the order is what produces the close that takes eleven working days and still gets reopened.

One structural point before the detail. A close is a control process, not a data entry exercise. Its purpose is to give a defined group of people confidence that a specific set of numbers, as at a specific date, is complete and supportable. Everything in it should be traceable to that purpose. A step that nobody can explain the purpose of has usually survived from a previous system, and it is costing you days.

Step one: cut-off, and stopping the period

Cut-off is the determination of which period a transaction belongs to. It sounds procedural and it is the single highest-value control in the close, because a cut-off error moves profit between periods without breaking anything. The trial balance still balances. The bank still reconciles. Nothing flags. The only thing that has happened is that this month made more money than it earned and next month will make less.

The classic cases are all timing gaps between a physical event and a document. Goods are received on the twenty-ninth and the supplier invoice arrives on the fourth of the following month; if nothing is accrued, the cost lands in the wrong period while the stock lands in the right one. A shipment leaves on the last day of the month and is invoiced two days later; revenue and cost of sales separate. A service is delivered across the month boundary and billed once, in arrears. In each case the question is the same: when did control transfer, or when was the service performed? The invoice date is evidence of that, not a substitute for it.

Practically, cut-off is enforced by three things. First, a stated posting deadline per source: sales stop entering orders for the period at a known time, goods receipts are entered same-day, expense claims are submitted by a date. Second, a review of the documents that straddle the boundary, which in most businesses means the last few days of goods received notes, delivery notes and dispatch records, matched against what was invoiced. Third, a system that will refuse a back-dated posting once the period is closed rather than silently accepting it.

The last of those is worth stating plainly, because it is where most systems disappoint. If a user can post a journal dated the thirty-first of last month at any point in the following six months, then no close is ever final and every comparative you publish can change after the fact. Period locking is not an administrative nicety. It is the mechanism that makes a closed period mean something.

Step two: close the feeder systems before the ledger

The general ledger is downstream of everything else. Sales, purchasing, inventory, payroll, fixed assets, expenses and cash all originate transactions elsewhere and hand a summary or a set of postings to the ledger. Closing the ledger before those sources have stopped producing is the most common structural error in a slow close, because it guarantees rework.

The order within this step follows the flow of goods and money. Purchasing and goods receipt close first, because inventory valuation depends on them. Inventory and any production or assembly activity close next, so that cost of sales for the period is complete. Sales and dispatch close alongside. Cash and card settlement close after sales, since receipts reference invoices. Payroll usually runs to its own calendar and closes independently, but its journal has to be in before the ledger is considered complete. Fixed assets close last of the subsidiary registers, because additions come from purchasing and disposals sometimes come from sales.

A short note on the depreciation charge, because it is regularly run too early. If depreciation is calculated before the month additions are capitalised, the additions get no charge in their first month and the schedule quietly disagrees with the ledger from then on. Run it after the register is complete, and treat re-running it as normal if a late addition appears.

• Purchasing and goods receipt: all receipts entered, all supplier invoices matched or flagged as unmatched for accrual.
• Inventory: movements posted, any stock count adjustments recorded, valuation run on the agreed basis for the period.
• Sales and dispatch: all deliveries invoiced or held deliberately, credit notes for the period issued rather than deferred.
• Cash, card and payment gateway: receipts and settlements posted, unallocated cash identified rather than left sitting.
• Payroll: the payroll journal posted, including employer costs, statutory deductions and any accrued but unpaid amounts.
• Expenses: claims submitted, approved and posted, with a stated treatment for anything unsubmitted at the deadline.
• Fixed assets: additions capitalised, disposals recorded, the depreciation charge run after both.

Step three: accruals and prepayments

Accruals and prepayments exist because cash movement and economic activity do not share a calendar. An accrual records a cost that has been incurred but not yet invoiced. A prepayment removes from this period a cost already paid that belongs to later ones. Both are estimates in the general case, and both are reversed or released against the eventual invoice.

The discipline that separates a reliable close from a guessed one is that every accrual has a stated basis and a stated release. The basis is why the amount is what it is: a contract rate multiplied by days, a purchase order value less what has been invoiced, a usage report from the supplier portal, last month plus a known increase. The release is how it will unwind: automatically reversed on the first of the next month, or held and specifically matched against the invoice when it arrives. Accruals without a stated release are how a balance sheet accumulates a decade of small credits that nobody dares remove.

Two categories deserve particular attention. Goods received not invoiced is usually the largest accrual in a business that holds stock, and it should be derived from the system rather than estimated: the value of receipts with no matched supplier invoice, at the receipt value. If that figure has to be assembled by hand, the matching process upstream is broken. Utilities, professional fees and anything billed in arrears are the second category, and these are the ones that drift, because each month is estimated from the previous estimate rather than from an actual bill.

Prepayments are simpler and go wrong differently. Annual insurance, software subscriptions, rent paid in advance and licence fees all need a schedule that states the total, the period covered, the monthly release and the remaining balance. If the schedule exists as a spreadsheet that one person maintains, the risk is not that it is wrong; it is that it stops when that person leaves. Prepayment schedules belong in the system that produces the balance they support.

Step four: bank reconciliation

A bank reconciliation compares the ledger balance for a bank account with the balance the bank reports, and explains every difference. That is the whole of it, but the definition contains a demand that is frequently ignored: every difference has to be explained, individually, by an item that will clear. A reconciliation with a residual difference described as timing, or worse, plugged, is not a reconciliation.

The legitimate reconciling items are few. Payments issued and recorded that the bank has not yet processed. Receipts recorded that have not yet cleared. Bank charges, interest and returned items that the bank has processed and you have not yet recorded, which should be posted rather than left as reconciling items. Direct debits and standing orders that hit the account without a document. Anything else on the list is a symptom.

Automated bank feeds and statement matching have made the mechanical part of this fast, and that has created a new failure. Auto-matching on amount alone will happily pair an unrelated receipt with an unrelated payment of the same value, and the reconciliation will show as complete. Matching should use date, amount and reference, and anything matched on amount alone should be visible as such. The reconciliation is only as good as the rule that produced it.

Cash accounts other than the bank need the same treatment. Petty cash, tills, card settlement suspense and payment gateway balances are all cash-equivalent accounts that hold real money and can hold real errors. A gateway account in particular should be reconciled to the gateway statement, because the difference between what a customer paid and what was settled to the bank is fees, refunds and chargebacks, all of which are costs that arrive without an invoice.

• A reconciling item older than the normal clearing cycle is not a timing difference. It is an error or a stale entry, and it needs a decision.
• A payment on the statement that is not in the ledger at all is a completeness problem, and completeness problems in cash are the ones that matter most.
• A ledger entry with no bank counterpart, more than a cycle old, usually means a duplicate posting or a payment that failed and was never reversed.
• Round-number differences almost always come from a manual journal posted directly to the bank account rather than through the cash book.

Step five: subledgers to control accounts

Every subsidiary ledger has a single account in the general ledger that represents it. The receivables control account should equal the sum of unpaid customer invoices. The payables control account should equal the sum of unpaid supplier invoices. Inventory, fixed assets and, in most systems, VAT work the same way. Agreement between the two is not optional and it is not an accounting nicety; it is the check that the detail supporting a balance sheet line actually adds up to that line.

When the two disagree, the cause is almost always one of a small number of things, and knowing the list shortens the investigation considerably. Someone posted a manual journal directly to the control account, bypassing the subledger. A document was posted to the correct subledger but mapped to the wrong control account. A foreign currency balance was revalued in the ledger but not in the subledger, or the reverse. A transaction was posted in one period in the subledger and a different one in the ledger, which is a cut-off problem wearing a different hat. Or the subledger report is being run on a different date basis than the ledger enquiry, which is not an error at all and wastes an afternoon roughly once a year in every finance team.

The control worth having is not the reconciliation itself; it is the prohibition. Manual journals to control accounts should require a specific permission, and the small number of people who hold it should be posting only correcting entries that they have documented. Where a system allows any user with journal rights to post directly to receivables, the reconciliation is a detective control compensating for a missing preventive one, and it will fail on the month when nobody has time to run it.

Step six: intercompany

Where a group has more than one legal entity, balances between them must agree, in the sense that what entity A shows as owed by entity B must equal what entity B shows as owed to entity A. On consolidation these balances eliminate against each other, and any difference does not disappear. It lands somewhere in the consolidated result, usually in a line nobody wants to explain.

Intercompany differences arise from four recurring causes. Timing, where one side has posted and the other has not, which is genuine but must be aged and cleared rather than carried indefinitely. Currency, where the two entities have different functional currencies and each has translated the same transaction at a different rate, which is normal and produces a real difference that has to be recognised somewhere by policy rather than absorbed. Disagreement, where one side has raised a charge the other has not accepted, which is a commercial matter that has been allowed to become an accounting one. And plain error, where the amounts simply do not match.

The practical answer is a short intercompany calendar that runs before the main close: charges raised by an agreed date, statements exchanged, differences agreed or escalated, all before either entity finalises. Attempting to agree intercompany balances after both sides have closed means reopening at least one period, and a group that does this every month will eventually stop reopening and start absorbing the difference instead.

Intercompany also includes transactions in inventory. Where one entity sells stock to another and the buyer still holds it at the reporting date, the profit in that stock has not been earned by the group and is eliminated on consolidation. This requires knowing what the buying entity still holds and what margin was in it, which is a data requirement on the inventory system rather than a spreadsheet exercise, and it is the intercompany step that is most often skipped.

Step seven: foreign currency revaluation

Under IAS 21 an entity records foreign currency transactions in its functional currency at the rate on the transaction date. At each reporting date, monetary items denominated in a foreign currency are retranslated at the closing rate, while non-monetary items measured at historical cost are not retranslated. The gain or loss arising on retranslation of monetary items is generally recognised in profit or loss in the period in which it arises. The equivalent requirement exists in other frameworks; the mechanics described here are common to them.

The word doing the work in that paragraph is monetary. A foreign currency bank account, receivable, payable or loan is monetary and is revalued. Inventory held at cost, prepayments for goods or services, and fixed assets are not monetary and are not revalued, because their carrying amount is fixed in the currency in which the cost was incurred. Systems that revalue every account with a foreign currency flag produce a plausible-looking journal that is wrong, and the error is invisible unless somebody reads the account list on the revaluation.

Revaluation must run after the subledgers are closed and reconciled, for the obvious reason that it revalues what is there. It must also revalue the subledger and the ledger consistently; a revaluation posted only to the control account will break the reconciliation you completed in the previous step. And the rate used has to be documented: which source, at what time, on what date. Rate sources differ by fractions and those fractions become audit questions on large balances.

One further point that matters to anyone reporting in a currency other than the functional one. Translation for presentation is a separate operation from revaluation of monetary balances, and it uses different rates: closing rate for assets and liabilities, and rates approximating those at transaction dates for income and expenses. The difference goes to a separate component of equity rather than to profit or loss. Confusing the two produces a profit figure that moves with the exchange rate for no economic reason.

Step eight: suspense, clearing and the accounts nobody owns

Every ledger accumulates accounts that exist to hold something temporarily: suspense, unallocated cash, payroll clearing, goods received not invoiced, intercompany clearing, VAT clearing, payment gateway settlement, stock in transit. Each is legitimate. Each is also a place where an unresolved item can sit indefinitely while the trial balance continues to balance, which is precisely why they need reviewing every month rather than every year.

The rule that makes these accounts safe is that each one has a defined normal state and a named owner. Some should be nil at every period end, and any balance is an exception to be explained. Others carry a balance by design, and what matters is that the balance is made up of identifiable items of a plausible age. A goods received not invoiced account with a balance is normal. A goods received not invoiced account containing receipts from fourteen months ago is telling you that supplier invoices are not being matched, and the cost sitting in that account may never have been challenged.

A small procedural habit helps more than any system feature here: review these accounts by age, not by balance. A clearing account can show a small net balance made up of a large debit from two years ago and a large credit from last week. The net figure looks harmless and the composition is the problem.

• Suspense: should be nil at close. Any balance is an unposted decision, not a balance.
• Unallocated customer receipts: cash received but not matched to an invoice. Ages badly and inflates both receivables and cash-in-hand thinking.
• Goods received not invoiced: normal balance, but every item should be recent and traceable to an open receipt.
• Payroll clearing: should clear to nil once the payroll journal and the payment have both posted.
• Stock in transit: real, but each item should correspond to a shipment with a known arrival window.
• Gateway or card settlement: the difference between takings and bank settlement is fees, refunds and chargebacks, all of which should be posted rather than left.
• VAT or tax clearing: should agree to the return filed for the period, with any difference explained by timing that is documented.

Step nine: review before you believe the numbers

By this point the ledger is arithmetically complete. That is not the same as being right, and the review step exists to catch what reconciliation cannot: entries that are supportable, balanced and wrong. The technique is comparison. Compare this month against last month, against the same month last year, against budget, and against the operational reality that finance staff know independently.

Useful comparisons are specific rather than general. Gross margin by product group, not overall. Payroll cost against headcount. Cost of sales against units shipped. Utilities against a seasonal pattern. Bad debt provision against the actual ageing. Any line that has moved more than a set threshold since last month, with an explanation attached, and any line that has not moved at all when it should have, which is the harder one to spot. A rent charge that is identical for eleven months and then identical again after a rent review is a missing journal, and no variance report configured on percentage change will flag it.

The review should also test the balance sheet, not only the profit and loss, because balance sheet errors are what carry forward. Receivables days and payables days moving sharply, a deferred income balance that does not track the billing pattern, an accrual that is the same figure it was six months ago, a fixed asset register whose net book value is drifting from the ledger: these are the findings that prevent a restatement later.

Someone other than the preparer should perform this review, and their review should leave a record. That is not bureaucracy. If the only evidence that a close was reviewed is that the person who prepared it remembers reviewing it, then there is no review control, and the first material error will be found by the auditor rather than by you.

Step ten: lock the period

Locking is the act that turns a set of balances into a reported result. Before the lock, the numbers are a draft. After it, they are the numbers, and anything that changes them is an event with its own trail. A close that never locks produces figures that quietly disagree with what was reported last month, and it removes any possibility of relying on a comparative.

A usable locking mechanism has a few properties. It applies to all posting sources, not only to manual journals, because a back-dated goods receipt or a back-dated sales invoice changes the accounts just as effectively. It distinguishes soft close, where a small group can still post, from hard close, where nobody can. It records who unlocked a period, when, and why, and it makes reopening visible rather than routine. And it is enforced by the system rather than by an instruction, since an instruction is only as strong as the busiest week of the year.

Skyline Nexus holds fiscal periods that can be closed and locked, and records the closing, locking and reopening of a period as audit events carrying the user and the time. Coverage is worth checking rather than assuming, in any system: a lock enforced on manual journals and on purchasing, but not on the sales or point-of-sale path, still leaves the highest-volume posting route open, and a lock that is an opt-in setting does nothing until somebody turns it on. Ask your vendor which write paths the lock actually refuses, and test one. No software makes books correct. A lock only makes what was reported stay reported, and any change to it visible.

What should follow the lock is a short written record: the balances as reported, the reconciliations supporting them, the judgemental entries with their basis, the review evidence and any known open items carried into the following month. The last of these is the one most often left out and the one that saves the most time, because next month begins with the list of what was left unresolved rather than with rediscovering it.

Making the close faster without making it worse

Most attempts to shorten a close attack the wrong end. They compress the final days, which is where the work is visible, rather than the upstream behaviour, which is where the work is caused. A close is long because information arrives late, because reconciliation is deferred, and because the same exceptions are re-investigated every month.

The interventions that actually shorten it are unglamorous. Reconcile the bank daily or weekly so that month-end is a confirmation rather than an investigation. Match supplier invoices to receipts continuously rather than in a batch at close. Maintain recurring journals, prepayment schedules and depreciation as standing calculations rather than monthly reconstructions. Set and enforce submission deadlines for expenses and timesheets. Fix the mapping rule that causes the same misposting every month instead of correcting it every month.

A last word on ambition. A five-day close is a reasonable target for a business with clean upstream processes and a single reporting currency. A two-day close is achievable and usually requires continuous reconciliation and a genuine soft close discipline. Neither is worth having if it is achieved by estimating what used to be reconciled. The point of the close is confidence in the numbers, and speed that costs confidence has bought the wrong thing.

• Move reconciliation from month-end to continuous, particularly cash and supplier invoice matching.
• Give every recurring judgemental entry a standing schedule with a basis and an owner.
• Publish a close calendar with named owners and deadlines per step, and let it be visible to the people who feed it.
• Fix root causes of recurring exceptions instead of correcting the same posting each month.
• Separate the hard close from the reporting pack, so analysis is not on the critical path to locking.
• Track how long each step actually takes for three months before deciding which step to attack.