Live data from Hacker News

Accounting for Developers, Part II

moderntreasury.com

21–30 of 79 posts

Re: Accounting for Developers, Part II

#22
post #20

The website is so fast I did not notice it redrawed when I clicked Part I. I'm impressed.

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.

Re: Accounting for Developers, Part II

#23

Does anybody know a good SQL / DDL schema for a double entry accounting system?

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: 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…

To build a chart of accounts, you can have a parent column in accounts table. Account balances is just:

SELECT account.name, SUM(amount) balance

FROM account ac

INNER JOIN transaction_line tl ON tl.account_id = ac.id

GROUP BY account.name

You can cache this balance values with a current_balance column on accounts table

Once you have that, for any real world transaction, all you need to figure out is what are the accounts to debit/credit, ie classification. That is a higher level thing and is the business logic of an accounting application.

Re: Accounting for Developers, Part II

#24

> "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…

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.

Re: Accounting for Developers, Part II

#25

Love the simplicity of their system but don't like the price tag. Anyone know of cheaper alternatives to ModernTreasury.com ? Funtionality needed: ledger + integration with payments.

TigerBeetle is an open source ledger database you might be interested in. Not sure about payments integration though. https://github.com/coilhq/tigerbeetle

Thanks!

Re: Accounting for Developers, Part II

#26
post #18
post #3

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 exp…

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 t…

That's great insight. When I was at big 4, I helped look over in house software and translate it for auditors to gain reasonable assurance that the software was correctly implementing accounting processes.

A buddy of mine is working on a YC-funded company (https://www.keeper.app/) that's designed around assisting the lives of bookkeepers using quickbooks. I think it's a great angle because I agree with you that quickbooks is the most logical option for an average company. Where software could really be improved in my eyes is SAP. Boy does their software make me want to hurl... But they have such a strong hold in the industry.

This is a bit tangential, but my biggest insight when conducting walkthroughs with the client's accountants was that there is so much valuable knowledge that is internalized in singular individuals. I'd have an accountant show me their month end close process with links between 5 Excel worksheets. Totally illogical flow and only that person understood how to follow the process from start to finish. There would be situations like randomly multiplying a line item by 32 because of some piece of paper on their desk that they had written down years ago. These people had been at the company for 20+ years. I have to think there's a better system for handling accounting processes like that. Weeding through a messy code base can be a nightmare, but going through someone else's accounting worksheets that are crucial for tying out the financial statements can be nearly impossible. I suppose eventually the audit team has to decide what's material, make a judgement call, and move on.

Re: Accounting for Developers, Part II

#29
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.

Re: Accounting for Developers, Part II

#30

Does anybody know a good SQL / DDL schema for a double entry accounting system?

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.

[1]: https://github.com/ruuda/hanson/blob/351e8e9bc5c96a9c1dc76fd...

Post reply on HN