Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accounting for Developers, Part II

moderntreasury.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Accounting for Developers, Part II

#71

Post by redbar0n »

contingencies wrote: post #63
redbar0n wrote: post #61

Earlier quoted context omitted.

> 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. True. But it doesn't actually matter. > Thus, a large number of transactions will always have hanging references. No, it doesn't need to be any dangling references. Because you model external accounts with an internal account (node…

you model external accounts with an internal account (node) in your ledger. ... achieving what, exactly? How is the set of outbound transactions already stored associated with a given external destination not precisely the same information? This is needless data duplication, AKA database design no-no 101.

Achieving an internal record that balances out, and has no dangling references. Later inter-company audits can also verify that neither company has unilaterally corrupted their books. To be clear: I’m just talking about the standard accounting practise here (as normally done with tables/books), nothing fancy. Just applied to graphs, so the graph has no dangling references/edges.

Re: Accounting for Developers, Part II

#72

Post by yobbo »

HWR_14 wrote: post #58
meekaaku wrote: post #37

Earlier quoted context omitted.

The problem with this will be when you have 3 accounts involved on a transaction. Eg, you take a sales receipt with part bank transfer, part cash. Sales Cr $100 Cash Dr $30 Bank Dr $70 Your approach will have: Sales Cr $70, Bank Dr $70 Sales Cr $30, Cash $30 That looks like two sales, which is not really the case.

Isn't it more accurate to say it was two sales than one? In what way is it misleading?

Distinguishing between sales and payments is required, but any confusion is basically impossible in online systems such as this schema would be used in, in real examples.

Typical accounting GUIs present transactions and ledgers such that it becomes intuitive for business users to enter sales/invoices. Entering the above transaction in those GUIs might cause confusion.

The schema here is used by an online system recording business events as a type of log of user interactions. It lives in a sql database, and thus needs to rely on row constraints to guarantee double-entry. Transactions are never entered manually or randomly.

The effect of split transactions can be achieved by using an intermediate account. Those accounts have balances which are not guaranteed to be zero, but that is unavoidable and sometimes OK and intended.

Re: Accounting for Developers, Part II

#73

Post by mmckelvy »

meekaaku wrote: post #68
mmckelvy wrote: post #62

Earlier quoted context omitted.

What do "-ve" and "+ve" denote?

negative and positive for credit and debit respectively. Eg: an entry of -$100 is a credit entry.

Ah, ok. So the "ve" was just a placeholder for the value in the "amount" column for each entry.

How does this handle the fact that credits increase the value of some accounts (e.g. sales, equity) but decrease the value for others (e.g. assets)?

Re: Accounting for Developers, Part II

#74

Post by gen220 »

meekaaku wrote: post #37
yobbo wrote: post #32

Earlier quoted context omitted.

This sort of schema requires a process to verify the sum before committing, and verification is annoying to achieve with constraints. Instead, you might consider something like: transaction_line (id, transaction_id[fk], dr_account_id[fk], cr_account_id[fk], amount)

The problem with this will be when you have 3 accounts involved on a transaction. Eg, you take a sales receipt with part bank transfer, part cash. Sales Cr $100 Cash Dr $30 Bank Dr $70 Your approach will have: Sales Cr $70, Bank Dr $70 Sales Cr $30, Cash $30 That looks like two sales, which is not really the case.

I think you could solve this with a `sale_id` for grouping transactions together, no?

The benefit of row-level guarantees on balancing is considerable, even if it somewhat complicates the application layer (the layer that translates your first ledger into your second ledger, and vice versa).

If you're storing a transaction that needs to balance across N rows, the only solution is at the "application level" (i.e. a stored procedure, or some middleware in code), which is unfortunately more difficult to reason about.

Re: Accounting for Developers, Part II

#75

Post by contingencies »

redbar0n wrote: post #71
contingencies wrote: post #63

Earlier quoted context omitted.

you model external accounts with an internal account (node) in your ledger. ... achieving what, exactly? How is the set of outbound transactions already stored associated with a given external destination not precisely the same information? This is needless data duplication, AKA database design no-no 101.

Achieving an internal record that balances out, and has no dangling references. Later inter-company audits can also verify that neither company has unilaterally corrupted their books. To be clear: I’m just talking about the standard accounting practise here (as normally done with tables/books), nothing fancy. Just applied to graphs, so the graph has no dangling references/edges.

In the database world it is generally recognized that doing data duplication to 'flatten' a particular view is a special case of normalization (adapting data to a model) which is encouraged to be done dynamically (eg. as an SQL view) and not in stored data (as this would create redundant information, which negatively affects the database in terms of ongoing management, authority and clarity). Generating reports in whatever format users prefer is generally a very cheap and fast operation.

Also, duplicating the data does not make it more correct or more authoritative. Do not confuse presentation with data. A rose by any other name would smell as sweet.

Edit: I can't reply to your response so will reply here. I suggest reading some basic database design books. Good luck.

Re: Accounting for Developers, Part II

#76

Post by redbar0n »

contingencies wrote: post #75
redbar0n wrote: post #71

Earlier quoted context omitted.

Achieving an internal record that balances out, and has no dangling references. Later inter-company audits can also verify that neither company has unilaterally corrupted their books. To be clear: I’m just talking about the standard accounting practise here (as normally done with tables/books), nothing fancy. Just applied to graphs, so the graph has no dangling references/edges.

In the database world it is generally recognized that doing data duplication to 'flatten' a particular view is a special case of normalization (adapting data to a model) which is encouraged to be done dynamically (eg. as an SQL view) and not in stored data (as this would create redundant information, which negatively affects the database in terms of ongoing management, authority and clarity). Generating reports in wh…

How does that relate to what I said?

Re: Accounting for Developers, Part II

#77

Post by meekaaku »

mmckelvy wrote: post #73
meekaaku wrote: post #68

Earlier quoted context omitted.

negative and positive for credit and debit respectively. Eg: an entry of -$100 is a credit entry.

Ah, ok. So the "ve" was just a placeholder for the value in the "amount" column for each entry. How does this handle the fact that credits increase the value of some accounts (e.g. sales, equity) but decrease the value for others (e.g. assets)?

-ve i used to denote credit, not necessarily to indicate increase/decrease. In accounting terms, if you sales increase, your entries on the credit side of sales account increase. In my implementation it means larger negative number. Hope that explains.

Re: Accounting for Developers, Part II

#78

Post by kojim »

m33k44 wrote: post #70
kojim wrote: post #24

Earlier quoted context omitted.

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.

> Any other deep-dive guides on fintech/payments that would be helpful for readers here? How online payments actually work behind the scenes, complete flow from sender to receiver. That deep-dive would be really useful.

Do you mean for card payments, like the card network and authorization flow? I found this article really good from the systems design side although you might have to be a subscriber: https://newsletter.pragmaticengineer.com/p/payments-system

Re: Accounting for Developers, Part II

#79

Post by m33k44 »

kojim wrote: post #78
m33k44 wrote: post #70

Earlier quoted context omitted.

> Any other deep-dive guides on fintech/payments that would be helpful for readers here? How online payments actually work behind the scenes, complete flow from sender to receiver. That deep-dive would be really useful.

Do you mean for card payments, like the card network and authorization flow? I found this article really good from the systems design side although you might have to be a subscriber: https://newsletter.pragmaticengineer.com/p/payments-system

> Do you mean for card payments, like the card network and authorization flow?

Yes.

Post reply on HN