What does transactional activity look like in your ERP? In an ideal world, everything would follow the right process. But as most NetSuite teams know, an ideal world isn’t the real world. A business’ needs are complex, and constantly evolving.
The result is that, while strong policies and processes are essential parts of running a transparent, accountable organization, it’s just as important that you have controls in place for tracking when things fall through the cracks. That’s where exception reporting comes in. Financial exceptions can include anything that deviates from your standard review or approval process. Want some common examples?
- Journal entries created and approved by the same person
- Deletion monitoring
- Invoices edited after approval
- Administrator involvement in transactions
- Changes to vendor data
With a list like that, it’s understandable why this is a key concern for auditors.
Financial exceptions in NetSuite
All this would be complicated enough if you worked exclusively offline. But cloud-based systems, and the kind of collaboration they foster, add an extra layer of complication.
In NetSuite, the Admin role is a frequent source of financial exceptions. Ideally — in that perfect world we talked about above — NetSuite users with Admin privileges would be supporting and managing the configuration of the business, not handling transactions. In other words, they shouldn’t be touching your financial data at all.
The problem with false positives
In NetSuite, it's possible to create scripts and workflows that execute as an Admin, rather than the role assigned to the user who triggers it. It's a common workaround to reduce testing when customizing the system, or in managed bundles that want to ensure the widest range of functionality and compatibility with different accounts.
For example, you may have a script that automatically creates an invoice once a user creates a sales order. To do this, the script executes with Admin privileges. This wouldn’t be a problem, except that, now, NetSuite’s system notes will record that the entire transaction was initiated by the user, who likely doesn’t — and shouldn’t — have the Admin role.
Here's Strongpoint's Amy Carlson with a brief explainer:
For many of our clients, identifying and clearing these ‘false positive’ financial exceptions is one of the biggest parts of getting ready for an audit. Fortunately, Strongpoint gives you two easy ways to deal with it:
- Run a search to identify and clear all 'execute as Admin' scripts and workflows that are causing the problem. (We’ve got a blog post all about this here.)
- Or, use our Agent crossmatch feature to double join the results of two saved searches and filter out false positives from your data:
Handling true financial exceptions
The 'execute as Admin' problem is an example of NetSuite flagging something as an exception — and potential SoD violation — that it shouldn’t flag. But what about true financial exceptions? Your auditors will want to see you have a process for reviewing and approving them. And you should want it, too, because it will help you sleep at night!
The problem is most organizations handle exceptions in a pretty ad hoc way. Email chains, spreadsheets and shared drives are all common solutions. Unfortunately, none of these will satisfy your auditors. All occur outside of NetSuite, and can be edited or altered after the fact. Worse still, all are prone to human error.
The better way — Strongpoint Agent!
Strongpoint Agent is a comprehensive, NetSuite native system for tracking and reporting on financial exceptions in NetSuite. It continuously monitors for transactional behavior and checks it across a list of customizable rules to flag non-compliant issues for review. Then, it gives you a set of tools for resolving those violations, and logs everything in an unchangeable, audit-ready record.
It’s all done using NetSuite’s saved searches, so it’s easy to learn, too. Here's Amy again with a rundown of how it works:
Want to see Strongpoint Agent in action in your account? Book a demo here: