--- title: "Choosing a React component library for finance software" description: "There are good dashboard kits, data grids and fintech templates. Very few of them know what a currency is. Here's an honest comparison, including when you shouldn't use this one." canonical: "https://lopifi.com/docs/guides/choose-a-finance-component-library" --- # Choosing a React component library for finance software > There are good dashboard kits, data grids and fintech templates. Very few of them know what a currency is. Here's an honest comparison, including when you shouldn't use this one. Source: https://lopifi.com/docs/guides/choose-a-finance-component-library Part of: Lopifi — Planned: US GAAP books on autopilot, checked by a CPA (https://lopifi.com) --- # Choosing a React component library for finance software There are good dashboard kits, data grids and fintech templates. Very few of them know what a currency is. Here's an honest comparison, including when you shouldn't use this one. --- ## The question to ask first Skip "does it look like finance?" Ask it to render this: ```tsx ``` A dashboard kit prints `$0.00`, `NaN`, or nothing. Those are three different bugs, and all three ship. A finance-native component prints `n/a` because it knows the difference between a number it has and one it doesn't. In an accounting product, that's the distinction that costs money. That's the first test. Four more: 1. Render `JPY 1200`. Does it print `¥1,200` or `¥1,200.00`? 2. Put `(1,234.00)` and `9,876.00` in one right-aligned column. Do the decimal points line up? 3. Render burn falling `4.2%`. Falling burn is good news, so a library that paints every negative red gets it backwards. Can you tell the component that down is good for this metric, or that the change is neutral? 4. Render a journal entry. One signed column, or two? Passing all five doesn't make a library better designed. It means someone has used it against a general ledger before. ## What is out there | Project | What it is | Where it stops | |---|---|---| | [shadcn/ui](https://ui.shadcn.com/) | The distribution model and base primitives | Deliberately domain-agnostic. It's the foundation here, not the competitor: this registry consumes it through `registryDependencies`. | | [Tremor](https://tremor.so/) | "Open-source, accessible components for dashboards and charts" (checked 2026-10-18) | Closest in spirit, and good. But dashboard-native: its site lists charts, filters and dashboard blocks, money formatting is a `valueFormatter` you supply, and we found no statement or ledger components (checked 2026-10-18). | | [ReUI](https://reui.io/) | "1,264 Free Shadcn UI Components" under MIT, plus paid Pro blocks (checked 2026-10-18) | Breadth over depth: general-purpose components rather than accounting-specific ones. | | Fintech dashboard templates | Finished apps you fork and adapt | A template, not a system. Fork-and-diverge rather than install-and-compose. | | [Shadcnblocks](https://www.shadcnblocks.com/) | Blocks and templates; paid plans from $149 one-time ([pricing](https://www.shadcnblocks.com/pricing), checked 2026-10-18) | A general block library, not a finance one. In our reading, page sections more than accounting product surfaces. | | [Recharts](https://recharts.org/) / [visx](https://airbnb.io/visx/) | Charting engines | The right choice; wrap them. They're general-purpose, so negative-aware baselines, money axes and fiscal periods are yours to add. | | [Actual Budget](https://actualbudget.org/), [Firefly III](https://www.firefly-iii.org/) | Personal finance applications | Applications, not component libraries. The UI is built for their own app, not for reuse. | Finance **templates** are plentiful. A finance **primitive system** mostly isn't. ## The gap, stated precisely Across the list above, as we read it (re-checked 2026-10-18 where a row says so), we didn't find these seven things: 1. **A money primitive**: minor-unit storage, per-currency decimals, accounting negatives, `null`/`0`/redacted as distinct states. 2. **Financial statement components**: P&L, balance sheet, cash flow, with hierarchy, rollups, period columns, variance, drill-down and correct rule lines. This is the biggest hole. We haven't found a library that ships a ``. 3. **Reconciliation UI**: two-pane matching, confidence scoring, bulk match. In our experience, accounting products rebuild it from scratch. 4. **FX primitives** that treat a rate as a perishable, timestamped fact instead of a number. 5. **Typographic accounting conventions**: case-shifted parentheses, single and double rules, em-dash nil. 6. **A motion doctrine** where the frequency of an interaction decides whether it animates at all. 7. **Designed responsive collapse for dense tables**, not `overflow-x: auto`. ## When you should not use this A comparison that recommends itself in every case is an ad, so here's when not to. - **You're building a marketing site for a fintech.** These are product surfaces. Use a blocks library. - **You need a generic admin CRUD app** and money is one field among forty. A general kit will be faster, and you won't miss the ledger semantics. - **You want a finished application to fork.** This is a set of primitives you compose. A template will get you a demo sooner. - **You're locked to a component framework** like MUI, Mantine or Chakra. These are Tailwind- and shadcn-shaped, and porting them costs more than the correctness is worth to you today. ## When you should - The interface will show a general ledger, a statement, a close, an AR or AP workflow, or multi-currency anything. - An accountant will look at it and judge it in the first four seconds. - You're prompting an AI agent to build accounting screens and need it to compose primitives that already encode the rules, instead of inventing formatting per screen. That's the whole argument of [vibe accounting](/vibe-accounting). ## What this borrows rather than rebuilds Distribution from shadcn/ui: `registry.json`, namespaced installs, copy-paste ownership. Charting from Recharts. Accessible behavior from Base UI or Radix, because nobody should hand-roll a combobox. Toasts from Sonner and drawers from Vaul, both already reference implementations of the motion doctrine here. The difference isn't more components. The formatting rules live inside the component instead of being the consumer's problem, and the statements exist at all. --- ## Judge it yourself - [Every implemented component, rendering](/showcase): with theme, density, grayscale and reduced-motion switches, where a correctness claim is actually testable - [The catalog](/components): every component, each with its spec, dependencies and full source - [Prior art](https://lopifi.com/md/docs/prior-art): this comparison as an internal document, with the re-check cadence - [Product teardowns](https://lopifi.com/md/docs/product-teardowns): what we borrow from Ramp, Mercury, Brex, Rho, Numeric, Digits, Xero and NetSuite, and what we refuse - [The manifesto](https://lopifi.com/md/docs/manifesto): the non-goals, which are the useful half