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

Double Entry Accounting for Developers

django-hordak.readthedocs.io

Post reply on HN
Print view View original

201–210 of 237 posts

Re: Double Entry Accounting for Developers

#201

Post by Lazare »

gowld wrote: post #41
bdowling wrote: post #20

Earlier quoted context omitted.

> I mean, this is just....wrong. It's beyond wrong. The developer here is redefining established accounting terms because he doesn't like their inconsistencies.

> It's beyond wrong. How so? > The developer here is redefining established accounting terms because he doesn't like their inconsistencies. Yes. What's wrong with fixing inconsistencies? Established accounting terms are from 500 years ago when people had trouble with subtraction.

There are no inconsistencies here.

We have an algebraic indentity, a + b = x + y. (Let's not even think about what those might represent; it doesn't matter.)

The two sides must always be equal. Any transaction must maintain that equality. Therefore, any transaction must increase both sides by the same amount, decrease both sides by the same amount, or leave both sides unchanged.

One way to ensure this is respected is to add up everything which increases the left side or decreases the right side, then add up everything which decreases the left side or increases the right side, and ensure these two subtotals match. If they do, the transaction balances, and is legal.

By convention, we call things of the first type (which increase the left side or decrease the right side) "debits", and things of the second type (which increase the right side or decrease the left side) "credits". This lets us say "debits must equal credits" as a shorthand, although again what we really mean is that the two sides must continue to balance.

The end. There's really no inconsistency here.

Re: Double Entry Accounting for Developers

#202

Post by sago »

kgwgk wrote: post #199
sago wrote: post #197

Earlier quoted context omitted.

> Did it displayed assets It's an API. There are many tools built on top of it, many with UIs. I'm sure they display things in many different ways for people internally and externally. The system I was working was back-end. It used negative numbers for debits. And it was really important you didn't confuse credit and debit numbers. > Was that accountant fine with assets as negative numbers? I find it hard to believe…

For the record, this is what the consolidated balance sheet looks like: https://imgur.com/a/i8q0Fa2

Neat. Thank you. I get what you're saying now.

And that makes sense. You can see the balance. Because it will balance. Or you'd know which of the things were debit accounts and which went credit accounts.

Yep.

But I definitely bet it's not raw unsigned/untyped numbers behind that document! I suspect we've just been mismatching on different levels: I began this discussion about developers understanding double entry bookkeeping. I would be surprised if you could get very far if you didn't understand the difference between debit and credit. But your pushback makes sense. Thank you.

Re: Double Entry Accounting for Developers

#204

Post by kgwgk »

sago wrote: post #202
kgwgk wrote: post #199

Earlier quoted context omitted.

For the record, this is what the consolidated balance sheet looks like: https://imgur.com/a/i8q0Fa2

Neat. Thank you. I get what you're saying now. And that makes sense. You can see the balance. Because it will balance. Or you'd know which of the things were debit accounts and which went credit accounts. Yep. But I definitely bet it's not raw unsigned/untyped numbers behind that document! I suspect we've just been mismatching on different levels: I began this discussion about developers understanding double entry bo…

I do understand the difference between debit and credit. The point is not whether you can balance the books looking at them when they fit in a single page. The point is that in a balance sheet assets appear as $x (where x is rarely negative, an asset with negative value would become a liability).

People want assets to be positive in the balance sheet. This may be a convention but it's a reasonable convention. I don't think you're helping developers who try to understand accounting by telling them that assets are negative quantities (it may make sense as an implementation detail, but not so much as an accounting concept).

Re: Double Entry Accounting for Developers

#205

Post by goat_whisperer »

SnowingXIV wrote: post #200
goat_whisperer wrote: post #4

From the site: "I found the core explanation of double entry accounting to be confusing. After some time I distilled it down to the following: "Debits decrease the value of an account. Always. [1] Credits increase the value of an account. Always. [1] "[1] (1, 2) This is absolutely not what accountancy teaches. You’ll quickly see that there is a lot of wrangling over what account types get increased/decreased with a d…

Spot on. This is another situation of trying to solve a problem that doesn't exist and the writer does not understand at all . There are reasons why GAAP and IFRS exist. Accounting can make a lot of sense to a programmer, I've moved between fields early on with relative ease because accounting is extremely rule based/puzzle-oriented and adheres to a structured and specific framework. I haven't touched accounting in y…

Hey Snowing, would love to learn more about your experience -- I'm a fellow accountant (BS accounting) looking to move into development.

Re: Double Entry Accounting for Developers

#206

Post by sago »

wrycoder wrote: post #193
sago wrote: post #171

Earlier quoted context omitted.

> Equity is similar to a liability. Ít is owed to the owners of the entity. You can kind of see the easy rationale there. I'm not sure it's very deep though. Revenue is in the same group (Credit). And the assets are like expenses (Debit). That is a bit more of a just-so-story in my mind. > Making assets positive in code is conventional. Are you sure? What code are you talking about? Making everything positive in the…

For one example, read the docs for Beancount, which is mentioned above. Signed values are the way to go!

> Signed values are the way to go!

100% agree!

> For one example, read the docs for Beancount, which is mentioned above.

Do you have other examples too?

You are dead right with this one. It is the opposite way to the way the systems I'm familiar with did it. Debit is positive, And credit negative.

Thanks so much for the link.

I'm still not sure what I would concede that it is conventional ;) But my assumption it was nothing but the other way is definitely incorrect!

I wonder if they did it this way because they felt people would understand negative income being a good thing better than a negative bank accounts being a good thing. The bank account is usually the big problem with understanding debit and credit.

As usual, the world is more complex and interesting then I assume!

Re: Double Entry Accounting for Developers

#207

Post by inopinatus »

buyx wrote: post #172
inopinatus wrote: post #166

Earlier quoted context omitted.

It doesn’t quite. You’ll also need to consider allocations and accounting for tax (sales and income), depreciation, transaction fees, warehousing, shipping revenue and expenses, revenue and expense recognition, discounts, returns, overpayments, prepayments, futures, chargebacks, refunds, credit notes, invoicing, subscriptions, subsidies, tariffs, reconciliation, adjustments in the current financial year, adjustments…

I specifically stated it was an unsophisticated example. GP wanted to know what happens with the "simplest transaction" when he buys a banana.

That was the simplified version.

Re: Double Entry Accounting for Developers

#208

Post by zzo38computer »

juped wrote: post #115
zzo38computer wrote: post #23

I learned double entry accounting. "Debits decrease and credits increase" is just one way to represent the numbers; I have also seen the other way around (where debits are positive). But more commonly, the presentation is such that debits increase the accounts on the left, and credits increase the accounts on the right. (Nevertheless, the explanation there does work.) Some time ago (while I was bored in the accountin…

Compare to https://arxiv.org/abs/1407.1898

I have not seen that; thank you for this information.

Re: Double Entry Accounting for Developers

#209

Post by sago »

kgwgk wrote: post #204
sago wrote: post #202

Earlier quoted context omitted.

Neat. Thank you. I get what you're saying now. And that makes sense. You can see the balance. Because it will balance. Or you'd know which of the things were debit accounts and which went credit accounts. Yep. But I definitely bet it's not raw unsigned/untyped numbers behind that document! I suspect we've just been mismatching on different levels: I began this discussion about developers understanding double entry bo…

I do understand the difference between debit and credit. The point is not whether you can balance the books looking at them when they fit in a single page. The point is that in a balance sheet assets appear as $x (where x is rarely negative, an asset with negative value would become a liability). People want assets to be positive in the balance sheet. This may be a convention but it's a reasonable convention. I don't…

If you are using a negative numbers you can do it in three ways.

1. positive numbers represent the default for an account (A positive number in a debit account is a debit, but a positive number in a liability say, is a credit). This is done a lot. But he causes a lot of rules about when to add and went to subtract what the balance with what. I think this is why they lot of double entry bookkeeping and has a hard reputation. Certainly if you coded it you would have to code all those rules manually.

2. The approach I'm used to of having negative numbers in the debits and positive credits. This makes all the double accounting balancing much simpler. But I can see it may confuse some people when assets are negative.

3. Make credits at the beauty of an debits positive (incidentally I only today learned that beancount does it this way). Again balancing and double-entry accounting becomes simpler. Now money in the bank would be positive, like your bank statement. But sales income would be negative (it is a credit). I wonder if that would confuse people.

So maybe that's why UI should make everything positive and undifferentiated. But given the amount of time the Accounting 101 has to drill in all the rules of what

Re: Double Entry Accounting for Developers

#210

Post by navaati »

kgwgk wrote: post #126
juped wrote: post #83

Earlier quoted context omitted.

Yeah, I guess eating pizza usually counts as opex.

But looking down at the balance you may find some of it gets capitalized.

(for these who struggled like me: the weighting balance,not the account balance. Nice one once you get that :)
Post reply on HN