How to build a finance dashboard with v0

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, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   Sketch the overview and one detail page, and stop there

   The shape of the thing, with placeholder figures, in one chat. The point is to settle which five numbers belong on the overview before anything is stored anywhere.

   PromptSketch the dashboard screensCopy

   Build the shell of a finance dashboard in Next.js with placeholder content for now: an overview page with KPI cards for revenue, expenses, profit, cash and receivables, each with a period-on-period change, plus a revenue chart and an expense breakdown. One detail page, receivables, with ageing buckets and a days-sales-outstanding figure. Include a filter bar for period, currency and segment, and put a visible slot on every page for the accounting basis and base currency the figures are on. Show me the empty state for a company that has imported nothing yet, because that is what this app looks like on its first day. Keep it readable on a phone. Somebody will check cash on a phone.

   Use Design mode for the visual corrections rather than describing them. On a dashboard, the density of a KPI card and whether a change indicator reads clearly at a glance are most of the product, and those are exactly what Design mode is for.

2. 02

   The hard stop: a real export, and every placeholder retired

   Add the database integration, then hand over an actual month from your accounting system. Nothing else gets built until the cards are reading imported rows.

   PromptModel the company and import a real fileCopy

   A Supabase integration is now connected. Two things in this chat, and no new screens. First, the schema, with 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. Bank lines with a date, an amount and a direction. A rate table keyed by currency and date with a flag for real or carried-forward. A per-company settings table with the accounting basis, base currency, timezone and whether future dates are allowed. Empty daily-figure tables for revenue, expenses, cash flow, receivables and payables. Second, the import: a private bucket restricted to CSV and scoped per user folder, and a server-side route that parses an upload, validates every row (required fields, parseable dates inside a stated period, numeric amounts, known currency, no duplicate of an existing record), inserts what passes and writes every failure to a rejects table with the line and the reason. A real export from my accounting system is in the project: read it first and tell me what you found before writing the parser. Then import it and take the placeholder figures out of the two pages I already have.

   Do not let this chat end with a placeholder still on screen. Everything after it reads real rows, and a card designed against an invented figure has to be rebuilt the moment the real one turns out to be negative, or in another currency, or missing for the first three weeks of the period.

3. 03

   The figures, in the database, in their own chat

   The step that decides whether the cards mean anything, and the one where a tool that leads with interfaces will cheerfully hand you a total computed in a component.

   PromptCompute the daily figuresCopy

   New chat, for the figures. Build them as database jobs invoked by a server-side route, each rebuilding a period I name, not as arithmetic in a route handler and definitely not in a component. Revenue from invoices by issue date for accrual and from payments by their own date for cash, computed both ways. Expenses by date and category. Cash flow as inflows and outflows from payments and bank lines with a running balance. Receivables and payables outstanding, bucketed by how overdue, plus days-sales-outstanding. Convert into my base currency at the rate for each record’s own date, carrying the last real rate forward where none exists, marking the resulting figure as partly estimated, and never overwriting a real rate. What I am asking you not to do is fetch rows and sum them in JavaScript. The arithmetic belongs next to the data, and the reason is not speed, it is that two pages summing the same rows in two places will eventually disagree. Then print the working for one month, with both bases side by side.

   Say "not in JavaScript" and then check the diff for it. Fetching and reducing is the natural thing to write when the interface came first, and here it produces the specific failure that destroys trust in a dashboard: two screens showing different totals for the same month, both of them defensible.

4. 04

   The remaining pages, now that a figure means something

   Revenue, expenses, profitability and cash flow over real computed figures. Fast, because the hard part is behind you and these are the screens v0 is best at.

   PromptBuild the remaining pagesCopy

   Add the rest of the pages, all reading the computed daily figures rather than the raw records: revenue with filters that drill down to the invoices behind a total. Expenses by category with the same drill-down. Profitability with the margin definition printed beside the number. Cash flow with a running balance. A reports page offering downloadable profit-and-loss, cash-flow and expense packs as PDF and CSV. Every page shows the accounting basis and the base currency it is on, and marks any total that used a carried-forward rate. Keep the filter bar from step 01 working across all of them and let a filter set be saved and reused. Nothing here computes a figure of its own. If a number you need does not exist in the figures tables, tell me and I will add it there rather than in a page.

   That last sentence is worth keeping in the prompt. The moment one page computes something the figures tables do not have, you have two sources of truth and no way to tell which one a reader was looking at, and it always starts with a single innocuous percentage.

5. 05

   One company’s books: auth and access rules, in their own chat

   One company’s books, and everybody who should not see them. Its own chat again, and its own reviewable diff.

   PromptAdd auth, roles, and the access rulesCopy

   New chat, for authentication and access rules. Add email-and-password sign-up, login, logout, a persisted session, and a profile row per account carrying its company. Add two roles (admin and viewer) in a separate table rather than on the account record, with a security definer function to check a role. Then row-level security on every table, with two things done deliberately. 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, because which row you may edit and what that row may become are different questions and this column is what every other policy resolves to. Two: any policy meant to be admin-only calls the role check in its condition rather than only in its name, most importantly on the roles table itself, since a viewer who can write it is an admin. Beyond that: only an admin writes records, changes settings or triggers the jobs. A viewer reads everything and writes nothing. Every server-side route re-checks the role itself. Then prove five things as a second signed-in account: the other company’s invoices are unreachable, its 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.

   Give this its own pull request rather than stacking it on the pages. Of every change in this build, the access rules are the one you will most want to read back as a single self-contained diff in six months, when somebody asks what stops one client’s accounts appearing in another client’s dashboard.

6. 06
   Destination

   The forecast, the audit trail, then merge and reconcile

   The line to the right of today, the record of who changed what, and a month checked against your own books before anything is merged.

   PromptBuild the forecast, the audit trail, and reconcileCopy

   Last chat. First the forecast: project the next twelve months from my own computed figures using a trend and a month-of-year seasonal factor, and name the method and the number of months it was fitted from on the chart itself. If a model is involved at all, restrict it to one sentence of commentary that cannot change a number, and label that sentence as commentary in the interface and not only while it is loading. Then audit triggers on invoices, payments and expenses recording the old and new values of every change, with a screen to read them. Then, before I merge: reconcile with me. Take one real month, put your revenue, expense and cash figures beside the same three from my accounting system, and account for every difference, including whatever is in the rejects table. Tell me plainly if any of them do not match.

   Reconcile before the merge, not after. A merge into the branch your Vercel project deploys from is the moment this stops being your dashboard and starts being the one somebody else quotes in a meeting, and the figures should have been checked against a source you trust before that happens.

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.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.