Live data from Hacker News

Double-entry bookkeeping as a directed graph

matheusportela.com

361–370 of 388 posts

Re: Double-entry bookkeeping as a directed graph

#361
post #194

There is one limitation of the graph visualization that's worth paying attention to: If you add a larger number of transactions to it, the graph will become tangled up and difficult to make sense of: You see which accounts trade with each other, but the order of the trades got lost, because all transactions share the same "account" nodes. Indeed, if you'd try to also track balances in the graph, you'd end up with the…

And then crypto-sign each transaction with an enormously expensive proof-of-work function because you don't trust anyone wearing a suit and then blindly go all-in on this new "blockchain" being the solution to every problem and then get scammed all the way up your own asshole by believing your own bullshit, and then beg those people in suits to fix it for you like a housecat begging for food from their owner they just scratched the shit out of, and be confused that they can't fix everything for you this time because you intentionally cut them out of the system. It's foolproof!

Re: Double-entry bookkeeping as a directed graph

#362
post #337

Earlier quoted context omitted.

> It would be very confusing to label expense accounts as "liability". Why? > expenses do not necessarily increase liability. That depends on what you mean by "expenses". If you give someone an expense account, that is a commitment to make payments for expenses, i.e. debt, so it's a liability. When you actually pay for those expenses (or reimburse someone for incurring those expenses) you are paying off debt and redu…

>That depends on what you mean by "expenses". If you give someone an expense account, that is a commitment to make payments for expenses, i.e. debt, so it's a liability. This is not what expense account means in accounting. An expense account is an account that records expenses incurred such as your AWS bill, rent payments or salaries paid. These are not liabilities and labelling them as such is more than confusing.…

> An expense account is an account that records expenses incurred such as your AWS bill, rent payments or salaries paid.

Ah.

> These are not liabilities

Well, that depends.

Every expense that involves an invoice or purchase order that is not paid immediately in cash must be recorded as two transactions. The first transaction is the issuing of the invoice or the PO. That transaction is a liability to the buyer, an asset to the seller. The second transaction is the payment of the invoice. That transaction involves a decrease in the buyer's cash reserves (asset) and a discharge (decrease) of the the buyer's liability, and an increase in the seller's cash reserves (asset) and a decrease in the seller's accounts receivable (asset).

When I look in "accounting for dummies" type web sites, they all give examples of expense accounting as a single transaction. That is deeply broken. If you try to record an expense as a single transaction then your balance sheet is going to be wrong if you have any unpaid invoices, either payable or receivable. In fact, recording an expense as a single transaction doesn't even work if you're paying cash in a brick-and-mortar store unless you literally keep all your cash as physical cash in a safe because ATM withdrawals are transactions that need to be recorded too.

In a situation like an employee being reimbursed for a travel expense there are at least four transactions:

1. The employee using their credit card to buy something (liability to the employee, asset to the merchant)

2. The merchant getting paid by the credit card company (converting a receivable into cash, i.e. trading one asset type for another)

3. The employee submitting their expense report (invoice) to the company for reimbursement (liability to the company, asset to the employee)

4. The employee getting paid by the company for the incurred expense (company converts asset into a discharge of liability, employee converting receivable into cash)

I say "at least" because if there is a credit card involved then step 2 actually involves a bank issuing a loan to the credit card holder, so there is an additional entity involved, and more transactions on their end. And of course when I say "cash" I actually mean "demand deposit" which is not quite the same thing, though people tend to conflate the two.

Re: Double-entry bookkeeping as a directed graph

#363
post #192

Earlier quoted context omitted.

You have completely missed the point, which is that the way in which accountants use these words is unnecessarily confusing because it does not align with the common English definitions of the words "credit" and "debit".

The common English use of 'credit' and 'debit' is correct, as they ought to be since we learned them from banks. Most people are only aware of one type of account, a liability account managed by the bank in their name. The mistake is that we talk about them as "our" accounts.

> The common English use of 'credit' and 'debit' is correct,

Yes, by definition.

> The mistake is that we talk about them as "our" accounts.

No. The mistake is the failure to recognize that every account is actually two different accounts, one for each party to a transaction. A bank account looks different to the bank than it does to a depositor or to a borrower. To a depositor, a positive balance is an asset -- quite literally "money in the bank". To the bank, a positive balance in a deposit account is a liability, a loan that it has taken from the depositor on which it must pay interest (at least sometimes) and which it must eventually pay back. To a borrower, a positive balance on a loan is a liability, to the bank it's an asset. Every financial asset is a liability to some counterparty. Even cash is a liability to society at large. So whether something is an asset or a liability depends entirely on your point of view, and so if both parties are going to use the same number to represent an account balance, it is an arbitrary choice what the sign represents. A positive number is always going to be an asset to one party and a liability to the other. Which is which is totally arbitrary, except that there are some deeply entrenched conventions: a positive balance on a deposit account at a bank represents an asset to the depositor, a liability to the bank. A positive balance on a loan represents an asset to the lender, a liability to the borrower. A positive balance on an invoice represents an asset to the seller and a liability to the buyer. But there is no inherent reason why it has to be that way, it's just tradition.

Likewise, whether "credit" means "increase" or "decrease" is also simply a matter of convention. A "credit" to a deposit account means the balance goes up. A "credit" to a loan account (i.e. a loan payment) means the balance goes down. The thing that unifies these things is that a "credit" is either an increase in an asset or a decrease in a liability since both assets and liabilities are recorded by convention as positive numbers. So in isolation (i.e. without a balancing double-entry transaction), a (positive) credit increases your net worth and a (positive) debit decreases it.

Re: Double-entry bookkeeping as a directed graph

#364

Earlier quoted context omitted.

The person you're replying to is confused, but that's because accounting can be confusing. An account is fundamentally either an asset or a liability. When you buy something with a credit card, you've incurred a liability, and gained an asset, no matter what you've purchased. If you use a debit card or cash, you're trading one asset for another. One of the basic asset categories is expenses. That's the confusing part…

These are the sorts of comments that make accounting and bookkeeping more difficult for people who are learning it. It helps no-one to try to think of income and expenses as equivalent to liabilites and credits. They are merely on the same sides of the accounting equation. Assets + Expenses = Liabilities + Equity + Income Expenses are not assets. For example, depreciation is not an asset. It is the representation of…

N.B. I meant assets, not credits, in the first paragraph.

Re: Double-entry bookkeeping as a directed graph

#365

Earlier quoted context omitted.

Bob and Alice each have a "money" account and a "books" account. Each money account tracks how much money they have on hand while each books account tracks the total value of their private libraries. So to be clear, there are 4 accounts. Bob's Money, Bob's Books, Alice's Money, Alice's Books. Because these two homeless librarians only have money and books, you can add the two balances together for each person to get…

> She -credit's her books account $20 and her net worth goes down by $20. Stupid question maybe. Is net worth an account too? Where does the debit side of Alice’s credit go?

Cash might be an account, and a bank account might be another one. So if Alice buys with cash, it'd be $20 debit in the books account [1] and $20 credit in the cash account. Or if she paid for the book with something that directly takes the money from the bank account, the credit would be to the bank account.

Note that "credit" in double-entry bookkeeping means a transfer from that account and debit means a transfer to that account. So the debit side of buying the book goes into the books account. The credit entry is for whatever account value is transferred from in the transaction.

I'm not sure I'd say that Alice's net worth goes down by $20 when she buys the book since the financial value of the book would technically also be part of her net worth.

I also wouldn't consider "net worth" to be a single account.

Technically net worth would be the sum of all of Alice's assets in cash, bank accounts, real estate, books and other non-financial assets etc., minus all her liabilities. Each of those might be a separate account in the bookkeeping.

Disclaimer: I'm not an accountant.

[1] There might not be a separate account for books unless Alice is a real books aficionado and a meticulous bookkeeper, so the account might also be "books, movies & music", "entertainment & culture", or just "personal items" depending on what granularity is desired/needed.

It might also be that such items are not considered to have financial value in the system (which would probably be the correct unless Alice collects books) and the debit ("to") would actually go in some kind of an (abstract) expenses account instead. Either way, both the value leaving cash/bank and the value "entering" some other account would be entered.

Re: Double-entry bookkeeping as a directed graph

#366
post #2

Hi, all! I'm not an accountant but decided to study double-entry bookkeeping and basic accounting a while ago. I learned a lot from many places, including great threads here on HN, and wanted to give back to the community. In this article, I explain the mechanics of double-entry bookkeeping and how I came to realize it's a directed graph. I know there are many accounting nerds on HN so please feel free to criticize o…

Great article. I would love an RSS feed or place to subscribe on your site so I can be sure to read the next in the series

Thanks! I just set up my RSS feed here: https://matheusportela.com/atom.xml

Let me know if it doesn't work for you!

Re: Double-entry bookkeeping as a directed graph

#367
post #103
post #88

Earlier quoted context omitted.

Every time money is exchanged, it has to come from somewhere and it has to go somewhere -- that's two places it need to be recorded (or "entered in the books"). Money can not be created out of thin air, and it can not be destroyed. Every movement of money has to be accounted for, which is why it's called "accounting". Double-entry accounting means you have to account for where the money comes from, and you have to ac…

> Where it can become confusing is when money leaves you or comes in from an external source. There are still two entries, but one entry is in one party's books and the other entry is the other's. For example, I get a paycheque and I enter my income in a little book with green paper and DB/CR columns. At the same time, my employer has entered an expense in their book. Double entries. NO. I mean your employer probably…

Might be the slight fever talking, but wouldn't the debit and credit be exactly the other way around? When you get paid by your employer, in your books the money enters your bank account ("debit") and is coming from an (abstract) employment income account ("credit").

When you pay your power company, the money leaves your bank account ("credit") and enters the (abstract) power company expenses, utilities expenses, or whatever account ("debit").

Re: Double-entry bookkeeping as a directed graph

#368

Earlier quoted context omitted.

While money can’t be created or destroyed (unless you run a central bank…), value can be. Ledgers always have a specific perspective, and that perspective can assign a different value to something than someone else. In the case of gifting something, from the perspective of the gifter, they destroyed some value they had on their books and got nothing of value in return. There’s an account type for tracking why your ne…

> While money can’t be created or destroyed (unless you run a central bank…), value can be. Money is created and destroyed by extending and resolving credit. central banks do it, but so do regular banks and non-bank institutions.

Macroeconomics is not bookeeping.

If a bookkepper destroyed or created money they would be in a great deal of trouble and probably end up working for the state for two years less a day.

Re: Double-entry bookkeeping as a directed graph

#369
post #368

Earlier quoted context omitted.

> While money can’t be created or destroyed (unless you run a central bank…), value can be. Money is created and destroyed by extending and resolving credit. central banks do it, but so do regular banks and non-bank institutions.

Macroeconomics is not bookeeping. If a bookkepper destroyed or created money they would be in a great deal of trouble and probably end up working for the state for two years less a day.

Are you, perhaps, confusing money with currency?

Money is just a promise. Anyone can create those. Which should be quite obvious. When you go to work to, as we literally say, make money, your employer is making a promise that in exchange for you work you can take something of some defined value later. Later, you will take that promise and turn it into something of value, such as food. Once spent, the money is destroyed. The promise is no longer valid. The deal is done.

Currency is a promise to a particular entity, such as a central bank. A central bank will loan you something of some value, you equally promise to give them something of equal value (we'll ignore interest for simplicity) back at a later date. Indeed, only the central bank can accept promises made to the central bank. If you accepted a promise on behalf of the central bank, without explicit authority, then you are quite right that trouble is coming your way.

Because there is a trust component required in promises, often promises made – such as the promise of your employer to feed you later – will be backed by a promise to the central bank. The central bank has a military to send if someone really tries to play nasty with promises made, so that carries a lot more trust than if you and I wrote up our own 'IOU'. This may be why you see money and currency as being one and the same. Often they are, but not necessarily so.

Accounting is simply for keeping track of promises. That's why we invented it. You don't need accounting for barter. It is the promises that necessitate accounting in order to keep track of what promises are outstanding and what are fulfilled. A bookkeeper doesn't create money per se, but they certainly account for money created and destroyed by the entity they are bookkeeping for.

Re: Double-entry bookkeeping as a directed graph

#370
post #368

Earlier quoted context omitted.

Macroeconomics is not bookeeping. If a bookkepper destroyed or created money they would be in a great deal of trouble and probably end up working for the state for two years less a day.

Are you, perhaps, confusing money with currency? Money is just a promise. Anyone can create those. Which should be quite obvious. When you go to work to, as we literally say, make money , your employer is making a promise that in exchange for you work you can take something of some defined value later. Later, you will take that promise and turn it into something of value, such as food. Once spent, the money is destro…

I think you’re right that currency is technically what I meant by money in that sentence. Like you said most people equate the two, which is why I prefer to use the word “value” for the various promises we track in accounting. It just has less baggage with most people since it’s more abstract. Value can definitely be created or destroyed from the perspective of the entity whose net value we’re tracking.

AR and AP accounts track promises, and as you point out, bank accounts and cash are also conceptually no different than other AR account. I call these asset and liability accounts State accounts. They track the current state of your promises and expectations. Since a promise can be reneged or an expectation not met, we need accounts that balance changes in State accounts when value is created or destroyed. That’s what income and expense accounts do — which I call Change accounts [1]

> You don't need accounting for barter.

I get what you’re mean, but I think a good way to get your head around multi-currency accounting is to think of it as double-entry bartering. Each currency only has value because it can be swapped with another currency at a certain rate. Which is basically bartering. How many sheep for how much grain? How many USD for how many GBP?

The interesting part is bringing double-entry into this:

- how do you balance a transaction when the two sides are in different currencies?

- How do you track the exchange rate between currencies?

The answer to each question is the other question. You balance entries by adding two more lines that track gain/loss due to exchange rate fluctuations. I did a talk on this at Fintech Devcon [2] and we cover this in our docs [3]

[1] https://news.ycombinator.com/item?id=39994335

[2] https://youtu.be/uH0SaCPKcPY?si=zKtPAPhvOnOGr8ei

[3] https://fragment.dev/docs#handle-currencies

Post reply on HN