Why I built our accounts software instead of buying it

The spreadsheet didn't break. That's the thing nobody warns you about.

It just stopped being true. Somewhere around month fourteen, I stopped trusting the numbers in it, and once that happens you're not running a business off a spreadsheet anymore. You're running it off memory, with a spreadsheet nearby for comfort.

I'm an ACCA. I spent four years in audit before I ever touched a marketing dashboard, and I still run the books, the banking and the payroll for a company that bills clients in three currencies. So when I say I looked at the accounting software on the market and decided against all of it, I want to be clear that this isn't a developer's excuse to avoid paying twelve dollars a month. I've used these packages. I know what they do well.

What follows is the actual reasoning, including the parts that argue against me.

Excel isn't a system

Let me be fair to the spreadsheet first, because it gets blamed for something that isn't its fault.

Excel is a list. That's all it's ever been. It has no relationships, no constraints, no idea that the client in row forty and the client in row four hundred are the same client spelled two different ways. It will let you delete a payment and nothing will complain. It will let you overwrite a formula by typing a number over it, and six months later that number is load-bearing and nobody knows who put it there.

None of that is a bug. It's the product working as designed. Excel is an extraordinarily good list.

The problem is that a business isn't a list. A business is a set of relationships: this client, that project, these three invoices, that payment which covered two of them, this cost which belongs to a project that closed in March. Excel can hold all of that. It just can't enforce any of it.

So the spreadsheet wasn't the problem. It was the symptom. The problem was that we had relationships in the business and no way to express them.

The translation tax

Here's what happened every single time I trialled an accounting package.

I'd open the chart of accounts and start mapping. Our revenue has four lines. Theirs wants twelve categories that don't correspond to anything we actually do. Fine, I'll consolidate. Then I'd try to answer the only question I actually care about — did we make money on that project? — and discover that the software has no real concept of a project.

To be fair, Xero has tracking categories and QuickBooks has projects. I'm not pretending those don't exist. But they're tags on transactions, not a model. You can label an invoice. You can't say: this project was billed in three stages over five months, two of those invoices are still outstanding, four different subcontractors charged against it, and one of them invoiced us after we'd already closed it. That's what a project actually looks like in an agency. A tag doesn't hold it.

So I'd end up exporting to a spreadsheet to do the reconciliation. Which meant I was maintaining two systems: the one that produces the official numbers, and the one that answers the questions.

That's the translation tax. Every accounting package is an opinion about what a business is, and the opinion is usually a ledger with a period end. Ours is a set of engagements with margins. The distance between those two things is where all the work lives, and no monthly subscription removes it. You still do the translation. You just pay for the privilege of doing it inside someone else's interface.

Once I saw that clearly, the build stopped being a dramatic decision. It was just the obvious one.

Reporting is an argument

Every package ships with reports. Every report is an opinion about what you should want to know.

I wanted to know which of our four service lines was actually profitable after we paid the people doing the work. I wanted to know what would happen to cash in six weeks if one specific client paid thirty days late. I wanted a receivables view grouped by the person who owns the relationship, because that's who has to chase it.

What I got was a P&L, a balance sheet, and an ageing summary. All correct. All useless at four in the afternoon on the last day of the month, when I need one specific number that the software wasn't built to produce.

And look — I want to be careful here, because this is the argument that's easiest to overstate. A spreadsheet is a genuinely good reporting tool. It's flexible, it's transparent, and you can see every calculation. I'm not anti-spreadsheet. I still use them every day.

I'm anti-spreadsheet as a system of record. Those are different jobs and we were asking one tool to do both.

So the answer wasn't "leave Excel." It was: put the relationships in a database, and keep using spreadsheets for the analysis on top. That distinction turned out to be the whole thing.

What I gave up

This is the section I'd normally skip, because it's the part that makes the story less tidy.

I don't get bank feeds. Someone has to import the statement.

I don't get payroll tax tables that update themselves when the rules change. When they change, I change them.

I don't get multi-currency revaluation, or a proper audit trail, or a decade of accumulated edge cases that a company with forty thousand customers has already hit and fixed so I don't have to.

I don't get to stop maintaining it. Every feature request comes to me. Every bug is mine. If I'm ill, nobody else can fix it, and that's a real operational risk I've taken on for a company that isn't only mine.

And I don't get the thing that matters most to an auditor: I can't point at a vendor and say they say the numbers are right. I'm the vendor now. When I sign off, I'm asserting correctness on a system I also built. Any auditor worth anything will find that uncomfortable, and they'd be right to.

For most businesses, those five points settle it. Buy the software. You're getting compliance, continuity and a support line, and the monthly fee is cheap for all three. If your operations resemble what the package assumes, you should absolutely not build this, and you shouldn't feel behind for not building it.

The question isn't whether you can build it. It's whether you're already building it, in a spreadsheet, every month, and just not calling it that.

The actual argument

We weren't choosing between Excel and accounting software. We'd already been maintaining two systems for over a year — the official one and the real one. We just hadn't admitted it.

So this wasn't a decision to save money, and it wasn't a decision to prove I could write the code. I could have hired it out. It was a decision to stop pretending the second system didn't exist.

Everything since has been a detail. The database has foreign keys, so a client can't be spelled two ways. An invoice can't exist without a project. A payment has to attach to something. Those aren't features. They're constraints, and constraints are the entire difference between a list and a system.

Month-end close went from about eleven days to about four. I'd like to say that was cleverness. Mostly it was just that the numbers stopped needing to be reconciled against each other, because there was only one set of them.

I've spent the last few months building the tools I kept needing — a Form-C generator, a bulk transfer spreadsheet builder, a building management system. It's turned into more than I expected, which I understand is how these things go.

If you're running a small business and you've found yourself exporting from your accounting software into a spreadsheet three times this month, that export is the signal. Not to build anything, necessarily. Just to notice that you're already maintaining the real system, and it's the one without a name.