RoseRyan and Silicon Valley Bank are pleased to present “New Accounting Issues Affecting Technology Companies” September 29 in Santa Clara. Technical accounting pro Maureen Earley will review the practical implications for technology companies of several new accounting rules introduced in 2011. She’ll also pull back the curtain and give you a peek at what’s next. If you work in finance at a private technology company, you’ll want to know how these new rules affect the information you provide to your company, investors, board and even your lenders.

What you’ll learn:

  • Revenue recognition accounting changes for 2011
  • Financial Accounting Standards Board rule changes in the pipeline
  • Common accounting issues for VC-backed technology companies

The program is free, and will be held 4–5:15 p.m., followed by a networking reception, at Silicon Valley Bank, 3005 Tasman Drive, Santa Clara.

Register here.

Need more information? Please send an email to Eve Murto.

In my work with smaller companies I’m seeing that there’s still much more they can do to strengthen their control environment, create efficiencies and reduce compliance costs in their SOX 404 program by taking a top-down risk-based approach—focusing more effort in higher-risk areas and relying on preventive and monitoring controls in lower-risk areas.

While the Dodd-Frank Act of 2010 eliminated the requirement of an external audit of financial reporting controls for nonaccelerated and small-company filers (companies with a public float of less than $75 million), they still need to document, test and certify valid internal controls. And they have to comply with the same complex accounting requirements (revenue recognition, equity accounting, inventory and asset valuation, etc.) that big companies do, but often they have limited technical accounting resources.

If you’re in this category (and even if you’re not), you should take a fresh look each year to identify the processes and controls that pose the greatest risks for errors in your financial statements. When you know where your greatest risks lie, you should spend the most time and resources evaluating the design and operating effectiveness of controls in those areas, and spend less time on those you’ve identifed as lower risk.

Similarly, small companies don’t always have a second set of eyes to review the accounting for highly complex transactions, so it might make sense to consider having an outside expert assist in their review—you can bring in accounting expertise only when you need it and reduce your risk of error.

Because management has greater visibility of activity across the organization in smaller companies, you have the opportunity to identify and leverage entity-level (monitoring) controls that mitigate financial statement risks for lower-risk processes. As an example, you could rely on monitoring controls such as account reconciliations rather than multiple transactional controls. Relying on monitoring controls that are performed on a weekly, monthly or quarterly basis will require less testing than transactional-level controls, saving time and money.

Taking a risk-based approach to SOX 404 gives companies a real opportunity to focus on what matters most and improve ongoing processes. As a bonus, you can save time and money, too.

When I talk with finance executives about implementing XBRL, nearly everyone asks, “What will auditors be looking for? Do they care about XBRL?” The answer is no, they don’t. But they do care about your controls, and that relates directly to how you design and document your due diligence in XBRL creation process. Ultimately, as XBRL gets built into your close process, the more it may start to fall into the SOX environment.

While XBRL exhibits are not subject to SOX 404 internal controls over financial reporting, they are nevertheless subject to disclosure controls and procedures (DC&P). This means that management is responsible for the implementation of controls over the XBRL creation process as well as documentation that the DC&P are performed and reviewed. How can companies provide evidence to their auditors that management, including the CEO and CFO, have evaluated the effectiveness of the design and operation of DC&P?

To design proper DC&P controls, you first need to ask, “How do you know your XBRL files are complete, accurate, consistently mapped and comply with the mandated XBRL structure?” A best practice is to develop an XBRL technical and compliance checklist to document every aspect of your XBRL creation process, from taxonomy mapping and appropriate extensions to common error reviews, technical and SEC validations, structure compliance issues. You may also want to involve your disclosure or audit committee in the review and consideration of your DC&P process and get them on board with your XBRL strategy.

As XBRL technology becomes more embedded into your overall financial reporting process and integrated into the creation and preparation of your financial statements, XBRL controls may start to fall within the scope of SOX 404. As this happens, you should reevaluate your XBRL controls under SOX 404 framework.

Most service firms (like payroll and healthcare claims processors) have provided a SAS 70 report to their clients simply as a matter of course. Over time these CPA reports on the service organization’s internal controls have evolved from being solely an auditor-to-auditor communication to include information about risks beyond financial reporting, and in some cases they’re being used as a marketing tool.

As of June 15, SAS 70 reports were replaced by SSAE 16 reports. There are any number of publications and opinions about the transition (just ask Google), but it strikes me that there is an opportunity here to take a fresh look at the value of these reports. I’ve seen a tendency to for companies to include SAS 70 reports in the SOX controls only because they are available, and my guess is that there are probably quite a few them with other controls that cover the same bases. On the flip side, the SAS 70 might not address risks that need additional work to mitigate, or the business has changed and the risks are no longer consequential.

So, take a closer look at past SAS 70 reports and determine if you’re actually relying on them for your internal control environment. If you don’t need to include them in your SOX controls—don’t. (That will apply to the SSAE 16 as well.) You’ll save time and possibly a bit of money.

This is not to say there is no value to the SAS 70 or SSAE 16 report if you don’t need it for SOX. Companies just need to ask themselves whether that value is as a SOX control or for other operational or risk mitigation purposes. Seize this opportunity, and at the very least you’ll have a good understanding of your controls environment.

Having been in the trenches with XBRL since it came on the scene, we’re pleased to announce the launch of our dedicated XRBL practice. Sure, it’s a business opportunity for us, but we believe we can go above and beyond. We’ve seen what companies are going through to comply, have a whiteboard full of best practices from phase-in groups, and we’ve helped our clients both do it right and benefit from it. XBRL is a necessary evil (sort of like SOX used to be), but with it comes the chance for companies to really take ownership of their data, and make sure their information is accurate, transparent and comparable to everyone who uses it.

Our chief XBRL guru is Lucy Lee, a newcomer to RoseRyan but an experienced hand at XBRL and compliance issues. She’s developed a six-step XRBL methodology, with quality assurance at its core, that we’ll use in every engagement. XBRL implementation is relatively new and still changing, but we stay on top of the rules updates and Edgar Filer Manual changes, including SEC guidance and most common errors. We can help with every aspect of XBRL implementation (not something everyone can claim), and when we’re done, we often leave companies with a more streamlined close and reporting process.

You can learn more about our new XBRL practice in our press release and in the Services section of our website.

This past fall I attended a panel discussion presented by the SEC Professionals Group on detailed XBRL tagging. Overall it was very helpful and provided great insight into what other companies experienced for their first experience with detailed tagging.

The incredible workload surprised all of the panel members, who were primarily SEC reporting managers and controllers from high-tech companies that were part of the Group One XBRL. This first group had to prepare detailed tagged financial statements and footnotes (versus block tagging), so the panel included some of the first companies who experienced the joys and the trauma of detailed XBRL tagging.

Common pain points for these companies: the huge volume of work involved in the detailed tagging (an average of ~250 hours in prep/review/validation) in addition to their normal filing process; incredibly long turnaround times for changes from the printers (six to seven days in some cases); many errors in tags chosen by the printers; and subpar quality on work outsourced by the printers.

The lessons learned reflect my own work with XBRL: start the process early, and leave plenty of time for review; don’t rely on printers’ accounting expertise (you know your financials and footnotes better than they do); the responsibility for the accuracy of the XBRL filing resides with you, not the printer; and have a really solid methodology for tracking changes. Finally, do a test run to make sure the results meet your expectations.

Keep these things in mind, and things will go a lot more smoothly.