Exception reports are a special type of report that point out exceptions. First, I went out and did a little bit of research just to see how other people, or other companies, define exception reports. Here’s what I found. An exception report is a type of summary report that identifies any event that is outside the scope of what is considered a normal range. This was from a finance source, smartcapitalmind.com. Another accounting definition is an exception report refers to a statement disclosing the dissimilarity between actual and expected occurrences. That was from wallstreetmojo.com. Finally, from a project management source, Prince2 at Wiki, an exception report is normally an issue report that documents an issue that is out of tolerance.
I think those are pretty much in line with how I would define exception reporting, as well. I would say that an exception report is a report that highlights a situation which is not within our expectations. It’s highlighting something that is out of range or highlighting something that is unexpected. Why would you want to create exception reports? First, I would say that exception reports are often focused on the negative side of things. When is something not happening that should be happening, or when is something not in line with expectations? But there’s probably no reason why we couldn’t have the opposite, what are the exceptions to the rule, even on the positive side of things, as well.
If we’re talking about sales achievements, who are the sales reps who are exceeding expectations? In other words, they are an exception on the positive side, they’re exceeding goals. Nevertheless, we do often focus on the negative side of things, because we’re trying to figure out how do we improve an organization. We’re doing that by focusing on the things that are not happening that we believe should be happening. When we look at exception reports, we got to ask ourselves, first, why are we creating an exception report? Well, first, we don’t want to put our head in the sand. As painful as it might be, we really do need to pay attention to things that are not happening the way we expect they should be happening. That’s as cut and dry as I can make it. But even though we often have a lot of opportunity to point out the things that aren’t happening that maybe should be happening, sometimes we’re hesitant to do so.
Obviously for a lot of different reasons, we don’t want to be negative. Exception reports, just from their nature, are almost always a negative report. Things are not happening the way we would like them to, and people don’t naturally want to be negative. It’s not something that we enjoy doing, pointing out the problems. It’s not something we enjoy doing, that’s one reason. The other thing is you might be worried about offending someone. Often these exception reports are very focused. We’re pointing out behaviors and there’s no hiding. We’re not trying to hide anything. We’re just saying here are the things that are happening that we want to change. So sometimes creating an exception report might add a little stress. But if we’re going to improve, we must be willing to change. We need to be willing to be critical of ourselves.
It’s not about pointing fingers and just trying to make someone feel bad. It’s about identifying where a problem is and trying to improve that problem. Now, of course, what happens after you identify the problem is very important, but we’ll get to that in just a minute.
So, reason number one for why you’d want to create an exception report again, is we want to know if things are not happening as we expect. Another reason is we want to catch a problem before it becomes a big problem. We want to catch that problem early on, and sometimes these exception reports are critical in that nature. We’re going to identify an exception here, which usually is based on business rules. When that thing happens, we know it’s not what we want to have happen, and we want to stop it before it snowballs into something much bigger. I mentioned before, another reason we would create exception report is to change behavior. That’s ultimately what we’re trying to do … change behavior.
Another example of why we might create exception reports is we want to identify and possibly even address business process issues. This does get into the weeds. When you have a business process, it may be more complicated than to just doing “A”, for example. It could be a whole bracket of decisions that are happening. It’s important to identify those key points in the process and make sure that they’re happening the way we expect. Addressing business process deficiencies is another reason we might create an exception report. Exception reports are based on business rules. I guess all reports are, but when you think about exception reports, they often manifest themself by, basically, stumbling across a situation. Then you want to know if that ever happens again. I want to know when that happens, and that’s for all the reasons I just mentioned.
Let’s discuss a few different types of exception reports. I came up with five different categories. There is an unlimited number of categories. You could just think about your business and ask yourself is that what you want to know when something’s not going right. Or something is not meeting your expectations. How do you want to be alerted to that? What are those rules? What are those business processes? What are the goals? You can come up with any number of exception reports. I’m just going to give a few that were top of mind whenever I was thinking about this episode.
The first one I think is probably universal. That is if we are not in line with goals or budget. Typically, when you think about finance, if we are not currently performing in line with the goals. You can think of a sales goal, for example, or if we’re not in line for budgetary reasons. Then we want to know that right away.
That brings up another point. Usually, in my experience, exception reports are a very granular type of report. Not always, they can be at any level of the organization, but typically, at least when I think about an exception report, we’re thinking about something granular.
If we’re talking about sales goals, for example, we’re probably going to be looking at those sales goals initially at the individual sales rep level. We’re going to look at all our sales reps, and who is not meeting their goal. There’s an exception report, however we define goal and however we measure the performance. If we created a report like that, you want it to be very clear what’s being pointed out. In the case of a sales goal, it’s very clear, for example, that John Doe is at 25% of goal, and we’re already 90% of the way through the period. So, they’re often very granular, but they don’t have to be.
You could have a regional exception report. To me, that’s a lot less common. It’s a lot less impactful when you look at a region, maybe a region is made up of 20 different sales reps. If you say that region one out of four regions in an organization is not meaning their goal. Well, that’s not as actionable. You’re still going to have to go down to the individual sales reps to figure out exactly what’s going on. But nevertheless, I see no reason why you couldn’t have an exception report at any level of the organization.
Another type of exception report that’s common is just out of range values. One of the things that often happens is we have business applications that don’t have all the features that we need. I’m just going to make stuff up here, but you can fill in the blank. Your business application may not have a way of validating a data entry, for example, and maybe that data entry could be out of range. I’ll just use consulting, since LeapFrogBI is a consulting firm. We provide business intelligence services, and we bill our clients for our time. So, one of the things that we track, in an exception manner, is no bill time. When any of us feels like we don’t want to bill a client, we no bill that time so we can account for our time, but we don’t bill the client for it. That’s perfectly normal. It’s fine. It happens. But you can’t have 50% of your time be no bill, that would be an exception.
So we have reporting internally that helps us keep track of what percent of time is being not billed, and that’s done all the way at the individual consultant level.
There’s a lot of other examples for manual entry. If the business application we’re using doesn’t have the level of validation we need, then often, in reporting, we’ll point out data entry errors. Which could be critical, because those data entry errors, if someone just puts in an extra zero or two somewhere, that could throw off a lot of reporting. We want to try to catch those things early, because we don’t want it going into our financial statements. We don’t even want it going up to any level of management and looking at the incorrect value. So having an exception report that helps us identify data entry errors is often important and quite common.
Another type of exception report I would put into the reconciliation area. This is where, like any reconciliation, you’ve got two, maybe three, different pieces of information that should be in sync, but they’re not. You’ve got to identify it and address that issue. The reason for them being out of sync could go in a lot of different directions. It might be the data entry error we just talked about or some other issue. Nevertheless, reconciliation type exception reports will identify the cases where systems are out of sync. They’re not able to reconcile.
Another type of exception report would be a business process exception report. This could be a lot of different things. We could start out with consulting. We enter our time every day, but if someone doesn’t enter their time, well, that’s an exception. We need to make sure that time gets entered the next day. At our company, we tell our clients we’re going to keep our time current every day. If a client looks at their time and the time is not current, now we have a problem. So it’s important that we’re identifying an exception, in this case, is just missing time.
Another type of an exception, I’m giving some of our examples here just because I’m most familiar with that. Another business process type of exception would be what we call, unscheduled commitments. This is where we are working with clients, and we’re telling them the things we’re going to do. We create cards on a combined board, which is how we track all our activity, requests, and the phase of development that they’re in. And we also time block that activity, so we put it on the consultant’s calendars, essentially, so that they can have the time needed to carry out that task. If we have a situation where a commitment was made, but that commitment is not on anybody’s calendar, that’s an exception, and it needs to be handled.
Business process exceptions are common, and reporting can make a big difference in, not only pointing out the exceptions, but trying to solve that problem. That leads me to the last important point that I want to make about exception reporting. Exception reporting is very common. It’s very useful. But exception reporting is just going to highlight that an unexpected event occurred. Something is out of range. We came up with the rules. We ran the numbers and here’s the report that tells us the things that are out of range.Things are not going to improve by identifying the exception. We now must have some type of process in place to correct the behavior. We need to try to find a way to resolve the problem. Some of these are trivial things. Some of them are important things that need to be addressed quickly. The point being that the exception report, itself, is going to tell us that something is out of range. It’s important that we have a plan in place for how we’re going to address that exception.
We could also take it to the next step. We might measure how often exceptions are occurring. I’ll give you an example. I have one client that I work with that does what they call, intake error exceptions. This is all about billing and claims processing in healthcare. What happens is they have an error on what they call, an intake, a sale of a product. If they have an error either on the entry of data into their system, or in any piece of the process, when a claim is being processed, that’s an intake error exception. We want to know when that occurs, first. Obviously, so we can correct it. But number two, we want to know how often it’s occurring, and what types of errors are happening with which people That’s now actionable even on another level.
Now we see which type of an exception is occurring an unacceptable amount of time. They can make sure people have the training that they need, so they can get their job done. Maybe we find that these people are overloaded, there’s no way they could get all this work done. We need to get some more staff on this situation, or maybe we need to try to automate some of this stuff. So basically, it leads into a lot of different directions when you start putting these exception reports out there.
When you create reports, it changes behavior. That’s for sure. As soon as you start identifying exception reports, and people understand it’s not good to be on the exception report, they’re going to get off it. Or they’re going to communicate why it’s not possible to be off that exception report, which is exactly what we want.
To me, that’s exactly what we want in an organization. We want people to give us the feedback, don’t worry about feelings. Of course, we’re going to be nice to one another, but, at the end of the day, we want to look at the problems. Even though it’s not always comfortable to invoke the type of change needed to overcome that problem, we do want to highlight the problem. We do want to solicit feedback from the people involved with the business process that’s having the problem. That’s essential, because without doing that, it’s impossible to then try to figure out how to solve the root cause of the issue and enable the organization to improve overall.
Exception reports are one of the first steps in that process after you figure out where something is going wrong. We’re going to monitor that situation and highlight it, but it’s not the end of the process.
