How to build a finance dashboard with OpenAI Codex

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 learn.chatgpt.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 Codex runs the commands.

1. 01

   Write AGENTS.md before there is any code to contradict it

   Codex re-reads that file at the start of every task you hand over, which makes it the cheapest place to put the two rules this build depends on.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind, and the Supabase JS client, and this project is a finance dashboard. Fix the vocabulary (company, invoice, payment, expense, bank line, daily figure, basis, base currency, rate, reject, role) and record two standing constraints. First: every figure shown is derived from records, on a stated accounting basis and at a stated rate, and anything carried forward or estimated stays flagged all the way to the card. No figure is ever hardcoded or produced by something the screen cannot explain. Second: every row belongs to a company, the company a person belongs to is what every access rule resolves to, and it is therefore never a value that person may change. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots.

   The second constraint is the one worth writing down rather than saying. It is a sentence about one column that will not be re-derived from context five tasks later, and on a multi-company finance application it is the difference between a permission model and the appearance of one.

2. 02

   One task for the schema, with the company on every table

   Nothing depends on this yet, so it is cheap to get wrong and cheap to throw away, which is exactly why it is worth reading the SQL rather than the summary of it.

   PromptModel the company and the recordsCopy

   One task, the data model, with no authentication and a company reference on every table from the start. Supabase migrations for: 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 real or carried-forward. A per-company settings table holding the accounting basis, base currency, timezone and whether future dates are allowed. Add empty daily-figure tables for revenue, expenses, cash flow, receivables and payables, by company and date. Show me the SQL before you run it, then seed two companies with deliberately awkward data: one invoicing in three currencies, one with invoices paid sixty days late.

   Read the rate table and the settings table hardest in that diff. Whether a rate is keyed per currency per day, and whether the basis lives per company rather than globally, are the two decisions every later task is written against, and both are cheap now and expensive once five jobs read them.

3. 03

   Give the parser its own task, and hand it your real file

   Export a real month out of your accounting system first. What Codex needs is not a description of your file, it is the file.

   PromptImport a real fileCopy

   One task, the import. A real CSV export from my accounting system is in the project. Read it first and report what you found before writing anything: column names, date format, how negatives and credit notes are written, total rows at the bottom, and anything you cannot map to my schema. Then build it: a private 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 stated period, amounts numeric, currency known, no duplicate of an existing record), inserts what passes and writes every failure to a rejects table with the line number and the reason. No row is dropped silently. In the diff, mark every judgement call you made about my file’s format, because those are the lines I want to read first. Then run it and give me the accepted count, the full reject list, and the sum of accepted invoice amounts.

   That instruction to mark the judgement calls is the review. A parser is nothing but small decisions about somebody else’s formatting, and a short list of them beats reading three hundred lines looking, particularly the decision about a row it only half understood.

4. 04

   One task for the figures, and read the SQL that computes them

   The task that decides whether this dashboard is worth pointing at a decision. Ask for the jobs and their SQL before either runs, and judge them on which records they include.

   PromptCompute the daily figuresCopy

   One task, the figures: server-side jobs, each rebuilding a period I name rather than appending, and not queries in a screen. 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 every amount into my base currency at the rate for that record’s own date. Where no rate exists, carry the last real rate forward, mark the figure as partly estimated, and never overwrite a real rate. Show me the SQL before you run it, and be explicit about two things I want to read rather than infer: how you group by date across timezones, and how a partial payment against an invoice affects both bases. Then print the working for one month: which records fed each figure, on which basis, how many conversions used a carried-forward rate, and both totals side by side.

   Read the partial-payment handling character by character. It is the commonest source of a finance dashboard that is subtly wrong for a quarter, because on a tidy month where everything is paid in full both bases agree and the bug is invisible.

5. 05

   Tighten the permission boundary, then read every policy

   Sign-in, and the rules standing between one company’s books and everybody else. This is a task to run Codex on a shorter leash than you would for an ordinary edit.

   PromptAdd auth, roles, and the access rulesCopy

   Narrow your permissions for this task before starting it. Everything here touches authentication. Wire in Supabase Auth for 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 off the account record, plus a SECURITY DEFINER role-check function. 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. 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 admin-only policy calls the role check in its condition rather than only in its name, which matters most 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. Each server-side function re-checks the role itself, since they run with a key that bypasses these policies. Show me every policy as SQL before it runs, then prove five things as a signed-in account: the other 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.

   Ask Codex to list which tables and operations it actually covered, then check that list against your own schema rather than assuming it came out complete. The tables forgotten here are the dull ones (the rejects table and the audit log) and both hold the same figures as the tables everybody remembered.

6. 06
   Destination

   Send the pages to a cloud run, then reconcile a month yourself

   The pages and the exports are tightly specified and self-contained, which makes them fair to hand off. The reconciliation at the end is the opposite kind of work, and it catches what reading a diff never will.

   PromptBuild the pages, the forecast, and reconcileCopy

   Two pieces, the first contained enough to run unsupervised. First, the pages, 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 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. Show the accounting basis and base currency on every page, mark any total that used a carried-forward rate, and add audit triggers on invoices, payments and expenses recording old and new values. Second, the forecast, reviewed rather than delegated: twelve months projected from my own figures with a trend and a month-of-year seasonal factor, the method and months fitted named on the chart, and any model restricted to a sentence of commentary that cannot change a number. When both are merged, 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 whatever is in the rejects table.

   Do not send the forecast to a cloud run with the pages. Its output is a claim about the future rather than a restatement of the past, and the difference between a projection you can defend and a plausible line somebody will hire against is a couple of lines you want to have read.

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 should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.