Fincline Case Study

Fincline is a payment reconciliation and accounts-payable product for small businesses and bookkeeping firms. It sits between a bank account, an accounting platform and an email inbox, matching incoming payments to open invoices and capturing vendor bills automatically.

I ran research, the stakeholder sessions that settled what we were actually building, the wireframes, the high-fidelity screens for both buyer types, and the design system behind them.

A bookkeeper loses 12 to 20 hours a week to work that is mechanical but not safe to automate blindly: about three hours hunting down ACH payments that arrive with no memo, four re-keying vendor invoices into QuickBooks, five chasing receivables nobody is tracking.

QuickBooks and Xero record what happened. They do not work out what happened. That gap is the product.

I studied the tools these people already live in: QuickBooks, Xero, Mercury, Stripe, Linear. I was looking for the patterns a bookkeeper reads without thinking, and the places those patterns run out.

The finding that shaped everything: the danger is not the payment that obviously matches, or the one that obviously does not. It is the middle, the one that looks right. That is where errors get confirmed at speed and surface at month-end close.

Sessions with the founders to resolve the ambiguities in the brief before anything was drawn: which buyer leads, what ships in the MVP, and what the product is allowed to do on its own.

The decision that set the tone: Fincline stays read-only until a human confirms. Nothing posts to the books by itself. That single rule turned out to be the product's argument for itself, and it is stated on the dashboard rather than buried in settings.

I sat with accountants and watched them reconcile. I was looking for the mental process behind a confirmation: what they check before they click, not what they click.

Three things came out of it. They do not want a score; they want a reason. They work by client, not by transaction, so a firm managing a dozen books needs one queue, not a dozen logins. And a good morning means being finished by nine, which made the ten-minute review the thing the whole interface is organised around.

The spine is a morning: money arrived overnight, the system matched what it could, and a person confirms, investigates or defers, then the books are posted and the day starts.

The exceptions carried the design weight, because they are the reason the product exists: a payment with no reference, a duplicate invoice, an expired connection that silently stops posting, a partial payment that closes one invoice and leaves another open.

Fifteen screens across two buyer types, built on one set of tokens: a blue for action, and green, amber and red carrying exactly one meaning each. Confirmed, needs review and exception read the same in a badge, a row and a status card.

One decision was made against instinct. Every fintech reference we studied used a dark sidebar; we tested it and bookkeepers found it jarring against a white content area all day. The sidebar stayed white, because familiarity was worth more here than fashion.

Payment matching took the most rounds. Early versions showed a confidence percentage, which tested badly in both directions: people either trusted 91% blindly or stalled at 88% with no idea what to do differently.

The number came out and reasoning went in: exact amount, known vendor, consistent with past payments. Then the list was split by what the reader is being asked to do: above ninety per cent groups together for bulk confirmation, the middle band is individual and deliberately slower, and anything below is quarantined as an exception that is never pre-applied. The friction in the middle is the feature.

The dashboard opens on a sentence, not a chart: what came in overnight, what matched, what needs a human. Every number is a door into the queue behind it.

Matching is where the ten minutes are actually spent, so it carries the confidence bands, the split-payment maths and the custom rules that let a firm encode a client's quirks once. The trust screens are the quiet half of the product: alerts written in plain English, an immutable audit log of every system and human action, and a connections screen that says plainly which integrations are read-only and which can write.

Fifteen screens across two buyer types on one set of tokens: the morning review, the matching queue with its confidence bands, custom rules, alerts, the immutable audit log and the connections screen. The rule the founders and I settled first, nothing posts to the books until a human confirms, survived to the shipped design and is stated on the dashboard rather than buried in settings.

The matching screen is where the work shows. The confidence percentage came out and the reasoning went in, and the queue was split by what the reader is being asked to do rather than by score. I do not have post-launch numbers for this one. The figure that would settle it is not matching accuracy but how long a bookkeeper's morning actually takes afterwards, measured against the ten minutes the interface was designed around.

Removing the confidence score was the highest-leverage decision in the project. It reframed the interface from reporting what the model thought to giving a professional what they need to take responsibility for a decision.

What I would do differently: the firm work queue is the reason a practice switches, and I designed it after the single-company flows rather than alongside them. It should have led, because the multi-client case is the harder constraint and the easier one falls out of it.