How to build a finance dashboard with Claude Code

Rule of thumb: if the numbers must arrive automatically rather than through a file, if several entities need consolidating, if a client expects a branded pack with a review trail, or if somebody would rather ring a supplier than read a query, rent. If what you want is your own five numbers, defined the way your business defines them, in a currency you chose, with a bill that does not move when you open a second company, that is the half worth owning. One honest note either way, from the same survey as the figure above: 68% of those senior finance people said manual work leaves their organisation vulnerable to decision-making errors. Building the dashboard does not fix that by itself. It fixes it on the day you stop maintaining the spreadsheet beside it.

* Two free-tier lines matter here, and neither is the one people check. The 500 MB database is enough for years of records, because financial data is small. What bites is the pause: a free project stops after a week of inactivity, and a dashboard read monthly is exactly the sort that goes quiet for a week. Pro, from $25/mo, ends the pause, keeps a daily backup for 7 days, and lifts egress to 250 GB (then $0.09 per GB) and file storage to 100 GB (then $0.0213 per GB), the second being where imported files accumulate.

Either way the dashboard is yours, and the only running costs are the database tier and whatever the forecast spends on a model. The difference between the columns is who does the work: pay someone up front, or describe what you want and build it yourself.

Prices and rates from supabase.com, developex.com and claude.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Get it running, and write down what a figure is allowed to be

   An app booting against your own database, and a CLAUDE.md carrying the two rules the rest of this build depends on.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a finance dashboard (company, invoice, payment, expense, bank line, daily figure, basis, base currency, rate, reject, role) and recording two standing rules. First: every figure on screen is derived from records, on a stated accounting basis, at a stated exchange rate, and anything estimated or carried forward is flagged as such all the way to the card. No number is ever hardcoded, rounded into a constant, or produced by anything the screen cannot explain. Second: every row belongs to a company, the company a person belongs to is the answer every access rule depends on, and therefore it is never a value that person can change.

   Put both in the file rather than only in this message. The second one sounds like a technicality and is the whole security model of a multi-company finance app: the instant somebody can edit which company they are in, every other rule in the schema is decoration.

2. 02

   Model the company first, then everything that hangs off it

   The schema, with a company on every row from the very first migration. No authentication and no screens yet, which makes this the cheap moment to find out your own records need a field nobody thought of.

   PromptModel the company and the recordsCopy

   Write the data model as Supabase migrations, with no authentication yet and a company reference on every table from the start. Companies. Profiles linking an account to a company. Customers and vendors. Invoices with an issue date, a due date, an amount, a currency and a customer. Payments against invoices with their own date. Expenses with a date, an amount, a currency, a vendor and a category, plus my own category table. Vendor bills for payables. Bank lines with a date, an amount and a direction. An exchange-rate table keyed by currency and date with a flag for whether the rate was real or carried forward. A per-company settings table holding the accounting basis (accrual or cash), the base currency, the timezone and whether future dates are allowed. Then empty tables for the daily figures we compute in step 04: revenue, expenses, cash flow, receivables and payables, by company and date. Seed two companies with deliberately awkward data: one invoicing in three currencies, one with invoices paid sixty days late.

   Seed the two companies now rather than later. Everything that goes wrong in a multi-tenant application is invisible while there is only one tenant, and a second one with real-looking figures in it is the cheapest test instrument you will build all week.

3. 03

   Import your own export, not a tidy invented one

   Go and export a real month out of your accounting system before this step. The file you actually have is the specification for the hardest part of this build, and no amount of describing it beats handing it over.

   PromptImport a real fileCopy

   A real CSV export from my accounting system is in the project. Read it before you write anything and tell me what you found: column names, date format, how it writes negatives and credit notes, any total rows at the bottom, and anything you cannot map to my schema. Then build the import: a private storage bucket restricted to CSV and scoped so a person reaches only their own folder, and a server-side function that parses an upload, validates every row (required fields present, dates parseable and inside a period I state, amounts numeric, currency known, no exact duplicate of an existing record), inserts what passes and writes every failure into a rejects table with the line number and the reason. Never drop a row silently. Then import my real file and show me three things: the accepted count, the full reject list with reasons, and the sum of accepted invoice amounts so I can compare it against the same figure in my accounting system.

   That last number is the point of the whole step. A total you can check against your own books in ten seconds is what turns this from a plausible dashboard into one you will make decisions from, and it is far easier to compare now than after four more layers of aggregation have been built on top of it.

4. 04

   Turn records into figures, on a basis you have chosen

   The step this application is actually made of. Ask for the arithmetic as server-side jobs, then make Claude Code show its working for one month rather than a chart.

   PromptCompute the daily figuresCopy

   Build the jobs that turn records into daily figures, as server-side functions rather than queries in a screen, each rebuilding a period I name rather than appending. Revenue: from invoices by issue date for the accrual basis and from payments by their own date for the cash basis, computed both ways. Expenses: by date and category. Cash flow: inflows and outflows from payments and bank lines, with a running balance. Receivables and payables: what is outstanding, bucketed by how overdue it is, plus days-sales-outstanding. Convert every amount into my base currency using the rate for that record’s own date, and where no rate exists for that date, carry the last real rate forward and mark the resulting figure as partly estimated. Never overwrite a real rate with a carried-forward one. Then print the working for one specific month: which records fed each figure, which basis was used, how many amounts were converted at a carried-forward rate, and the totals both ways so I can see the accrual and cash pictures side by side.

   Read the two bases side by side before you go further, especially if you invoice on terms. Seeing the same month come out strong on one and thin on the other is the moment the settings row stops looking like a preference and starts looking like the most important field in the schema.

5. 05

   Sign-in, two roles, and the rule about what a row may become

   What a business earns and who owes it money now sits in a database, and two kinds of person who should not have the same power over it. This is the step to read slowly.

   PromptAdd auth, roles, and the access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, and a profile row per account carrying its company. Add a role enum of 'admin' and 'viewer' in a roles table kept out of the account’s own record, plus a SECURITY DEFINER role-check function. Then row-level security on every table, with two things done carefully rather than quickly. One: every policy scopes rows to the person’s company, and the profile update policy carries an explicit WITH CHECK forbidding a change to which company it points at. Which row you may edit is a different question from what that row may become, and this column is what every other policy depends on. Two: any admin-only policy calls the role check in its condition rather than only in its name, since a rule that merely tests company membership is not a restriction, and that matters most on the roles table itself, because a viewer who can write it is an admin. Also: only an admin writes records, changes settings or triggers the import and figure jobs. A viewer reads everything and writes nothing. Each server-side function checks the caller’s role itself, since they run with a key that bypasses these policies. Then prove five things by querying as a signed-in account: the second company’s invoices are unreachable, its computed figures are unreachable, a viewer cannot insert an expense, a viewer cannot change the base currency, and an account cannot move its own profile to another company.

   Insist on that fifth check as a query you watch fail. It is the one that decides whether this is a multi-company application or a single database with a company column in it, and it is the check nobody thinks to run because the account doing it is behaving entirely legitimately right up to the last clause.

6. 06
   Destination

   The seven pages, an honest forecast, and one month reconciled

   The screens, the exports, the audit trail, and the part most builds skip: check a month against your own accounting system before anybody makes a decision from it.

   PromptBuild the pages, the forecast, and reconcileCopy

   Finish the app. The pages first, all reading the computed figures rather than raw records: an overview of KPI cards, revenue with filters that drill to the rows behind a total, expenses by category, profitability with the margin definition printed beside it, cash flow with a running balance, and receivables and payables with ageing buckets and days-sales-outstanding. Show the accounting basis and base currency on every page, and mark any total that used a carried-forward rate. Then the forecast: twelve months projected from my own figures with a trend and a month-of-year seasonal factor, the method and the months fitted named on the chart itself, and any model restricted to a sentence of commentary that cannot change a number. Then reports: downloadable profit-and-loss, cash-flow and expense packs as PDF and CSV. Then audit triggers on invoices, payments and expenses recording old and new values. Finally, reconcile with me: one real month, your revenue, expense and cash figures beside the same three from my accounting system, every difference accounted for, including the rows in the reject table.

   Do the reconciliation before you show the dashboard to anybody else, and do it on a month you already know the answer to. Every difference you find will be one of three things (a rejected row, a basis mismatch, or a definition you and your accountant disagree about) and all three are cheap to fix now and expensive to discover in a board meeting.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks the rest here: the database service key and the model provider key belong on the server only: never in the app your colleagues download, and never in a repository. Either one that gets out is burned: replace it the same day, and check the audit log for what was done with it in the meantime.

All eight serve the app well enough that speed is not the deciding question. Three others are: does the plan permit commercial use, since Vercel’s Hobby tier does not. Does it publish from a private repository, given what this code sits beside. And does a deep link resolve for a browser that has never seen your site, because the URL people share points at the page that worried them.

The twelve-month forecast currently sends my history to a model and asks for realistic projections. Change it in two steps. First, compute a baseline in the database from my own figures (a trend over the last twelve months plus a month-of-year seasonal factor) and draw that as the forecast line, naming the method and the months it was fitted from on the chart. Second, keep the model but give it a different job: send it the computed projection and have it return a short commentary on what the shape suggests and which assumptions would break it, with no power to change a number. Label the chart so a reader can tell arithmetic on my data from a model’s opinion, in the chart, not only while it loads.

Add a screen listing imported expense rows with no category or one I have flagged as doubtful. Send the description, the vendor and the amount to my server-side ai function and get back a suggested category from my own list, plus a confidence and a one-line reason. Show them as a reviewable list I accept, change or reject in bulk, writing nothing until I do. Anything below a confidence I set stays uncategorised rather than guessing. Include recent accepted examples for that vendor so it learns from my corrections, and never invent a category that is not already in my list.

Add a "why did this move" action on any figure. Compute the answer with queries first: the top contributing categories, customers or regions behind the change between two periods, with their amounts and their share of the movement. Then send only those computed contributions (no customer names unless I turn that on) to my ai function for two or three sentences explaining the movement in plain language. Print the figures it was given underneath, state the two periods, and where the movement is mostly one row, say so rather than listing three.

After every import, run a check for rows worth a second look: amounts far outside the usual range for that vendor or customer, near-duplicate invoices, dates outside the period I said I was importing, and totals differing from last month by more than a threshold I set. Compute all of it with queries. Then send the flagged rows, without customer names, to my ai function for a one-line reason each on why it might be a mistake, and show the list with an accept or investigate action per row. Nothing is deleted or edited automatically, and the flagged count sits beside the import summary.

Add a panel where I ask about my own figures in ordinary words. Have my ai function turn the question into a read-only query against my computed figures tables, run it under my own access rules so it can never reach another company’s data, and use the model only to phrase the answer. Show the query it ran and the rows it used under every answer, state the period and the accounting basis, and refuse rather than guess when the question needs data I do not import. It never writes, and never answers from memory instead of from a query.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.