Month-End Close

Month-end close is the set of accounting tasks a company runs after a calendar month ends to turn raw transactions into a finished, trustworthy set of financial statements: reconciling subledgers, booking accruals and adjustments, eliminating intercompany activity, reviewing the result, and locking the period so nothing more can post to it without an explicit reopen. It is not one task — it is a checklist of dozens of smaller reconciliations and reviews, run in a specific order, where a single unresolved item (a bank reconciliation that won't balance, an intercompany elimination that leaves a currency delta, a phantom AP liability from a broken sync) can hold up every downstream step until someone finds and fixes it.

The close, in the order it actually runs

Close checklists vary by company, but the dependency order is close to universal, because each stage needs the one before it to be correct:

1. Lock subledger cutoffs — AP, AR, and payroll transactions for the period stop posting, so the reconciliations that follow are working against a fixed set of numbers.
2. Reconcile balance sheet accounts — bank accounts, AP and AR subledgers against the general ledger, prepaid and accrued schedules, and fixed assets all get tied out account by account.
3. Book accruals and adjustments — expenses incurred but not yet billed, revenue earned but not yet invoiced, and correcting entries for anything the reconciliation step surfaced.
4. Revalue and eliminate intercompany activity — for any company with more than one legal entity, intercompany balances are revalued at the current exchange rate and then eliminated so the consolidated financials don't double-count internal transactions.
5. Consolidate and review — subsidiary results roll up into a single consolidated set of financials, which a controller or CFO reviews for anything that doesn't match expectations.
6. Lock the period — accounting periods are closed to further posting, so a backdated edit can't silently unreconcile something that was already tied out.

Why the close takes as long as it does

Close duration is almost never limited by how fast someone can type a journal entry. It's limited by how long it takes to find and resolve the handful of items that don't reconcile cleanly. Three patterns account for most of the delay this cluster documents:

• Cross-system breaks that surface late — a phantom AP liability from a broken Bill.com-to-accounting sync, or an AR balance thrown off by a customer record that didn't sync, often isn't discovered until someone tries to reconcile the account at close, well after the transaction that caused it.
• Intercompany and currency complexity — every additional legal entity, and every additional currency, adds another elimination and another revaluation that has to happen in the right order before consolidation, and a currency delta that won't eliminate cleanly is one of the most common single points where a close stalls.
• Spreadsheet consolidation at a scale it wasn't built for — a workbook that consolidates three entities by hand works fine; the same approach at eight entities, multiple currencies, and dozens of intercompany relationships becomes a source of silent errors, because nothing forces the spreadsheet's formulas to stay correct as the business underneath it changes.

When a spreadsheet close becomes a risk, not a preference

There's no single entity count or transaction volume where a spreadsheet close definitively fails — but four thresholds reliably predict when the risk of a material, undetected error crosses from unlikely to expected:

Hitting two or more of the higher-risk columns is the practical signal to move consolidation and elimination logic out of a general-purpose spreadsheet and into a system built to enforce the mapping — not because spreadsheets are inherently unsafe, but because nothing in a workbook stops a broken formula from producing a confident, wrong number.

Score your own close against these four signals with the close-cycle risk calculator.

A worked example: why a currency delta blocks elimination

Say a US parent company invoices its UK subsidiary $100,000 for shared services in a given month. On the parent's books, that's a $100,000 intercompany receivable. On the subsidiary's books, the same transaction is recorded in GBP at whatever exchange rate applied on the transaction date — say £79,000 at a rate of 0.79. At month end, before elimination can run, both entities' intercompany balances are revalued to the period-end exchange rate. If the rate has moved to 0.81 by period end, the subsidiary's £79,000 payable is now worth $97,531 when translated back to the parent's reporting currency, not $100,000. That $2,469 gap is the currency delta, and it has to be posted to a cumulative translation adjustment account before the intercompany elimination will net cleanly to zero. Skip that revaluation step, or get the exchange rate source wrong, and the elimination leaves a residual balance that a controller then has to chase down by hand — which is exactly the failure mode behind one of this cluster's diagnostic pages.

How a broken sync turns into a phantom liability

A phantom AP liability follows a predictable pattern: an AP automation tool like Bill.com records a bill and pays it, that payment syncs to the accounting system as a bill payment, but a sync failure — an expired connection, a mapping change, a duplicate record — means the accounting system never receives the corresponding payment record, only the original bill. The bill then sits open in AP, showing a liability the company no longer actually owes, because the payment happened but the record of it never arrived. This is invisible day to day, because nothing about the vendor relationship changes and no one reconciles every open bill in real time. It surfaces specifically at close, when someone reconciling the AP subledger against the bank statement finds a payment on the bank side with no matching open item on the AP side, or an AP balance that's stubbornly higher than it should be. Catching this requires reconciling the AP aging against actual bank disbursements at least monthly, not just trusting that a sync marked "connected" is actually current.

What a close calendar actually looks like

A typical five-business-day close for a multi-entity company runs roughly like this: business day 1 locks subledger cutoffs and starts bank and subledger reconciliations; day 2 finishes those reconciliations and books routine accruals; day 3 runs currency revaluation and intercompany elimination, which is also where a currency delta or a cross-system break most often surfaces and has to be chased down before the calendar can continue; day 4 consolidates the entities and the controller or CFO reviews the result against expectations; day 5 books any final adjustments the review surfaces and locks the period. Every day this calendar slips almost always traces back to day 3 — elimination and revaluation are where the close's dependencies are tightest, because consolidation on day 4 cannot start until every entity's intercompany activity nets to zero.

The metrics that show whether close is actually under control

• Days to close — calendar days from period end to a fully reviewed, locked set of financials. Under 5 business days is common for companies at maturity level 3 or 4; 10 or more usually points to one of the three bottleneck patterns above.
• Reconciling items open at close — the count of unresolved differences across all balance sheet reconciliations on the day the period is locked. A healthy close has this at or near zero by design, not by exception.
• Manual journal entry count — a rising trend, month over month, at flat transaction volume is a leading indicator that something upstream (a sync, a mapping, a reconciliation) has started requiring manual correction that used to be automatic.
• Restatement or reopen frequency — how often a locked period has to be reopened after the fact. This is the metric that most directly measures whether "closed" actually means closed.

What a controller is actually checking during review

The consolidated review step is easy to describe as "looking over the numbers," which undersells what's actually happening. A controller reviewing a freshly consolidated close is checking, specifically: whether each account's month-over-month movement is explainable by something that actually happened in the business (a new hire, a large customer contract, a one-time expense) rather than an unexplained swing; whether every manual journal entry posted during the close has a documented reason attached to it, not just a number; whether the intercompany elimination actually nets to zero rather than leaving a residual the team decided to write off as immaterial; and whether anything in the period-close checklist was skipped under time pressure rather than genuinely completed. This is also the point where a close that looks done on paper but was rushed through an unresolved reconciliation gets caught — or doesn't, which is how an error survives into a locked, reported period.

Three ways teams actually run this process

Close mechanics get implemented in roughly three ways in practice. Spreadsheet-based consolidation, still the most common at smaller and simpler companies, keeps every entity's trial balance and every elimination formula in a shared workbook — flexible, but exactly as reliable as its formulas and the discipline of everyone touching it. Native ERP consolidation modules (NetSuite OneWorld's period close and elimination features are one example) build entity structure, intercompany relationships, and elimination logic directly into the system of record, trading some flexibility for consistency the spreadsheet can't guarantee. Dedicated close-management software sits on top of an ERP and adds task tracking, sign-offs, and an audit trail for the checklist itself, which addresses a different problem — not whether the numbers are right, but whether the process that produced them was actually followed and by whom. None of the three eliminates the need for the reconciliations this cluster documents; they only change how much of the mechanical work is enforced by the system versus trusted to the person running it.

Who owns each part of the close

Subledger reconciliations are typically owned by the team closest to that subledger — AP by the AP lead, AR by the AR lead, payroll by whoever runs payroll. Intercompany elimination and consolidation almost always sit with a controller, because they require visibility across every entity at once. The most common organizational failure this cluster's diagnostic pages describe isn't a missing owner for these core steps — it's a missing owner for the cross-system exceptions that don't cleanly belong to any one subledger, like a payment recorded in one system that never posted to the other. Naming an explicit owner for exactly that category of problem, before close week rather than during it, is one of the highest-leverage process changes available to a team that hasn't automated everything yet.

What's in this cluster

The pages below cover what month-end close is and how teams speed it up; the specific, sourced diagnostics for the breaks that most often stall a close — intercompany elimination, currency deltas, and cross-system phantom liabilities; and the practical checklist and period-lock questions that apply regardless of company size.

If your close is taking longer than it used to, start with the reconciling-items-open metric above and the diagnostic pages — they're the fastest way to find which specific step is the actual bottleneck, rather than guessing at the close process as a whole.