Data Science for Accountants: A Practical Starting Point

When I tell accountants I do data science at Google, the most common reaction is a flinch. They picture machine learning models and a wall of code, decide it is not for them, and move on. I want to reset that picture. Data science in accounting is not some separate priesthood. It is a set of practical skills that make your existing work faster, cleaner, and more trusted. I use these skills every week, and almost none of it looks like the science fiction version people imagine. Let me show you the real starting point, built from the actual work I do and teach.

Yes, I Use SQL. You Will Too.

Let me answer the question I get asked most. What is the most common language used to query, filter, join, and aggregate data before sourcing it into dashboards? It is not a CRM system and it is not HTML. It is SQL, Structured Query Language. This is the single most valuable technical skill an accountant can pick up, and it is far more approachable than people fear.

Here is why it matters for your career right now. Based on top down messaging I have heard from senior leadership, there is a strong and growing preference for accountants who know SQL. The reason is simple. Accountants live in data, and SQL is how you pull, filter, and combine that data yourself instead of waiting on a data team. You do not need to be a programmer. You need to be able to select the columns you want, from the table you want, where the conditions you set are true. That is the core of it, and you can be useful with it in weeks.

Start With Data Reconciliation

Before you do anything clever with data, you have to trust it. What is the point of pulling numbers if you do not know whether they are complete, accurate, and correct? Reconciliation is where data science meets the accounting instincts you already have. I check three things every time:

• Completeness: are all the expected records actually included?
• Accuracy: do the values match a trusted source?
• Validity: does the data follow the business rules it is supposed to?

Here is a real example from my work. I was tasked with driving automation for our revenue processes, and we had several director meetings just to discuss the data. The first thing we had to align on was the definition of revenue and the metrics driving it. After pulling 2024 revenue from internal database tables, we calculated total revenue of 350 billion dollars for the year. The interesting part is the next question. How do you validate that number and build confidence with your director? You tie it back to a trusted source, like the figures in the company annual report, the 10-K. Reconciliation is the habit of never trusting a number until you have proven it against something solid.

Use Case One: Accounting UAT

One of the most practical applications I show is accounting UAT, or user acceptance testing. This is the part of testing focused on validating the accounting and finance impacts of a project launch before it goes live. It is exactly the kind of work that blends accounting judgment with light data skills, and it follows a clean three step process:

• Step one: use SQL to pull the accounting data. Test invoices get generated in the system, and you use SQL to pull the billing data tied to those test transactions, which usually involves numerous tables and joins.
• Step two: analyze and validate. Make sure the proper debit and credit accounts are being hit, the proper profit centers are impacted, and the proper invoice amounts are booked.
• Step three: obtain sign off. After your preliminary review, submit it to the product controller for final sign off.

Make it concrete with a test case. A customer purchases an annual subscription for 120 dollars on January 1st. The correct accounting entry is a debit to Accounts Receivable of 120 dollars and a credit to Deferred Revenue of 120 dollars. What you are testing is whether the system actually generates that entry correctly. To organize and analyze debits and credits across multiple GL accounts as you check, the classic framework is the T-account. SQL pulls the data, your accounting brain validates it, and the T-account keeps it visual. That is data science that feels like accounting.

Use Case Two: Database Migration

Here is a use case that teaches an important lesson about being careful with data. I was tasked with leading a SQL script update during a database migration to make sure every script aligned with the new structure. The old database was named Revenue and the new one was named RevenueV2.

Now a quiz I love giving. If you migrate to the new database and update only the table name in your script, will the old SQL test script still work? Take a script that selects first_name from Revenue where first_name is alex, and you simply change Revenue to RevenueV2. The answer is no. It will fail, because migrations often change more than the table name. In this case the column itself was renamed from first_name to name_first. Only when you update both the table name and the column name, selecting name_first from RevenueV2 where name_first is alex, does the script finally work. The lesson is that data structures change underneath you, and a careful accountant checks the schema, not just the surface.

A Framework for Structuring Your Analysis

Once you are comfortable pulling and trusting data, you need a way to think about what to do with it. This is the framework I teach for structuring any analysis. Each type answers a different question, and together they cover the real work accountants do:

• Descriptive analytics asks what happened.
• Diagnostic analytics asks why it happened.
• Predictive analytics asks what is likely to happen, which is where forecasting lives.
• Prescriptive analytics asks what we should do about it.
• Anomaly detection asks what looks unusual, which is how you catch errors.
• Controls and risk asks whether the accounting is reliable.
• Automation asks how we reduce manual work.

These categories help accountants analyze activity, explain variances, forecast outcomes, detect errors, strengthen controls, and automate work. You do not need to master all seven at once. Pick the one that solves a pain in your current role and start there.

Two Rules Before You Automate Anything

Automation is the prize most accountants are chasing, and it is real. I have used AI to streamline the semi automation of posting a journal entry, collapsing a slow cycle of requirements, back and forth, code development, and UAT testing into a much leaner flow. But before you automate, hold onto two rules I never skip:

• SOX controls: make sure the data sources feeding your accounting automation are SOX certified. Garbage or uncontrolled inputs make automated accounting dangerous, not helpful.
• Scalable automation: make sure your automation is scalable and that you have a clear RACI for the new process, so everyone knows who is responsible when it runs without a human in the loop.

Why This Is Worth Your Time

These skills are not a side hobby. They open doors. The accountants who pick up SQL, reconciliation discipline, UAT, and this analytics framework are the ones moving into roles like Financial Analyst, FP&A, Accounting Analyst, and Finance Transformation. You are not abandoning accounting. You are becoming the accountant who can also speak data, and that combination is exactly what Big 4 and Big Tech employers are paying a premium for.

Start small. Learn to write a basic SQL query. Reconcile one number against a trusted source. Walk through one UAT test case. Each step compounds. You teach yourself by doing the real work, one approachable piece at a time. I teach all of this live and free, and you can schedule at summitresume.com/resources.

Want the complete roadmap? Read The Complete Guide to Breaking Into Big Tech Finance.