3 ms·
I think building a superior product would be trivial and profitable for a reasonably funded, small team of developers. Most of the accounting profession uses to
by calderarrow 7y ago
I think building a superior product would be trivial and profitable for a reasonably funded, small team of developers. Most of the accounting profession uses tools that are from the 80s and 90s, so the user experience is horrible for staff accountants.
The main problem is that selling to accounting firms is difficult because procurement usually goes through partners. At the firms I worked for, our procurement process required buy-in from a majority of the partners and the product would require serious security features that are beyond my current abilities, so those two facts deterred me from pursuing that route.
The real future is integrating audit software with financial bookkeeping. This is one area where I think blockchain/smart contracts actually could be utilized to ensure audit quality. Auditors essentially look at a small portion of the transactions made by a company during a year, so software could monitor it in parallel. You’d still need an audit team to review the findings and ensure the software was working properly, but the cost would be a fraction of what it takes to audit a company by hand today.
Thank you for asking — it’s been a while since I’ve been able to geek out like this! One day I’d like to build those tools, but in the meantime I’m working on a personal finance product. It’s almost done, so hopefully you’ll see it when I submit it to HN to get dragged across the coals.
- gen220 7y agoI’m working on financials-related software that has increasing involvement with our internal compliance/audit team. I totally agree with your premise, although in practice I’ve found that the phrase “review the findings and ensure the software was working properly” snuggles in a lot of complexity. It implies that working properly is well-defined and formally verifiable, when it usually isn’t. I’ve had very frank meetings where I’ve explained that, ultimately, log statements can be totally fictional, and we can technically pay out amounts that diverge from the amounts in a report. The amount of trust you have in the developer and your dependencies are the weakest links in the chain, and, if you’re honest in explaining to that level of detail, most compliance minded people come away uneasy. But this is how every company operates? There’s definitely a need for verifiable money transfer infrastructure, but I think most companies that roll their own payment infrastructure would rather pretend that the problem is a boogeyman.