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

61–70 of 79 posts

Re: Accounting for Developers, Part II

#61

Post by redbar0n »

contingencies wrote: post #50
3pm wrote: post #33

A quote from a related blog post: "Eventually I figured it out: basic accounting is just graph theory. Accounts = Nodes, Transactions = Edges" 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...

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

> 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) in your ledger.

Re: Accounting for Developers, Part II

#62

Post by mmckelvy »

meekaaku wrote: post #16
perlgeek wrote: post #12

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…

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

Re: Accounting for Developers, Part II

#63

Post by contingencies »

redbar0n wrote: post #61
contingencies wrote: post #50

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. 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,…

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

Re: Accounting for Developers, Part II

#64

Post by contingencies »

juskrey wrote: post #60
contingencies wrote: post #50

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. 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,…

On UTC: why so, as accounting periods are happening in local time

We live in a global era. Any novel system should assume that it may in future be operated cross-border, distributed, etc. or used in combination with such systems. Many countries even have multiple timezones internally. Given such a circumstance, any use of local timezones is by definition a presentation layer concern. Not recognizing this at design time is a surefire way to create needless technical debt with zero functional benefit.

Re: Accounting for Developers, Part II

#65

Post by Raziarazzi »

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.

Re: Accounting for Developers, Part II

#66

Post by juskrey »

contingencies wrote: post #64
juskrey wrote: post #60

Earlier quoted context omitted.

On UTC: why so, as accounting periods are happening in local time

We live in a global era. Any novel system should assume that it may in future be operated cross-border, distributed, etc. or used in combination with such systems. Many countries even have multiple timezones internally. Given such a circumstance, any use of local timezones is by definition a presentation layer concern. Not recognizing this at design time is a surefire way to create needless technical debt with zero f…

The database will be always using utc, but according periods will be always local. Hence was my question, why emphasize this that is?

Re: Accounting for Developers, Part II

#67

Post by lelanthran »

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?

One sale is always one sale, even if it has multiple transactions associated with it[1]. It must never look like multiple sales.

[1] Lots of use-cases: People paying partly by credit card, partly in cash. People using vouchers which are recorded as a negative transaction. Group of people splitting a bill and each doing a CC transaction for their bit. None of these are multiple sales, because recording each transaction as a single sale wreaks havoc on the inventory control.

Re: Accounting for Developers, Part II

#68

Post by meekaaku »

mmckelvy wrote: post #62
meekaaku wrote: post #16

Earlier quoted context omitted.

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…

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

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

Re: Accounting for Developers, Part II

#69

Post by meekaaku »

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?

No. In the real world it is a single sale. In the accounting/finance domain it is single sale, so it should be represented as such. It also matters when you look at KPI like avg order size, num orders for customer, not to mention it is one invoice at the time of invoice creation, but payment collected in multiple methods.

Re: Accounting for Developers, Part II

#70

Post by m33k44 »

kojim wrote: post #24
photochemsyn wrote: post #10

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

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

Post reply on HN