Product teardowns

The moodboard sets the visual register. This page goes product by product through the finance software category and says what we take and what we refuse.

How to read this. Where we quote a product's own description, the URL and the date we checked it are next to the quote. Everything else is our opinion of a product's public design and what's worth borrowing from it. It makes no claim about how the product works or what it ships. Facts about another company that we couldn't source were taken out.

Lopifi has to serve two cohorts:

• The spend/banking layer: Ramp, Mercury, Brex, Slash, Rho, Navan, Bill. This is where money moves. Consumer-grade polish, high-frequency use, strong opinions about the primary action.
• The accounting layer: Puzzle, Digits, Numeric, FloQast, Campfire, Rillet, Xero, QBO, NetSuite. This is where money gets recorded. Dense and workflow-heavy, and in our view the bigger design opportunity.

Across both, the products we admire make the core action obvious for one specific role, show the numbers competitors hide (fees, rates, limits), and add friction on purpose in high-stakes flows. Most of this design system follows from that.

---

Cohort 1 — Spend & banking#

Ramp#

To us, the clearest model in this cohort for how a finance UI should be organized.

What we take from it, as design ideas:

• Lead with the exception. The dashboard shows what's wrong (anomalies, policy violations, duplicate vendors, unused subscriptions) ahead of total spend.
• The table is the hero surface. Row density, column hierarchy and bulk selection get the craft most products spend on a marketing hero, because transaction review is most of the work.
• Bulk operations are the main path. Select 40 transactions, categorize them, create a rule from the pattern.
• Savings framed as a product outcome. We note it here and refuse it below.

Lopifi takes:

• AnomalyCard in the core catalog, and no generic "welcome back" hero anywhere.
• BulkActionBar and CategoryPicker, with rule creation inline from a single transaction and a match-count preview.
• Suggestions always show their basis: "coded to Software because the last 6 charges from this vendor were", where others show an opaque confidence score. Encoded as a rule in icons & microcopy and in ReconciliationView's match suggestions.
• The transaction table gets the same design budgetFinance & planningBudgetThe plan for a period, line by line, approved before the period starts and held fixed while it runs, so actual results can be measured against it. Built on the same basis as the books — an accrual budget for accrual books — or every variance is partly a basis difference as the balance card.

Lopifi refuses:

• Marketing-grade motion inside the product. People review spend hundreds of times a day, so the frequency law makes it near-motionless.
• Framing every number as a saving. Accounting has to present neutral facts, including bad ones.

Mercury#

To us, the design benchmark of the cohort. You'd recognize a screenshot without the logo. The moodboard covers it in detail.

Lopifi takes: the one-accent law, a small brand palette against a larger structural one, decoration that never marks something clickable, and one trusted number per surface. All of it is in color.

Lopifi refuses: a dark-first default, because our users read dense numeric tables for eight hours next to a spreadsheet and often print. Also a proprietary display face. Ours has to look right in Inter and Geist Mono.

Brex#

What we take from it, as design ideas:

• Commit to one brand color.
• Policy enforced at the point of spend. Limits, categories and vendor restrictions apply when the money moves, before anyone has to catch them at review.

Lopifi takes:

• Prevention over detection, everywhere. BillForm runs duplicate detection before save. ExpenseCapture shows policy violations at entry. A control that fires when someone acts costs them a second. The same control at review costs a week.
• Committing hard to one accent. Ours is ink blue.

Lopifi refuses: brand color as a functional color. Green means "favorable" and never means "us".

Slash#

Describes itself as "The only card, expense, accounting, and banking platform you'll ever need", lists Virtual Accounts for separate pools of money, and offers credit lines through partner lenders (slash.com, checked 2026-10-18).

What we take from it, as design ideas:

• Purpose-scoped money. Money organized by what it's for (a campaign, a client, a product line) instead of one pooled balance. Businesses think about money this way.
• Cash and credit in one position view. We'd show them as two lines, below.

Lopifi takes:

• Dimensions. A purpose-scoped account is a dimension on the ledgerFoundationsLedgerA book of accounts, each holding the entries posted to it. The general ledger holds every account; a subledger — AR, AP, fixed assets — holds the detail behind one control account and must agree to it (see the accounting model). Every balance, statement and chart in Lopifi can be scoped by dimension, and the header always states the scope.
• Available-to-spend states its composition when it includes credit: cash and available credit as separate lines that sum, never one blended figure. Blend them and a company thinks it has runwayCash & runwayRunwayRunway is a cash and runway metric, calculated as Cash ÷ net monthly burn.Cash ÷ net monthly burn it doesn't.

Lopifi refuses: a credit line inside a cash balance. A credit line is a liability, and the balance sheetStatementsBalance sheetAssets, liabilities and equity at a point in time, proving the accounting equation says so.

Rho#

What we take from it, as a design idea: the accounting integration as a first-class surface, with sync status, mapping and errors shown in the product instead of buried in settings.

Lopifi takes: bank-connection status (AccountCard) and integration health live in the product. A broken sync that keeps showing old numbers is the most dangerous state a finance product can be in, so it gets a prominent component (StaleIndicator) instead of a gray dot in an admin panel.

Bill.com / Navan#

What we take from them, as design ideas:

• Approval workflows as a product in their own right: the approval inbox, approving from a phone, the audit trailControlsAudit trailThe immutable record of every state change.
• Policy at the point of booking, so the violation never happens.

Lopifi takes: ApprovalInbox is mobile-first, with the source document rendered inline. Approvals happen on phones between meetings, and an approver who has to click through to see the bill eventually stops clicking through. See payables.

Stripe and Wise belong in this cohort too. The moodboard covers what we take from each.

---

Cohort 2 — The accounting layer#

We think Lopifi's opportunity is here. The spend layer is well designed and crowded. In the accounting layer the workflows are hard and, in our view, nobody has settled on the right UI.

Puzzle#

Describes itself as "AI-native accounting software + Puzzle accounting services", for startups, small businesses and the accounting firms that serve them (puzzle.io, checked 2026-10-18).

Takes: accountant and operator are two different users of the same data, and the UI should say which it's addressing. Lopifi handles this with density modes and role-scoped surfaces instead of two products. The same ProfitAndLoss is comfortable for a founder and compact for a controller closing the books.

Digits#

Describes itself as "the first AI-native general ledgerFoundationsGeneral ledgerThe complete set of accounts, holding every posted entry for business owners and accountants" (digits.com, checked 2026-10-18).

Takes: a self-maintaining ledger is the right goal, and it means every automated action has to be inspectable and reversible. In Lopifi an auto-matched item can be reviewed and reversed, and auto-categorization rules default to autoPost: false. You can't defend an automation at audit if you can't inspect it.

Refuses: full autonomy as the default. The accountant answers for the numbers, so the UI makes their review fast and keeps them in it. Every suggestion in Lopifi shows its basis, and anything material needs a human to accept or reject it.

Numeric, FloQast, BlackLine#

The close-management lane. The ideas below come from the category as a whole and don't describe any one product.

Takes (the biggest structural borrow on this page):

• The close is a first-class object with a pipeline, owners, gates and sign-offCloseSign-offFormal approval that a section is complete. CloseStatus, CloseChecklist, AccountTieOut and FluxAnalysis are in the core catalog. See periods & close.
• Flux review with required explanations on material variances, and unexplained material variances as the reviewer's worklist.
• Sign-off is irreversible, audited, and bound to a version of the numbers.
• Every balance sheet account needs supporting evidence, and an account without any is itself a finding.

Refuses: the close as a separate system beside the ledger. In Lopifi the close runs on the same components that render the statements, so a tie-outCloseTie-outProving a GL balance against supporting evidence failure shows on the balance sheet itself.

Campfire / Rillet#

Both call themselves "The AI-Native ERP" and advertise multi-entity consolidation and revenue recognitionRevenue recognitionRevenue recognitionDeciding when, and how much, revenue is recorded — under US GAAP, when (or as) control of a promised good or service transfers to the customer, at the consideration the entity expects to be entitled to (campfire.ai, rillet.com, checked 2026-10-18).

Takes: multi-entity is table stakes, and retrofitting it is brutal. Lopifi makes entityId a required dimension on every transaction from day one, and EntitySelector, ConsolidationView and IntercompanyMatrix are core. See multi-entity & FX.

Xero & QuickBooks#

The incumbents, and the products many users will compare you against.

Takes:

• Bank reconciliationCloseReconciliationComparing our record to an external party's as the daily habit loop. "Suggest a match, one click to accept" is, to us, the right loop. ReconciliationView inherits it.
• The chart of accountsCore ledgerChart of accountsThe account structure is a user-facing object. People customize it constantly.
• Integration breadth is a moat, so components have to cope with imported data that's messy, partial and read-only. That's why source: "integration" entries are read-only with a link back.

Refuses:

• Modal-inside-modal navigation.
• Treating mobile as a cut-down viewer. People mostly approve, capture receipts and check balances on their phones. See responsive & input.
• The single-signed-amount column. Blur debit and credit together and users can no longer check the entry.

NetSuite#

Takes: mid-market companies need that depth of data model (dimensions, subsidiaries, revenue arrangements, allocation schedules), which is why the domain layer in these docs goes so deep.

Refuses: a deep data model as an excuse for a hard interface. We think you can have both the depth and a good UI.

---

Synthesis#

Layer	Our reference (opinion)	What Lopifi takes
Visual system	Mercury	Accent scarcity, one trusted number
Table craft	Ramp, Stripe	The table is a hero surface; bulk ops are the main path
Exception surfacing	Ramp	Show what's wrong, not what's normal
Prevention over detection	Brex, Navan	Controls fire at entry, not at review
Fee & rate honesty	Wise, Stripe	Itemize everything; timestamp every rate
Approval workflow	Bill, Rho	Mobile-first inbox with the document inline
Close management	Numeric, FloQast	The close as a first-class gated pipeline
Reconciliation loop	Xero	Suggest, one-click accept, inspect and reverse
Multi-entity depth	Campfire, NetSuite	Entity as a required dimension from day one
Automation posture	Digits (partially)	Inspectable and reversible; never silently autonomous
Dimension thinking	Slash	Purpose-scoped money, generalized as dimensions
Speed as aesthetic	Linear	Keyboard actions are motionless
Documentation	Stripe, Sonner	The docs site is the product

The gap, as we see it#

Our reading of the field: the spend layer leads on design, the accounting layer on accounting depth, and we have not found a component system that brings the two together.

Lopifi sits where they meet: Mercury's restraint and Ramp's table craft, applied to Numeric's close and NetSuite's data model, distributed as components you own. That's why the domain layer in these docs is as long as the design layer.