In this post I explain how we design B2B fintech products at Studio Scale: what is different from consumer fintech, the spend loop we design around, how we design roles and approvals so they get used, why reconciliation is the screen that decides adoption, how we design the accounting export, and what the admin side needs. Our earlier post on fintech product design covers KYC and transaction flows. This 1 is about what happens when the customer is a company.
What is different about B2B fintech product design
The user is not the buyer. An employee spends, a manager approves, a finance lead reconciles, an accountant books, an owner signs the contract. Each is a different person with a different device and a different 10 minutes. The finance lead decides renewal, and most products are designed for the employee.
The deadline is the month. Consumer money moves in seconds. Business money is judged on the 1st of the month, when everything has to match and the books have to close. A product that is pleasant on day 12 and unusable on day 1 is not adopted.
The record matters more than the transaction. In consumer fintech, the transfer is the product. In B2B, the transfer is 1 line in a record that has to survive an audit 2 years later: who spent, who approved, which receipt, which category, which ledger account. If the record is incomplete, the finance lead builds it in a spreadsheet.
The spend loop we design around
Before screens, we map the loop. Every B2B fintech product we have worked on, from an invoicing tool for freelancers to a card and expense platform to a business account with multi user access, runs on the same 5 steps.
Spend or bill
The employee or the supplier does it. The product has to show what was paid, to whom, from which budget. Products usually fail with a transaction with no context.
Document
The employee does it. The product has to show receipt, category and note, in under 30 seconds. Products usually fail with a form with 9 fields on a phone.
Approve
The manager does it. The product has to show 1 screen: what, who, how much, approve or ask. Products usually fail with a login link and a list.
Reconcile
The finance lead does it. The product has to show what matches, what is missing and who to chase. Products usually fail with an export button.
Book
The accountant does it. The product has to show clean lines in the ledger, mapped, once. Products usually fail with a CSV that needs 2 hours of editing.
When we run a UX audit on a B2B fintech product, we ask 5 customers what they export and when. The step where the export happens is the 1 we design first, and it is almost always reconcile.
Roles and approvals that get used
An approval flow exists in most products and is used in few. The reason is that it is designed as a permission system, not as a decision.
We design approvals in 3 layers.
The rule, written as a sentence
"Expenses over 500 from the marketing team need Sara's approval. Over 5,000, Sara and the CFO." If the finance lead cannot write the rule as a sentence in settings, the product will not enforce it the way they expect. The settings screen shows the sentence and the exceptions, not a matrix of checkboxes.
The decision, on a phone, in 20 seconds
The manager gets a notification that opens directly on 1 card: amount, who, what, receipt thumbnail, budget left, 2 buttons. Approve, or ask a question that goes back to the employee inside the product. No login wall, no list to search. We have watched managers approve 14 expenses in a lift with this screen and 0 with a dashboard.
The record, automatic
Who approved, when, under which rule, attached to the transaction forever. The accountant never asks.
Roles follow the same logic. An employee sees their own spend and their budget. A manager sees their team. The finance lead sees everything and the exceptions first. We write the 5 role views as a table in week 1, and it usually removes 25 percent of the planned screens, because 3 roles need far less than the founder assumed.
Reconciliation is the screen that decides adoption
Reconciliation is the step nobody puts in a pitch deck, and it is the 1 the finance lead judges the product on.
The screen has 1 job: show what does not match, and let the finance lead fix it without leaving. Transactions with no receipt, sorted by amount, with 1 tap to chase the employee inside the product. Receipts with no transaction. Amounts that differ from the invoice. Categories missing. Approvals pending past the deadline.
The default view is the exceptions, with a count at the top: 23 items to resolve before close. Each item has the action inline, upload, recategorise, chase, approve. When the count reaches 0, the month can close, and the product says so.
On the spend management product, this 1 screen replaced the monthly export for 3 of the 5 finance leads in the 1st month. The other 2 needed the accounting export fixed first.
The accounting export is a product, not a button
Every B2B fintech product has an export to the accounting system. Most of them produce a file the accountant edits for 2 hours before importing, which means the product was 80 percent adopted and the last 20 percent happens in Excel.
We design the export in 3 parts.
The mapping, once
Categories to ledger accounts, teams to cost centres, tax rates to tax codes. Set up in week 1 with the accountant, shown as a table, editable. Every unmapped item appears on the reconciliation screen, not in the export file.
The preview, before every export
What will be sent, how many lines, what is still unmapped, what changed since last export. The accountant sees the file before it exists.
The sync, with a status
Sent, accepted, rejected with a reason per line, and a retry that does not duplicate. A sync that silently fails on the 2nd of the month is the most expensive bug in B2B fintech, because the books are wrong and nobody knows until the auditor asks.
The same discipline applies to a direct integration. Connected, syncing, failed with a reason, last successful sync at a time. A product with 3 accounting integrations has at least 12 failure states here, and we draw all of them.
The admin side the buyer sees
The person who signs the contract sees 4 screens in the trial and decides on them.
Onboarding for a company, not a person
Company verification, then inviting people by role, then connecting the bank and the accounting system, as a checklist with a reason per item and a state per item. Half done is a state, and the product has to say what works already.
Limits and controls
Card limits per person and per team, merchant categories blocked, budgets per project, all readable as sentences and changed in 2 taps. The owner wants to know that nobody can spend 10,000 on a Saturday without a rule catching it.
The audit trail
Every change to a limit, a role or a rule, by whom and when, exportable. This is 1 screen and it is the reason a CFO says yes.
Multi entity
Companies with 3 legal entities want 1 login and 3 sets of books. If the data model does not know about entities on day 1, it is a rebuild on day 300. We ask in week 1.
Where AI tools help and where they do not
AI tools help with the volume of a B2B fintech product. Reading a receipt into amount, merchant, date and a suggested category, which customers now expect. Drafting the 60 status and error strings for the sync. Generating test data with 3 entities, 400 transactions and 23 exceptions so the reconciliation screen is tested with a real month.
They do not help with the structure. Which roles exist and what each 1 sees is a decision made with 5 customers, not a model. What the approval sentence can and cannot express depends on how your customers actually organise budgets. And an AI category suggestion still needs the same discipline as any financial action: show the suggestion, let the person confirm, keep the record of who confirmed. Our AI product design page covers that side.
Mistakes we see most often in B2B fintech products
Designed for the employee, bought by the finance lead
A beautiful card app and an export button.
Approvals as a permission matrix
Nobody can write the rule, so nobody trusts the rule.
Approval via a login link
The manager approves in email and the product still says pending.
Reconciliation as an export
The month closes in a spreadsheet, and the product is a data source.
Mapping inside the export
The accountant fixes the same 40 lines every month.
FAQ
What does B2B fintech product design cover?
The 5 step spend loop: spend or bill, document, approve, reconcile, book. Role views for 5 roles, approvals as a sentence and a card, reconciliation built around exceptions, an accounting export with mapping, preview and sync status, and the admin side with limits, audit trail and multi entity.
How do you design approval flows that managers actually use?
As a decision, not a permission. The rule is written as a sentence in settings, the manager gets 1 card on the phone with the amount, the person, the receipt and 2 buttons, and the record is attached to the transaction automatically. No login wall, no list to search.
How do you reduce the monthly export to a spreadsheet?
By designing reconciliation as an exceptions list with inline actions and a count to 0, and by moving the category and ledger mapping out of the export into a settings table set up once with the accountant. Everything unmapped appears on the reconciliation screen, not in the file.
Do you design the accounting integration side?
Yes. Mapping, preview before export, sync with a status per line, retries that do not duplicate, and every failure state for each integration. A product with 3 accounting integrations usually needs 12 or more of them drawn.
How long does B2B fintech MVP design take?
For a product with 25 to 35 screens across 4 roles, 6 to 8 weeks, with the approval card, the reconciliation screen and the export preview prototyped and tested with 3 finance leads in the 1st 2 weeks. It runs 1 to 2 weeks longer than consumer fintech because of the role count and the accounting review loop.
Working with us
We design B2B fintech products, business banking, spend and expense management, invoicing and accounts payable tools, around the 5 step spend loop. A 25 to 35 screen B2B fintech MVP takes 6 to 8 weeks. For a live product where customers export every month, the same work runs as conversion UX design on 1 step of the loop at a time. Our approach and examples are on the fintech product design page.
We also say when you do not need us. If your finance leads close the month inside the product and nobody exports, your loop works and your next problem is sales. If you have 400 companies and do not know which step they leave for a spreadsheet, a 1 week UX audit with 5 finance leads will tell you, and it costs less than rebuilding the wrong step.
If your customers export on the 1st of every month, book a free 15 minute intro call and send us 1 exported spreadsheet before it. We will tell you which screen it should have been.
