> "We hope to publish guides about more complex use cases (lending, insurance, etc.) in the future."
That would be appreciated. It'd be nice to see the minimal complexity needed for something like a local credit union that managed customer savings and checking accounts, as well as home and car loans.
More ambitious would be a central banking app, in particular how does double-entry accounting work when a central bank (i.e. the Fed) is doing 'quantitative easing' and using their helicopter money to buy up Treasury bonds and mortgage-backed securities in order to keep major banks and government solvent? What's the private bank's balance sheet look like when they use the central bank money for stock buy-backs instead of for increasing commercial lending?
For example, the Fed says it's unloading the mortgage-backed securities it bought up in 2008-2009. That's got to be some convoluted accounting:
That's a cool idea. Any other deep-dive guides on fintech/payments that would be helpful for readers here? We're always looking for new topics to write about.
Klepmann is correct but practically you don't control external accounts thus cannot authoritatively determine if they either exist, have ceased to exit, or the contents of their ledgers. Thus, a large number of transactions will always have hanging references. This ultimately dictates the need for a "settlement state", which should be modeled as a state machine with careful transitions. Reversible transactions, fees, taxes and discounts then come in to play, some of which may be shared between parties, some of which are not calculable before the fact.
Fowler's approach is amusing in that, in classic UML style, he models things which are optional in an authoritative way as if they are requirements, thus muddying the waters even further. While his adjustment implementations are interesting as a basis for feature comparison, there's a lot to be said for simplicity, and this effectively requires throwing out what the bean-counters are used to and reconsidering the need from scratch. The default correction is another transaction, and this requires no special implementation.
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).
As a CPA and software developer, I've been wondering if I should build my own product out, but there seems to be a number of options available in the ledger space. However, I'm surprised there isn't more of an overlap in software engineering and accounting. There's a bit of overlap in the fields that scratch the same itch. Although the theory behind accounting is a lot more interesting than most of the work in my experience.
I'm also a CPA and develop software now (there are dozens of us!). I think part of this is that the perception among devs is that accounting is too complicated, and therefore can be radically simplified in software, which can be true, but largely doesn't meet real world scenarios. The problem is that accounting is generally complicated because business is complicated. I've seen software that throws away the ability to add more than 2 line items to a transaction. I've also seen software that goes too far the other way and automates every step of a process (okay great, how can we show the auditors now that this works?). It's a pretty classic misunderstanding of the domain, where most CPAs don't speak software, so there's a severe lack of communication (which probably makes CPAs who do understand software very valuable!).
The other factor is that while accounting software as a whole sucks, but at least for larger businesses, its probably better to tell the auditors that you use quickbooks, versus some custom in house software. From a risk management perspective, that's a much easier value proposition for the board/management.
Hey I'm co-founder of Proper Finance https://www.properfinance.io we're building integrated ledgering and reconciliation software for fintech companies. Happy to be helpful where we can - most of the team were early engineers at Marqeta where we worked on the core ledger, as well as reconciliation and financial controls - so happy to provide perspective. shoot me a note - travis@properfinance.io
I’ve often thought that had I been born into a world without computers I’d have been an accountant.
On high school career day I attended a talk by an accountant, and unfortunately he lived up to the stereotype. One of the most (superficially, anyway) boring people I’ve ever met.
I’m actually the founder is a startup trying to bridge the gap between Eng and finance. I’d love to hear your perspective on what a good solution would look like!
would love to connect as we're evaluating ledgers for rental properties. there are a gazillion management softwares with "accounting" ledgers but they were always an after thought. we're interested in building the defacto single source of truth ledger for real estate. taylor at apmhelp.com
It's running on NextJS which pre-loads the content of each link in the viewport unless you tell it not to, so it's loading a .json file containing the article content immediately, making the page transition instant when and if you click it.
I'm on the growth team at Modern Treasury. Using our Ledgers and Payments products together could definitely help here. Ledgers is actually free to get started. The startup plan includes 5000 transactions a month and is free forever and the enterprise plan has volume-based pricing. We'd love to chat more about your use case and pricing. Feel free to drop a note - pranav@moderntreasury.com.
Don't want to hijack the thread here but we're building an open-source platform that includes ledgers and a scripting DSL for money movements at Formance, with payments connectors in beta and coming up for recon - always keen to chat
Mentioned this above but I'm a co-founder of Proper Finance https://www.properfinance.io where are building integrated ledgering and reconciliation software for fintech companies. We are happy to help where we can - the team were early engineers at Marqeta where we built the ledger, as well as reconciliation and financial controls. Shoot me a note - travis@properfinance.io
The heart of double entry accounting is extremely simple. Forget about asset/liability/expense. Money always flows from one account to another. What goes out from account_1 must go into another account(s).
Typical tables:
I use -ve amount for credit, +ve for debit. That way when you do SUM(trascation_line.amount) it would come to 0.
This also cleanly maps to database transaction too where all transaction_line rows and transaction row should be atomic.
If you want multi-currency support, instead of amount column, it needs to be currency_code, currency_rate, amount_in_currency, amount_in_basecurrency ( i know we don't need this all, but sometimes you want to record the amount as entered, eg EURO 52.10 u want to record as entered even if your base currency is USD)
I would like to know about this as well. I struggled with this for a while for a prediction market app that I'm building. Eventually I ended up with [1]. I am somewhat pleased with it, but it does feel unwieldy to work with. I have some vague hope that somebody who actually implemented banking software would know of an obvious and elegant schema.
The summary of my approach is:
* A table with accounts.
* A table with account balances and an index on (account id, id), so you can efficiently query the current balance.
* A table with transactions.
* A table with mutations. Mutations have an amount, and reference a credit account, debit account, and transaction. (So one transaction can consist of multiple mutations.)
* The account balances table list the post-balance, but also references the mutation that caused it to be that new value.
All of these tables are append-only. I later added another layer, with transactions and subtransactions, but I'm not sure if this was a good idea.
The experimental directory of `beancount` has some code for converting beancount data structures into SQL structures [1].
You could also take a look at the data structures used by GNU Ledger (e.g. account [2]) and transcribe them to SQL. A bit more work, but probably educational.
Wish there was similar guide explaining the basics of cooperate accounting for developers. As a dev that has to occasionally work on integrating web apps with our erp system, I still get lost when the erp guys or biz people talk about various accounting processes.
Is chart of accounts usually a flat structure, or can it look more like a tree? I'm thinking of grouping similiar accounts together to see what's the balance on single ones vs the group.
As a CPA and software developer, I've been debating whether to create my own solution or explore the possibilities already present in the ledger area. However, I'm surprised that accounting and software engineering don't have more in common. The issue is that because business is complicated, accounting is often complicated as well. Software that disables the ability to add more than two line items to a transaction has been seen.
I did like Charles Dickens who has Mr Micawber say ‘Annual income 20 pounds, annual expenditure 19 [pounds] 19 [shillings] and six [pence], result happiness. Annual income 20 pounds, annual expenditure 20 pounds ought and six, result misery.’
I'll take advantage of the simplistic calculation. If you give me all your money, I'll give you back all your money plus N (N guaranteed to be a positive number). Now, I'll give it back in 10 years, but you'll have definitely made money. Or, in your terms "hells yeah"!
infogulch|3 years ago
photochemsyn|3 years ago
That would be appreciated. It'd be nice to see the minimal complexity needed for something like a local credit union that managed customer savings and checking accounts, as well as home and car loans.
More ambitious would be a central banking app, in particular how does double-entry accounting work when a central bank (i.e. the Fed) is doing 'quantitative easing' and using their helicopter money to buy up Treasury bonds and mortgage-backed securities in order to keep major banks and government solvent? What's the private bank's balance sheet look like when they use the central bank money for stock buy-backs instead of for increasing commercial lending?
For example, the Fed says it's unloading the mortgage-backed securities it bought up in 2008-2009. That's got to be some convoluted accounting:
https://www.marketplace.org/2022/06/02/why-the-federal-reser...
kojim|3 years ago
3pm|3 years ago
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
Also probably worth checking out Martin Fowler's writing on accounting.
https://martinfowler.com/apsupp/accounting.pdf
https://www.amazon.com/Analysis-Patterns-Reusable-Object-pap...
contingencies|3 years ago
Fowler's approach is amusing in that, in classic UML style, he models things which are optional in an authoritative way as if they are requirements, thus muddying the waters even further. While his adjustment implementations are interesting as a basis for feature comparison, there's a lot to be said for simplicity, and this effectively requires throwing out what the bean-counters are used to and reconsidering the need from scratch. The default correction is another transaction, and this requires no special implementation.
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...
pwpw|3 years ago
Naga|3 years ago
The other factor is that while accounting software as a whole sucks, but at least for larger businesses, its probably better to tell the auditors that you use quickbooks, versus some custom in house software. From a risk management perspective, that's a much easier value proposition for the board/management.
travisG23|3 years ago
mamcx|3 years ago
Also it could be very local-dependent.
Here in Colombia how we approach it is different to how I see people in USA do it.
What I don't know is how make it both easy, universal, practical and pluggable.
If for example is a out-of-band solution (aka: a micro-service) will be a total NO for many of potential users..
macintux|3 years ago
On high school career day I attended a talk by an accountant, and unfortunately he lived up to the stereotype. One of the most (superficially, anyway) boring people I’ve ever met.
memset|3 years ago
taylorhou|3 years ago
janci|3 years ago
jasonbarone|3 years ago
cyral|3 years ago
RicoElectrico|3 years ago
keeptrying|3 years ago
Anyone know of cheaper alternatives to ModernTreasury.com ?
Funtionality needed: ledger + integration with payments.
eatonphil|3 years ago
Not sure about payments integration though.
https://github.com/coilhq/tigerbeetle
deshp|3 years ago
unknown|3 years ago
[deleted]
superzamp|3 years ago
https://docs.formance.com
travisG23|3 years ago
perlgeek|3 years ago
meekaaku|3 years ago
accounts (id, name)
transaction (id, date) /* some call it journal */
transaction_line (id, transaction_id[fk], account_id[fk], amount)
I use -ve amount for credit, +ve for debit. That way when you do SUM(trascation_line.amount) it would come to 0.
This also cleanly maps to database transaction too where all transaction_line rows and transaction row should be atomic.
If you want multi-currency support, instead of amount column, it needs to be currency_code, currency_rate, amount_in_currency, amount_in_basecurrency ( i know we don't need this all, but sometimes you want to record the amount as entered, eg EURO 52.10 u want to record as entered even if your base currency is USD)
ruuda|3 years ago
The summary of my approach is:
* A table with accounts. * A table with account balances and an index on (account id, id), so you can efficiently query the current balance. * A table with transactions. * A table with mutations. Mutations have an amount, and reference a credit account, debit account, and transaction. (So one transaction can consist of multiple mutations.) * The account balances table list the post-balance, but also references the mutation that caused it to be that new value.
All of these tables are append-only. I later added another layer, with transactions and subtransactions, but I'm not sure if this was a good idea.
[1]: https://github.com/ruuda/hanson/blob/351e8e9bc5c96a9c1dc76fd...
gen220|3 years ago
You could also take a look at the data structures used by GNU Ledger (e.g. account [2]) and transcribe them to SQL. A bit more work, but probably educational.
[1]: https://github.com/beancount/beancount/blob/1f180e7176808139...
[2]: https://github.com/ledger/ledger/blob/master/src/account.h
vineyardmike|3 years ago
https://wiki.gnucash.org/wiki/SQL
nirav72|3 years ago
rudasn|3 years ago
Personally I think that's the main reason for working on any project, let alone being your full time job.
icepopo|3 years ago
meekaaku|3 years ago
Expense
- Salaries
- Rent
-- Warehouses
-- Retail space
- Utilities
Raziarazzi|3 years ago
racl101|3 years ago
Thank you!
pkrumins|3 years ago
hum3hum3|3 years ago
HWR_14|3 years ago
chris-orgmenta|3 years ago
This doesn't work on a low level, such as: If you're looking at an account you want to balance to 0, e.g. a suspense account, prepayment account, etc.
Also doesn't work with practical application, such as: Catering for a profitability target e.g. ($in / $out) > 1.1
PopAlongKid|3 years ago