Ode to accounting: A lesson from my time as an entrepreneur
In this post, I’ll explain why I’m so enthusiastic about fast, machine-accessible accounting and why Titanium Birch often blogs about it.
I learned a lesson from my entrepreneurial journey—one I wish I could travel back in time to tell myself 15 years ago when my partner and I were starting out. It permeates our strategy at Titanium Birch, and I imagine entrepreneurs starting with blank slates now might benefit from it.
Here’s the insight: doing accounting well and early has cross-cutting benefits for the entire business, including in how it enables the elegant design of job roles. This can lead to more empowered employees, better decision-making, less stress for founders, better retention, easier hiring, and other benefits. Conversely, doing accounting too late or too slowly can be a critical obstacle to achieving the most effective organisational designs.
Let me illustrate by example. We ran a subscription business where customers prepaid for one to twelve months at a time to enjoy our service. Our financial statements recognised a liability of unearned revenue at the time of signup, then accrued revenue monthly. The process to get there was unnecessarily complicated, mostly because we created the corresponding journal entries too late in the pipeline. Our CRM created single-entry transaction records: when a customer signed up, sent a payment, cancelled, got a refund, referred a friend and got a free month of service, etc, each was logged as a single entry. We then turned those into double-entry journal entries in monthly batches. This process was brittle and a lot of work for engineers and accountants.
Most importantly, the end results were siloed in accounting software accessible only to humans, not robots, and with data that was typically a few weeks behind reality. We needed Excel and human effort to answer questions like “How much profit contribution came from this new software feature or that marketing campaign?” We couldn’t easily run split tests on profit metrics, and it was generally cumbersome to understand profit sliced by dimensions such as customer cohorts.
This limitation restricted what we could delegate to employees, which mattered more than I realised at the time. Our employees owned and were accountable for results like customer satisfaction (measured by metrics like NPS), sales volumes, revenues, costs, various metrics around service quality, etc., but very rarely did anyone own profit—in large part because we didn’t have the numbers, certainly not sliced by the dimensions needed to attribute causality via split tests. The data was “stuck” in an accounting system, occasionally shared via spreadsheet exports. People owned “input metrics” that we believed to influence profits, but we rarely measured the real impact. Not because we didn’t want to but because our data architecture made it too difficult. Decisions like “How much time and money is worth spending on this effort?” and “Why do this project as opposed to something else?” thus relied too much on either top-down guidance or wild guesses.
I think much more elegant would have been to write the double-entry journal entries right at the source of the data. When a customer signed up, I should have written a set of journal entries. For just a little bit of extra effort at the source, we would have saved huge amounts of effort downstream, and it would have been much more feasible to enable robots to have close to real-time access to profit metrics and thus run split tests keyed on them. This would have made it more feasible to have a larger set of employees own various slices of profitability and thus be more empowered to make business decisions independently; our employees could have felt an even greater sense of job satisfaction from knowing their impact with more certainty and less reliance on faith. Unfortunately, because of the short-sighted decisions I made early on, it was very costly to morph our architecture into this more elegant model retroactively.
Back in 2009, it would have been difficult to find an accounting system that could handle many millions of journal entries in real-time APIs. But in 2024, entrepreneurs are lucky to have much more powerful tools at their disposal. We’re using SoftLedger, a general ledger SaaS product that we quite like.
Long story short, here’s my advice to myself in 2009 (and to entrepreneurs starting with fresh architectures today): “Think early about what you’ll want your humans and robots to know about your business. Accounting is the language of business, so think clearly about how accounting will help you understand your business. Then, have cross-functional teams of engineers and accountants make it easy for anyone in the organisation to have access to the answers they need to make their decisions and measure their impact.” This approach can make it possible to hire people and have them own a slice of profits, not just input metrics, which can make it even easier to attract and retain great talent. Good accounting obviously isn’t sufficient, but I believe it’s often necessary.
Think early about what you’ll want your humans and robots to know about your business. Accounting is the language of business, so think clearly about how accounting will help you understand your business.
These days, when we chat with entrepreneurs seeking investments from us, certain phrases—like references to their “finance team” or continued use of Xero and Quickbooks instead of API-first general ledgers—make our ears perk up. Those words often mean that accounting is treated as a silo, and that probably means there’s a lot of value left on the table. Consider going cross-functional! Magic can happen when accountants work side by side with engineers and product managers.
