Another Lesson on Accounting Controls

Royal Bank of Canada has settled charges with the Securities and Exchange Commission over poor accounting controls for software development, which might sound super nerdy — because it is, really — but the case also lets us ponder yet again the importance of a strong control environment.

The SEC announced the case late last week. RBC agreed to pay a $6 million penalty and implemented various remedial measures, although as usual with SEC settlements, the bank neither admitted nor denied the charges.

The gist of the complaint is that from 2008 to 2020, RBC improperly recorded the costs of its internally developed software and didn’t always assess potential impairment costs according to proper procedure either. That led to inflated assets on the balance sheet when those assets should have been written down in value over the course of their useful life.

The real story, however, is that RBC didn’t keep up its investments in strong accounting systems to govern all those transactions, even as the cost and scope of its internally developed software ballooned over the years. That points to a weakness in RBC’s control environment, an issue that SEC officials have raised  numerous times lately when urging companies to do better with risk assessments. Poor control environment leads to poor risk assessment, which then leads to flawed processes and flawed transactions. That’s pretty much the pattern we see here. 

The Art of Tracking Software Costs

To appreciate what went wrong here, we need a quick review of (nerd alert!) the accounting rules for internally developed software. According to the international accounting standards that Royal Bank of Canada follows, a company developing its own software can capitalize some of those costs and list them as an intangible asset on the balance sheet. Those costs are then amortized over the estimated useful life of the software application, just like you’d do with any other intangible asset. 

First important detail: you can only capitalize costs related to development of your software — that is, the actual writing of code and implementing it into your IT infrastructure. You cannot capitalize costs related to whatever research phase you might do before the coders start typing.

Second important detail: once your software project is listed on the balance sheet as an intangible asset, then like any other intangible asset, you need to test it for impairment (read: sudden decline in value) every year. For example, if your company decided to buy better software that made your internally developed app obsolete, you’d impair the value down to zero dollars. 

Like any big financial firm, Royal Bank of Canada had lots of internal software projects happening across the enterprise. Projects valued at  C$5 million or more (the “C” stands for “Canadian”) were reviewed individually to determine how much of their cost could be capitalized according to those above rules. 

Smaller projects, however, were lumped together into a single consolidated pool. Then accountants capitalized a percentage of those collective costs by applying a single capitalization rate for the whole group.

At this point savvy financial reporting and audit people might be saying, “Uh oh. They’re using an estimate.” You would be right to say that. 

Where RBC Went Sideways

RBC’s troubles were with those pooled projects and the capitalization rate. As described in the SEC settlement order, the bank’s accountants set the estimated rate at 78 percent. Then they added up salary and benefit costs for employees and contractors who worked on those internal software projects, and divided that number into total costs (which would also include rent, utilities, training, and other incidentals). If the result of that calculation was somewhere near that 78 percent estimate, the accountants just went with the 78 percent rate. 

That approach to estimations and capitalization costs isn’t specific enough to comply with international accounting rules. Yet Royal Bank of Canada kept following that flawed practice from 2008 to 2016, even as its spending on internally developed software increased sharply.

Starting in 2017 the bank tried to improve matters by conducting small studies to validate whether its 78 percent estimate was accurate. Except, RBC’s method for conducting those validation studies was unreliable: poor sampling and response rates to surveys, incomplete information, lack of documentation for third-party contracts, and the like. 

RBC also discovered that some software projects included in its pool shouldn’t have been in there in the first place, which led to the secondary realization that RBC had no process to determine whether a software project should remain in the pool or be impaired and written off. 

Meanwhile, those large software projects reviewed on an individual basis had their own problems. To determine whether a project should be impaired, the accounting team relied on the business units using those applications to tell the accounting team that the software was impaired, or at least warranted the accountants doing an impairment assessment. 

RBC also lacked a process to identify when the accountants should start amortizing those intangible software assets. So as the software wasn’t impaired or amortized, that overstated their value and understated the costs that should’ve been expensed right away. 

Back to the Control Environment

I warned you at the start that this case would go full nerd, and I believe we’ve met that objective. But despite all the arcane details, the biggest lesson here is the simplest: RBC didn’t invest in its accounting and internal control capabilities to keep pace with growth. 

That growth was considerable. RBC capitalized C$658 million of software projects in 2011; that number grew to C$1.1 billion by 2021. Likewise, the amount spent on pooled projects went from C$100 million in 2008 to more than $C600 million by 2020. 

With all that growth in a complex area of corporate accounting, any company should keep investing in the size, competence, and sophistication of its accounting function. That commitment needs to come from the control environment — and yet, as the SEC phrased it, “development of [RBC’s] control environment did not keep pace, and internal accounting control deficiencies affected its cost capitalization accounting for [software] projects.”

Let’s draw that line connecting the control environment to risk assessment to flawed processes a bit more clearly. When your control environment weakens and you don’t have sufficient resources to maintain internal control, you can’t execute an effective risk assessment. Consider these two principles for risk assessment as defined by the COSO internal control framework:

• Organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. (Principle 7)
• Organization identifies and assesses changes that could significantly impact the system of internal control. (Principle 9)

You can’t fulfill those principles when your accounting staff is too small, under-resourced, or out of their depth — and once you’re in the position, where your team struggles to define and understand the company’s risks, it’s almost inevitable that accounting and internal control processes will fall out of alignment with those risks. Those faulty processes don’t record transactions properly, and you end up with SEC enforcement actions like what we see here.

That’s how problems in the control environment flow down throughout the rest of your system of internal control, until you end up on the wrong side of an SEC enforcement action. 

And if this particular case was too nerdy for you, don’t worry. I’m sure we’ll have other examples to consider in the future.