There is a surprisingly narrow gap between an invoicing tool that genuinely helps a UK self-employed person and one that technically works but quietly drives them mad every time they raise a bill. I have spent a fair amount of time poking around tools like FreeAgent, QuickBooks, Xero, and Zoho Invoice from a design perspective rather than an accountant’s, and what I keep finding is the same cluster of UI decisions made by people who either don’t understand how UK freelancers actually bill, or who designed for a generic global user and bolted on a ” UK mode” as an afterthought. The details really do matter here, and invoicing app design for UK freelancers, specifically around MTD, is one of those domains where a handful of small interface choices either build or completely destroy a user’s trust.
Why invoicing is a harder UX problem than it looks
On the surface, an invoice is just a document with some numbers on it. The complexity creeps in the moment you layer on the UK-specific regulatory context. A self-employed person in the UK might be VAT-registered or not. If they are, they need to apply the correct rate (standard 20%, reduced 5%, or zero-rated), show the VAT amount as a separate line, display their VAT registration number on the invoice face, and generate a quarterly summary that feeds into a Making Tax Digital-compatible submission to HMRC. If they are not VAT-registered, none of that applies, but the interface still has to handle the state gracefully rather than just hiding fields and leaving a confusing gap in the layout.
MTD for Income Tax Self Assessment (ITSA) is rolling out to sole traders and landlords with income above £50,000 from April 2026, dropping to £30,000 from April 2027, according to HMRC’s own guidance on Making Tax Digital. That means a significant chunk of self-employed users are going to need their invoicing tool to connect directly to HMRC’s API infrastructure, or at least export data in a format a bridging tool can consume. If the app’s data model doesn’t cleanly separate gross income, allowable expenses, and tax by quarter, the UI will become a mess of manual workarounds.
The VAT calculation problem is mostly a UI sequencing problem
I’d argue that most VAT errors in invoicing UIs are not calculation errors at all. They are sequencing errors. The app asks for a line item amount, and it is unclear whether that amount is exclusive or inclusive of VAT. Some tools default to exclusive (the accountant-friendly default) without making that obvious to a user who typed in a round number expecting it to be what the client pays. Others toggle the behaviour per line item but hide the toggle in a settings panel three levels deep.
The cleanest pattern I have seen is a persistent, visible label directly adjacent to every price input: a small toggle that reads “ex. VAT” or “inc. VAT”, styled as a segmented control rather than buried in a dropdown. The gross and net amounts then update live beneath the input. This sounds obvious. Very few tools actually do it. FreeAgent gets close, though it tends to assume ex. VAT at all times, which trips up newer freelancers who quote inclusive prices to clients.
Partial exemption is where things get genuinely gnarly. A designer who also licenses stock assets might have a mix of standard-rated and exempt supplies on the same invoice. The interface needs to handle mixed-rate line items without requiring the user to split the invoice manually. This is rare enough that most tools don’t bother, but for micro-agencies it comes up constantly. If you’re designing a micro-SaaS product aimed at solo UK developers, this is exactly the kind of edge case that separates a tool worth paying for from one people drop after two months.
Payment status states: the UI gets lazy here every time
An invoice is not a static document. It passes through multiple states over its lifetime, and a well-designed tool treats each state as a distinct UI moment with distinct affordances. The states a UK freelancer actually cares about are broadly: draft, sent, viewed (if read receipts are available), partially paid, overdue, paid, and written off. Most apps handle draft and paid. The middle ground is where the design falls apart.
“Overdue” is particularly underserved. An invoice becomes overdue the moment it passes its payment terms date. The correct UI response is an immediate, ambient status indicator on the invoice list view, not a buried orange badge that only appears when you open the individual record. The list view should surface: how many days overdue, the outstanding amount, and a one-click chase action that generates a polite reminder email using the client’s name pulled from the contact record. Xero’s invoice list is reasonable here. Zoho Invoice used to be terrible at this but improved around late 2024.
Partial payment is handled badly by almost everyone. The UI typically shows a payment received, subtracts it from the total, and leaves the remaining balance visible on the invoice record. What it rarely does is update the invoice status label to something meaningful like “Part paid” or show a visual progress bar on the payment. A bar showing £600 received against a £1,200 invoice is immediately scannable. A number buried in a summary table is not. This is a basic data visualisation principle that applies just as much to invoicing as it does to analytics dashboards.
There’s also the question of what happens after payment is marked. Most tools do nothing. A smart tool archives the invoice, updates the client’s payment history, and optionally prompts the user to log any bank transfer fees as an expense, keeping the MTD records clean. That last step is the kind of thought that shows real understanding of the workflow, not just the document format.
MTD compliance in the UI: what it actually requires you to show
Making Tax Digital for ITSA requires digital records of income and expenses, quarterly submissions, and a final declaration. For an invoicing tool, the UI implication is that every invoice needs to be classifiable by tax year and quarter at the point of creation, not retroactively. Some tools make you tag invoices manually by quarter; this is a design failure. The quarter should be inferred automatically from the invoice date and the user’s accounting period settings, with a visible indicator on the invoice record confirming which submission it will roll into.
The quarterly summary view is where most tools currently fail their UK users most visibly. What a freelancer needs to see, in plain language, is their total taxable income for the quarter, their allowable expenses, and the net figure that will be submitted to HMRC. Many apps show these figures somewhere, but they are scattered across separate reports rather than surfaced as a single pre-submission dashboard. The GOV.UK Design System approach of task-based progress states would work beautifully here: a checklist that shows which invoices are categorised, which expenses are logged, and whether the quarter is ready to submit. Incidentally, there is a lot the public sector has figured out here that the private sector still ignores, which I wrote about separately in a piece on what the GOV.UK Design System gets right that most private sector UI libraries get wrong.
The submission itself should be a single action with a clear confirmation state. Currently, most tools that support MTD direct submission show a modal, ask for confirmation, fire the API call, and then return the user to the dashboard with no persistent record of what was submitted or when. The correct pattern is a submission receipt view with a timestamp, a reference number from HMRC, and a link to download the submitted data as a PDF. Audit trails matter for compliance and they matter for the user’s peace of mind.
Small details that builders consistently miss
A few things I would add to any design spec for this kind of tool. First, the invoice number sequence. UK freelancers often have clients who require invoices to follow a specific format, and the ability to customise the prefix and starting number is non-negotiable. But the UI should also warn users if they are about to create a gap in the sequence, because a missing invoice number can flag a VAT audit.
Second, currency handling. A UK freelancer who invoices in GBP but occasionally bills an EU client in euros needs the tool to record the sterling equivalent at the exchange rate on the invoice date, for MTD record-keeping purposes. This is largely ignored by mid-market tools. If you’re thinking about building something in this space and you’ve looked at how Figma’s Dev Mode handles complex state management between design and code, the principle is similar: the source of truth needs to be unambiguous even when the display layer shows a different unit.
Third, the statement of account view. Many UK clients request a statement rather than individual invoices when settling multiple bills at once. This is a separate document type with its own UI requirements: it lists all outstanding invoices for a given client, with dates, amounts, and running balances. Most invoicing tools treat this as a secondary feature or don’t have it at all. For a freelancer managing ten or more active clients, it’s essential.
The invoicing interface is genuinely one of the most legally consequential UIs a self-employed person uses. Getting it wrong is not just a UX annoyance; it can mean a failed VAT return or a compliance gap in their MTD records. That’s reason enough to design it properly from the start, rather than treating the UK regulatory layer as a localisation task someone can bolt on in a sprint.
Leave a Reply