Why I spent 6 months getting HMRC to approve my invoicing app

I built Honest Invoices because a friend's dad — a plumber — was paying £35 a month for accounting software he didn't understand, didn't use, and didn't know was about to be made "wrong" by Making Tax Digital.

He'd never heard of MTD. He thought his accountant would handle it. The accountant told me, quietly, that she didn't have time to walk every client through it. That's the gap.

I'm a software engineer. I've built integrations against Stripe, Plaid, the GitHub API, and a dozen lesser ones. Getting to a working MTD ITSA integration took six months.

It is not because the technology is hard. It's because:

• The sandbox is partly stateful and partly not, and the documentation rarely tells you which.
• Fraud prevention headers require over ten data points per call — device fingerprint, screen size, public IP, vendor licence ID — many of which are silently rejected if a single field is mis-formatted, with a 403 and no correlation ID to debug from.
• The Self-Employment Business and BSAS APIs version separately, retire endpoints, and use different URL conventions for the same tax year.
• Support is "fill in a form, wait three days." If your question is technical and your test scenario edge-case, you can wait weeks for a useful reply.

None of this is malicious. It's an infrastructure built for enterprise providers, not for solo developers and small teams.

Lots of accounting platforms display an "HMRC-recognised" badge. That tick on a homepage rarely tells you whether the provider has done the full end-to-end journey, or just the minimum to be listed.

I'm being deliberate: until we're on the HMRC Software Choices list for ITSA, you won't see "HMRC-recognised" on the Honest Invoices homepage. You will see "Built end-to-end against HMRC's MTD ITSA APIs" — because that's true today, and the recognised tick should mean it's been earned.

I was invited to HMRC's call-for-evidence roundtable in May 2026 to speak to exactly this. Three things would make a measurable difference for the next solo developer who tries:

• A small-provider pathway for production approval — fewer hoops, faster turnaround, mentor support.
• Pre-populated sandbox scenarios so you're testing against state that mirrors real customer journeys, not building it from scratch.
• A dedicated technical channel per API, so when an integration breaks at 2am there's a route to a real engineer at HMRC, not a queue behind 200 enterprise tickets.

£15 a month, locked. No surprise price hikes — not in three years, not in five. If a higher tier launches, you stay on £15 forever.

Built by someone who knows what it took to build, and isn't going to make you pay for that complexity. That's the difference.

— Vix Hawley · founder, Airtisan · v.l.hawley@hotmail.com

HMRC’s MTD APIs require a set of 13 fraud-prevention headers on every transactional call — device ID, screen dimensions, public IP, timezone, user agent, and several more. I’d built them all, run my 16-step end-to-end sandbox journey, and watched all 16 calls return 200 OK. Looked done.

Then I found out there’s a separate HMRC validator service — txm-fph-validator-api — that the Software Developer Support team runs your evidence through before approving you for production. I ran my exact same headers against it. The validator returned 22 errors and 7 warnings.

The transactional sandbox had been silently accepting requests that the validator considered malformed. I was URL-encoding the screen dimensions string — width=1920&height=1080 — but the validator wanted those structural = and & characters raw. I was sending timezone as +01:00 when it needed the literal prefix UTC+01:00. I was sending a Gov-Client-User-Agentheader that isn’t valid for server-to-server traffic. Six bugs in total.

If I hadn’t found the validator before submitting my production-access application, I’d have sent HMRC evidence that worked technically but failed compliance. That’s the kind of thing you don’t get a second chance at quickly. Built me a deeper respect for the value of secondary verification systems — and a habit of asking, when something passes a check, “is there a stricter version of this check somewhere I should also run?”