I think this depends on what you consider to be the fundamental trait of double-entry accounting: the error-checking or the explanatory power.
It is true that by enforcing that value movement have both a source and a target, we make it possible to add a useful checksum to the system. But I believe this is a side benefit to the more fundamental trait of requiring all value flow to record both sides, in order to capture the cause for each effect.
I agree with your general perspective though: technology has afforded us new and different tools, and thus we should be open to new data models for accounting. I don't agree with other commenters that we should tread lightly in trying to decipher another field, nor do I agree with the view that the field of Accounting would have found a better way by now if there were one. Accountants are rarely, if ever, experts in CS or software engineering; likewise software developers rarely have depth in accounting.
Source: just my opinions. I've been running an accounting software startup for 5 years.
I agree with your first statement, but a little lost on the last one—I would think of the first idea as a question of data modeling, whereas the last (bad inputs) is one of enforcement and ownership.
Both present challenges, but better inputs don't help without a better model for business objects (as I see it)?
Numeric | Software engineer (4+ YOE) | ONSITE in San Francisco, CA | https://www.numeric.io
We're building the platform to automate accounting and tackle the underlying data issues which plague accounting and finance departments. Customers like Plaid, Wealthfront, AngelList, Mercury, and more depend on Numeric to automate their work, to collaborate, and to monitor, analyze, and share insights on their financial data. We've raised $10M to date from excellent investors like Founders Fund, Menlo Ventures, and more.
We're a product-first company with technical founders and an engineering team whose past experiences include Brex, Segment, Carta, and more. This will be a fit if you're excited to understand your users and the domain, as well as to have substantial responsibility and impact. We work in person in our SF & NYC offices, and prioritize speed and ownership (both technical and product ownership). We're growing rapidly, we're well-funded, and building out our team to continue investing in ambitious product goals.
Product-oriented engineers appreciated, bonus points for startup experience and/or full-stack experience with Typescript. >=3 YOE.
It is true that by enforcing that value movement have both a source and a target, we make it possible to add a useful checksum to the system. But I believe this is a side benefit to the more fundamental trait of requiring all value flow to record both sides, in order to capture the cause for each effect.
I agree with your general perspective though: technology has afforded us new and different tools, and thus we should be open to new data models for accounting. I don't agree with other commenters that we should tread lightly in trying to decipher another field, nor do I agree with the view that the field of Accounting would have found a better way by now if there were one. Accountants are rarely, if ever, experts in CS or software engineering; likewise software developers rarely have depth in accounting.
Source: just my opinions. I've been running an accounting software startup for 5 years.