[HN Gopher] Double-entry bookkeeping as a directed graph
___________________________________________________________________
Double-entry bookkeeping as a directed graph
Author : mportela
Score : 438 points
Date : 2024-04-10 10:13 UTC (12 hours ago)
(HTM) web link (matheusportela.com)
(TXT) w3m dump (matheusportela.com)
| mportela wrote:
| 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 or suggest changes where I got things wrong!
| RcouF1uZ4gsC wrote:
| > and how I came to realize it's a directed graph.
|
| One of the funnest things in computer science is realizing how
| some problem that you may not suspect initially turns out to be
| some type of graph.
| anodari wrote:
| Nice article, congratulations. I have worked with information
| systems all my life and one of the biggest insights I had was
| that the transaction, a purchase or a sale, which is the basis
| of the ERP system, is converted into 2 flows, the money that
| enters or leaves on one side and the product or service in
| another, this is accounting double entry. It may be obvious and
| simple, but I see that few people in my area have this
| understanding.
| samsin wrote:
| One of those threads may have been a blog post by Martin
| Kleppmann [1], who also describes double-entry bookkeeping as a
| directed graph.
|
| [1] https://martin.kleppmann.com/2011/03/07/accounting-for-
| compu...
| wjnc wrote:
| I've been in finance for nearly 20 years and okay, so, I'm kind
| of hesitant to admit... this is so great. Would love for my
| controllers to create such graphical flows of operating
| results. At some scale accounting gets pretty hard (hard as in
| at least one professor on the accounting policies team) and
| what I've learned from statistics is that graphics matter (Ross
| Ihaka, Andrew Gelman). With the appropriate abstraction any
| figure can get a graph of the constituting components. Moment
| of clarity here, thank you.
| foobarian wrote:
| Just wanted to say, I have been trying to understand double-
| entry bookkeeping for 30 years now and this is the first
| explanation that finally clicked for me so thank you!
| blackhaj7 wrote:
| 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
| sgarland wrote:
| Nothing of substance to add, I just wanted to say that I
| thoroughly enjoyed this post.
| nickpinkston wrote:
| I think people underestimate the beauty and impact of accounting.
|
| Just a tiny number of formulas (accounting identities [1]) and
| statements (P&L, balance sheet, etc.) can represent what's going
| on in any org in ways that can be roughly comparable. Reminds me
| of the "fundamental theorem of calculus" or "central dogma of
| biology".
|
| Accounting is also where we get math and written language [2] as
| ancient Mesopotamian civilizations initially kept track of
| commodities using specific "accounting tokens" [3] shaped like
| the thing represented, and that evolved into written language,
| imagine: hieroglyphics.
|
| Later, Al-Jajr [4] (aka algebra, literally "balancing") was
| invented by Al-Khwarizmi (origin of "algorithm") to solve Islamic
| inheritance law, whose rules of splitting up became a series of
| equations that led to the need to solve them quickly and
| correctly. Al-Khwarizmi's quadratic formula was the origin of why
| "algorithm" gets its name from him.
|
| [1] https://en.wikipedia.org/wiki/Accounting_identity
|
| [2] https://en.wikipedia.org/wiki/History_of_accounting
|
| [3]
| https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
|
| [4] https://en.wikipedia.org/wiki/Al-Jabr
|
| [5] https://en.wikipedia.org/wiki/Al-Khwarizmi
| wongarsu wrote:
| On the other hand some things in how accounting is
| traditionally done suffer from accounting predating a lot of
| "modern" math.
|
| Negative numbers were first used around the 3rd century in
| China and took until the 16th century to be used in Europe.
| Modern double-entry bookkeeping was invented in the 14th
| century in Europe. So if you ever wonder why they traditionally
| use a column for debit and one for credit, with definitions
| that seem a bit strange: that was the best way to make it work
| with only positive numbers.
| alexb_ wrote:
| I wonder if this is why losses are written down with ()
| instead of -.
| kqr wrote:
| Yes, that's part of it. The lengths accountants will go to
| to avoid having to deal with negative numbers is a bit
| funny.
| inopinatus wrote:
| it's because they know it's a slippery slope into
| allowing imaginary and irrational numbers, which is how
| accountants go to prison.
| PopAlongKid wrote:
| It's just to make it more visually apparent. A tiny
| preceding hyphen is easy to miss. Same reason why negatives
| are sometimes printed in red, leading to such phrases as
| "drowning in red ink".
| kinleyd wrote:
| I'm not sure if that's the reason for it, but I'm pretty
| certain introducing negative numbers would confound the
| accounting process.
| juped wrote:
| Negative numbers have no place* in accounting, and people
| need to stop thinking "oh, credits are just negative numbers"
| and hopelessly confusing themselves and others by putting
| nonsensical signs on an unsigned magnitude of flux.
|
| * you can actually think of oddball reasons you might
| consider a "negative credit/debit", but it's more akin to
| something like a negative mass in physics
| kinleyd wrote:
| I tried using John Wiegley's Ledger, which uses negative
| numbers. Everything was great about Ledger except for that
| part - I just couldn't wrap my head around it.
| juped wrote:
| Yeah, I had basically the same problem with it.
| barrucadu wrote:
| Maybe this is one of those things that's harder to
| understand if you have an accounting background. As
| someone without an accounting background, I found it
| incredibly intuitive: if money moves out of an account,
| that's a posting with a negative number; if money moves
| into an account, that's a posting with a positive number;
| a transaction is a set of postings that together sum to
| zero, indicating that no money has been created or
| destroyed out of thin air.
|
| There's no need to learn any confusing "credit" or
| "debit" jargon, you just need to think about the movement
| of money (which you had to do already).
| jjeaff wrote:
| Then this would be one of those cases where working around a
| problem (the lack of negative numbers) actually resulted in a
| superior product. You don't want negative numbers because
| that would require the description of a category to change
| based on whether it is positive or negative. You wouldn't
| want to be changing "Assets" to "Liabilities" every time the
| number goes below zero.
|
| You don't need negatives in accounting, because anything that
| is affecting a number differently than the rest (reducing
| rather than increasing), needs to be accounted for
| separately. Imagine showing negative revenue. That would be
| mostly useless. You want to see how much revenue you had, and
| in a separate entry, how many expenses. Imagine how
| misleading it could be to show $0 in expenses last month,
| when in reality, you had $100 in expenses, but you subtracted
| $100 out because you returned some big purchase from last
| month and got a refund.
| ebolyen wrote:
| > You don't want negative numbers because that would
| require the description of a category to change based on
| whether it is positive or negative
|
| That's actually already how it works, the kind of inverse
| you use depends on if the account is credit-normal or
| debit-normal. You end up in the same place.
|
| > Imagine showing negative revenue. That would be mostly
| useless.
|
| Revenue is already credit instead of debit, which if you
| were consistent in using negative numbers, a negative
| revenue be completely correct (so you would want to sweat
| if revenue was a positive number). It's weird, but it lets
| your cash on hand be a positive number, which is just a
| necessary consequence of the system.
|
| > Imagine how misleading it could be to show $0 in expenses
| last month, when in reality, you had $100 in expenses, but
| you subtracted $100 out because you returned some big
| purchase from last month and got a refund.
|
| Wouldn't that be accurate? This would be a debit of 100 and
| a credit of 100 which nets a balance of 0. But individually
| you would see the transactions and could sum the credits
| and debits if you were so inclined.
|
| Alternatively, contra-accounts exist if reporting these
| individually is material for some reason.
| soheilpro wrote:
| Having separate debit and credit amounts (instead of a single
| positive/negative number) serves another purpose as well: To
| track the total amount added or deducted from each account.
| accrual wrote:
| I also kind of like the double column approach with positive
| numbers, since neither party is exchanging "negative money",
| so it kind of underscores the balanced nature of the
| transaction.
| yread wrote:
| > can represent what's going on in any org in ways that can be
| roughly comparable.
|
| It can also obfuscate it pretty well!
| actionfromafar wrote:
| Obligatory "Seeing Like a State" reference.
| PopAlongKid wrote:
| That's where statement of cash flows[0] comes in -- because
| over a long enough time frame, profit is just cash in minus
| cash out. Hard to obfuscate that. Companies usually go
| bankrupt not because of negative net worth, but because of
| insufficient cash flow.
|
| [0]the third basic type of statement, in addition to balance
| sheet and profit & loss.
| Solvency wrote:
| so why isn't there a single cash flow view/report that all
| businesses use rather than all of these bloated and
| apparently ineffective methods? PL etc..
| joncrocks wrote:
| Cash flow is not just what is happening, but what will
| happen. i.e. the difference between when money goes out
| vs. it coming in.
|
| If you are selling widgets for $1.20 and buying them for
| $1, and they are delivered after you order them, you are
| limited on how many open orders you can have at any point
| in time even though you make money on each order.
|
| A companies cash flow will be dependent on employees,
| capital expenditures, money for stock, returns rates, tax
| requirements etc. etc. So it's heavily dependent on what
| type of business is being run and the specifics of how
| the business is being run.
| PopAlongKid wrote:
| There _is_ a cash flow report that all (public)
| businesses use -- as I said, it is one of 3 basic reports
| that capture different aspects of the companies financial
| performance. You need all 3 for a complete picture. The
| cash flow statement helps "unobfuscate" certain aspects
| of the other two reports (which I hope you agree are not
| _pure_ obfuscation).
|
| For example, see this Apple Corp. financial report[0] --
| it includes a statement of cash flows. I think you'd find
| that all other companies required to publicly share their
| financials will include the same report.
|
| [0]https://www.apple.com/newsroom/pdfs/FY22_Q4_Consolidat
| ed_Fin...
| kqr wrote:
| Yes, there's a neat simplicity in how everything in accounting
| must work out, but extrapolating from that into "P&L, balance
| sheet, etc. can represent what's going on in any org in ways
| that can be roughly comparable" sounds like a very
| financialised worldview.
|
| There are many important aspects of organisational design that
| are only loosely correlated with financial statements.
| shiandow wrote:
| I know people underestimate the impact. Before the 1800s or so
| Europe didn't have negative numbers, except for the odd
| mathematician who claimed you could calculate with them even if
| they were obviously meaningless.
|
| It was only after bookkeeping became ingrained into all levels
| society that negative numbers were considered equally real as
| positive numbers.
| nyrikki wrote:
| They didn't have modern notation, specifically the integers
| as a convention hadn't been adopted by primarily Greek
| mathematicians like Diophantus.
|
| That is very different from understanding concepts like owing
| someone money, which is a form of negative.
|
| Chinese and Indian mathematicians and accounting from
| Babylonian times didn't have the same mental blocks.
|
| The Bakhshali manuscript is still the first known example of
| modernish notation I think, but used +
| pcrh wrote:
| My understanding of double-entry bookkeeping is that it does not
| care who Alice bought the book from, nor what their accounts look
| like.
|
| Instead, the "double entry" that complements the money leaving
| Alice's cash ledger is the entry of the value of the book into
| Alice's "book ledger", one decreases by $20, and the other
| increases by the same amount.
| rco8786 wrote:
| You're right about the double-entry part, but bookkeeping more
| generally definitely cares about who Alice bought the book
| from.
| grantc wrote:
| Indeed. While dr==cr gets you far towards being able to
| calculate account balances and an entity's aggregate
| financial position, it's also fairly foundational that you
| are able calculate the company's position with different
| counterparties. So knowing that Alice purchased the book from
| Foo Booksellers, but maybe hasn't settled with FooBooks yet
| is super relevant.
|
| The company's accountant may care about balances and
| reconciling them back to things like the existence of said
| book, a receipt for payment or a bank transaction indicating
| settlement happened. At a big enough company, the accounts
| payables nerds may come along and be focused on making sure
| the full process procuring and paying has happened correctly,
| including record-keeping, tax compliance, and the actual
| movement of funds.
|
| When you start to scale how all of these processes are
| executed and recorded, it's dense enough that it still
| surprises me many years later.
| kayo_20211030 wrote:
| Kinda yes and no on this. The journal entry capturing the
| transaction will be for the transaction of Alice buying the
| book from Bob. The debits and credits will be tied to that JE.
| Somebody is keeping book and the accounts are the accounts of
| that somebody. A fictional bookstore will have all the info,
| but Alice's and Bob's bank might not.
| evrimoztamur wrote:
| In real-life bookkeeping the journal entries contain a lot of
| metadata which link the individual entries to other objects
| such as invoices, fixed assets (computers, equipment,
| furniture, etc.), contacts.
|
| In an organisation's accounting (Alice LLC), the basis entry
| would state a debit (increase of expense) in the book expenses
| account, credit (decrease of asset) in the cash balance. The
| complete entry would then make a reference to the
| invoice/receipt of the purchase and the contact details of the
| bookstore (address, chamber of commerce registration ID, tax
| number, etc.).
|
| The exact level of detail is determined by how 'complete' your
| books are supposed to be. A book expense might not mean much to
| Alice LLC (which does not deal in book sales/purchases), but a
| laptop should (see more on the subject of fixed asset
| registries), or a large invoice from a business from a
| different country (which will require a lot more diligence with
| tax 'metadata').
|
| On the other hand, the bookstore definitely cares more about
| books and will then consider the sale and replenishment of its
| book inventory, and once again introduce more meta-accounting
| data (see more on the subject of management/manufacturing
| accounting).
| BoppreH wrote:
| I always enjoy these explainers that use computer science terms.
|
| In this case, you can be more precise about the type of graph:
| double-entry accounting creates a Directed[0] Bipartite Graph[1]
| with Labelled Edges[2]. Every edge is between a Transaction and
| an Account nodes, which makes it bipartite, and the amounts are
| edge labels.
|
| [0] https://en.m.wikipedia.org/wiki/Directed_graph
|
| [1] https://en.m.wikipedia.org/wiki/Bipartite_graph
|
| [2] https://en.m.wikipedia.org/wiki/Graph_labeling
| kayo_20211030 wrote:
| Nice job on this. But, one has to be careful with redefining
| terms that have a generally accepted meaning. Changing
| Debit/Credit to Incoming/Outgoing smacks of jargon and will cause
| confusion. Any bookkeeper will understand what credit cash and
| debit expense means. Putting that in incoming and outgoing terms
| will not help the people who do the work, or have to explain the
| work. It's probably worth the effort of learning the nomenclature
| that's been useful for a few hundred years rather than falling
| back on what are metaphors.
| EvanAnderson wrote:
| I'll go further: Knowing basic accounting and bookkeeping
| jargon is a super power when it comes to dealing with finance
| people. Your credibility builds tremendously when you can
| engage with them using the proper jargon correctly.
| UglyToad wrote:
| But the problem is the accounting jargon is counter (contra?)
| to the layman's gut understanding.
|
| If I get credited or I use a credit card money came from
| nowhere, woohoo. If I have a debit well that sounds like debt
| and my money decreased, boo.
|
| I get that actually there's a good reason for the names but a
| field that doggedly sticks to non intuitive jargon that runs
| counter to every usage yet encountered for outsiders could do
| with some different non-overloaded terms.
| mrkeen wrote:
| > Changing Debit/Credit to Incoming/Outgoing smacks of jargon
| and will cause confusion.
|
| I disagree. Discussions like this on HN always invite someone
| to say "Look, it's super simple. Credits are just... and debits
| are just ...". Then a reply saying "You have it backwards.
| Look, it's simple! Credits are just..."
|
| I would be perfectly happy to ditch those terms forever.
| mrkeen wrote:
| Plenty of downvotes, and yet, after writing this prediction,
| this thread is indeed filled with people all defining the
| terms 'Credit' and 'Debit' at one another. :D
| MeetingsBrowser wrote:
| It seems like the target audience of this is people not already
| familiar with accounting.
|
| I don't understand how describing debit/credit (accounting
| jargon) in layman's terms smacks of jargon, but maybe that is
| because I am a layman =)
|
| As someone with no accounting background, credit/debt described
| as "money go in, money go out" seems like a good enough
| explanation in the context of this post.
|
| Do the "true" definitions of credit/debit differ from that in a
| meaningful way here?
| mrkeen wrote:
| I just Googled it, and picked the first two results:
|
| > A debit decreases assets or increases liabilities, while a
| credit increases assets or decreases liabilities. [1]
|
| > A debit is always used to increase the balance of an asset
| account, and the cash account is an asset account. [2]
|
| [1] https://xendoo.com/blog/debits-and-credits/ [2]
| https://www.fool.com/the-ascent/small-
| business/accounting/ar...
|
| It's not just that they're _a bit confusing_ , it's that
| those words serve exactly one purpose, which is to
| disambiguate the exact thing that people find confusing about
| them.
|
| The biggest indicator of their failure is that they are
| always explained in terms of something clearer, and the
| reverse it not true. No-one says: "I don't understand what
| 'we received $50' means, can you explain that in terms of
| credits and debits?"
| wrycoder wrote:
| The first definition is exactly backwards - ignore it!
| qznc wrote:
| Still too complicated. It goes wrong with "Let's add the
| Transaction column to our table."
|
| Don't store the account data. Instead store the transactions.
| Compute the accounts from that. The table "Transactions" should
| have the fields: Date, Amount, SourceAccount, TargetAccount,
| Description.
|
| That is how it becomes beautiful in my opinion. Unlearn this
| habit of thinking in accounts just because that is what you know
| from your bank statements. Think in cash flows.
|
| (Ok, this is too simple for the tax use case. Sometimes
| transactions have multiple sources or targets. So my schema above
| needs to be adapted for that. My point is that the thinking
| should still be different.)
| thfuran wrote:
| Isn't having to replay every transaction in history to query
| current balance rather inefficient?
| globular-toast wrote:
| It's a trade off. Immutability is a big enough win to pay the
| price of a few extra CPU cycles. In practice it's very quick
| anyway. Computers are very good at adding numbers together
| (it's almost like it's what they were made for!). I keep all
| my accounts for over 12 years in one file and I still don't
| notice any delay when calculating balances etc.
|
| If it does become a problem then one solution is to take sums
| at some point in time and start the ledger again paying each
| account from a contra account containing the previous
| balance.
| qznc wrote:
| You can cache it. ;)
| Solvency wrote:
| technical speaking what does 10 years of transactions look
| like when it's "cached" with one current year still being
| raw text lines? how are the two reconciled?
| airstrike wrote:
| basically 9 years are cached and the last year is
| recalculated as needed. you have a source of truth for
| what the data looked like at moment T+9 years, you can
| just take as granted. and then process the transactions
| following that date "live" as needed
| rockostrich wrote:
| Once a period of time is reconciled then you can pre-compute
| whatever information you need and then you're only computing
| the current balance for the current period of time that
| hasn't been reconciled.
| Mister_Snuggles wrote:
| The act of "posting" a transaction updates the ledger to
| reflect the current balance. Think of the ledger as "Current
| state" and the transactions as "how we got there".
| inopinatus wrote:
| Computers are astonishingly fast at summing integers.
| epcoa wrote:
| They are not comparably astonishingly fast at retrieving
| that data.
| inopinatus wrote:
| accounting data is so compact that the word "comparably"
| is doing all the heavy lifting in that statement.
| thfuran wrote:
| They're pretty fast, but if everyone writes software that
| does 10,000x more computation than necessary on that basis,
| suddenly they're slow.
| inopinatus wrote:
| [delayed]
| MgB2 wrote:
| That's basically what beancount does, isn't it? You basically
| have all the transactions in your plaintext files, and it
| generates the full ledgers from those on the fly once you want
| to do any evaluations.
| EvanAnderson wrote:
| Any time I've dealt with bookkeeping or accounting software
| where I find functionality like "Rebalance accounts" I become
| suspicious and wary. I know that the programmer has tried to be
| clever and keep running totals, versus calculating them the
| source transactions. There be dragons there.
| Mister_Snuggles wrote:
| > Don't store the account data. Instead store the transactions.
| Compute the accounts from that. The table "Transactions" should
| have the fields: Date, Amount, SourceAccount, TargetAccount,
| Description.
|
| This is a bad design, please don't do this.
|
| The better design is to have header and detail tables:
|
| Header: TransactionID, Date, Description, (other fields as
| required, e.g., posting status, reconciliation status, etc)
| Detail: TransactionID, LineNumber, Account, Amount,
| Description, (other fields as required, e.g., reference numbers
| for subledgers, etc)
|
| This allows a transaction to affect any number of accounts. In
| effect, the transaction ends up reflecting a business
| transaction which may affect many accounts.
| EvanAnderson wrote:
| I don't think you're saying anything different than the
| parent poster, fundamentally. You're both saying "event-
| source the totals".
|
| You're adding an abstraction to enable more flexibility and
| functionality. That doesn't change the fundamental event-
| sourced nature of totals.
| atemerev wrote:
| And that is how people invented blockchain (it is slightly more
| complicated, particularly that each transfer should include the
| source address in the output, but the idea is the same). As
| mentioned elsewhere in the thread, we also need multiple
| inputs/multiple outputs for each transaction.
| dkyc wrote:
| I find it a strange choice to explain double-entry bookkeeping
| with the example of "one entry for Alice, one entry for Bob".
| That's really not what it's about. It's obvious that a
| transaction with two parties could be recorded in two places, but
| to me the crucial point of double-entry bookkeeping is that it
| requires two entries _for each party of the transaction_. So if
| Alice buys book from Bob, _four_ entries are made.
|
| I get that this is supposed to be a simplification for
| educational purposes, but I find this is simplification is an
| oversimplification, since it omits the key point.
| em-bee wrote:
| i was about to write the same thing. knowing that double-entry
| is meant to apply to myself only, i actually found the example
| confusing, because well, of course bob is going to have an
| entry in his accounting book, but i don't care about bobs
| accounts, i don't want to track that. i only care about mine. i
| buy a book. how do i record this transaction using double entry
| bookkeeping in my accounting book?
|
| and bob is not even doing any bookkeeping. he is bookselling
| ;-)
| toong wrote:
| You gained $20 worth of assets, so the counterpart of the $20
| leaving your bank account is countered by your assets-account
| gaining $20
|
| Now each year your book loses 1/5th of its value, due to wear
| and tear (4$ disappearing from your assets-account), this is
| countered by your depreciation-account (4$ tax write off,
| every year!)
|
| After 5 years, it is worth $0 according to your books, but
| you manage to sell it again for $10: your bank account gets
| debited for $10, while your capital-gains-account gets
| credited for $10
| nolongerthere wrote:
| This is the best explanation, everyone else is giving wrong
| explanations that appear to be at least partially sourced
| from some AI.
| probably_wrong wrote:
| And how about food? I can understand a book having a resale
| value I keep in my books, but once I've eaten the hot-dog I
| bought it is gone forever.
| chimeracoder wrote:
| > And how about food? I can understand a book having a
| resale value I keep in my books, but once I've eaten the
| hot-dog I bought it is gone forever.
|
| Perishable and consumable food wouldn't be counted as an
| asset in the first place. You spend the money - it's
| credited to your asset account (reducing the value of
| your cash-in-hand) and then debited from your expense
| account (reducing the value of your equity - or, in more
| layperson's lingo, increasing the total sum of the
| expenses you incurred during that period).
| eviks wrote:
| Of course it would be, asset is anything of value, you're
| confusing with subtypes of assets. Just mujhe liability
| is anything you owe regardless of for how long
| chimeracoder wrote:
| > Of course it would be, asset is anything of value,
| you're confusing with subtypes of assets. Just mujhe
| liability is anything you owe regardless of for how long
|
| If an office buys snacks on Monday for the office party
| on Friday, they're not counting it as an asset and
| depreciating it on their books.
|
| If food production or delivery were part of the core
| business, it would be one thing, but in the context that
| OP's talking about, it would be overkill at best (and
| fraudulent, in extreme cases) to try and count a
| transient consumable as an asset on their books.
| eviks wrote:
| Depreciation isn't relevant here, again, you're confused
| in the types of assets, not all of them are depreciated,
| only some with some specific properties like time of
| expected user. Just read the definition of assets in any
| (accounting) dictionary, or try to record your snack
| purchase in real accounts and see which side of the
| balance sheet this account end up in (hint: inventories,
| assets).
| chimeracoder wrote:
| > or try to record your snack purchase in real accounts
| and see which side of the balance sheet this account end
| up in (hint: inventories, assets).
|
| Yeah, and as I said, this makes sense for a company for
| which food is a relevant part of their business, but in
| the context OP is asking about, nobody is tracking it
| this way.
| renewiltord wrote:
| Do you actually do that? When people are working late at
| the office and you order pizzas you put that into your
| inventory and then remove it as people consume the
| pizzas? I record that into a separate operating expenses
| account meant for this kind of fringe benefit, not into
| inventory.
|
| Pretty small so I do the accounting as well, but I think
| I'd lose my mind if I had to record them into inventory.
| Then when they leave half the pizzas for the next day, I
| record that? No way.
| eviks wrote:
| you don't need to record the halves, nothing stops your
| pizza order to be automatically recordered as
|
| -A_cash +A_inventory
|
| -A_inventory + L_expenses
|
| Sure, if your pizza is frozen and consumed in another
| period, your books will not reflect reality, but so what,
| when talking about the very basics of accounting you
| offset that misrepresentation of a simple example by
| gaining an important pedagogic benefit! Which one,
| though? What do you gain by denying that pizza is an
| asset, going so far as calling recognition of an asset as
| an asset a fraud (but only in extreme cases of 5 pizzas!)
| and bringing depreciation/core business in?
| renewiltord wrote:
| Perhaps this is obvious to you, but I don't see what I'm
| gaining by doing this. My inventory management system
| will have different things unless I'm also recording
| these pizzas in there for the day. And it will show my
| inventory valuation as fluctuating when I do things like
| lunch or dinner for the team. It really seems useless to
| me when running the business.
| eviks wrote:
| That's fine, many accounting practices eschew precision
| for simplicity, you don't mark-to-market everything,
| depreciation is linear, etc, so if you don't see any
| value in this, but only troubles with integration with
| other systems etc, then it's useless to you. But then the
| article wasn't about running a real business
| chimeracoder wrote:
| > Do you actually do that?
|
| No, nobody does this. GP is engaging in an exercise in
| pedantry, under the guise that it serves some pedagogical
| purpose. Personally, I don't think it's particularly
| useful to teach people about how things could
| theoretically be done, when it's much easier to show then
| how things actually are, but I'm sure there is some
| accountant nerd out there who is extremely meticulously
| tracking the total value of the gumballs on the
| secretary's desk as they are consumed.
| samatman wrote:
| 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! When you acquire an asset, which is
| consumed or otherwise has no book value, that's an
| expense.
|
| So when you buy groceries with a debit card for a hundred
| bucks, that's a +100 in Expenses:Groceries, and a -100 in
| Assets:Checking. If you buy the same groceries with a
| credit card, it's +100 in Expenses:Groceries, and -100 in
| Liabilities:CreditCard. When you pay off the credit card,
| that's -100 Assets:Checking, and +100 in
| Liabilities:CreditCard.
|
| Asset is overloaded here, because Expenses are not
| included in calculating net assets. It's confusing! I
| find it even more confusing that Income is a liability,
| which always gets lower. That's because whoever paid you
| had a liability to do so, which they met out of assets.
|
| This is also why, when you pull a CSV of a checking
| account, purchases are positive numbers, and income is
| negative. A CSV of a credit card will have purchases as
| negative, and payments as positive. It's the difference
| between an asset account and a liability account. Again,
| not to be confused with net liabilities: Income is a
| liability, but not one you owe anyone, rather the
| contrary, Income just gets smaller and smaller (ideally!
| If it isn't getting smaller then your net assets will be
| shrinking, most of us can't afford that for long).
|
| The main thing is that an account which fluctuates from
| zero to positive, or accumulates, is an asset account.
| One which fluctuates from zero to negative, or
| accumulates negatively, is a liability account. There are
| times when this matters, notably when you can take a tax
| deduction for expenses, that's a good example of why
| they're on the asset side of the books.
| samatman wrote:
| This comment fleshes out what I'm saying here:
| https://news.ycombinator.com/item?id=39992035
| mulmen wrote:
| It's been 15 years since I took an accounting course. Why
| would my bank account be debited when the balance went up?
| Is a debit not negative? Is the cash balance presented as a
| negative?
| lottin wrote:
| In your books, your bank account is an asset, and
| therefore an increase in the balance is recorded with a
| debit. In the bank's books, it's the other way around.
| awirick wrote:
| Your bank account is an asset for you, so debits increase
| the balance while credits decrease it. This is also
| called a "debit normal" account.
|
| Liability accounts are tracked in reverse and are "credit
| normal". You increase the value (how much you owe) with a
| credit to the account and decrease the value (payments
| you receive) with a debit.
| orthoxerox wrote:
| In a nutshell, double-entry bookkeeping is tracking all your
| money in two ways:
|
| - where has it come from/has it forever gone? - where is it
| now?
|
| So, you start a simple ledger of having $100 in cash with a
| transaction like this: Dr "cash" Cr
| "original funds" $100
|
| Then you spend some of it on food and loan some to Bob:
| Dr "food expenses" Cr "cash" $25 Dr "loan to Bob" Cr
| "cash" $20
|
| Bob pays you back $22: Dr "cash" Cr "loan to
| Bob" $20 Dr "cash" Cr "interest income" $2
|
| You can't write 'Cr "Bob" $22', because... I don't want to
| get into the principles of accounting, but basically all
| asset accounts only go one way. You can't have minus two
| dollars in your pocket, and Bob can't owe you minus two
| dollars either.
|
| Some of the accounts, like "original funds", aren't very
| useful by themselves, but they are the only way to make sure
| "money I literally have in my account/pocket", "money I owe
| people" and "money that people owe me" can all be counted
| together: if you tally up both kinds of the accounts, the
| total sum should be the same, just with the opposite "sign".
| Octokiddie wrote:
| Every explanation of double entry accounting seems to do the
| same thing. If I'm trying to understand the _double_ part of
| double-entry bookkeeping, what exactly does the "double" refer
| to? What's being "doubled"?
|
| How would you salvage the article to actually explain the
| "double" part in detail? Could you do it purely from Bob's (or
| Alice's) perspective?
| insane_dreamer wrote:
| Because double-entry accounting requires two (thus "double")
| entries for each transaction (i.e., Alice buys a book)
|
| - one for the assets/liabilities account involved in sending
| or receiving the money ($30 credit, bank account) - one for
| the income/expense account to which the transaction
| corresponds ($30 debit, "education" expense account)
|
| one of the two entries is a credit and the other a debit
| alexambarch wrote:
| From what I got out of the article and my own limited
| understanding of double entry bookkeeping, the "double" seems
| to be referring to the part where we split a transaction into
| credits and debits as opposed to a transaction with positive
| or negative balance. The doubling is happening with the
| labels we use to describe what's happening with the money.
|
| From an individual account perspective, there's a doubling of
| the number of columns you could enter a transaction's amount
| into.
| gorjusborg wrote:
| The core innovation of 'double entry' is that you can see
| the flow of money between accounts for every transaction.
|
| This is possible because you (the accountant) are always
| adding a back-reference from the other account (hence the
| 'double' in 'double entry').
|
| There's really not much to it. It throws people that are
| new to it for a loop, I think, because it is a strange way
| of behaving, and it isn't obvious why you're doing it until
| you have to track down something that doesn't balance. It's
| just a disciplined behavior that accountants started using
| because it allows one to track things that were difficult
| without it.
| vpribish wrote:
| this is probably not true, but I heard that this stuff
| predates the idea of negative numbers so you have db and cr
| accounts that offset each other without negatives.
| bluepencil123 wrote:
| The 'double' in double entry book-keeping is related only to
| the book keepers own records/books. It has nothing to do with
| counter party's record keeping.
|
| If Alice purchases a house worth $100,000 in cash, then 2
| (double) accounts will get effected. Her cash account will
| decrease (Credit) by $100,100 and simultaneously her House
| equity account (or any other appropriate name such as
| immovable asset etc) will increase by $100,000 (Debit).
|
| This can be recorded in a 3 column table as
| Credit account -- value -- Debit account Cash --
| $100,000 -- House equity
|
| In the above transaction, two accounts were effected. Hence
| the name double entry. This gives a truer picture of ones
| assets and liabilities.
|
| Note: 1. Debit and credit dont have much to do with increase
| decrease. 2. A transaction can be modelled to have affect
| more than 2 account. For example if Alice were to make the
| purchase with $80,000 loan, then the book keeping could go
| like Credit Lender $80,000 Credit Cash
| $20,000 Debit House Equity $100,000
|
| For the sake of better understanding, if one is uncomfortable
| with having one record affecting 3 accounts, one can be more
| robust and split the loan and the purchase into 2
| transactions. After all, taking a loan and purchasing a house
| are 2 different events(transactions).
| Transaction one -> Credit Lender $80,000 Debit
| Cash $80,000 Transaction two -> Credit Cash
| $100,000 Debit House equity $100,000
|
| edit 1: attempt at better formatting
| datavirtue wrote:
| Don't forget the depreciation, interest, maintenance, and
| tax accounts if you want to track those against the real
| estate cost basis for various purposes. You also need to
| figure out how to create and map accounts to IRS rules or
| you could put yourself in a real bind when it comes to
| figuring out tax liabilities or deductions.
| atomicfiredoll wrote:
| Remember, this was all done on paper before software with
| tagging and such existed.
|
| I'll give a description shot, since I've been doing finance
| work recently. Other people can feel free to correct.
|
| A company using double entry (as opposed to single) has a
| "chart of accounts." This means they have a bunch of
| imaginary accounts for tracking everything, including:
|
| - Assets (e.g. cash on hand.)
|
| - Liabilities (e.g. loans)
|
| - Equity (e.g. investments in the company from outside
| parties)
|
| - Income/Revenue: (edit: as PopAlongKid kid mentioned, I
| forgot this one. This could include sales revenue, but also
| things like interest.)
|
| - Expenses (e.g. team lunch or a flight cost)
|
| Some of these "accounts" may map to actual bank accounts:
| there is likely a liability account for a credit card or an
| asset account for the company checking.
|
| Knowing all that, every time money is deposited or withdrawn
| (a transaction) the "double" references the fact that it's
| recorded in the journal (a.k.a ledger) of two accounts.
| (Edit: As bregma mentioned, one records where money is coming
| from and the other where it's going.) Often, an expense is
| often recorded in the checking "account" and the and the
| corresponding expense "account." E.g. a flight may be
| recorded in a travel expense "account," but you also record
| that the money came from the checking account. Every
| transaction is recorded in two places.
|
| Beyond just being more accurate than single entry, this helps
| with important finance reports like Profit & Loss, since you
| can now see how money is moving around.
|
| Edit: Now that I'm back on my desktop, these are a couple of
| useful links for understanding basic double entry
| bookkeeping: Accounting for Computer Scientists [0] and
| Accounting for Developers, Part I | Modern Treasury Journal
| [1]. What is a Sample Chart of Accounts for SASS Companies
| [2] illustrates some charts, which may be helpful for some
| folks.
|
| [0] https://martin.kleppmann.com/2011/03/07/accounting-for-
| compu...
|
| [1] https://www.moderntreasury.com/journal/accounting-for-
| develo...
|
| [2] https://kruzeconsulting.com/startup-chart-accounts/
| kqr wrote:
| > this helps with important finance reports [...] since you
| can now see how money is moving around.
|
| This is the real benefit I've encountered. Any time I try
| to "simplify" financial recording for someone else and
| avoid double-entry, I inevitably end up wanting to perform
| a query that would be easy in a double-entry system but is
| not in any other system.
| atomicfiredoll wrote:
| Right. I didn't mention that a chart of accounts can look
| different in different companies/sectors. Some accounts
| may be considered nested (software may even show them as
| nested.) Then you can roll the totals for all accounts of
| a type into a general category account like "Assets" or
| "Expenses." That makes it easier to answer questions
| like, "how much have we spent in total?"
| Fire-Dragon-DoL wrote:
| How do you determine which thing goes in which account, is
| it subjective or there is a formal way with a definition
| atomicfiredoll wrote:
| The chart can differ in different companies or sectors.
| In my mind, it comes back to what you want to be able to
| report on.
|
| Some companies may have a larger and more detailed chart
| of accounts so that they can have very specific
| breakdowns of things. I've heard of big charts where each
| of a company's departments have specific accounts and all
| departmental transactions go there while the rest are
| lumped into a "Sales, General, and Admin" bucket.
| (Although I think it's more common to tag transactions
| with a department code these days?)
|
| That said, categories can be broken down into sub-types
| beyond Assets/Liabilities/Equity/Income/Expenses. For
| example, assets are categorized based on how quickly they
| can be converted to liquid money and if they physically
| exist. So, under the assets account you may have accounts
| for current, fixed, and intangible (e.g. trademark or
| domain name) assets and you would record those
| appropriately.
|
| Edit: To answer the question more directly, it depends on
| the company and how they've customized their accounts or
| guidelines. But, there are general accounting practices
| that mandate the need for specific things and common
| questions to be answered, so a lot similar structures and
| guidance emerge that a company's finance team could use
| to tell you where something belongs.
| zie wrote:
| In a general sense, it really doesn't matter, as long as
| you are consistent.
|
| That said, there are accounting standards that define the
| general set of accounts for a particular industry, etc.
|
| But every person having a set of books will want to
| customize it to some degree.
|
| For instance in a personal set of books, if you want to
| track every person you pay, you might have accounts, 1
| for every single person you have ever paid, ever.
|
| That obviously can get pretty big! Others might not care
| that their electricity provider changed from Tootie inc.
| to Turtle inc, so they just have Utilities:Electricity as
| their account name.
|
| Others might not care at all, and just have a very
| general "Expenses" account for things like that.
|
| Make sense?
|
| The important part is consistency of using the same
| accounts for the same transactions.
| Fire-Dragon-DoL wrote:
| OK So it is somewhat open but you could use a set of
| standard accounts, I see.
|
| Makes sense. Probably it's important to keep somewhat of
| a registers of accounts available to avoid making
| mistakes and to write directions on where things should
| go
| tomnipotent wrote:
| There's also GAAP in the US and IFRS in Europe, which are
| standards for how certain things need to be done to be
| compliant. It's not specific about things like account
| names or how your ledger should be structured, but
| outlines many expectations and rules/constraints that
| build confidence in the resulting numbers.
| zie wrote:
| Agreed, but every industry/sector might have their own
| set of standards that usually are overlays on top of
| GAAP/etc. For example in the US for state and local
| governments there is GASB: https://gasb.org
| zie wrote:
| Of course! There is a standard term for that: Chart of
| Accounts
|
| If you search for example chart of accounts <INDUSTRY YOU
| CARE ABOUT> you can probably get a sample set to work
| from.
| PopAlongKid wrote:
| >A company using double entry (as opposed to single) has a
| "chart of accounts." This means they have a bunch of
| imaginary accounts for tracking everything, including:
| - Expenses (e.g. team lunch or a flight cost) -
| Liabilities (e.g. loans) - Equity (e.g. investments
| in the company from outside parties) - Assets (e.g.
| cash on hand.)
|
| Not sure why you didn't complete your list by adding
| "Income".
| atomicfiredoll wrote:
| Thanks, I was sure I was missing something obvious like
| that when trying to simplify the explanation.
| m3kw9 wrote:
| So double entry is defeated if you uses a computer to enter
| the entries. For example if you brought a laptop for 1000,
| but you accidently wrote 2000 AND the computer
| automatically entered 2000 in the asset account it would
| still balance even though it was a mistake to enter 2000.
|
| In addition, you can still make the same mistake by hand
| for both entries. So I'm still not getting how double
| entries catch mistakes
| jsty wrote:
| When you reconciled the balance in your bank account /
| credit card statement against that in your set of
| accounts, you'd notice the error as the statement balance
| would be 1000 higher than reflected in your accounts.
| JetSetIlly wrote:
| There are several categories of mistake that you can make
| when bookkeeping. Some are caught by the double-entry
| system when a trial balance is prepared.
|
| The error you've described is an "error of original
| entry" and will be invisible if you only look at the
| trial balance. It can ultimately be caught when you
| compare the banking ledger with what's actually in the
| bank.
|
| Other errors that don't appear in the trial balance can
| be incredibly hard to detect and in fact, may never be
| noticed. This is where the real art of bookkeeping is
| IMO.
|
| The types of errors that _do_ affect the trial balance
| are things like forgetting to enter a purchase in the
| purchase ledger but entering the transaction into the
| banking ledger correctly. Silly errors really, but we can
| all need help to stop us making those.
| Linosaurus wrote:
| > actually explain the "double" part in detail?
|
| $100 appears in your account. That's one part. The other part
| depends on why.
|
| * you moved money from another account, the double is -100 in
| that account.
|
| * you sold stuff, +100 in income.
|
| * you borrowed some money, +100 in 'debt'.
|
| In a physical book each of these categories would have a left
| and right column, and each transaction has numbers in one
| left and one right column. Or in many columns but the sums of
| left vs right columns must be the same.
| theptip wrote:
| It's a checksum; by decomposing every transaction into a
| double of (credit A, debit B) that must sum to zero, you
| catch random arithmetic errors.
|
| You can think of it as "conservation of value", so you can't
| just create money out of thin air in your payment service
| (credit), without tying it to some account with a
| corresponding debit.
|
| This originally was intended to protect against typos; eg
| write a 10 instead of 100, at the end of the day your ledger
| needs to balance. In software typos are less likely bit it
| still provides auditability to prevent a large class of bugs
| from wiping you out.
| dragonwriter wrote:
| > This originally was intended to protect against typos;
|
| Double entry bookkeeping is much older than typing, but,
| yes, its a check against incorrect entries.
| ectopasm83 wrote:
| Babylonian dogs walking on your clay tablet.
| jacques_chester wrote:
| Speaking of history, I learned that the word "control"
| comes from _contra rotulus_ -- roughly "checking against
| the wheel", which was apparently from an early medieval
| device for keeping tallies. The second meaning of
| "domination" came later.
| bregma wrote:
| 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 account for where it goes, and
| each of those is a separate entry and it all has to add up to
| zero.
|
| 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.
| fauigerzigerk wrote:
| _> 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._
|
| I agree with your first two paragraphs but not with this
| last one. When money leaves you or comes in from an
| external source, there is always some proxy account for
| that external party in your own books. And the whole
| situation is mirrored in the accounting system of the
| external party (unless they are a consumer). Each party
| records two entries.
| bregma wrote:
| Yes. I have a proxy account with one entry (say,
| "expenses: bank fees"). They have a proxy account with
| one entry (say "income: bank fees"). Between the two
| proxy accounts there are two entries. Money can be
| neither created nor destroyed.
| randomdata wrote:
| _> Money can not be created out of thin air, and it can not
| be destroyed._
|
| Yet accounting is necessary _because_ money is created out
| of thin air. Money is just the representation of debt, an
| IOU. There needs to be a record of it in order to know that
| a debt was created and that a debt was destroyed.
|
| More practically, let's say you give me corn today, and I
| promise to deliver some of the chickens fed that corn to
| you after it is ready to for slaughter. Money keeps track
| of the promise outstanding. We record that promise, or
| account for it if you will, so that we remember that there
| is a promise and so that we can later ensure that the
| promise was delivered upon as agreed. Something that
| becomes especially important when you realize that promises
| can be traded on to other people who weren't party to the
| initial deal. Perhaps you don't really want chicken, but
| would prefer a watch instead. Luckily the watch maker would
| like to eat chicken for dinner down the line, so you give
| him the promise of chicken in exchange for the watch. So
| on, and so on.
|
| Realistically, double-entry accounting is really quadruple-
| entry accounting. You record that something was received
| and you record that a promise was made, then, later on, you
| record that something was delivered as promised and also
| record that the promise is no longer outstanding (or in
| reverse if you are on the opposite end of the transaction).
| A profit indicates that people still owe you things that
| you haven't collected upon. A loss indicates that you still
| owe people things that you haven't yet delivered.
| zie wrote:
| > 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 has a set of books, but
| that's not true in your own local set of books.
|
| In your local set of books you would have something like:
| ACME, inc Employment Income $100 DEBIT Bank
| Account $100 CREDIT
|
| You are accounting for ACME, Inc's Employment expense in
| your set of books too.
|
| When you send a payment to your Power Company:
| Power Company Expense: $100 CREDIT Bank Account:
| $100 DEBIT
|
| I mean if you are categorizing expenses you might do
| something like that. If you aren't, you might title one
| account "Expenses" and spend it all there, it doesn't
| really matter what you call the accounts, just that you are
| consistent.
| bregma wrote:
| Well, if I have a local entry ACME, inc
| Employment Income $100 DEBIT
|
| in my employment income account that money has not come
| out of thin air. Remember, money can not be created nor
| destroyed in this system. Somewhere there is a matching
| entry something like bregma, services
| rendered $100 CREDIT
|
| in my employer's books. And that money, in turn, was
| probably moved in from some other account internally.
| Mean time the only real movement of "money" was an
| electronic communication between two banks (my employers
| and mine), with a matching entry in an account in each.
|
| Things like income accounts and expense accounts are not
| magic sources or sinks for money flows. They're just half
| of a double entry system with the other half somewhere
| else.
| m3kw9 wrote:
| What if your company decides to be generous and just gave
| 1000 to random Joe, what is the double entry for that?
| tromp wrote:
| Cash account is credited $1000, and Gifted (or
| Cash_Gifted) account is debited $1000.
| randomdata wrote:
| That method only works if money can be created out of
| thin air, and also destroyed. The grandparent comment was
| pretty clear that money cannot be created out of thin
| air, nor can it be destroyed.
|
| A curious contradiction. How do we resolve it?
| bregma wrote:
| No money was created or destroyed. The "cash gifted"
| account would have a corresponding entry in the
| recipients books reflecting the cash received. Unless
| he's delinquent about updating his books in which case
| it's implied but not realized. Few (unmedicated)
| individuals are going to track every transaction to that
| level though.
|
| If it was important to account for the cash donation, the
| company would require a receipt in exchange. If it's part
| of a coverup the receipt may be for something unrelated
| but at least the books are in good order.
| randomdata wrote:
| Cash went out. One half of the double entry is correct.
| But nothing came back in return. There is no
| corresponding element of trade to account for. The
| transaction doesn't balance. Which is obvious in human
| terms. That's the point of a gift - the transaction isn't
| supposed to balance! But formal accounting methods are
| not as fluid as people are.
|
| So, of course, in reality money was created (and then
| destroyed, it being a gift) in order to make the
| transaction whole. But as far as this magical fairytale
| land where money can't be created the entry doesn't work.
| You can't account for nothing.
|
| Let's say it's not a gift. Let's say someone is borrowing
| $1,000 cash instead. The same applies. There is no
| corresponding element in trade to account for. It doesn't
| balance. Thus, when the cash goes out you need to create
| money out of thin air to satisfy the other side of the
| transaction, which is later destroyed when the cash is
| returned.
| thereticent wrote:
| You're misunderstanding double-entry bookkeeping.
| Something does not have to come into the company got
| every transaction moving something out of the company. If
| your company gives $1000 to Billy, you document a $1000
| debit from your gift account and a $1000 to Billy's
| account payable. The goal isn't to get any one account to
| zero but to get a source and destination recorded
| separately for every movement of funds.
|
| Lending would be at least two sets of doubly-recorded
| transactions.
| randomdata wrote:
| _> The goal isn 't to get any one account to zero but to
| get a source and destination recorded separately_
|
| Right, because transactions are actually two-sided. I
| give you something, you give me something in return.
| That's how people work with each other. And, as such, we
| account for a source and destination because that matches
| what actually happens.
|
| But often times you only offer a promise. For example, I
| write some software for you, and in return you offer me
| food. But I'm not hungry right now, and I certainly don't
| want food that is going to spoil before I get around to
| eating it, so instead you promise to give me fresh food
| sometime in the future when I am hungry.
|
| How do you account for that? You received software
| services, but gave nothing back in return other than a
| promise. Well, what if you recorded the promise? Software
| services in, promise out. You got your software, I get my
| food, the credit and debit accounts match. Everyone is
| happy.
|
| Congratulations, you just created money out of thin air!
| -- And now, later on, I am feeling hungry and am ready to
| take you up on your food offer. You give me the food, I
| give back the promise, food out, promise in, I'm fed,
| debits match credits, and the money is destroyed.
|
| That's exactly why we invented accounting: To keep track
| of the money being created and destroyed. You wouldn't
| need accounting if promises never needed to be made.
| Without promises, you'd have the software services, I'd
| have the food, and we'd have no reason to think about the
| transaction ever again. It is the promise that has us
| wanting to look back to make sure that promises
| outstanding are made good.
| ectopasm83 wrote:
| Think of a ledger as a list of transactions. Transactions are
| directed hyper-edges: they are composed of a set of credits
| and a set of debits. For each transaction, the sum of debits
| must be equal the sum of credits. "Double-sided" might be a
| better term. Also a DAG doesn't convey the historical aspect
| of a ledger, each ledger should be conceived as a sequence
| diagram lifeline. See temporal graphs: https://teneto.readthe
| docs.io/en/latest/what_is_tnt.html#add...
|
| Going further with this model, you could introduce the notion
| of higher-order links between transactions to keep related
| entries together, for instance to link a correcting
| transaction to the corrected transaction, grouping recurring
| payments for a loan together and so on.
|
| You could (should!) model this on top of a bitemporal
| database to overcome the painful limitation of the event
| sourcing model, namely that corrections aren't retroactive.
| Imagine you need to establish due taxes for the past year for
| certain ledgers in your database, and for some of them you
| performed corrections to transactions for that fiscal period
| _after_ the fiscal period ended. With an event-sourced model
| (a single timestamp for each transaction), the corrections
| won 't impact your tax calculations unless you explicilty
| track those corrections in your query. But with a bitemporal
| model (two time axis), you'll be able to record both the time
| when you made the correction and when it should apply in the
| past and you'll be able to query your database normally,
| without even thinking about it. This could also be used to
| perform corrections that remain invisible to your customers
| while being fully tracked in your db. Another case were this
| could prove to be useful is with transactions that are not
| immediate and can be rolled back. Typically in these
| situations, you move money from one ledger to a counterpart
| dedicated temporary outgoing ledger before the transaction is
| confirmed. This allows you to prevent double spending. Using
| a bitemporal model, you could get rid of these temporary
| counterpart ledgers provided you add a status field to your
| transactions.
| test6554 wrote:
| 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 their net worth.
|
| If Alice owns 3 books worth $120, then the "Alice's Books"
| account would show a balance of $120. Meanwhile, Bob has 12
| books worth $700.
|
| When Alice buys the books, she -credits her bank account $20
| and +debits her books account $20 (the value of the new
| book). Thus her net worth stays the same, but she has more
| books assets and fewer cash assets.
|
| Similarly Bob -credits his books account $20 and +debits his
| bank account $20. His net worth also stays the same but he
| now has more cash than before.
|
| On Alice's way back to the bridge she resides under, it
| starts to rain. Alice's new book is ruined. She -credit's her
| books account $20 and her net worth goes down by $20.
|
| Life as a homeless librarian is harsh.
| victor106 wrote:
| > 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?
| kaynelynn wrote:
| In a real world example you would be correct. This would
| fall under the "equity" of the accounting equation assets
| = liabilities + equity. The equity part can be confusing
| but is where many of the non obvious second entries end
| up.
| BayesianDice wrote:
| And when the book is ruined, she credits her books account
| (an asset account) $20 and debits her
| "depreciation/impairment" account (an expense account) $20.
| conductr wrote:
| Always needs two entries to keep assets equaling liabilities
| plus equity. If you do anything it effects both sides of the
| equation, thus "double entry" is required to keep this
| relationship. It's the accounting equation.
|
| https://www.investopedia.com/terms/a/accounting-equation.asp
| btown wrote:
| In all fairness, if you're trying to understand a piece of
| software like Quickbooks and are not coming from an accounting
| background, anthropomorphizing each "account" at your company
| as an individual actor with their own ledger can actually be a
| helpful mental model. Everything needs to be a dance between
| actors, and, for instance, when you make a vendor payment in
| cash, you can only do so as a message sent simultaneously to
| the Accounts Payable actor and the Cash actor, and each actor
| must accumulate the effects of that message/event in the way
| that makes sense. (Namely, each one will translate the event
| into credits/debits based on the characteristics of who they
| are, and maintain a balance accordingly. Double-entry, I
| suppose, means each event must be ingested exactly once by an
| even number of actors.)
|
| If you're building payment rails, that event might itself be
| one of a pair of events, sourced from a meta-event tracking the
| transaction intent. (As a meta-point, I find it much more
| useful to think of the "graph" in accounting as having edges
| not made of money, but of data in a derived-event hierarchy.)
|
| And a first step towards being able to have that mental model
| is ensuring that you have a good mental model of multiple
| physical-human actors accumulating events in a structured and
| atomic way.
|
| But the OP doesn't actually make it clear that this is what the
| analogy is in service of! And I fear that the OP article will
| cause more confusion than it solves.
| Mister_Snuggles wrote:
| > if you're trying to understand a piece of software like
| Quickbooks and are not coming from an accounting background
|
| Unfortunately, QuickBooks won't help you understand
| accounting. It's not a true double-entry accounting system,
| at least it wasn't the last time I touched it. That said, it
| still does its job and does it well enough, and real
| accountants are fine with dealing with it.
|
| Simply Accounting is a better example of a true double-entry
| system.
| PopAlongKid wrote:
| > It's not a true double-entry accounting system, at least
| it wasn't the last time I touched it.
|
| Can you elaborate? I've used Quickbooks for over 15 years
| and it has always been a true double entry accounting
| system during that time.
| chimeracoder wrote:
| > Unfortunately, QuickBooks won't help you understand
| accounting. It's not a true double-entry accounting system,
| at least it wasn't the last time I touched it.
|
| QuickBooks absolutely is a double-entry accounting system.
| The "bookkeeper" mode abstracts away and hides what's going
| on under the hood, but if you enter "accountant" mode,
| you'll see the full ledger, and you can even make direct
| journal entries to modify it.
| Mister_Snuggles wrote:
| I must have only ever encountered it in "bookkeeper
| mode". That abstraction is likely what threw me off!
| chimeracoder wrote:
| > I must have only ever encountered it in "bookkeeper
| mode". That abstraction is likely what threw me off!
|
| I personally find the bookkeeper mode very confusing, and
| having observed others (non-accountants) using it to
| manage small businesses, I think that folks would be
| better off taking a one-day course in accounting and
| learning just enough to use it in accountant mode.
|
| You don't have to be a CPA, just literally enough about A
| = L + E to follow the flow within Quickbooks and record
| one side of each entry.
| em-bee wrote:
| anthropomorphizing the accounts is not the problem. the
| problem is that in the example the two parts of the double-
| entry are the two partners of the transaction. to
| anthropomorphize properly alice and bob would be two
| employees of the company buying a book from a bookstore.
| fauigerzigerk wrote:
| _> Double-entry, I suppose, means each event must be ingested
| exactly once by an even number of actors.)_
|
| No, the number of accounts (actors) does not have to be even.
| The sum of debits and credits has to be equal (or zero if you
| like).
| btown wrote:
| You're right - it was a silly thing for me to write!
| Something more accurate would be that because debits and
| credits must balance, there is no way to send a message
| that would only be seen by a single account (other than a
| no-op); thus, any meaningful transaction will have an
| impact on at least two accounts.
| fauigerzigerk wrote:
| Agreed.
| winstonrc wrote:
| I'm biased, but I hope my explanation[0] is more intuitive
| coming from a CPA.
|
| [0]: https://www.winstoncooke.com/blog/a-basic-introduction-to-
| ac...
| resters wrote:
| I think the key point is that not only is double entry
| accounting a directed graph, _so is single entry accounting_.
|
| Therefore (and to your point) the observation is of limited
| usefulness.
| 2Gkashmiri wrote:
| Is there any person who wants to test an old but currently in-
| development agpl licensed accounting software? Your help would be
| regarding testing the software, reporting bugs and maybe submit
| PRs to fix issues
|
| https://gnukhata.org/install/
| gibsonf1 wrote:
| A better way to do this would be to more closely model what is
| really happening, that is the transaction events which change
| state. The states being changed would be the account balance
| amounts input to and output from the transaction event. With the
| event, you can also track the system performing the function in
| the event. (All with rdf) https://graphmetrix.com/trinpod-server
| mo_42 wrote:
| I believe double-entry bookkeeping needs more attention.
|
| I think double-entry bookkeeping is, at least to me, as
| fundamental to economics (and of course business) as logic to
| math. Even if some actors don't use it explicitly, it still
| holds. If I buy ten apples for 10 bucks, I have ten more apples
| in stock and ten bucks less.
|
| Many economic discussions (not only on HN) get out of hands
| because people don't try to see the full picture or deliberately
| choose to see one side. I've even seen a professor of economics
| claim in public that the world is too much in debt. Well, double-
| entry bookkeeping tells you that there are always two sides to
| consider.
|
| For example, in case of governmental debt they ignore the other
| side of that debt, which might be assets. Assets like airports,
| schools, bridges, etc. Usually, we call such things useful.
|
| Another typical example is the central bank "prints money". Well,
| double-entry bookkeeping tells us that it's not possible. If they
| hand out currency, the counterpart needs to trade something in
| (typically repurchase agreements with commercial banks). (Leaving
| aside here the idea of helicopter money, which could even go into
| neg. equity or a loss.)
| pcrh wrote:
| Agreed. The "magic" of double entry bookkeeping is that it is a
| financial version of the Principal of the Conservation of
| Energy.
|
| It isn't as strict in that it allows for assets to alter in
| value, for profits or losses to be made. But it does keep track
| of the way that money and "value" circulates in different
| forms, e.g. as cash, assets, debts, depreciation, etc.
|
| The "double entry" keeps track of the transformation of the
| nature of "value". This is hard to do using a simple household-
| style "cash-in" and "cash-out" set of accounts.
| xphos wrote:
| Economics is funny because its very anti complex math. For the
| local economics (household even company level) that makes total
| sense but for anyone doing research or systems modeling for
| things bigger than a company the total distain for calculus and
| non-equilibrium systems really prevents any discussion. I think
| its because if you remove stability most of supply and demand
| arguments fall apart. Its crazy because stable systems are
| extremely rare in natural complex systems its weird to apply it
| to large parts of economics as a given.
|
| But here I'd caution against the idea that banks (not even
| central) cannot increase money supply because that's not really
| true. If a Bank is the backer of both sides of loans or engage
| in fractional reserve banks (i.e all banks), they can
| effectively increase money supply which in my opinion is equal
| to printing money. Especially since in the loan case, the loan
| is not necessarily a guaranteed asset (think cars in a crash).
| This effect is called the money multiplier effect via
| fractional reserve banking.
| https://www.youtube.com/watch?v=93_Va7I7Lgg
|
| The multiplier is more of ceiling to the amplification rather
| than it actually happening on loans. None of this necessarily
| bad loans and investment are really important to other parts of
| economics but none of it is simple and non of it is stable in
| the traditional sense
| jacques_chester wrote:
| I find that economics is drenched in maths, depending on the
| school. Take Chicago's undergraduate program, for example[0].
| It requires calculus classes before you even get to the
| starting line for the economics classes, and they encourage
| students to go further: "Students who have an interest in the
| major should take calculus at the highest level for which
| they qualify."
|
| [0] http://collegecatalog.uchicago.edu/thecollege/economics/#
| Fun...
| mo_42 wrote:
| Banks don't have that limitation for creating credit/money
| [1]. Technically, they just need to extend the balance sheet.
| Limitations are rather that they need to find good projects
| that yield enough returns to cover the interest rate.
|
| I think this is yet another good example of thinking with
| double entry bookkeeping.
|
| [1] https://www.investopedia.com/articles/investing/022416/wh
| y-b...
| 29athrowaway wrote:
| Well, in this case
|
| - balance = states
|
| - transactions = state transitions
|
| It is simply the representation of state transitions as a
| diagram, similar but not equivalent to that of a state machine.
| t_mann wrote:
| > Definition 6: Credit An entry that represents money leaving an
| account.
|
| > Definition 7: Debit An entry that represents money entering an
| account.
|
| Not really, the meaning of debit and credit depends on the type
| of account: https://en.wikipedia.org/wiki/Debits_and_credits
|
| Maybe there's a reason why it takes more than one course to
| become a CPA (https://www.accounting.com/careers/cpa/how-to-
| become/).
| rahimnathwani wrote:
| Not really, the meaning of debit and credit depends on the type
| of account
|
| That's how most accountants think about it. But I think there's
| something more fundamental: a CR entry is an increase is what
| the company owes (to creditors or shareholders), and a DR is an
| increase in what the company owns.
|
| EDIT: see this link for how this relates to the accounting
| equation https://news.ycombinator.com/item?id=32501707
| jfengel wrote:
| Isn't that exactly backwards to what most people think of
| credits and debits? If you credit me something, I now have
| something. I don't owe anything.
|
| I can kinda squint and see "Oh, you want the universe to
| balance, so if I have something it is some kind of karmic
| debt". But it still feels like exactly the opposite of what I
| grew up thinking of these terms to mean.
| rahimnathwani wrote:
| It's the opposite because when a counterparty (like a bank
| or a store) says they're 'crediting your account', they're
| talking about the impact from _their_ perspective, not
| _your_ perspective.
| t_mann wrote:
| That's (somewhat) true for accounts that represent stocks
| (assets, liabilities, not really for equity though), it's not
| true for accounts that represent flows (income, expenses).
| Income is recorded as a credit entry in an income account, eg
| (the corresponding debit entry would typically be on
| something like a current account or claims on customers).
| rahimnathwani wrote:
| Consider the positioning of income and expense accounts
| within the accounting equation. Essentially, they are
| components of equity. View equity as the company's
| obligation to its shareholders. A credit entry signifies an
| increase in what the company owes, whether to creditors or
| shareholders, while a debit entry reflects an increase in
| the company's assets.
| jfengel wrote:
| Every time I look at accounting, the different kinds of
| accounts baffle me. I can never keep straight what each kind of
| account is used for, or which ones have positive credits and
| which ones have negative credits.
|
| As far as I can tell, the point is to double the amount of work
| in the hopes of catching certain kinds of errors. Which makes
| sense when you have humans making the entries and humans doing
| the arithmetic.
|
| But I grew up in a world where computers do all of the math,
| and it always looks to me like it's violating the Don't Repeat
| Yourself principle. If you say the same thing in two different
| places, one of them is always going to be wrong.
|
| I feel as if, had accounting been designed in the modern era,
| we wouldn't have done it that way.
|
| I'm not an accountant and my failure to understand does not
| make the thing wrong. But my bafflement at "credits _decrease_
| an asset account " feels emblematic of something being
| genuinely off base.
| kqr wrote:
| The point is not to double the amount of work to reduce
| errors. The point is to record both where money came from and
| where it went to. This simplifies analysis, reporting, etc.
| down the line.
|
| The fundamental unit of a double-entry system is the
| transaction, which records from where things came and to
| where they went. In software parlance, it's an event-sourced
| system rather than the stateful/interactive system of single-
| entry accounting.
| velcrovan wrote:
| > But I grew up in a world where computers do all of the
| math, and it always looks to me like it's violating the Don't
| Repeat Yourself principle. If you say the same thing in two
| different places, one of them is always going to be wrong.
|
| This is wrong on a couple of levels.
|
| In your understanding do RAID disk arrays and backups violate
| "the Don't Repeat Yourself principle"? Is one of the copies
| of the data guaranteed to be wrong? Do data backups duplicate
| data because of pre-modern thinking?
|
| But on another level it's irrelevant, because in double-entry
| bookkeeping, there is no duplication of information. If you
| buy an apple for a dollar, your journal entry will mark a
| dollar out of cash -- which is true because you now have 1
| less dollar -- and a dollar against your "Food" expense
| account -- which is true because the thing you just spent a
| dollar on was food. If you took away either entry, you would
| be losing information. The fact that both entries have to
| balance isn't because of duplication, it's because the same
| dollar can't exist in more than one place at a time, which is
| axiomatically true regardless of whether you use a computer.
| t_mann wrote:
| > the point is to double the amount of work in the hopes of
| catching certain kinds of errors
|
| That's also how I like to think about it, as a kind of
| checksum mechanism. Double-entry bookkeeping originated in
| medieval European markets, which were often open-air, noisy,
| dirty, full of thieves and other dangers. Keeping your
| records straight in that environment must be a challenge, and
| having a logic that allows you to catch some mistakes can be
| a powerful tool in that context.
|
| But there's more to it, eg it allows you to make a
| distinction between expenses and investments, so it is
| actually a truly different way to think about your financial
| situation than eg looking at cash flows only. Spending X on a
| buying livestock has a different economic meaning than
| spending X to pay a security guard. There are economic
| historians who argue that this kind of perspective was an
| enabler of early capitalism, because it enables people to see
| that money spent on an investment isn't lost value.
| jfengel wrote:
| Thanks for that. Lemme probe a bit deeper.
|
| If you spend $X on sheep, you credit $X where? Debit it
| from where? You put "$X worth of sheep" on what account?
| When the sheep die, do you credit some account with "$X
| worth of dead sheep?" (Where presumably they remain as
| dead-sheep forever.)
|
| (I'm sorry, I know that sounds dumb.)
|
| How is that "$X worth of dead sheep" different from "$X
| worth of security guarding" that you supposedly received?
| t_mann wrote:
| > If you spend $X on sheep, you credit $X where? Debit it
| from where?
|
| You debit your 'sheep' account (maybe called sth like
| inventory) and you credit your cash account, or a
| liabilities towards suppliers account. Your equity stays
| constant in either case (no profit or loss impact), if
| you paid cash you've swapped X worth of cash for X worth
| of sheep, otherwise your liabilities went up by X.
|
| When they die, you debit some kind of expense account
| (extraordinary losses or sth like that), and you credit
| the sheep account. In that case, you've made a loss of X
| and your equity (when you next draw up your balance
| sheet) will be lower by X (assuming that's the only
| business case). It might even go negative, eg if the
| sheep were your only asset and you still have the
| liability towards the guy who sold them to you.
| jfengel wrote:
| Thank you. I really appreciate that.
|
| It still feels exactly the opposite of what I thought a
| credit and debit were. Surely when you add sheep, you
| _credit_ the sheep account and _debit_ the cash.
|
| I get it. It's just a shift.
| t_mann wrote:
| Yeah, best not to think of any semantics wrt to the words
| debit and credit. Debit is left-hand side, credit is
| right-hand side, and just remember the rules how they
| work :)
| jacques_chester wrote:
| > _the Don 't Repeat Yourself principle_
|
| I think this is meant mostly to apply to code. For data,
| redundancy is a very common strategy for assuring accuracy
| and durability.
|
| > _If you say the same thing in two different places, one of
| them is always going to be wrong._
|
| Yes! This is the exact point. The mismatch flags that there
| is an error that needs to be investigated and added to the
| ledger as a correcting transaction.
| Sammi wrote:
| Second sentence of that wikipedia article is: "A debit entry in
| an account represents a transfer of value to that account, and
| a credit entry represents a transfer from the account."
| guthriej wrote:
| Martin Kleppmann (author of Designing Data-Intensive
| Applications) has a great article in the same vein:
| https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
| btbuildem wrote:
| I think I'm missing something here. How does looking at
| transaction history as a directed graph help anything? Is it an
| improvement on the centuries-old "double-entry" practice?
|
| It seems to barely work with the toy example of couple
| transactions - imagine what the graph would look like with dozens
| or hundreds of edges between pairs of nodes. What use would there
| be for the typical algorithms that work with graphs?
|
| This feels a bit like using pliers as a hammer. Sure, you can, I
| guess -- but why?
| weego wrote:
| The article feels like a similar insight to the founding ideas
| of cryptocurrencies.
|
| Engineers stumbling on foundational principles baked into other
| fields that software happens to be replicating.
| inopinatus wrote:
| It's hare-brained. The article is over-egging the pudding. They
| haven't established a justification, and the author's claim
| that this visualisation helped them arrive at a clearer
| understanding is rather undermined by the category errors they
| make in the course of trying to geeksplain D.E. from first
| principles. What's more they've represented only one very
| simple transaction. God knows how they're going to gain from a
| graph-based visualisation of something more abstract e.g.
| dissimilar tax and book depreciation, adjustments for
| gains/losses on foreign exchange, allocation of franked
| dividends, PAYG, holding of amounts in trust for other parties,
| partial recognition of deferred revenue and so forth.
| zamubafoo wrote:
| I can see what you are saying, but I think it helps in two
| ways:
|
| 1. it is another way to conceptualize an idea. For most
| purposes this might not be relevant, but who knows where a hard
| accounting problem might be resolved through the application of
| graph theory (or the inverse!).
|
| 2. it is another way to visualize flows. Not everyone is
| financially literate or numerically inclined, so instead of
| handing them a table of columns of numbers and having them
| reason about the flows numerically, it lets you represent the
| flows spatially which maybe easier. After all, not all tools
| are for professionals.
|
| Additionally, while the cumulative history in one graph might
| be much, simply adding filters based on transaction date might
| provide non-obvious insight that other visualizations miss. I
| can see this probably being even more helpful by cross
| referencing other information such as location.
| globular-toast wrote:
| Everyone should do their own accounts. I've been doing it for
| over 12 years and I'm so glad I've kept up with it.
|
| I don't bother keeping my ledger immutable, though. The point
| about immutability is that whatever happened is immutable
| (because it's in the past; it already happened!) and the ledger
| should just reflect that. So if I somehow made a mistake in my
| ledger I just correct it. I keep my ledger in git so that does
| record changes to the ledger itself, but I rarely, if ever, need
| to access these.
| brabarossa wrote:
| What does that mean? Are you using cash? Are you copying bank
| transaction history to your git?
| globular-toast wrote:
| Yeah, I source my ledger from multiple places like bank
| transactions, investments accounts, cash transactions etc.
|
| I can't really think of a case where I have made a mistake,
| but if, for example, I sold something to a friend I would
| debit (+) their "reimbursement" account with the amount they
| owe me. If I typoed that to 10x the amount, I would just go
| and correct the typo, I wouldn't make two new entries to
| revert then correct the mistake.
| vwkd wrote:
| Great idea to treat of personal finances like a business. Also
| makes a great source of data for stats.
|
| Can you share more on the system you've come up with? In what
| format do you store the data? Do you store files per account,
| or per day, etc.? Do you have a CLI helper to quickly read,
| write, edit the files? Maybe you can even share a demo repo?
| phailhaus wrote:
| I'm not sure that visualizing bookkeeping as a graph is helpful,
| it makes it really hard to tell what's going on and you lose the
| time dimension. What if you instead used a table to show movement
| of funds by transaction, and only used a graph to model the
| "aggregate result" of a set of transactions?
| doodlebugging wrote:
| Nice graphical breakdown.
|
| I think the real winner isn't Bob or Alice though they each
| benefited from the exchange. The real winner is the credit card
| company that banked 10% of the transaction on Alice's side and 5%
| on Bob's side. Sounds like they both chose the least sensible
| option to handle payment.
|
| Maybe Bob should've made it clear that he accepted cash, money
| orders, cashier's checks, or personal checks, or even
| cryptocurrency so that Alice would not need to suffer a foreign
| currency conversion fee especially when you consider that they
| live in the same small town.
|
| Just kidding. I realize that the example transaction needed some
| massaging on the path to the end graph to illustrate handling of
| more complex, real-world transactions.
|
| Great job producing this intuitive break-down.
|
| There is one thing that I found interesting near the top of the
| tutorial. You make the statement "But money is meant to be
| spent." If money exists to be spent then why do so many people
| accumulate such vast sums that they could never spend all that
| they have managed to accumulate? Dumb question, I know. Money in
| the hand has indeterminate or no value until the bearer needs to
| acquire a product or service and then the value of the money in
| hand is set by the seller of the product or service they require.
| The global economy functions because at some point in time a
| traditional barter system where useful physical items were
| exchanged was replaced by the current system involving exchange
| of special artisan linen papers or conveniently portable metallic
| disks emblazoned with cartoon images celebrating historical
| events or personalities.
|
| Anyway, this was a good read and I enjoyed watching the
| transaction ledger complexity increase to account for real-world
| situations where there are more than two parties involved in a
| single transaction. Years ago when I was in high school we had a
| class that introduced us to checking and saving accounts and the
| goal of the class was to teach us how money moves through the
| system so that we could manage our own assets once we had real
| jobs and incomes. We had the introduction to the ledger book with
| one side handling credits and the other handling debits. It was
| all confusing at first but ended up being very useful.
|
| A long time after this class I found myself working as an
| independent consultant paid a negotiable hourly rate. All of that
| earlier instruction came in very handy when I needed to split
| project time and classify and categorize all the transactions
| that helped me understand where all that cartoon cash came from
| and where it all went. My spouse is a CPA/Auditor so having her
| level of knowledge and experience close to hand was also
| enormously useful in splitting everything so that the charts and
| graphs I assembled were most intuitive.
|
| Thanks! I enjoyed reading this.
| andrewfowl wrote:
| I think it is a great article and graph representation would be
| very useful to have in accounting. There are a few things I would
| add:
|
| 1. It may be beneficial to segregate ledgers (used to record
| transactions with customer accounts, i.e. with assets you do not
| own) vs. books (transactions recorded to present own assets and
| liabilities). Books are used to account for all possible types of
| assets and liabilities, while ledgers are usually strictly
| limited to reflection of cash movements. I think the article is
| about ledgers.
|
| 2. Regarding the state of each account at each period in time, I
| think there is a lot of confusion between reflecting activity /
| transactions in the period and adjustments related to how prior
| transactions were recorded. I personally thought that adjustments
| could be better accounted for using something like a model with
| slowly changing dimensions where you can see history of each
| change. So it is not something you want to see on the directed
| graph by default, but something you want to be able to trace.
|
| 3. There was one idea that I really don't like because although
| it make sense on surface, it has really bad implications for
| accounting and analytics. The idea I am talking about is that you
| don't need to have one debit and credit for transaction, rather
| you just need to make sure that total debits equal total credits.
| say, Bob has several types of accounts and multiple customer. Now
| Bob asks you to tell him, how much of the current balance of a
| specific account was generated from proceeds by customer. To
| answer it, you now have to solve many-to-many relationships
| between customers and Bob's accounts. And sometimes it has no
| deterministic answer because we balanced multiple accounts in one
| entry. And accountant now have to use imagination and excel to
| prepare a manual report that uses multiple assumptions to answer
| this question.
| brvsft wrote:
| It was 'cute' the first time it was posted (in this form:
| https://martin.kleppmann.com/2011/03/07/accounting-for-compu...),
| but I find pointless musing like this to be counterproductive
| sometimes. While I understand the tendency to fixate on 'nerdy'
| topics like, _" How can I take <thing> people think about as <X>
| and shove it into math or computer science idea <Y>?"_ this (a)
| doesn't introduce any substantive ideas (in this particular
| instance) and (b) would completely fuck up your bookkeeping and
| result in you failing an audit if you completely ditched double-
| entry bookkeeping in place of a directed graph.
|
| Use the appropriate structure for the data. A graph is not
| appropriate as you lose information about time, which is
| important to the ledger. No, you can't add time as a value on
| your edges. If you did, you'd either have several dozen graphs,
| or they would look absurd.
| thinkxl wrote:
| This is my mental model and how I built the backend of a
| budgeting web app.
|
| Two types of accounts:
|
| - assets (you want your balance to be more than 0)
|
| - liabilities (you want your balance to be 0)
|
| Two types of entries:
|
| - debits (increase balances of assets, decrease balances of
| liabilities)
|
| - credits (increase balances of liabilities, decreases balances
| of liabilities)
|
| Rules:
|
| - A transaction represents a transfer of value between accounts.
|
| - Every transaction must have at least two entries. The balance
| of all entries the transaction holds should be 0, i.e., balance =
| debits - credits.
|
| You don't think about money leaving or entering an account before
| you nail down those definitions. The account representations can
| be anything that holds a numeric value, not just money.
|
| You can affect more than two accounts by adding additional
| entries with the condition of keeping the balance to 0.
| kqr wrote:
| Given just the two accounts you have, your goals are impossible
| to achieve, because Assets = Liabilities, so you cannot have
| one more than zero and the other zero.
|
| I think in this problem hides two mistakes:
|
| - Zero liabilities is not a reasonable goal for most people.
|
| - There's an equity account type also. (Also income and expense
| accounts.)
| thinkxl wrote:
| I don't understand your point. But instead of rationalizing
| with words, let's put it into practice.
|
| - I receive my paycheck in my bank account.
|
| - I want to budget $800 for groceries every month.
|
| - I have a credit card with a balance of $250.
|
| - I want to know how much I have left; we will have an
| account named Left to Budget (LTB).
|
| Let's outline them as accounts:
|
| - Bank Account. It's an Asset and has a balance of $0.
|
| - Groceries "category" Account. It's a Liability and has a
| balance of $0.
|
| - AMEX Account. It's a Liability and has a balance of $250.
|
| - LTB is my income account. It's a Liability (yeah, I know,
| but stay with me).
|
| When I receive my $1,000.00 paycheck.
|
| - Debits Bank (ASSET) for $1,000.00
|
| - Credits LTB (LIABILITY) for $1,000.00
|
| Balances:
|
| - Bank (ASSET) $1,000.00
|
| - Groceries (LIABILITY) $0.00
|
| - AMEX (LIABILITY) $250.00
|
| - LTB (LIABILITY) $1,000.00
|
| I budget $800 for Groceries for this month.
|
| - Debits LTB (LIABILITY) for $800.
|
| - Credits Groceries (LIABILITY) for $800.
|
| Balances:
|
| - Bank (ASSET) $1,000.00
|
| - Groceries (LIABILITY) $800.00
|
| - AMEX (LIABILITY) $250.00
|
| - LTB (LIABILITY) $200.00
|
| I go to the grocery store and buy Milk for $50 and Bread for
| $10.
|
| - Credits Bank (ASSET) for $60.00
|
| - Debits Groceries (LIABILITY) for $60.00
|
| Balances:
|
| - Bank (ASSET) $940.00
|
| - Groceries (LIABILITY) $740.00
|
| - AMEX (LIABILITY) $250.00
|
| - LTB (LIABILITY) $200.00
|
| As of now, I effectively know that:
|
| - I have $940 in my bank, but I only have $200 available to
| spend (LTB).
|
| - I have $740.00 left to spend on Groceries in my Bank.
|
| - If I wanted to pay my Credit Card (AMEX) in full, I
| couldn't. Even though I have enough money in my Bank, most of
| it is already allocated to Groceries. BUT I could adjust my
| budget, like so:
|
| Adjust my Groceries budget by moving $50 back to my LTB, so I
| can pay my Credit Card in full this month.
|
| - Debit Groceries (LIABILITY) for $50
|
| - Credit LTB (LIABILITY) for $50
|
| Balances:
|
| - Bank (ASSET) $940.00
|
| - Groceries (LIABILITY) $690.00
|
| - AMEX (LIABILITY) $250.00
|
| - LTB (LIABILITY) $250.00
|
| OK, so now I know that:
|
| - I still have $940.00 in my bank.
|
| - If I wanted to pay my Credit Card I can because I have
| enough in my LTB category.
|
| - I have $690.00 available to spend in Groceries, because I
| moved $50.00 away.
|
| Now, let's pay my Credit Card.
|
| - Credit Bank (ASSET) $250.00
|
| - Debit AMEX (LIABILITY) $250.00
|
| Balances:
|
| - Bank (ASSET) $690
|
| - Groceries (LIABILITY) $690.00
|
| - AMEX (LIABILITY) $0.00
|
| - LTB (LIABILITY) $0.00
|
| Now the money I have left in the Bank is for Groceries only.
| If I wanted to spend on something else, I'd have to either:
|
| - Create a new Category and transfer an amount from
| Groceries, or
|
| - wait for my next paycheck.
|
| --
|
| We were able to manage all this information with only one
| bank account, but we successfully managed a small budget.
|
| Double-entry is a concept that's not necessarily applied
| directly to "physical" accounts. We transfer values between
| accounts even when the money stays where it is.
|
| > - Zero liabilities is not a reasonable goal for most
| people.
|
| Zero liabilities is not a goal; it's the direction on whether
| money balance increases or decreases; it's not tied to the
| money you have or owe. It's a concept or formula rather than
| a reality.
|
| > - There's an equity account type also. (Also income and
| expense accounts.)
|
| Equity and expenses are Assets. Income can be an Asset or a
| Liability, depending on how you want to represent it. For me,
| it is a liability because I want it to be 0. Even tho, my
| income account will have money, its representation of Money
| Left to Budget will be zero because the accounts that
| transfer value from it will include savings or investing
| accounts.
| elijahbenizzy wrote:
| This is a great write up, thank you! One thing I'm curious about
| is what properties/metrics of the graph mean for accounting.
| Spectral properties (eigenvalues, etc...) might have some
| insightful meaning for the financial system.
|
| Also I'm sure this is extremely well studied but I'm not super
| familiar -- ML on accounting graphs could identify shapes that
| indicate illegal transactions, etc... Will dig for reading :)
| nyrikki wrote:
| Personally I find the model of a collection of immutable events
| that preserve assets= liabilities+ equity easier.
|
| Events being constrained to historical statements of fact.
| rjinman wrote:
| Double-entry bookkeeping is very easy to understand once you
| ditch the ridiculous "credit" and "debit" terminology.
|
| Essentially, the goal is to keep the accounting equation true at
| all times. The equation is: Equity = Assets - Liabilities.
| Eventually, earnings (Income - Expenses) will become part of
| equity, so splitting that out, you have: Equity + Income -
| Expenses = Assets - Liabilities. Rearranging to get rid of the
| minus signs you get: Equity + Income + Liabilities = Assets +
| Expenses. This equation must be true or something has gone wrong
| - like money appearing or disappearing out of nowhere. To keep it
| true at all times, it should be clear that any time you add money
| to an account on the left side of the equation (say, to an Income
| account), you must either add the same amount to an account on
| the other side or subtract the same amount from the same side.
|
| For example, you sell a lemonade for $5. You add $5 to Sales
| (Income) and add $5 to Current Account (Assets).
|
| The "credit" and "debit" terminology is ridiculous because their
| definitions swap around depending on which account you're talking
| about, which is an utterly absurd (mis)use of language and the
| main reason people find this confusing.
| jandrese wrote:
| The one thing I remember most from my economics courses in
| college is that economists have highly idiosyncratic
| mathematical conventions and they don't care. So many graphs
| with the independent variable on the Y axis...
| abtinf wrote:
| > So many graphs with the independent variable on the Y axis
|
| I was perplexed by this as well and none of my profs could
| cogently explain it. The classic example are supply and
| demand curves, with price as the Y axis.
|
| I finally realized they are actually trying to communicate
| that price is _not_ under the control of the buyer or seller,
| but that the market dictates the price given a level of
| production. This kind of "spherical cow" thinking made me
| develop a healthy contempt for conventional economics.
| abdullahkhalids wrote:
| Indeed, one of the main problems with econ education is
| that at the most basic level they teach a model for the
| "spherical cow" free-market. Which is all that most people
| end up learning. And then those people try to apply this
| reasoning to real world markets - the vast majority of
| which do not satisfy the assumptions of the free-market
| model. So almost all public discussions of micro-economics
| is totally useless.
| freedomben wrote:
| I mostly agree, but I hardly think it's useless. Much
| like beginning your understanding of physics with
| Newtonian equations, it just needs to be qualified. But
| it's _shocking_ how many people don 't understand the
| basic idea of supply and demand and how the relate
| relative to some rationing system (usually price).
|
| If you don't understand that foundational idea, then
| considering the effects of different rationing systems is
| utterly impossible. For example, that gets you a whole
| lot of people who make decisions that exacerbate housing
| crises by creating rent controls or building
| restrictions, and then being utterly perplexed when there
| isn't enough supply to go around (because they decoupled
| the signalling mechanism that the suppliers use (aka
| price) from what the buyers use (who got there first, or
| who is luckier with timing, or who is more politically
| connected). This is not to say that price controls are
| always bad, because real life is much more complicated
| than econ101 concepts lay out. But with nearly every
| other subject we expect people to have a basic level of
| understanding (like biology, history, english, etc)
| because we recognize it's importance for society and
| individuals to have at least a basic level of
| understanding in many different subjects. One that has as
| big an impact on life as economics seems like one of the
| worst to omit.
|
| Just like we tell 8th grade physics students that "in the
| real world, cows aren't spherical so it's a little more
| complicated than this, but this gets you 80% to 90% of
| the way there" I don't see why we shouldn't do the same
| for economics.
| juped wrote:
| Double entry bookkeeping is very easy to understand once you
| ditch the ridiculous "accounting equation".
|
| "Credit" means "source", "debit" means "sink".
|
| Suppose you invoice a customer 10,000 euros. You now have a
| promise for 10,000 euros, but you account in dollars so it's a
| promise for 11,000 dollars at current exchange rates. So you
| credit the source, your "Income: Customer A" account ("income"
| and "expense" accounts represent the external world) $11000,
| and debit "Assets: Accounts Receivable" (an account for trade-
| credit promises like this) $11000.
|
| Later, the customer pays your invoice, which gets you $10,500
| because exchange rates have moved around. How do you account
| for this?
|
| Your promise, which you accounted as $11000, is the source, so
| you credit Accounts Receivable $11000. You debit cash $10500,
| because you got $10500 in cash. Finally, credits and debits
| have to balance, so you debit "Expenses: Loss on Foreign
| Exchange" $500. (recall that "expenses", like "income",
| represents the external world, and you lost the other $500 to
| forex traders or whatever.)
|
| Since you don't liquidate the business on any typical day of
| its operation, why would you attempt to figure out how that
| $500 fits into a hypothetical instantaneous liquidation when
| you could just... account for it by balancing credits with
| debits? (You do sort of instantaneous-liquidate when preparing
| financial statements, an infrequent task which is very
| mechanical compared to ledger entry.)
| bongodongobob wrote:
| The only time I've ever seen source and sink used is in
| electronics. You may as well call it squeem and flurb, source
| and sink isn't helping anyone.
| temporarely wrote:
| Well, this is hacker news, so a generous reading of the
| comment is that it is being mapped to semantics most of us
| here fully grok, and not as a general audience rewording
| for accounting.
| bongodongobob wrote:
| Just because someone knows how to build a website doesn't
| mean they know anything about discrete electronics. I'd
| wager the majority of this audience doesn't. It's mostly
| software people.
| mhink wrote:
| I've seen it used frequently in the context of data
| pipelines and stream-processing applications, which is
| even more applicable to the subject.
| mijoharas wrote:
| > The "credit" and "debit" terminology is ridiculous because
| their definitions swap around depending on which account you're
| talking about, which is an utterly absurd (mis)use of language
| and the main reason people find this confusing
|
| What would you suggest as an improvement? The article suggests
| "incoming" and "outgoing" which seems to have the same issue,
| as does everything I see in your comment (the person spending
| 5$ on lemonade sure as hell isn't putting 5$ in their accounts
| sales entry).
|
| I'm not fully understanding the confusion both here and in the
| article.
| globular-toast wrote:
| It doesn't matter about the person buying lemonade. Their
| accounts are theirs alone and don't affect your accounts.
| DwnVoteHoneyPot wrote:
| When I talk to accountants, I get confused with debit/credit
| so I use "increase" and "decrease". Everyone seems to
| understand me fine. For example, "Decrease cash", to buy
| equipment "increases assets". "Increase cash" by borrowing
| money is "increasing liability".
| freedomben wrote:
| Indeed, the dirty secret is that many accountants think of
| debit and credit as decrease and increase as well. After
| using the terms for a little while they switch the symbol
| (word) they think of, but it still retains the same
| meaning. They are basically synonymous.
|
| source: friends and family members who are accountants and
| have generously given free bookkeeping tutorials
| fauigerzigerk wrote:
| _> Indeed, the dirty secret is that many accountants
| think of debit and credit as decrease and increase as
| well._
|
| So how would you correctly express the parent's example
| in terms of debit/credit if debit/credit are synonymous
| with decrease/increase?:
|
| _> >"Increase cash" by borrowing money is "increasing
| liability"._
|
| "Crediting cash by borrowing money is crediting
| liability" would sound obviously incorrect to any
| accountant.
| freedomben wrote:
| Passing on the answer I got:
|
| > _I wouldn 't say "they are basically synonymous"
| because there are situations where they flip depending on
| the rules/approach that you are following. After working
| with it you get pretty familiar with these situations and
| don't really even translate anymore. It's important to
| remember though that there are books the way most people
| see them, and the way an accountant following GAAP sees
| them. "Increase" and "decrease" are quite helpful for
| most people the way most people see the books. If you are
| applying GAAP it's like working in a different language
| where words don't cleanly translate._
|
| Given that we are mostly talking about double-entry in
| this thread, I think he is basically telling me I'm wrong
| but trying to explain how I came by it honestly so I
| don't feel stupid :-D
|
| To quote the famous Bender from Futurama: "I'm so
| embarrassed. I wish everybody else was dead."
| braiamp wrote:
| Because people don't understand that credit and debit only
| make sense in the context of the account being applied to. If
| you deposit money to your bank account, it's a credit in your
| <name of back account>. If you withdraw money from the ATM,
| you debit your bank account and credit your cash account. But
| globally you haven't gotten more money.
| tantalor wrote:
| > If you withdraw money from the ATM, you debit your bank
| account and credit your cash account
|
| You have that exactly backwards!
|
| Assets (like bank accounts and cash) are "debit accounts"
| meaning they increase with debits and decrease with
| credits.
|
| When you withdraw money from your bank account, the bank
| account goes down, so we know that must be a credit to the
| bank account, while the cash goes up, that is a debit to
| the cash account.
|
| Your confusion might be due to perspective. From the bank's
| view your bank account is a liability (credit account) so
| it increases with credits and decreases with debits.
| lisper wrote:
| > What would you suggest as an improvement?
|
| Use the intuitive meaning of the words: a credit means you
| have money coming in, a debit means you have money going out.
| An increase in assets, income, or equity is a credit, and an
| increase in expenses or liabilities is a debit, and vice
| versa.
|
| Or, alternatively, just use "credit" for _any_ increase, and
| "debit" for _any_ decrease. But this:
|
| "Definition 6: Credit - An entry that represents money
| leaving an account."
|
| is just totally backwards.
| fauigerzigerk wrote:
| _> Use the intuitive meaning of the words: a credit means
| you have money coming in, a debit means you have money
| going out. An increase in assets, income, or equity is a
| credit, and an increase in expenses or liabilities is a
| debit, and vice versa._
|
| An increase in assets is a debit.
|
| _> Or, alternatively, just use "credit" for any increase,
| and "debit" for any decrease._
|
| How is this consistent with the fact that an increase in my
| bank account balance is a debit?
| lisper wrote:
| 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".
| fauigerzigerk wrote:
| Yes, sorry, I was defending the established terminology
| without making clear why.
|
| My problem is that your alternatives don't just change
| the words, they change the logic. The invariant of
| debit/credit is that they need to balance out.
|
| If you choose words that can occur on both sides of the
| equation then this is no longer true and you're throwing
| out a lot more than just the admittedly unintuitive
| meanings of these words.
| lisper wrote:
| > My problem is that your alternatives don't just change
| the words, they change the logic.
|
| No, they don't. They just change the words you need to
| express the logic.
|
| > The invariant of debit/credit is that they need to
| balance out.
|
| Sure. So? If I give you a dollar, that's going to balance
| whether we call that a debit to me and a credit to you or
| a credit to me and a debit to you. The labels don't
| matter.
| fauigerzigerk wrote:
| What matters is that the labels are different on each
| side of the equation.
|
| That contradicts your suggestion that we should use the
| intuitive meaning of the words and it contradicts your
| suggestion to 'just use "credit" for any increase, and
| "debit" for any decrease'.
|
| Let's say a company raises equity (i.e it issues new
| shares), money comes into the bank account. In
| traditional terminology that would result in:
| debit bank credit equity
|
| According to your suggestions, however, raising equity
| would result in increase bank
| increase equity
|
| This violates the principle that the sum of labelAs need
| to cancel out (or balance out) the sum of labelBs. And
| this is why I said that you're changing the logic.
| lisper wrote:
| It doesn't matter whether you encode the signs in the
| terminology or in the equation. If you say X + Y = 0 i.e.
| X = - Y and stipulate that a transaction adds to X and
| subtracts from Y, that is completely equivalent to saying
| X - Y = 0 i.e. X = Y and stipulating that a transaction
| adds to both X and Y.
| fauigerzigerk wrote:
| Sure, but if you want to keep your terminology consistent
| with the math, you would then have to make a distinction
| based on the types of the accounts involved in a journal
| entry.
|
| E.g, this would be correct: increase bank
| increase equity
|
| but this would be incorrect: increase
| bank increase receivables
|
| If all numbers are positive then there would be no way to
| check whether the journal entries balance out without
| considering the account types.
|
| If, on the other hand, you encode the sign in the amounts
| then the sign would disagree with the semantics of the
| label and you would have to flip signs based on the
| account type at the time of recording the entries:
| increase bank $100 increase receivables -$100
|
| I don't suppose this is what you meant.
| lisper wrote:
| > you would then have to make a distinction based on the
| types of the accounts involved in a journal entry
|
| That's right. The distinction is based on whether the
| account represents an asset or a liability.
|
| > increase bank
|
| > increase receivables
|
| You would have to define what you mean by "bank" in order
| for this to make sense. But in general, receivables
| represent money that a company is owed from orders that
| have not yet been paid for, i.e. they are a effectively a
| loan from the company to its customer, and like all loans
| they are an asset to the creditor, which in this case is
| the company. When a payment is made against an
| outstanding receivable, the receivable is debited (the
| loan balance is reduced) and the company's cash balance
| is credited. Because cash and receivables are both
| assets, these add together and cancel out just as you
| would expect.
|
| The rules under my system are still very simple:
|
| 1. Every financial asset is someone else's liability, and
| vice versa. Cash is an asset to its owner and a liability
| to society at large. Loans are assets to the creditor and
| a liability to the debtor. Purchase orders are a
| liability to the purchaser and an asset to the supplier.
| Etc. etc.
|
| 2. Every financial transaction is a change in someone's
| liability coupled with a change of equal magnitude in
| someone else's assets.
|
| 3. The absolute value of your assets minus the absolute
| value of your liabilities is your net worth.
|
| A completely equivalent formulation is that liabilities
| have negative signs attached to them, and then your net
| worth is the sum of your assets and liabilities, but this
| is just a question of where you hide the negative sign. A
| - B is the same as A + (- B). It really doesn't matter
| except insofar as one convention might make it easier to
| think about things. Most people are used to seeing their
| liabilities expressed as positive numbers, i.e. if you
| owe money on your credit card bill, the balance due is
| positive, and if you have a credit balance, the balance
| due is negative. But it's all just a shell game with
| where you hide the signs.
| tantalor wrote:
| I solve this by remembering "debit = destination" (d=d) in
| all cases.
|
| Examples:
|
| If you deposit money into a checking account (asset) that is
| a debit (account increases) because the money "goes to" in
| that account (destination).
|
| If you borrow money from a credit card (liability) that is a
| credit (account increases) because the money "comes from"
| that account (not destination).
|
| The hard part is remembering debit accounts increase with
| debits, and credit accounts increase with credits.
| EvanAnderson wrote:
| The accounting equation is the right thing to think about.
| People want debit and credit to mean something more than they
| need to.
|
| My 100-level accounting instructor said it pretty succinctly:
| Debit means an entry in the left column. Credit means an entry
| in the right column. What a transaction means for the business
| depends on the accounts.
| mikeyouse wrote:
| Right - the words themselves aren't as important as the
| concept. Any replacement word will suffer the same confusion.
| There's a reason that the language of debits and credits has
| largely remained the same for the past thousand years, and
| the language describing accounting is unlikely to be
| 'optimized' by first-principles CS concepts from people only
| loosely familiar with the field.
| eviks wrote:
| There's a reason, but it's definitely not that any
| replacement is just as bad since that's close to an
| impossibly strong statement
| grantc wrote:
| Well said. It's actually not complicated or arbitrary. It
| also works effectively in practice over the gdp of the
| known universe. If you are savvy enough to be interested in
| and understand the different computing approaches to
| double-entry bookkeeping, one can assume the whole DR/CR
| concept isn't beyond you.
| fauigerzigerk wrote:
| And what if there are no columns? Google "journal entries for
| X" and you're going to find something like this:
| Dr accountX PS100 Cr accountY PS90 Cr accountZ
| PS10
|
| Left and right was fine when T accounts were universally used
| to record entries, but that's no longer the case.
| eviks wrote:
| I did, opened one random top result
|
| https://www.deskera.com/blog/journal-entries/
|
| And got left/right as explanation and also as left and
| right columns
| freedomben wrote:
| Yeah, GP really undermined their point with the whole
| "google x" and see.
|
| For most people who aren't accountants though, the
| spreadsheet thing is correct.
| fauigerzigerk wrote:
| Clearly I overstated my case. I'm not denying that
| columns are often used, especially in educational
| material. It's just no longer as universal as it once
| was.
|
| https://www.accountingweb.co.uk/any-answers/vat-double-
| entry
| lisper wrote:
| > Debit means an entry in the left column. Credit means an
| entry in the right column
|
| But that just shifts the arbitrariness of the whole thing
| from the words "debit" and "credit" to the words "left" and
| "right".
| EvanAnderson wrote:
| I think his intent was to prevent students from fixating on
| making the words debit and credit "mean" something by
| themselves. A debit doesn't have some intrinsic meaning
| about the "flow of money". It's just an entry in the left
| column. On the other hand, a debit to Accounts Receivable
| actually means something.
| lisper wrote:
| > A debit doesn't have some intrinsic meaning about the
| "flow of money".
|
| But it does. "Debit" is an English word with an
| established meaning in common usage. It means to take
| money _out_ of an account. It is related to the word
| "debt" which is something that _decreases_ the net worth
| of the _debtor_ and increases the net worth of the
| _creditor_. If you overpay a bill, the (positive)
| difference between what you paid and what you owed is a
| _credit_ on your account, and can be used just like money
| to pay your next bill.
| pessimizer wrote:
| > If you overpay a bill, the (positive) difference
| between what you paid and what you owed is a credit on
| your account
|
| Or it's a debit on the company's account. I think that's
| the point that was being made; not to confuse technical
| terms with English common usage, and not to go to the
| dictionary or etymology(!) as the arbiter. Debits are
| credits and credits are debits, but the real question is
| which column does it go into.
|
| Same nature as discussions about clients/servers.
| lisper wrote:
| > Or it's a debit on the company's account.
|
| That's exactly right. _They_ owe _you_ money, so it is
| (or at least it should be) a _credit_ on your account,
| and a _debit_ on theirs. But that is _not_ what the
| definition given in the article says. TFA 's definition
| of "credit" was "An entry that represents money leaving
| an account" and likewise a debit is "An entry that
| represents money entering an account." So when you paid
| your bill, that was (by the articles definition) a
| _credit_ to your checking account and a _debit_ to your
| account with company whose bill you were paying, which is
| exactly backwards. According to the standard English
| definitions, a credit is something that makes your net
| worth go up, and a debit is something that makes your net
| worth go down. So when you pay your bill, that should be
| a debit to you (cash going out decreases your net worth)
| and a credit to the counterparty (cash coming in
| increases their net worth).
|
| > Same nature as discussions about clients/servers.
|
| How so? It seems to me that distinction is clear: the
| client is the machine that initiated the connection, the
| one that did the DNS lookup.
| mhink wrote:
| That's not entirely correct- or at least, it's more
| complicated than that. The question of whether a
| debit/credit increases/decreases an account has to do
| with the kind of account you're talking about.
|
| When I deposit money, it modifies _two_ accounts at the
| bank:
|
| - the account which represents how much money they owe me
| - and the account which represents how much money they
| have on hand.
|
| The former is a liability, and the latter is an asset.
|
| The meaning of debit/credit is reversed between these two
| types of account. So, when I deposit $100, the entries
| entered are: - CREDIT mhink's account
| $100 (increasing liability) - DEBIT cash account
| $100 (increasing asset)
|
| Since we only see one side of this, we start to associate
| "debit" with "less money for me" and "credit" as "more
| money for me".
|
| Oddly enough, another common financial situation
| reinforces this interpretation from the other direction:
| accounts with utility providers. Unlike the bank, your
| account at the utility company represents how much _you
| owe them_. So the meaning of debit /credit is reversed,
| but so is the direction of responsibility: your account
| at the utility provider is money _you owe them_ , which
| is an asset. So when I pay them $100, the entries entered
| are: - CREDIT mhink's account $100
| (decreasing asset) - DEBIT cash on hand $100
| (increasing asset)
| lisper wrote:
| The problem is that whether something is an asset or a
| liability depends on your point of view. If I have $100
| in cash, that is an asset to me and a liability to the
| rest of society. If I have a $100 loan, that is a
| liability to me and an asset to my creditor. So there is
| no way to say whether something is an asset or a
| liability in an absolute sense. Every debt is an asset to
| the creditor and a liability to the debtor.
|
| This has nothing to do with labeling transactions so that
| the labels conform to the common meanings of English
| words. When an account representing assets has its
| balance go up, that's a credit. When an account
| representing a liability has its balance go up, that's a
| debit. And vice versa. If I, say, draw down a line of
| credit for $100 and deposit the funds in my checking
| account, then from my point of view, my LoC should
| debited by $100 and my checking account should be
| credited for $100.
|
| This makes sense regardless of how you think about the
| LoC. If you think of the available credit as an asset,
| then when you draw down the LoC the available credit
| balance goes down and it's a debit. If you think of the
| amount owed on the LoC as a liability, then when you draw
| down the LoC the amount owed goes up and it's still a
| debit.
|
| > CREDIT mhink's account $100 (increasing liability)
|
| No. This transaction does not increase liability in any
| absolute sense. It increases liability _only from the
| bank 's perspective_. From your perspective, it increases
| assets.
| epcoa wrote:
| > It increases liability only from the bank's
| perspective.
|
| You missed the context: When I deposit money, it modifies
| two accounts at the bank.
|
| It appeared to me they were very much explaining this
| from the banks or utility company's perspective.
| lisper wrote:
| > When I deposit money, it modifies two accounts at the
| bank.
|
| Yeah, I get that. I don't see what that has to do with
| the labels used to describe the transaction.
|
| Actual physical cash is weird because it's an asset to
| its owner and a liability to the rest of society. But
| when you deposit cash in a bank, the bank doesn't become
| the owner of the cash. It has borrowed that cash from
| you. So that cash is both an asset (because having
| borrowed it from you it can turn around and loan it to
| someone else) _and_ a liability (because the bank is in
| debt to you for the amount of the deposit).
|
| A simpler example is depositing a check. In that case,
| money just gets transferred from the payor to the payee.
| It's a debit from the payer's account and a credit to the
| payee's account. Or at least that's how it should be.
| wodenokoto wrote:
| But at that point how can you tell if something goes left
| or right?
| rahimnathwani wrote:
| It sounds like your accounting instructor may have focused
| too much on implementation details (left/right), and too
| little on accounting principles.
|
| The terms _debit_ and _credit_ have meaning independent of
| their columnar position on a traditional ledger. I could
| create a ledger with the columns reverse or (shocking!) use a
| computer program with a data structure that doesn 't encode
| the concept of left or right.
|
| I think about it like this: CR / Credit /
| Creditors -> what the business owes DR / Debit /
| Debtors -> what the business owns
|
| A CR entry is an increase is what the company owes (to
| creditors or shareholders), and a DR is an increase in what
| the company owns.
|
| A common objection to this is 'what about income and expense
| accounts'? But those are just equity:
| https://news.ycombinator.com/item?id=39991837
|
| I wrote more about this here:
| https://news.ycombinator.com/item?id=32498992
| EvanAnderson wrote:
| The sheer amount of discussion this has created (both here
| and back in August, 2022, when you and I commented back and
| forth to each other in your link) validates my my
| instructor's philosophy to me. Concentrating on the
| accounts and the accounting equation, ignoring any
| "meaning" for the words debit and credit, results in the
| "right answer" without a lot of consternation.
| lurkingmba wrote:
| That's too simple. That logic roughly works the balance
| sheet. However, it says nothing about the income statement.
|
| For the income statement, CR -> revenue and DR -> expense.
| rahimnathwani wrote:
| I addressed this earlier:
| https://news.ycombinator.com/item?id=39991837
|
| When you record transactions in accounting, you're
| updating various account balances, such as assets,
| liabilities, and equity. These updated balances
| contribute to the creation of the balance sheet, which
| provides a snapshot of a company's financial position at
| a specific point in time.
|
| The income statement, on the other hand, reflects the
| changes in these balances over a period of time. There's
| nothing special about the line items on the income
| statement (e.g. revenue or expense). Any value on the
| income statement represents a change in what the company
| owns (assets) or what it owes (liabilities or equity).
| sudhirj wrote:
| The way I understand debits and credits is to take the same
| equation and name the left and right side.
|
| Assets + Expenses = Equity + Income + Liabilities
|
| Sum of all debits = sum of all credits
|
| These two equations have their sides associated.
|
| Assets and equities increase with a debit and decrease with a
| credit, and vice versa.
| abtinf wrote:
| > The "credit" and "debit" terminology is ridiculous because
| their definitions swap around depending on which account
|
| I find it easy to just think of debit as adding to the left and
| credit as adding to the right. Their definitions are always the
| same that way.
| lisper wrote:
| But that just begs the question because you have to remember
| the arbitrary assignments of what things go on the left and
| what things go on the right.
| freedomben wrote:
| It's easy! Debits add to the left, credits add to the right
| :-)
|
| (to be clear, I'm backing up your point by giving the same
| circular explanation that I got constantly through
| Accounting 101 and 102, and then occasionally after that
| when dealing with the books)
| lisper wrote:
| Yeah, they should be called leftits and rightits. Or CARs
| and CDRs.
| nuttingd wrote:
| It's the accounting equation being represented in canonical
| form. A chart of accounts is visualized in the minds of an
| accountant as:
|
| Assets | Liabilities + Equity
|
| Accounts classified as assets are debit accounts (left
| side), and accounts classified as liabilities or equity are
| credit accounts (right side).
|
| The theory discussed everywhere in this thread is sound.
| You really don't need to use terminology like debit/credit
| for accounting.
|
| What the discussion misses is the application of this
| framework. It is useful for a human to be able to visualize
| a complex transaction and work through missing pieces with
| the hints this framework provides. I'm missing something on
| the left? Oh yeah, I missed the deferred revenue debit.
| lisper wrote:
| > You really don't need to use terminology like
| debit/credit for accounting.
|
| That's exactly right -- you don't need to. The problem is
| that people _do_ use this terminology, and they use it in
| a way that _conflicts_ with common usage, which makes a
| very simple concept vastly more confusing than it needs
| to be.
| nlitened wrote:
| > That's exactly right -- you don't need to. The problem
| is that people do use this terminology, and they use it
| in a way that conflicts with common usage
|
| I used to think that way, then I understood this thinking
| is the exact opposite of what's happening.
|
| Hundred million people on earth know how to work with
| debit and credit exactly as it has been written in
| accounting books for hundreds of years. When you need to
| expand your accounting department, you go and hire a
| person who understands things exactly the same way as
| your current accountants, can pick up their work, they
| can communicate effectively. As a CEO, you are spared of
| teaching every new junior accountant your own flavor of
| first-principles accounting, you don't need to write your
| custom accounting software, and convert your company's
| books for tax authorities and outside auditors who are
| not familiar with your system.
|
| Same with music notation. Same with Java language. Same
| with every other piece of human knowledge.
| lisper wrote:
| > Java language
|
| That's actually a pretty good analogy. There is a lot in
| Java that could be improved too.
| nuttingd wrote:
| > which makes a very simple concept vastly more confusing
| than it needs to be.
|
| Agreed. The concepts are all very simple. You can throw
| away all of the domain-specific terminology and reason
| about accounting theory with nothing but positive and
| negative numbers.
|
| The utility of the confusing terminology and age old
| accounting frameworks isn't obvious unless you are a
| practitioner living "in it". It's not until you face the
| complexities of real world transactions (an accountant
| booking closing entries for a F500 company or something)
| that the strange left/right debit/credit way of thinking
| is very valuable.
| lisper wrote:
| Sorry, I don't buy it. By the time you get to the point
| where you're doing the accounting for an F500 company you
| have been thoroughly indoctrinated into the conventional
| way of doing things. That doesn't mean that the
| conventional way isn't deeply flawed. It's kind of like
| the use of British units in the USA rather than metric.
| You have 350 million people who are thoroughly
| comfortable with miles and feet and inches and gallons
| and whatnot, but that doesn't mean that metric isn't
| objectively superior.
| globular-toast wrote:
| I find it more intuitive to use negatives. Then it's just
| equity + income + liabilities + assets + expenses = 0. In fact,
| every transaction and therefore the entire ledger sums to zero
| at all times.
|
| So if you take out a loan to buy lemonade: +$5 to expenses, -$5
| to liabilities. If you sell lemonade: -$5 to income, +$5 to
| assets. You just have to remember that equity, income and
| liabilities will be negative so flip them if you want to answer
| questions like "how much do I owe?"
| jancsika wrote:
| > The "credit" and "debit" terminology is ridiculous because
| their definitions swap around depending on which account you're
| talking about, which is an utterly absurd (mis)use of language
| and the main reason people find this confusing.
|
| As a neophyte: "credit" and "debit" make me think I'd need both
| entries to do books _at all_.
|
| The way you've written it makes me think: "Oh, this is just
| single-entry accounting for people who aren't careful like me!"
|
| So perhaps historically there was value in misusing terminology
| sufficiently to cause people to people turn off the optimizing
| compiler in their brain so that they just learn and do it
| correctly from the beginning?
|
| Edit: clarification
| jncfhnb wrote:
| Imo the only time the terms get confused is because there are
| classes of accounts where it was decided it was preferable to
| give it the opposite name rather than carry a negative balance.
| If we didn't do that, the separation would be intuitive.
| mrkeen wrote:
| > Double-entry bookkeeping is very easy to understand once you
| ditch the ridiculous "credit" and "debit" terminology.
|
| I'm with you so far.
|
| > the goal is to keep the accounting equation true at all times
|
| Perfectly reasonable.
|
| > For example, you sell a lemonade for $5. You add $5 to Sales
| (Income) and add $5 to Current Account (Assets).
|
| And now you've completely lost me. Money appeared. Lemonade
| disappeared. I want to see the corresponding +$5 and -$5.
|
| Making it fit the equation (Equity + Income + Liabilities =
| Assets + Expenses) is not an intellectually satisfying reason
| for 'Assets' to go _up_ by $5 when I just lost $5 of assets.
|
| What if it worked this way in physics?
|
| I could write Force * mass =
| acceleration 1N * 500g lemonade = 0.5 m/s/s
|
| Then I could say: "If we _halve_ the mass of lemonade, then we
| _double_ the acceleration: " 1N * 1000g
| lemonade = 1.0 m/s/s
|
| And then you could say "But you didn't halve the mass, you
| doubled it!" and then I could say "Yes I did, look, the
| equation still holds."
| thetwentyone wrote:
| The -5 doesn't belong in your ledger, it belongs in the
| ledger of the person who bought the lemonade. As other
| commenters have pointed out, the "double entry" refers to
| multiple entries within your own ledger, it has nothing to do
| with someone else's ledger.
| mrkeen wrote:
| > The -5 doesn't belong in your ledger, it belongs in the
| ledger of the person who bought the lemonade.
|
| This is just prescriptive (do it because I say so). It
| doesn't explain anything.
|
| > As other commenters have pointed out, the "double entry"
| refers to multiple entries within your own ledger, it has
| nothing to do with someone else's ledger.
|
| I didn't introduce the other guy's ledger, but since you
| did:
|
| I _lost_ lemonade (which is somehow an _addition_ to my
| assets). So the "-5" which belongs in the buyer's lemonade
| - is the negative sign there to indicate that he _gained_
| an asset?
| MajimasEyepatch wrote:
| Inventory is an asset, so if you want to account for
| inventory in this example, you would record two debits
| and two credits:
|
| - $5 debit to cash (asset => debit means +5)
|
| - $5 credit to revenue (equity => credit means + 5)
|
| - $X debit to cost of goods sold (liability => debit
| means - X)
|
| - $X credit to inventory (asset => credits mean - X)
|
| Where X is the cost of the materials that went into the
| lemonade. So if X < 5, you made a profit. In terms of the
| equation, this comes out to: Assets =
| Liabilities + Equities (5 - X) = (-X) + (5)
|
| So it all adds up to 0, but you make a (gross) profit or
| loss depending on the value of X.
|
| You wouldn't account for the customer's side of things
| because the customer is not on your books.
| hencq wrote:
| > Money appeared. Lemonade disappeared. I want to see the
| corresponding +$5 and -$5.
|
| If I understand your comment correctly, where you're getting
| confused is, you're reading Current Account (Assets) to mean
| your inventory of lemonade. What they actually mean in this
| case is money moved _from_ Income _to_ your Assets (e.g. your
| cash register). That 's why assets went up in this example.
|
| Of course for your lemonade business you might keep track of
| your lemonade as well (which I think is what you're talking
| about when you refer to assets). The lemonade sale would then
| lead to a decrease in your lemonade asset and and an increase
| in your expenses (cost of goods sold), so the right hand side
| of the equation balances.
|
| So when selling lemonade there are actually 2 things
| happening:
|
| 1. Your income and your assets (your amount of cash) both
| increased. Income and Assets are on different sides of the =,
| so the equation still balances
|
| 2. Your lemonade assets decrease and you incurred the cost of
| that lemonade as an increase of your expenses. Those are both
| on the same side of the =, so the equation still balances.
| mrkeen wrote:
| Thanks for moving this along.
|
| I knew beforehand that I will always get Credit and Debit
| wrong, but now I guess I can add Income and Assets to that.
|
| > What they actually mean in this case is money moved from
| Income to your Assets (e.g. your cash register).
|
| Usually when people say 'moved', it implies a _decrease_ in
| one place and an _increase_ elsewhere, and yet:
|
| > 1. You got income and your assets (your amount of cash)
| both increased.
| hencq wrote:
| > Usually when people say 'moved', it implies a decrease
| in one place and an increase elsewhere, and yet
|
| Yeah, I'm with you there. Personally I think this would
| be simpler if accounting just used negative numbers
| instead of a credit and debit side. That said, it's not
| super complicated. It's all derived from the accounting
| equation (explained well in this comment [1]):
|
| Equity + Income + Liabilities = Assets + Expenses
|
| Any transaction you do, needs to maintain that equation.
| That means that the changes either need to add to zero on
| one side or need to add to the same on both sides.
|
| - E.g. in the example I'm selling lemonade: I'm
| increasing my cash (an asset, so on the right side) by
| $5, so I need to also increase the left side by the same,
| meaning an increase of $5 in the Income account.
|
| - Or let's say I'm buying more lemons for my business. My
| cash (asset) goes down, but my inventory (also asset)
| goes up by the same amount.
|
| - If I bought those lemons with my credit card instead,
| my inventory (asset) would go up and my liabilities would
| go up by the same amount.
|
| In all cases the equation still holds after the
| transaction.
|
| ----
|
| NB
|
| You could construct an alternative way of accounting
| where the equation looks like this: Equity + Income +
| Liabilities + Assets + Expenses = 0
|
| In this world, moving money would indeed align better
| with your intuition. E.g. selling lemonade would be -5
| Income and +5 Assets (going _from_ income _to_ assets).
| That 's for instance how Beancount does it [2]. Note that
| that also means that Equity, Income and Liabilities will
| now (generally) be negative numbers.
|
| [1] https://news.ycombinator.com/item?id=39992035
|
| [2] https://beancount.github.io/docs/the_double_entry_cou
| nting_m...
| hencq wrote:
| Totally agree. That's what I like about the way e.g. beancount
| does it [1]. Instead of using the debit/credit nomenclature, it
| just relies on positive and negative numbers. This way all the
| legs in a transaction just sum to zero, making it easy to spot
| if something is off. In the example, you'd have -5 Income (it's
| coming _from_ income) and +5 Assets (it 's going _to_ Assets).
| The left side is typically negative and the right side
| positive.
|
| [1]
| https://beancount.github.io/docs/the_double_entry_counting_m...
| balderdash wrote:
| It think that's right, but where people struggle so much is the
| splitting up transactions between these accounts the right way
| omichowdhury wrote:
| Yeah, I think a more intuitive way is to replace credit and
| debit with State and Change as the pair of things in double-
| entry. It means that you don't have to swap meanings based on
| context and can use negative numbers intuitively.
|
| State Accounts track your net worth Assets:
| what you own Liabilities: what you owe
|
| Change Accounts track why your net worth changes
| Income: what you've earned Expense: what you've
| spent
|
| The accounting equation that follows is [?] State = [?] Change:
| Assets - Liabilities = Income - Expense
|
| Selling lemonade is +$5 Asset balanced by +$5 Income. If you
| substitute into the equation, it's: $5 Asset = $5 Income
|
| Taking out a loan is +$10 Asset balanced by +$10 Loan. In the
| equation: $10 Asset - $10 Liability = $0.
|
| In general, say you have a +Asset action, to balance the
| equation you can do it 4 ways: +Asset -Asset
| aka swapped for equal value +Asset +Liability aka
| took out a loan +Asset +Income aka sold something
| +Asset -Expense aka got a refund
|
| I've left out Equity as a separate account type since you can
| just treat it mathematically as a Liability account.
|
| This is the system we've implemented in our ledger API
| (https://fragment.dev)
| thomastjeffery wrote:
| The purpose of the words "credit" and "debit" is the same
| purpose of the structure of double-entry bookkeeping: to make
| every statement unambiguous, no matter what order or context
| you put the words in. By replacing familiar verbs like "paid"
| and "earned" with the nouns "debit" and "credit", we can write
| sentences where the order of words doesn't change the meaning,
| and where we never need to figure out what tense (past,
| present, future) to apply.
|
| To simply write that, "Bob's account has a credit of $12 and a
| debit of $7" is _timeless_. That sentence can go anywhere, and
| always be explicitly correct. It is _context-free grammar_ :
| the same category that all programming languages belong to.
| Because a programming language is context-free, it can be
| perfectly understood (and translated) by a parser and compiler.
| Because statements using the nouns "credit" and "debit" are
| context-free, they can be perfectly understood as the data they
| represent.
|
| > The "credit" and "debit" terminology is ridiculous because
| their definitions swap around depending on which account you're
| talking about, which is an utterly absurd (mis)use of language
| and the main reason people find this confusing.
|
| On the contrary! Their definitions are always the same. They
| apply specifically to the account you are talking about,
| because they _are_ that account: an account _is_ a list of
| credits and debits.
|
| The reason that people get confused is that we are used to
| using verbs like "paid" and "earned". When we use verbs, the
| data is the _transaction_ , not the account. When we use the
| nouns "credit" and "debit", the data is the _account_ , and not
| the transaction. Most people are introduced to these words with
| "credit _card_ " and "debit _card_ ". That was the mistake,
| because cards are used for _transactions_ , which is precisely
| the wrong context to use these words. It would have been much
| more clear to talk about " _crediting cards_ " and " _debiting
| cards_ ".
| mrkeen wrote:
| > Bob's account has a credit of $12 and a debit of $7
|
| (I'm 80% sure that the above reads that Bob actually owns $5
| he can spend. But I'm equally sure that I get Debits and
| Credits backward, so I probably read it wrong.)
|
| In any case, you've only described a single account at rest.
| You need to go one step further and describe an entire
| transaction in those terms, so that someone can swoop in and
| say "you got it backwards".
| thomastjeffery wrote:
| You read it correctly. The account's "balance" would be a
| "credit of $5".
|
| A transaction involves multiple accounts, so it would be
| written as multiple sentences: "Alice's account has a
| credit of $7. Bob's account has a debit of $7." If you want
| to write about the transaction itself, you could do that
| with a verb: "Transaction #23254 applies a debit of $7 to
| Bob's account, and a credit of $7 to Alice's account." A
| double-entry book is just a table with a column for each
| account, and a column for the date/time each credit or
| debit was transacted.
|
| The whole point here is that _when_ someone swoops in,
| every sentence spoken is guaranteed to be unambiguous; no
| matter what context that someone brings with them. So long
| as "credit" and "debit" are used exclusively as nouns,
| there can be no confusion.
| lmeyerov wrote:
| Very cool! Well-written, and surprisingly real:
|
| Somewhere VERY close to this modeling patterns has always been an
| interesting use case for us is large-scale visual analysis of
| crypto investigations, where the ledger gets shown quite
| similarly. The bit on taxes is funny too, as that's the first
| thing to get filtered out because it makes the graph messy :)
| Often, balances aren't initially known, so a post whole-graph-
| compute step is done to algorithmically enrich nodes after.
|
| You can also do visual tricks here, like collapse 'multiedges'
| between the same accounts to get a summary of their p2p history.
| Analytically, this becomes an easy groupby on a ledger dataframe
| :)
|
| To a lesser extent, we also see fiat $ investigations here too,
| imagine correspondent banking. I wish more bigco AML forensic
| accounting did this internally (erp, credit cards, ..),
| especially as so much is digital now, but we don't see that as
| much.
|
| An interesting area becomes when you do things like add identity
| details to the graph, and can then start realizing the "A" and
| "Alice" and contra XYZ are all the same person. Another, which
| helps once you have a lot of data, is to start to be able to
| decloak transaction $1 "food" is a Costco hotdog, or funny buying
| patterns. Both are where "graph neural networks" come in, which
| have really advanced over the last few years. We see this kind of
| things in finance, like risk analysis. We find most folks are at
| the viz stage vs AI stage, and it's a multi-year relationship to
| get them from one to another, but a fun one!
|
| ---
|
| Edit: Another practical modeling aha here is that a transaction
| can involve multiple entities. Formally, that is a hyperedge:
| it's fine for edges to connect more than 2 nodes. (And why
| languages like datalog are neat here, even if rare.) Visually
| that's confusing, so a trick is to make the transaction a node
| and connect it to all the involved accounts. Keeping transactions
| as event edges between entities can be nicer when zoomed out as
| fewer nodes, but having the transaction node is nice when zoomed
| in, and in the limit, there are asymptomatically fewer
| nodes+edges when doing the transaction node as you replace
| strongly connected components (quadtratic in edges) with a
| hub&spoke, which is linear.
| aquir wrote:
| Double-Entry Bookkeeping is great - I have learned it when
| started implementing ERP systems. This article is a bit
| overcomplicated and also, where is the Balancing Entry for the
| Opening Balances? It should be balanced against some Technical
| Account...
| m3kw9 wrote:
| Double entry can track networth better. Instead of a single entry
| of recording 500$ paid for laptop, which decreases your networth
| by 500, in reality you still have 500$ worth of a laptop in your
| hand. You would also record the asset increase as a +500$ from
| gaining a laptop. Which reflects reality of your situation
| better.
| balderdash wrote:
| My personal observation is that where many people struggle the
| most mentally is across the three statements (balance sheet,
| income statement, and cash flows), 1) that that balance sheet is
| point in time and the other two are over some period, but 2) how
| a record entry effects each of the statements...e.g. if you sell
| an asset for a gain causing a change in the composition of the
| balance sheet (asset > cash, reversals of accumulated
| depreciation etc.) income statement (income in excess of basis)
| and cash flow (actual cash received)
| jacques_chester wrote:
| Interestingly I sort of went in the other direction at one point
| -- converting what was obviously a graph (build pipelines) into a
| from-to / credit-debit representation. On reflection it's just an
| edge list.
|
| My main problem with adapting the representation was in the
| incommensurability of different kinds of asset moving through the
| pipeline. How does one credit source code and debit a blob store?
| I thought about learning more about multi-currency accounting as
| a source for ideas but never followed it up.
|
| That effort inspired my thinking about a "Universal Asset Graph"
| for software[0] -- keeping track of not just containment but also
| movement and transformation of software. It's a partial but not
| complete inspiration for GUAC, which aims to capture software
| part relations for easy querying.
|
| [0] https://theoryof.predictable.software/articles/some-
| requirem...
|
| [1] https://guac.sh
| eunos wrote:
| Cool! Reminded me to this accounting explanation for CS folks
| (written by Designing Data Intensive Applications author)
| https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
| sandGorgon wrote:
| I built a double-entry ledger for multiple different kinds of
| credit cards at redcarpetup. the way i like to primarily think of
| it technically is idempotency. Thinking of balances is the wrong
| way to model it :
|
| 1. since you want the capability to recompute all balances using
| ledger entries. 2. there are not two balances. There's usually a
| lot more. you want to update reward points, dues, late fees,
| partner share, etc etc etc. a 2 balance double entry ledger is a
| simplification.
|
| once you set your mental model to think of it as a idempotency
| problem, there are multiple ways to model it. For e.g. a directed
| graph - traverse the entire subgraph to update balances. Or model
| it as a log database and re-run txns to arrive at balance
| computation.
| ggrothendieck wrote:
| David P. Ellerman has a mathematical approach to accounting based
| on what he refers to as the Pacioli group. A provisional element
| of the Pacioli group looks like x//y where x and y are non-
| negative integers and we form equivalence classes based on x//y
| and u//v being equivalent if the cross sums x+v and y+u are
| equal. The group operation is x//y + u//v = (x+u)//(y+v) and the
| inverse of x//y is y//x . The identity element is 0//0. For more
| info see, for example, https://ellerman.org/wp-
| content/uploads/2012/12/DEB-Math-Mag...
| nosmokewhereiam wrote:
| This helped me. In class now and the first ever accounting course
| I've taken. It's hard to wrap your head around without any
| background.
|
| Thank you!
| xg15 wrote:
| 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 exact same limitations that the original,
| "mutable" account table had: You can only store a single
| "current" balance for each account and each time you add another
| transaction to the graph, the old balances of the accounts
| involved are lost.
|
| You could fix this shortcoming by redefining the meaning of the
| "round" nodes in the graph and essentially treating the graph as
| a ledger: Instead of a round node representing an account, make
| it represents an account _at a specific point in time_ , i.e.
| between two transactions. Then new transactions can be added as
| new nodes and edges to e.g. the right side of the graph and the
| graph will become a long _chain_ that grows from left to right
| and represents the exchange of money over time.
|
| (Another constraint has to be added that a transaction must never
| go "backwards in time", i.e. never go from a node to the right to
| one on the left and never have an "incoming" and "outgoing" edge
| pointing to the same round node)
|
| With many accounts and transactions, it might still get difficult
| to keep track, which transactions are close together in time and
| which are far apart. This could be made easier by introducing
| another container, let's call it a _block_ , that groups all
| transactions together which share at least one "round" node in
| their "incoming" or "outgoing" edge. Because of the "no going
| back in time" property, the blocks will be non-overlapping and
| they will also have at least a partial ordering to them that
| follows the chronologial ordering of the transactions.
|
| If you want to make the graph extra pretty, pick one transaction
| in each block and use its timestamp to turn the partial into a
| total ordering.
|
| If you zoom out, your graph indeed looks like a chain of blocks,
| going from left to right in the direction of time, with each
| block containing the transactions that belong to the same slice
| of time. A _blockchain_ , if you will...
| TeeWEE wrote:
| https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
| amelius wrote:
| Can one do accounting using Git commits, and would it be
| practical?
| ebolyen wrote:
| I see a lot of consternation about credits and debits and the
| nomenclature.
|
| Something that makes this simpler to think about from a modern
| perspective is that accounting is older than the popular use of
| negative numbers. By a lot. If we were to invent accounting
| today, we'd probably use positive and negative accounts instead
| of debit and credit accounts.
|
| Algebra over addition is second nature to us at this point, but
| it would not have been obvious to the average merchant in 1604,
| and even then, negative numbers were viewed quite poorly.
|
| What is important is that there are always two sides to a
| transaction and that they are inverses of each other. This is all
| a credit and debit are. Inverse operations on a number.
|
| Therefore, we can make a rule that a transaction balances when
| credit = debit. (aka we didn't invent money as debit + credit =
| 0, but remember that we didn't like negative numbers when this
| system was invented, so this last fact is more of a happy
| coincidence that happens to ALWAYS WORK, for some reason, rather
| than the goal).
|
| What is then reasonable is to consider literal cash on hand to be
| the most positive (debit) kind of account there can be, and work
| backwards from there. If I want to handle an expense, then I need
| to invert the cash account somehow (credit it) and therefore have
| the opposite kind of entry for where the money went (debit it).
| So an expense account must have a generally debit (or positive)
| balance.
|
| But where did the cash come from? Well that comes from income and
| I want the cash to be debit-ey so the place it came from must be
| credit-ey otherwise I risk writing a transaction that doesn't
| balance (equal zero). So then income accounts must generally be
| credit accounts rather than debit account (aka they hold a
| typically negative balance or are "credit normal").
|
| What is really killer about this system, is it just so happens
| that every mundane transaction you could ever write will end up
| as balanced transactions and each of these possible transaction
| accounts end up having the same usual balance of credit or debit
| (negative or positive). I think that is just so elegant.
| EvanAnderson wrote:
| I enjoy using the alliteration of "Capital" and "Credit" to
| remember the normal balance of the capital/equity accounts.
| Memorizing that and the accounting equation is all that's
| necessary to derive the normal balances of every other account
| type.
| yandrypozo wrote:
| nice trick, thanks!
| thedanbob wrote:
| I recently wrote my own bookkeeping software based on a budgeting
| spreadsheet my wife found a long time ago and used for years. It
| wasn't until reading this (and some of these comments and other
| references) that I realized it's actually a disguised double-
| entry bookkeeping system. No wonder it works so well!
| vezuchyy wrote:
| Ten years in SAP working on FI, SD and AA. (not anymore, I'm done
| with that)
|
| The post triggered PTSD and I want to go home and cry. You
| created your double entry, cool, now let's split it (because of
| million reasons) and add taxes. So now we deal with a basic 25
| line document where some lines are doing nothing but move funds
| through certain tax accounts. Oh, no, there is a typo, but we
| cannot just create the reversal because for some accounts, the
| transaction should stay reflected in turnovers, for some it
| should not and for most it depends on fiscal period and stuff.
|
| Don't forget that everything varies between countries. With all
| that let's create a financial statement for eg Walmart (who has
| every line item sold posted to SAP system when you buy things at
| store)
| ericpauley wrote:
| > Walmart (who has every line item sold posted to SAP system
| when you buy things at store)
|
| _Shudders_
| vezuchyy wrote:
| On the other hand, people who work on that don't think GPT
| will make them jobless. Also, I recall how a major client
| postponed adoption of a new reporting platform because it
| meant for them layoffs in accounting department and
| accountants started to sabotage the whole thing...
| JensRantil wrote:
| I work in the Carbon Accounting space where the accounting is
| used for carbon emissions.
| infogulch wrote:
| Double-entry bookkeeping is the original CRDT.
|
| Just by maintaining a local invariant -- debits and credits in a
| transaction sum to zero -- a distributed network of agents
| attending to their own ledger can reliably maintain a global
| consistent state (like, money is neither created nor destroyed),
| or heal it in the case of corruption.
| poslathian wrote:
| Came here for this comment. I've always kept an eye open for
| anyone who has applied this insight to something. There is
| something also satisfying about how accessible accounting is vs
| any other domain you encounter invariants (like noethers
| theorem, group theory, or equivariant neural networks)
| lurkingmba wrote:
| The article is wrong in at least one important respect. Debits do
| not always increase the balance of an account. Accounts can have
| either a natural debit balance or a natural credit balance.
|
| Credits actually increase the revenue account, which is a pretty
| important one!
| hacker_88 wrote:
| Block chain should solve any issues relating to accounting
___________________________________________________________________
(page generated 2024-04-10 23:00 UTC)