How a business discovered its internal controls had never kept pace with its growth

There is a particular discomfort that comes from learning about a problem in your own business from someone who has been inside it for three weeks.

The external auditors had been on site for less than a month. They were thorough, professional, and entirely without malice. The partner leading the engagement had conducted herself with the kind of measured diplomacy that experienced auditors develop when they are about to say something a client does not want to hear. When the management letter arrived, it used careful wording. The auditors described the findings as observations. They presented the language around risk in a calibrated and proportionate way.

But underneath the careful language was a simple and uncomfortable fact. The business had a set of internal controls that existed on paper and a set of internal controls that existed in practice, and the gap between the two had been widening for approximately three years without anyone formally noticing.

The CFO read the letter twice. Then she forwarded it to no one, closed her laptop, and sat with it for the remainder of the afternoon.

A Business That Had Grown Faster Than Its Controls

The company designed and distributed specialist equipment to commercial clients. It had started as a lean operation – twelve people, a single product line, a finance function that was effectively one person with access to a cloud accounting system and a working knowledge of what needed to happen at month end.

Over five years, it had grown considerably. Headcount had passed eighty. The product range had expanded across four distinct categories. There were now two sites. The finance team had grown from one person to five, with responsibilities distributed across accounts payable, accounts receivable, payroll, and management reporting.

What had not grown at the same pace was the control architecture sitting underneath all of that activity.

In the early days, the controls were informal because they didn’t need to be anything else. When the founder approved every purchase order personally and reviewed every bank payment before it went out, the approval chain was short, visible, and reliable – not because of a documented process, but because of the practical reality of how a small business operates when its owner is present in every financial decision.

As the business scaled, it replaced personal oversight with structured processes. Leaders delegated approval authority, hired new staff, and granted financial system access as employees joined, but rarely reviewed those permissions afterward. The founder also stopped approving purchase orders after stepping away from day-to-day operational decisions. Someone else approved them. In principle, a different someone else processed the resulting invoices.

In practice, no one had ever formally configured that separation. Everyone had assumed it existed.

The auditors had not assumed it. They had tested it. And what the tests revealed was that the separation of duties the business believed it had was, in several material areas, not reflected in the system it was relying on to enforce it.

What the Tests Actually Found

The management letter identified three specific control weaknesses, each significant in its own right, that collectively showed the business had not reviewed or meaningfully updated its control environment since it was a fraction of its current size.

The first was purchase-to-pay. The business had a formal purchase order policy. Approvers had to approve orders above a defined threshold before anyone could make a commitment. Teams were supposed to match invoices with approved orders before releasing payment. On paper, this was a clean three-way process: order raised, order approved, invoice matched. In the system, the user permissions told a different story. Several members of the accounts payable team had access rights that allowed them to both raise purchase orders and post the resulting invoices to the ledger. The three-way process depended on those individuals not using both of those permissions in the same transaction. There was nothing in the system preventing them from doing so.

The second was journal entry. Any well-structured finance function maintains a separation between the person who posts an adjusting journal and the person who reviews and approves it. This is one of the most fundamental controls in financial reporting because it protects the ledger from both error and manipulation. In this business, three members of the finance team held unrestricted journal posting rights. The system did not enforce an approval workflow. Team members posted journals and closed the period without requiring a second pair of eyes to review or approve them.

The third was user access. The business had experienced meaningful staff turnover over the preceding two years. Several individuals who had left the business had had their system access deactivated promptly. Several had not. One former employee, who had left eleven months earlier, still had an active login credential in the accounting system. No one used it after they left. But it existed. And the business had not known it existed until the auditors checked.

None of these findings suggested that anything improper had occurred. The auditors were clear on that point. The findings were about the conditions that would have made impropriety possible, or that would have made an honest error difficult to detect. That distinction matters, but it matters less than it might appear to. A control weakness that has not yet produced a loss is still a control weakness. The absence of a known incident is not evidence that the controls are working.

The Assessment: Separating Design from Reality

The management team engaged EcobSoft after receiving the management letter. Rather than responding to the auditors’ findings in isolation, they asked EcobSoft to understand the full scope of the gap by mapping the intended control framework against the system’s actual configuration and identifying every area where the two did not align.

This kind of assessment is more demanding than it might appear. A control framework exists in documents – policies, procedures, delegated authority matrices, role descriptions. A system configuration exists in permissions, workflows, access groups, and approval chains. To compare the two, you must work through both in parallel, follow the actual path a transaction takes from initiation to posting, and test at each step whether the system enforces the control the framework describes or whether it simply relies on the person operating it to observe the control.

What the assessment found confirmed the auditors’ observations and extended them.

The purchase-to-pay separation issue was more widespread than the management letter had indicated. It was not limited to accounts payable staff. Several users in operational roles had retained access rights granted to them during a period when the system was first implemented and the team was small enough that broad access had seemed practical. Three years later, those access rights had never been narrowed. People who had no current reason to post invoices retained the technical ability to do so, highlighting the need for netsuite support.

The delegated authority matrix, which the business had documented clearly and reviewed the previous year, bore limited relationship to the approval thresholds configured in the system. The policy said that capital expenditure above a certain value required CFO approval. The system had no approval workflow configured for capital expenditure at all. The system routed a purchase order for capital items to the approver assigned to that cost centre, regardless of its value.

The IT manager manually conducted the access review process only when prompted, without ongoing NetSuite support. The team did not schedule or document the process, nor did they formally link it to the off-boarding process. The inactive login that the auditors had identified was not an oversight by any individual – it was the predictable output of a process that had no systematic mechanism for catching it.

The assessment revealed a control environment that the business had originally designed for a smaller, simpler operation. Instead of redesigning it as the business grew, the company simply added to it. Each phase of growth brought new access permissions to meet emerging needs, but the business rarely removed outdated access or restructured existing controls.

The Remediation: Building Controls Into the System

The remediation programme operated on the principle that a control which relies on an individual choosing to behave in a particular way is not a control in any meaningful sense. It is a policy. Policies matter, but policies fail, making netsuite support essential. People forget, people are under pressure, people make pragmatic decisions in the moment that circumvent an intention they haven’t internalised. A system-level control that cannot be bypassed does not depend on any of those variables.

The organization enforced segregation of duties at the role configuration level. It restructured the accounts payable function into two distinct system roles: one that allowed users to raise and submit purchase orders, and another that allowed users to post and approve invoices. The organization assigned each user only one of these roles. The configuration made it technically impossible for a single individual to initiate and complete a purchase-to-pay transaction without a second user’s involvement. This was not a new policy. It was an old policy, finally reflected in the system that was supposed to be enforcing it.

The finance team configured the journal approval workflow for the first time. The system now requires a second user to review and approve any journal entry above the defined materiality threshold before posting it to the ledger. Authorised finance staff can still post journals below that threshold, while the system automatically generates a complete log and includes it in a weekly review report for the financial controller. The period-end close process now includes a mandatory sign-off step that users cannot skip.

The company replaced manual access reviews with a scheduled NetSuite support report. Each quarter, the system generated a list of active users, including last login date, role assignments, and employment status. The report was automatically sent to the CFO and IT manager for review and approval. The company also updated its off-boarding process. Finance now had to confirm system access was removed within 24 hours of an employee leaving, rather than relying only on the IT manager.

The capital expenditure approval gap was closed by configuring a value-based routing rule in the purchase order workflow. Orders at or above the threshold defined in the delegated authority matrix now routed automatically to the CFO for approval, regardless of cost centre. The policy and the system finally said the same thing.

Twelve months after the management letter, the same auditing firm returned for the following year’s engagement. Their controls testing found no material weaknesses. The observations from the prior year letter were each closed with evidence of remediation. The audit opinion was clean.

The CFO described the outcome not with satisfaction but with a kind of retrospective unease. The controls that had been put in place were not sophisticated. They were not novel. They were the standard, expected architecture of a finance function operating at the scale this business had been operating at for several years. The question she returned to, in the months that followed, was not how to feel good about having fixed the problem. It was why it had taken an external auditor, arriving with fresh eyes and no prior assumptions, to identify something that should have been visible from the inside.

The Lesson Behind the Letter

The answer, in this case as in most, was not negligence. It was momentum. Growing businesses move forward. The urgency is always in what is coming next – the next hire, the next product, the next market, the next quarter. The infrastructure supporting that growth tends to be addressed reactively, when something fails, rather than proactively, when something is simply no longer appropriate for the scale it is serving.

Internal controls are particularly susceptible to this pattern. They do not break dramatically. They erode quietly. Access rights accumulate. Approval thresholds become outdated. NetSuite system configurations reflect the business as it was, not the business as it is. Nobody experiences the erosion as an event, because it isn’t one – it is a slow accumulation of small gaps, each individually defensible, that collectively amount to a control environment that is no longer fit for purpose.

By the time an external auditor arrives and tests the architecture systematically, the gap between the policy and the reality may have been widening for years. The management letter is not the moment the problem began. It is the moment the problem became visible.

A control that lives in a policy document is not a control. It is an intention. The difference between the two is a system configuration that makes the intention unavoidable – not dependent on memory, judgment, or the assumption that everyone will always do what the procedure says. At the scale most growing businesses are operating, that difference is not a technical refinement. It is the foundation on which accurate financial reporting and genuine accountability are built, supported by netsuite support.EcobSoft works with scaling businesses to align their control frameworks with the systems that are supposed to enforce them – so that the gap an auditor might find is closed before anyone from outside the business needs to look for it.