How to build a finance dashboard with Lovable

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 docs.lovable.dev, checked August 2026.

Only the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.

1. 01

   Attach the database before you ask for a single chart

   Any dashboard designed over data that does not exist yet gets rebuilt the day it does. Connect the database first, and put the two rules this build rests on into the conversation while it is still short enough for them to hold.

   PromptSet up the projectCopy

   Connect my Supabase project before building any screens at all. Then set up a finance dashboard, and hold two rules for the rest of this project. First: every figure on screen is worked out from records, on a stated accounting basis and at a stated exchange rate, and anything estimated or carried forward stays marked as such right through to the card. Never a hardcoded number, and never a figure the screen cannot explain. Second: every row belongs to a company, the company a person belongs to decides what they can see, and so it is never a value that person is allowed to change. Use these words consistently: company, invoice, payment, expense, bank line, daily figure, basis, base currency, rate, reject, role. Confirm the connection is live, then tell me which of those two rules changes how you will design the settings and the rate tables, before you design them.

   That closing question earns its extra exchange. It is the cheapest way to find out now whether the model Lovable has in mind keeps a rate per currency per day with a flag on it, or plans to convert on the fly with whatever rate is handy, and only one of those two can answer a question about a total six months from now.

2. 02

   Design the tables, with a company on every one of them

   The one step where getting it right is worth more than getting it visible. Everything you build afterwards reads what you settle here.

   PromptModel the company and the recordsCopy

   Design the tables, with no sign-in yet, and put a company on every single one 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. A rate table keyed by currency and date with a flag for whether the rate is real or carried forward. A settings table per company holding the accounting basis (accrual or cash), the base currency, the timezone, and whether future dates are allowed. Add empty tables for the daily figures we will compute later: revenue, expenses, cash flow, receivables and payables, by company and date. Then add sample data for two companies, deliberately awkward: one invoicing in three currencies, one with invoices paid sixty days late.

   Bookmark the version once these tables exist, before anything reads them. Changing the shape of the rate table or the settings row later is the change in this build that touches every figure at once, and remember that restoring code in Lovable does not roll back your database, so a bookmark and a clear decision are worth more here than anywhere else.

3. 03

   Import your own file, and look at what it refused

   Export a real month out of your accounting system before this message. The interesting part of this step is not the upload, it is the list of rows that would not go in.

   PromptImport a real fileCopy

   Build the import. A private storage bucket restricted to CSV, scoped so a person can only reach their own folder. A server-side function that parses an uploaded file, 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), writes the rows that pass into the right table, and writes every row that fails into a rejects table with the line number and the reason. Nothing is dropped silently. Then a screen where I upload a file, watch it process, and see the accepted count beside the full reject list. I am going to upload a real export from my accounting system, so before we start, tell me what column names and date format you are expecting and what you will do with a row you only half understand, and after the import, show me the sum of accepted invoice amounts so I can check it against my own books.

   Ask what it will do with a half-understood row before you upload anything. The tempting behaviour (fill in a sensible default and carry on) is the one thing that makes a finance dashboard confidently wrong, and it is much easier to rule out in advance than to detect afterwards.

4. 04

   Ask for the figures as jobs, not as chart queries

   A preview cannot show you that a total is wrong, because a wrong total looks like a number. Ask for the arithmetic explicitly and check one month against something you already trust.

   PromptCompute the daily figuresCopy

   Build the figures as server-side jobs that rebuild a period I name, rather than as logic inside a screen, and treat this as the most important message in the project. 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 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 everything into my base currency at the rate for that record’s own date. Where no rate exists for that date, carry the last real rate forward and mark the resulting figure as partly estimated, and never overwrite a real rate with a carried-forward one. Then show me two things by running them: the working for one specific month: which records fed each figure, on which basis, and how many conversions used a carried-forward rate, and both the accrual and cash totals for that month side by side.

   Bookmark before you send this one too. The figures are the message most likely to take two or three goes, and coming back to a version you know produced a correct month beats untangling a half-changed set of jobs when you no longer remember which total was the right one.

5. 05

   Two roles, and the rule about what a row may become

   Your figures are now in a database, and the two things that matter are that another company cannot see them and that a reader cannot change them. This is the step where a preview is least able to reassure you.

   PromptAdd auth, roles, and the access rulesCopy

   Add email-and-password sign-up, login, logout, a persisted session, and a profile row per account carrying the company it belongs to. Add two roles (admin and viewer) in their own table rather than on the account record, with a security definer function to check a role. Then turn on row-level security across every table, and do two things deliberately rather than quickly. One: every rule scopes rows to the person’s company, and the rule that lets somebody update their own profile must carry an explicit with-check forbidding a change to which company it points at. Which row you may edit and what that row may become are different questions, and this column is what every other rule depends on. Two: any rule meant to be admin-only has to check the role in its condition and not merely in its name, and that matters most on the roles table itself, because a viewer who can write it is an admin. Beyond that: only an admin may write records, change settings or run the import and figure jobs. A viewer reads everything and writes nothing. Each server-side job checks the role itself, since those run with a key that bypasses these rules. Then, in the preview with a second account, show me five things: the other company’s invoices are unreachable, its figures are unreachable, a viewer cannot add an expense, a viewer cannot change the base currency, and an account cannot move its own profile to another company.

   Ask for those five as things you click rather than a summary of the rules. The last one especially: it is a perfectly ordinary profile edit right up to the final clause, which is exactly why it survives every test somebody thinks to write and why it is the one to watch fail with your own eyes.

6. 06
   Destination

   The pages, an honest forecast, and a month reconciled

   The seven pages, the exports, the audit trail, and then the part that decides whether any of it gets used: checking a month against your accounting system.

   PromptBuild the pages, the forecast, and reconcileCopy

   Finish the app. The pages, all reading the computed figures rather than the raw records: an overview of KPI cards. Revenue with filters that drill down to the rows behind a total. Expenses by category. Profitability with the margin definition printed beside it. Cash flow with a running balance. Receivables and payables with ageing buckets and days-sales-outstanding. A reports page with downloadable profit-and-loss, cash-flow and expense packs as PDF and CSV. Put the accounting basis and the base currency on every page, and mark any total that used a carried-forward rate. Then the forecast: project the next twelve months from my own 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 you want a model involved, it may write one sentence of commentary and may not change a number. Then audit triggers on invoices, payments and expenses recording old and new values. Finally, reconcile with me in the preview: 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 anything in the rejects table.

   The version that reconciles is the one to bookmark, before a domain or anything else touches it. It is your last recorded point where a real month came out right, and on this application that is a much more meaningful checkpoint than a version where everything merely renders.

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.

One button, and the app you have been previewing is live.

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.

You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.