Lede

Most small-business owners do not need accounting software. They need somewhere to put the receipt before it falls out of the wallet, and a way to know if the side business is making any money. Neatbooks is that — without the jargon and without a chart of accounts.

Context

There are over 5.5 million small businesses in the UK according to the Department for Business and Trade’s 2024 Business Population Estimates, of which around 4.1 million are sole proprietorships with no employees. The accounting software market is sized around them as a defensive crouch: Xero, QuickBooks, FreeAgent, Sage. All four were built first for accountants and adapted afterwards for owners. The vocabulary alone — accruals, double-entry, journals, COGS — is enough to make a sole trader give up and hand a shoebox to an accountant in March.

The shape of the population is shifting too. The Office for National Statistics tracks a steady rise in multi-stream income: a freelancer who also rents a room, a hairdresser who also resells products, a developer who also runs a Sunday-market stall, a Bento Labs founder who runs the studio and a stake in two restaurants. None of these people have one business. Their books do not fit neatly into one product, and so they fit into none — each business gets its own software subscription, its own login, its own quarterly chasing.

Making Tax Digital for Income Tax sharpens the timing. From April 2026, sole traders and landlords with qualifying income above £50,000 are mandated onto digital records. The threshold drops to £30,000 in April 2027 and £20,000 in April 2028, roughly doubling the affected population at each step. The next two years are when several million people who have never used accounting software are about to be told they have to.

The problem

Bookkeeping tools were written for bookkeepers. The interface speaks a dialect — debits and credits, COGS, accruals, journals — that has no purchase outside the profession. A sole trader opens Xero, sees a “chart of accounts” and “bank reconciliation” on the home screen, and closes the tab. They have not learned anything; they have confirmed the suspicion that this is somebody else’s job.

The cost of that confirmation is real. The accountant they hand the shoebox to in March charges £400–£900 for a self-assessment return. If the underlying receipts are missing, the accountant defaults to conservative numbers, and the trader over-pays tax to compensate for the missing evidence. The cost of disorganisation, in cash, often exceeds the profit of the side business that caused the disorganisation in the first place.

The multi-business population has it worst. A freelancer who also rents a room is operating two distinct tax surfaces. The freelancing is self-employment income; the room is property income, governed by the Rent a Room Scheme up to £7,500 a year. They have to keep the books separately, but they only have one wallet, and the receipts come in mixed. Existing software either forces them into two subscriptions or asks them to manually tag every transaction with a business, which neither of them does, and a year later they pay an accountant to untangle what an app could have prevented.

The receipts themselves are the simplest expression of the problem. A receipt is paper. It falls out of a wallet. It fades. It gets thrown out. The cost of the dropped receipt is the VAT it could have reclaimed or the deductible expense it could have offset. A sole trader runs at a 5–20% margin on most receipts they fail to capture, and over a year the missed-receipt tax leak is real money.

The shape needed is bookkeeping that does not require the user to learn bookkeeping.

What we built

A tracking tool for income, expenses and receipts across multiple businesses in one account.

Multi-business by default. The user creates one account and adds the businesses they actually run — the freelancing, the rented room, the Sunday-market stall — as separate entities under it. Each business has its own ledger. Each ledger rolls up into one consolidated view, so the user can also see the household-level shape of their working life.

Snap a receipt. The phone camera opens to a receipt-capture surface. The image goes to a vision model that extracts the merchant, the date, the total, the VAT line and the likely category. The user confirms or corrects in a single screen. The receipt lands in the right business with the right category. The image is stored. The receipt is no longer paper.

Plain-English categorisation. The category vocabulary is the one the user already speaks — “stock”, “fuel”, “office stuff”, “client lunch” — not the accountant’s chart of accounts. Behind the scenes Neatbooks maps the user’s category to the corresponding HMRC self-assessment box (or SA105 / SA103 box) so the year-end export to the accountant is clean. The user never sees the SA mapping unless they want to.

Ask the books a question. A small conversational surface answers questions in the same language the user thinks in. “How did the takeaway do last month?” — returns a sentence and a small chart, not a balance sheet. “What did I spend on fuel this quarter?” — returns a number, the trend, and the receipts behind it. The AI surface uses the user’s own data, no external corpus, and runs every answer past a deterministic ledger query rather than hallucinating a number.

Year-end export. When March arrives, the user’s accountant gets a clean export — one CSV per business, mapped to SA boxes, with linked receipt images. The accountant gets the structured data they need; the owner keeps the rest of the year.

The goal is bookkeeping you can do on the bus. The accountant still gets clean data at year-end; the owner gets to keep the rest of the year.

Architecture

Next.js 16 App Router for the entire surface — server components for ledger views and admin, client components for the receipt capture and the chat. Tailwind 4 for the design system, shadcn/ui for the component primitives, Framer Motion for the small interaction details that take a financial app from feeling clinical to feeling human.

Neon, Clerk and Vercel Blob carry the backend. Neon Postgres for the ledger, with row-level security on every table — a multi-business product cannot afford to leak one user’s stock-cost data into another user’s view. Clerk for sign-in and account management. Vercel Blob for receipt images. Vercel Functions for the receipt-processing pipeline that runs the vision call and writes the resulting transaction.

Groq powers both the receipt-vision model and the transaction-categorisation model. The choice of Groq over the default cloud LLM providers is latency-driven: Groq’s inference times on small models are the difference between a receipt-snap that feels instant and one that asks the user to wait. The same surface handles the natural-language “ask the books a question” flow.

Resend for transactional email — welcome, magic-link auth, monthly summaries, year-end export notifications.

Framer Motion for the motion design. The product is built for a non-professional audience, and the difference between feeling like a friendly tool and feeling like accounting software is, in large part, the quality of the motion.

The architectural posture is to keep the dependency surface small and the abstractions thin. Three named services — Neon for data, Clerk for identity, Vercel for compute and blob storage — carry the platform; the rest of the stack is a focused set of named external services that do the things the spine does not.

How it works (the short version)

• Next.js 16 App Router, Tailwind 4, shadcn/ui
• Neon Postgres with row-level security; Clerk for auth; Vercel Blob for receipt images
• Groq for the receipt-vision model and transaction categorisation
• Plain-English categories map invisibly to HMRC SA boxes for year-end export
• Resend for email; Framer Motion for the small motion details
• Multi-business by default — one account, many ledgers, one consolidated view

Live behaviour today

In active development. The receipt-scanning flow is wired against Groq’s vision endpoint and successfully extracts merchant, date, total, VAT and a candidate category from a typical UK receipt. The multi-business data model is in place. Row-level security is enforced. The natural-language query surface is in early build against the user’s own ledger data.

The categorisation logic is being dogfooded for Bento Labs’ own books across multiple legal entities — the studio, the restaurant interests, the founder’s personal sole-trader returns — before the first external cohort goes live. Operating the product on real books is the only way to find the categories the population will actually use.

The product is not yet public.

What’s next

• Closed beta (Q3 2026). Twenty users from the Bento Labs network across freelancing, hospitality and property income. Receipt-capture flow polished. Year-end SA export running clean. Pricing model decided.
• Public launch (Q4 2026). Open sign-up. Pricing tiers set against the value of the year-end accountant fee saved (typically £400–£900 a sole trader spends in March).
• MTD bridging (H1 2027). With the threshold dropping to £30,000 in April 2027, the addressable population roughly doubles. Neatbooks adds MTD quarterly-submission bridging — either directly against the HMRC APIs or via the same Intuit partnership track Holt is on — so users who become mandated can stay in one tool.

Tech stack

• Framework — Next.js 16 with App Router
• Database — Neon Postgres with row-level security
• Auth — Clerk
• Storage — Vercel Blob for receipt images
• Compute — Vercel Functions for the receipt-processing pipeline
• Styling — Tailwind CSS 4, shadcn/ui
• AI — Groq (receipt-vision, transaction categorisation, natural-language ledger query)
• Email — Resend
• Animation — Framer Motion
• Hosting — Vercel

Status

In active development. Receipt scanning and the multi-business model are wired; categorisation is being dogfooded for Bento Labs’ own books across multiple legal entities before the first cohort goes live.

Why this matters for Bento Labs

Neatbooks is the desk-and-wallet compartment of the bento. The studio’s own books cross several legal entities — the lab itself, the restaurant interests, founder sole-trader income — and every other tool on the market makes that shape painful. Building Neatbooks is partly the most direct dogfooding loop in the portfolio and partly the closest expression of the bento philosophy: most people’s working life is not one thing, and a product that pretends it is creates more work than it removes. Neatbooks holds the user’s multi-stream life the way the bento metaphor holds the studio’s multi-product life — separately and at the same time.