5 reasons Excel still belongs in an analyst's toolkit

I see no reason to remove Excel from my toolkit just because I can use SQL or Python. When I have a small file, want to inspect records with another person or need to prepare a simple result for further work, a spreadsheet can be convenient. Its usefulness depends on the task. An imaginary ranking of tools by how advanced they look tells me very little.

The original article described five reasons Excel remains useful: exploration, communication, data transformation, learning to think in tables and delivering a final result. Here I develop those ideas through a practical workflow. I also narrow a few claims that were too broad. Speed depends on the task, and a familiar spreadsheet interface does not mean everyone understands the data inside it.

I use five synthetic sales entries throughout the article. They are neither company data nor a client result. Keeping the dataset small lets us follow the entire process and check it manually. The same reasoning can help with larger files, although the way you perform the calculations may need to change as requirements grow.

Excel helps me inspect unfamiliar data

When I receive a CSV, I first want to understand its structure. How many columns are there? What does one row represent? Is an identifier unique? How are dates, amounts and missing values represented? A visible grid makes it easy to inspect a few records and compare specific cases. I do not assume it will be the fastest tool for every environment or file size.

In this exercise, one row represents a transaction entry with its own ID. Amount is a signed value: positive for a sale, negative for an adjustment and zero for an entry with no value. All amounts use one arbitrary unit. There are no mixed currencies or tax treatments. Put the following values in columns A:D, with the headers in the first row.

Treat ID as text, Date as a date and Amount as a number. Leading zeros belong to the identifier. They are not decoration. Before building a summary, I check that the negative amount and the zero remain in the data. Removing them because they look unusual would change the question the dataset answers.

For a CSV, I use the command to import data from text or CSV instead of relying only on double-clicking the file. In the preview I check the delimiter and encoding, then inspect the types in the transformation steps. Microsoft’s import documentation describes this workflow. Command names and supported sources can differ across Excel versions and platforms.

If automatic detection has assigned a numeric type to ID, I correct the relevant step before loading the data. Changing the appearance of a cell to text later will not recover information already lost. When entering this example manually, set the ID column to text before pasting the identifiers. Then check that you see exactly 00101 rather than 101.

A workbook gives a conversation a shared reference

I like being able to point at a specific row and ask what it means. In our example, the negative amount beside ID 00103 deserves attention. Is it a return, a technical correction or another event? I have defined it as an adjustment for the exercise. At work, I would confirm its meaning with someone who understands the process producing the data.

Looking at records together helps establish the rule before a report exists. If someone expects sales before adjustments while I sum all recorded values, we will produce different answers. Extra decimal places will not resolve that difference. I need a metric name, a description of the included events and a clear statement of the question the summary should answer.

I do not assume everyone knows Excel equally well. One person builds PivotTables comfortably; another mainly uses a workbook to enter comments. I therefore explain which cells contain inputs, where the results appear and what can be changed. A shared tool helps communication when the understanding of the data is shared as well.

In a practical workbook, I would separate source data, checks and results into clearly named worksheets. Beside the output I would include the date range, the definition of Amount and the time of the last refresh. The recipient should not have to guess whether “October” means a complete month or its first three days. Our exercise includes only the dates shown in the table.

A spreadsheet can also reveal that the recipient needs a different result. They ask for a total by channel, then discover while inspecting the example that they need a list of adjustments to investigate. I would rather learn that while discussing five records than after building an extensive dashboard. An early sketch makes misunderstandings cheaper to resolve.

I can record repeatable transformations

Correcting a header once is straightforward. Repeating the same dozen manual corrections in a monthly file soon becomes a separate job. At that point I consider Power Query: I record how to retrieve and transform the data so the agreed steps can run again during a refresh. I remain responsible for what those steps mean and whether they are correct.

For our example, the process would read the file, select the required columns, assign a text type to ID, interpret the date and convert Amount to a number. I pay attention to locale. The English table uses a decimal point, while the Polish version uses a decimal comma. The text 120,50 needs a locale that interprets that comma correctly. Microsoft Learn explains how locale affects type conversion. The interface language alone does not resolve every difference in the source data.

I give transformation steps names that explain their purpose. Removing entirely empty rows may be reasonable, but dropping every record with a missing amount requires an explicit decision. A missing value may be a problem someone needs to investigate. If I hide it automatically, the report looks tidier while useful evidence about source quality disappears.

For recurring batches, importing files from a folder can help. Before combining them, I check schema consistency and whether the folder contains only the intended files. A second copy of last month’s export with “corrected” in its name could duplicate some events. Automation can process an incorrect selection of inputs very efficiently.

I also distinguish Excel’s overall capabilities from the features available on a particular machine. Power Query, the data model, add-ins and supported connections depend on the edition and platform. Before handing over a solution, I check the recipient’s environment. The name Excel does not guarantee an identical set of features on Windows, macOS and the web.

I learn to reason about tables and their level of detail

A worksheet makes the difference between individual records and a summary visible. I have five transaction entries and two channels. I want one total for each channel. One way to produce it is to select the data, create an Excel Table and then insert a PivotTable on a separate sheet. Channel goes into Rows and Amount goes into Values, using Sum.

That last setting matters. If the amounts have been interpreted as text, Excel may suggest counting records. I inspect the aggregation setting rather than trusting the heading in the finished report. Microsoft’s PivotTable instructions describe preparing the source and selecting fields. A single header row and consistent columns make the process easier to follow.

The exercise should produce Web = 100, Partner = 230 and a grand total of 330. For Web, the calculation is 120.50 minus 20.50 plus zero. For Partner, it is 80 plus 150. The check is deliberately simple. If the PivotTable shows something else, I revisit the amount type, source range, filters and selected aggregation.

This reasoning transfers to other tools. Grouping by channel has an equivalent in SQL, and choosing columns and data types comes up again in Python. Excel provides visible material for practice, but does not guarantee good habits. It can also make it easy to keep adding manual totals, mix headers with records and encode important information only through cell color.

I therefore maintain one meaning for each column and one level of detail for each table. I do not add a “Total” row to source data that will be summed again. I do not put two channels in one cell when I expect straightforward grouping. I do not delete a repeated order ID before checking whether each row represents a separate line within that order.

I prepare output for the recipient’s next task

An analysis can run in a database or a script while the recipient still needs a spreadsheet for their own work. I treat that as a normal requirement for the output format. I first establish what should happen next. Will they filter records, add comments, compare scenarios or simply read three numbers? Each answer suggests a slightly different workbook layout.

If comments are needed, I provide a separate place for them and a stable record identifier. Manual notes beside a refreshed list can become misaligned when the row order changes. Without a key linking the note to a record, a comment about one transaction can suddenly appear beside another. That is a risk in how the result is used, even when every total remains correct.

I also label whether I am delivering a snapshot or a workbook that can refresh. A snapshot describes the data at a particular time. A connected workbook requires access to its source and appropriate configuration on the recipient’s side. Sending a file does not establish that another person can retrieve the same inputs. The instructions should explain the refresh process and the checks to perform afterward.

I keep the presentation simple: readable names, appropriate amount formats, filters and a short metric definition. I avoid decoration that makes further processing harder. A merged title may look appealing above a report, but it should stay outside the source table. Someone preparing another aggregation will benefit more from ordinary columns than an elaborate visual arrangement.

Before handing the workbook over, I ask the recipient to complete one task without my help: find adjustment 00103 or refresh the test data. If something is unclear, I improve the instructions or layout. This tests the file’s practical usefulness. Merely confirming that it opens on my own computer is a very weak handoff check.

Limits I check before expanding a workbook

Microsoft’s specifications give a limit of 1,048,576 rows and 16,384 columns in one worksheet. That describes the worksheet grid, rather than every capability of the data model or external connections. I do not wait until the last available row is occupied before considering a different approach.

Numeric precision matters too. Excel specifies 15 digits of precision for numbers. I therefore treat a long identifier as text during import, just as I do a code with leading zeros. Display formatting will not recover digits that have already been lost. Choosing a type expresses the meaning of the data; it deserves attention before the final formatting stage.

Another signal is growing dependence on manual operation. Perhaps a report needs several files from personal folders, refreshes in a particular order and knowledge held by one person. I then consider moving retrieval or transformation into a maintained process outside the workbook. Excel can remain a convenient place to receive the output while heavier processing happens elsewhere.

I also examine requirements for shared definitions and change history. If several teams independently edit the same metric, it may be time to maintain one common calculation source. If results must refresh without anyone opening a local file, I check what infrastructure supports that requirement. Concrete needs make tool choices more useful than arguments about which application looks most professional.

A short check after each refresh

After refreshing our example, I check the five records, preserved identifiers, date range and total of 330. I then reconcile channel totals with the overall amount. The zero and negative adjustment must remain present. This covers both the arithmetic and rules that could accidentally change during cleaning.

Real reports usually have changing expected values, so I document the checking rules as well. Group totals should reconcile to the source total for the same scope. Identifiers should retain their format. Records rejected during transformation should have a known count and reason. The absence of a technical error does not establish that every relevant input reached the result.

It is useful to test a failed refresh too. On a copy of the file, change the Amount header or move the source to another folder. Check where an error appears and whether the old result still looks current. Restore the input and repeat the checks. This small experiment reveals what maintenance instructions need beyond a Refresh button. The recipient should know how to recognize a failure and where to report it.

I check the PivotTable refresh separately. Changed input data does not prove that every view already uses the new dataset. When uncertain, I refresh the table and inspect one specific changed record. If its source is a fixed range instead of an Excel Table, I also check whether appended rows are included in that range.

I record the data date and the outcome of the checks where the recipient can find them. When something does not reconcile, I stop the handoff and investigate. Copying an old number into a cell so the report “looks right” turns a detectable problem into a hidden one. That is a particularly unhelpful form of automation.

Exercise: deliver a workbook someone else can maintain

Recreate the five records while preserving the text identifiers. Build a summary by channel and add a short definition of Amount. Then append ID 00106 with channel Web, date 2026-10-03 and amount 25. After the source expands and the PivotTable refreshes, Web should total 125, Partner should remain 230 and the grand total should be 355. The record count increases to six.

Give the file to another person with instructions for restoring the original data. Check whether they can locate the source, distinguish the adjustment from an error, find the refresh information and obtain 330 again. This connects the five reasons in the article: inspecting data, discussing meaning, repeating steps, understanding structure and delivering a usable result.

To develop individual parts of the workflow, start with lookup functions and array formulas. Then compare combining data with SQL JOIN types. Excel earns its place in my work when it helps complete the task and leaves a result that someone can understand, check and maintain.