How a growing firm cut their month-end close in half by removing the manual layer

There is a particular exhaustion that settles over a finance team in the first week of every month. Not the productive kind of tiredness that follows a period of intense, meaningful work. The other kind. The kind that comes from doing the same thing again, in the same way, correcting the same errors, chasing the same information from the same people — knowing that in thirty days, you will be back here doing it again.

The finance team at this professional services firm knew that exhaustion well. They had been living inside it for the better part of two years.

Three people. Fourteen days. Every month, the finance team spent almost half the calendar managing a close process designed for a business that was only a third of its current size. The individual tasks were not particularly complicated. However, the team had to navigate dozens of manual steps that, while reasonable on their own, collectively created a process that took far longer than it should have.

The breaking point, when it came, arrived not from inside the finance function but from a conversation with their bank.

The firm had a revolving credit facility with a covenant attached requiring submission of monthly management accounts within twenty-one days of month end. For most of the relationship, this had been fine. Twenty-one days felt comfortable when the close was taking fourteen, because there were seven days of buffer between finishing the books and the submission deadline.

What the covenant didn’t account for – what nobody had explicitly modelled – was what happened when the close slipped. And closes slip. A key team member takes leave. A large client invoice comes in late and needs to be reclassified before the books can be finalised. A prepayment schedule that should have been updated wasn’t, and the error only surfaces during the final review. Within the NetSuite ERP environment, the fourteen-day close becomes a sixteen-day close. The seven-day buffer becomes a five-day buffer. Then a three-day buffer. Then, on a particularly difficult month, no buffer at all.

That month, the management accounts were submitted on day twenty-three.

The bank didn’t terminate the facility. But they did request a call. And on that call, they asked questions that a lender asks when they are no longer entirely comfortable with the financial visibility they have into a borrowing relationship. The conversation was professional. It was also a warning that the finance director took seriously.

The problem was not the two-day breach. The problem was that a finance function in a growing business had a close process fragile enough that a two-day breach was possible at all. The bank inadvertently identified an issue that the internal team already knew about but had not yet received permission to address properly.

That permission, after the call, was forthcoming.

When EcobSoft assessed the close process, it first mapped every task performed between day one and day fourteen of the close, assigned an owner to each task, and recorded how long each one actually took.

This exercise, in the experience of most finance teams that go through it, is simultaneously obvious and uncomfortable. Obvious because the output – a complete picture of what the close actually involves – is clearly useful. Uncomfortable because the output tends to make visible inefficiencies that everyone had been aware of in a vague way but had never quite confronted directly.

The map that emerged from the assessment contained sixty-three discrete tasks. Of those sixty-three, eleven were tasks that had to happen in a specific sequence and genuinely couldn’t begin until something else was complete. The remaining fifty-two were, in principle, parallelisable – or, in many cases, automatable.

Of the fifty-two, thirty-one were recurring manual journal entries.

Every single month, the same thirty-one journals were being created from scratch. Depreciation. Accruals across eight cost categories. Prepayment amortisation across eleven active prepayment schedules. Intercompany recharges. Payroll journals built manually from the payroll report. Each one created, reviewed, and posted by hand, every month, without variation.

The question that the assessment team asked – and that the finance director found surprisingly difficult to answer – was simple: why are these being created manually?

The answer, when it came, was the answer that almost always comes in this situation. The tasks remained manual simply because that’s how they had always been done. In many cases, the system was never originally configured to automate them. Elsewhere, someone had attempted automation, encountered issues, reverted to the manual process, and no one ever returned to resolve the underlying problem properly.

The system was capable of automating every single one of those thirty-one journals. It always had been. The manual process wasn’t a system limitation. It was an implementation gap that had hardened, over time, into habit.

Beyond the recurring journals, the assessment identified three other significant contributors to the fourteen-day close.

The intercompany reconciliation was being performed using exported data manipulated in Excel. Both entities operated in the same netsuite erp environment. The data needed for the reconciliation existed in the system. But the reconciliation itself was being done outside it, which meant that any differences identified required going back into the system, making the correction, re-exporting, and running the reconciliation again. A process that could have been minutes was consistently taking the better part of a day.

The team handled the bank reconciliation process in a similar way. Instead of using the automated bank feeds available in the system, they matched transactions manually. Although they had connected the bank feeds in the past, they never properly configured the matching rules. As a result, the feeds generated more noise than useful information, so the team quietly abandoned them and returned to manual matching. Once again, the issue did not stem from a system limitation. The team encountered a configuration problem and chose to work around it rather than fix it.

Finally, the close checklist – the document that tracked which tasks were complete, which were outstanding, and who was responsible for what – lived in a shared Word document. Not a task management tool. Not a workflow system. Three people edited the same Word document simultaneously, creating version conflicts. Each morning, someone opened the document only to discover that a colleague’s save had overwritten the updates they had made the previous afternoon.

No single one of these issues would have transformed the close on its own. Together, they were adding days.

The team structured the remediation work over six weeks and deliberately sequenced it to address the highest-impact items first.

Week one and two were dedicated entirely to the recurring journal automation in netsuite erp. Every repeating journal was reviewed, documented, and configured as an automated schedule inside NetSuite. Depreciation journals now run automatically based on the fixed asset register. NetSuite automatically runs prepayment amortisation based on the prepayment schedule maintained inside the system instead of a separate spreadsheet. The system fully automates fixed monthly accruals. For accruals that require variable inputs, the team set up templates that pre-populate the static elements and prompt preparers to enter only the variable figure.

Thirty-one monthly journal entries reduced to seven that require any human input at all. The other twenty-four happen without anyone needing to touch them.

Week three addressed the intercompany reconciliation. Because both entities were already in the same NetSuite ERP instance, the configuration work was relatively contained. Intercompany transactions are now flagged at the point of entry. The reconciliation report, which used to require an export, an Excel manipulation, and a comparison process, now runs in real time inside the system. Differences appear immediately, at the transaction level, with enough information to identify the source of the discrepancy without needing to dig through exported data.

The bank reconciliation work happened in parallel during week three and four. Bank feeds were reconnected, but this time the matching rules were configured properly before they went live – rules that matched on amount, date, and reference, with tolerance thresholds set to avoid the false positives that had caused the team to abandon the feeds the first time. The first week the new reconciliation process ran, it auto-matched 87% of transactions. By the end of the second month, after the rules had been refined based on observed patterns, that figure was 94%.

The close checklist was rebuilt inside netsuite erp task management functionality. Every task from the sixty-three-item list was entered, assigned to an owner, sequenced where dependencies existed, and connected to the relevant record or report inside the system. The finance director could see, at any point during the close, exactly which tasks were complete, which were in progress, and which were outstanding – without opening a Word document, without chasing anyone for a status update, without reconstructing the picture from three people’s inboxes.

The first close on the new process finished on day seven

Not fourteen days. Not the twelve that had been the optimistic target when the engagement began. Day seven.

The finance director described the experience as slightly disorienting. Not in a negative sense. In the sense that the team had been so conditioned to the close taking two weeks that finishing in one felt, initially, like something must have been missed. The first action on day eight was a review specifically designed to check whether anything had been skipped. Nothing had been. The close was simply done.

By the third month on the new process, the close was consistently finishing between day six and day eight. The variation came from external factors – late information from one department, a complex transaction requiring additional review – rather than from the internal process itself. The process had become reliable in a way it had never been before, which meant that when something did cause a delay, it was immediately identifiable and addressable rather than lost in the general noise of a fourteen-day scramble.

The bank covenant conversation happened six months after the engagement ended. Not because of another breach – there wasn’t one. The finance director proactively shared the new close timeline with their relationship manager as part of a routine update. The ability to submit management accounts by day eight, against a twenty-one-day covenant, was received as exactly the kind of operational improvement that lenders like to hear about. The conversation that had previously been a source of anxiety had become, quietly, a proof point.

Inside the finance team, the change that mattered most was harder to quantify but easy to observe.

The person who had been most consumed by the manual journal process – building the same thirty journals every month, for two years, on top of everything else her role required — had her time back. Not in a trivial sense. In the sense that a meaningful portion of her working month was now available for analysis, for business partnering, for the kind of financial thinking that the firm was actually paying for. She had been spending that time on data entry that a properly configured system could do in seconds. She was no longer spending it that way.

That is the cost that rarely appears in any business case for a process improvement project. Not the carrying cost of excess inventory or the revenue timing error on an audit report — numbers with a pound sign attached that make the problem legible to a board. The cost of a capable, experienced finance professional spending a significant fraction of their time doing something a machine could do better.

It is real. It is significant. It doesn’t show up on the balance sheet.

The month-end close is, in many ways, the heartbeat of a finance function. It is the rhythm around which everything else is organised. When that rhythm is slow and irregular – when the close takes two weeks and the team spends the first half of every month just trying to get back to a position from which they can do their actual jobs – the effects spread outward. Reporting is late. Teams compress analysis and make decisions using numbers that are older than they should be.

A fourteen-day close in a business of this size and complexity was not a finance problem. It was a process problem with a finance symptom. The three people running the close were not slow or underskilled. The system never supported the work they asked it to do, despite their hard work.

Six days, reliably, with the same three people, doing substantially less manual work. Not because the team changed. Because the process did. EcobSoft helps growing businesses redesign and automate their financial close inside NetSuite, so the team spends less time doing the close and more time using what it produces. If your month-end process is running longer than it should, the answer is usually not more people – it’s a better process.