Writing Your First SQL Query: A Finance Analyst's Guide

Most finance analysts learn SQL for a very practical reason: waiting for someone else to pull an export gets old, and once you can query the source data yourself, a two-day turnaround becomes a two-minute one. The good news is that a working first SQL query only needs three clauses, and almost everything else builds on top of them.

SELECT, FROM, WHERE — the three clauses that do most of the work

Every SQL query starts from the same shape: SELECT the columns you want, FROM the table they live in, WHERE some condition narrows it down. SELECT invoice_id, customer_name, amount FROM invoices WHERE amount > 10000; reads almost like plain English, and that's deliberate — SQL was designed to be readable, not just written. Start with SELECT * (everything) to see what a table contains, then narrow to the specific columns you actually need once you know what's there.

Filtering with WHERE

WHERE supports the comparisons you'd expect — =, >, < — plus a few that come up constantly in finance queries. BETWEEN filters a range cleanly: WHERE invoice_date BETWEEN '2026-01-01' AND '2026-01-31'. IN checks against a list without stacking up OR conditions: WHERE department IN ('Finance', 'Operations', 'Legal'). And LIKE with a % wildcard handles partial text matches: WHERE customer_name LIKE 'Acme%' catches "Acme Corp", "Acme Ltd", and anything else starting with Acme. Combine conditions with AND / OR, and use parentheses once you have more than two — SQL evaluates them in a specific order, and relying on it without parentheses is how filters quietly return the wrong rows.

Sorting and limiting results

ORDER BY amount DESC sorts largest first; add a second column to break ties consistently. When you only need a preview — checking that a query looks right before running it against a huge table — LIMIT 10 (or TOP 10 in SQL Server / T-SQL) caps the result set so you're not waiting on thousands of rows just to sanity-check the shape of the output.

Aggregating with GROUP BY

This is where SQL starts replacing manual pivot-table work. SELECT department, SUM(amount) AS total_spend FROM expenses GROUP BY department; collapses every row down to one per department, with a running total for each. COUNT(), AVG(), MIN() and MAX() all work the same way. One subtlety that trips people up early: filtering an aggregated result needs HAVING, not WHERE — WHERE filters rows before grouping happens, HAVING filters the grouped totals afterward. WHERE amount > 1000 GROUP BY department HAVING SUM(amount) > 50000 uses both correctly: one filters individual transactions, the other filters the department totals.

A worked example

A common finance ask — total revenue by month, for the current year, highest months first:

SELECT MONTH(invoice_date) AS month, SUM(amount) AS total_revenue
FROM invoices
WHERE YEAR(invoice_date) = 2026
GROUP BY MONTH(invoice_date)
ORDER BY total_revenue DESC;

Read it in order of execution rather than the order it's written: filter to 2026 first, group what's left by month, total the amount within each group, then sort the totals. That execution order — FROM, WHERE, GROUP BY, then SELECT and ORDER BY — is worth understanding early, because it explains behaviour that otherwise looks inconsistent, like why you can't reference a column alias from SELECT inside a WHERE clause.

Mistakes almost everyone makes on their first few queries

Forgetting a WHERE clause on a large table and accidentally pulling millions of rows. Using WHERE when they meant HAVING on an aggregated query, and getting a confusing error. Assuming column and table names are case-insensitive everywhere — they usually are, but not always, depending on the database. And running an untested query directly against a live production database rather than a read-only reporting copy — worth checking which one you actually have access to before you start.

Where this goes next

Once SELECT, WHERE and GROUP BY feel natural, the next real capability jump is combining data that lives across multiple tables — invoices in one table, customers in another — which is what SQL joins are for. Most real finance questions need at least one join, so it's the natural next step rather than an advanced detour.

Getting comfortable without a live database to practise on

You don't need access to a production finance database to build this up. Most SQL dialects (PostgreSQL, MySQL, SQL Server's T-SQL) share the same core syntax covered above, and free browser-based sandboxes let you create a small sample table and run real queries against it with nothing to install. Practise on data you understand — a handful of invoices, a small expenses table you build yourself — so you can predict the answer before you run the query and immediately spot when something's off. That habit of predicting the result first is what turns "I copied a query that worked" into "I can write a query for a new question."

Two things make the first query land faster: why finance professionals need SQL, the difference between SQL and NoSQL and how SQL pairs with Python for analysis. Our Tech and Tools CPD for accountants turns the same material into CPD-recognised hours. Also worth reading: data analytics for accountants.