LuxorItPro

Sheet 07/16Business financeIn progress

Expense and operations management

Expenses, quotations, invoices and payroll records brought into one application with reporting.

Fig. 01 How an entry becomes a report
How an entry becomes a report How an entry becomes a report. Entry screen (One cache for server state). Then Expense or transaction (A shared shape for both). Then Quotation and invoice (Documents citing the amounts); Dashboard and reports (Reads rows the screens write). Arrows show the write path between components; a dashed arrow marks data derived from another component. Entry screen ONE CACHE FOR SERVER STATE Expense or transaction A SHARED SHAPE FOR BOTH Quotation and invoice DOCUMENTS CITING THE AMOUNTS Dashboard and reports READS ROWS THE SCREENS WRITE

Drawn from the Approach section of this write-up. No client names, no live data.

Problem

A small business usually tracks spending, quoting, invoicing and payroll in separate files maintained by separate people. Each file is internally consistent and collectively wrong: a payment appears in one place and not the other, and the monthly position is assembled by hand from returns that never quite agree.

Our role

Design and build, including the data model, the reporting views, and the screens used for daily entry.

Approach

The application is React and TypeScript on Vite, backed by Supabase on PostgreSQL. Server state is read through TanStack Query so a screen refreshes from one cache rather than from four unconnected requests, and reporting is rendered with Chart.js from the same rows the entry screens write.

Expenses and financial transactions share a common shape, with quotations and invoices as documents that reference it rather than duplicating amounts. Vehicle records and payroll-related entries sit alongside them because they were the second and third spreadsheets in the same workflow. Dashboards read the same tables, so a figure on a chart and a figure on a list cannot diverge.

Outcome

The workflow is built end to end in the application, and the reporting views render from live rows. Until the calculations have been reviewed against the business's own accounting treatment, this stays an operational tool rather than a ledger, and it is described that way on purpose.

Notes

No financial data, customer names, or figures from real records appear here. Dates that could identify a transaction are deliberately omitted.

All case studies Start a project