| I've implemented tens of accounting systems, always multi-currency and usually multi-lingual. Originally in RDBMS, but in the last decade generally with triggers in SQLite. The most complicated one I've done was Kraken (~2011) which needed arbitrary precision support for unknown future crypto asset types. Opine: (1) Accounting as a profession is being automated away as governments create APIs to facilitate report submission and SCM/ERP/payroll become automated. Not too soon. (2) Yes, IMHO absolutely the debit/credit account terminology needs to die. It's backward and a source of confusion for the non-indoctrinated. Use negative numbers and present formatting for antiquarians where required. (3) As a student of ancient history, falsely ascribing off-handed western-inventors to things is so 19th century colonialist. Double entry is just an overly-lauded stage in the development of accounting anyway, not the endgame. Ancient societies got by just fine tying knots in cords (ancient China, Maya, Polynesia, etc.) and many ledgers run fine without double entry now. It's primitive compared to what's available in computer science today. (4) Distributed transaction systems are an algorithmic problem, not an excuse for manual documentation. Let's give away autonomous implementations for free, make GAAP about reporting, standardize account and transaction identification and innovate on process. New systems recommendation: (1) For account identification, use IIBAN which provides IBAN-compatible account identification and checksums and is an open system @ https://github.com/globalcitizen/iiban (2) For all accounting, use UTC. (3) For transaction identification, use UTC second of origination (UTCSO) + account of interest (AOI; eg. IIBAN) + intra-second transaction identifier (ISTI). Free thoughts on forward-looking accounting systems @ https://raw.githubusercontent.com/globalcitizen/ifex-protoco... |