Excel: 2 Common Bugs, 1 Rare
By: Joseph Burton
Tags: Data Analysis, Data Analytics, Data Science, Debugging, Excel

Excel: 2 Common Bugs, 1 Rare

Photo by Joshua Coleman via Unsplash

Excel is king. It’s probably used by a lot of the stakeholders in your company. It’s commonly used for quick analysis. It has a rather low barrier of entry when compared to coding. With so many people using it with so many reports, you’re almost certain to stumble across a bug.

I am going to cover two common errors and a lesser occurring example. This article can either help you avoid these situations or can help you offer guidance to those using reports that have numbers that don’t check out with a source of truth.

(Red Ball From Minority Report Rolls Down) There’s a Data Discrepancy!!!

You throw on those gloves that allow you to move through the footage to identify the source of the problem. You have all of your monitors full of evidence. You’re on a mission!

Someone has pointed out that they’re coming up with different values for ‘average_$_per_cust’ than what they’re seeing in other places.

Photo by Author

This report has taken a column that has already calculated the ‘average_$_per_customer’ by store by month and it’s now taking the average for each month. Averaging averages is a no-no! Note the difference in the pivot table above when using the sum of the ‘sales’ / sum of the ‘cust’, a created formula.

This might not look like a huge difference, but when it comes to some important decisions that are made, this could be the end of a program that is actually doing just well enough to survive.

How Much Trouble Can Averaging Start?

Speaking of averages, the tricky part about them is that the value of the denominator can make a pretty sizable difference in results. In this example, Store 10 had not opened up last year, so no sales were associated with it. In our left column, we put a 0 for sales. In our right column, we don’t have a value. Using a 0 will add a 1 to the denominator for each observed instance.

Photo by Author

$905 (we’ll say that’s in thousands) split between 10 stores is very different compared to the 9 stores actually needed for the calculation.

This One’s a Little Sneaky

We’re going to change the scenery and bring in our old friend: the V-Lookup. This scenario is sort of an oddball. I’m wanting to show it just in case you run into something similar. First, take a look at the two columns near the middle of our output.

Photo by Author

In this scenario, we’re using our V-Lookup to bring in the value for ‘cust’, far right, to match up alongside ‘sales’. We don’t have a unique identifier to join on, so one was created. The column ‘year_week_store_concat’ seems pretty self-explanatory. It concatenates the year, week, and store columns. This will give us a unique value, right?

Note that in our ‘cust_vlookup’ column, we see a duplicate for the values of 52 and 50. If you look at our ‘year_week_store_concat’ column, you’ll notice that for the two rows with 52, the lookup for both of those rows is 2021111. Week 1, Store 11 looks just like Week 11, Store 1. With a V-Lookup, whatever value it finds first will be brought in.

The solution? Use a delimiter. Note that now we have 2021–1–11 vs 2021–11–1. Using this method, ‘delim_cust_vlookup’, matches the values correctly!

Final Thoughts

Because it’s so easy to throw data into an Excel file and create pivot tables in just seconds, people can forget the smaller details. My hope is that you won’t run into these issues, but if you do, maybe these will help in the debugging process and save you time.

These are great little tips to help others avoid issues as well. Ideally, you will be able to move forward as a team and spend less time comparing results. As always, keep on learnin’!

For those that use SQL, check out this possible bug when summing two columns with an explanation of how it works:

This will help you avoid a year calculating error when using DateDiff() in SQL: