4 ms·

> 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

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

gowld 6y ago
> 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.
- mariomariomario 6y ago
  Generally Accepted Accounting Principles
- bdowling 6y ago
  > What's wrong with fixing inconsistencies? In general, nothing. It's just not the software developer's job. If the accounting profession decided to change certain terms to fix inconsistencies, that would be fine.
  - fauigerzigerk 6y ago
    I think that's missing the point of the original article. Of course you have to present a view of the accounts that is consistent with accounting rules and conventions. But that doesn't necessarily mean you have to adopt that external view as an internal model for any software you're writing.
    - inopinatus 6y ago
      At audit time the world of “holy shit what were these people thinking?” will be colossal, because we do not get to pretend that a system is a black box at audit time. If those records don’t make sense to an accounting professional, then they’re fucked up, and that’s all she wrote. The world of audit has seen a million shysters try to falsify their books under the guise of alternative methods, and they are not interested in some self-serving hubris from programmers about re-inventing their own profession. So this guide isn’t just philosophically off beam. It could get someone fired or sued. Probably not prosecuted though. Probably.
      - 3pt14159 6y ago
        Yeah I've worked on so many systems that dealt with money. Telephone invoicing, business accounting, ticket sales, etc. One of the businesses I worked for did online invoicing and they initially started off without double ledger accounting. I was employee 30 or so and I kept repeating "we need double ledger accounting" every month or so. Nobody really listened to me (to be fair I was young, but this was after the telephone invoicing job) until the cracks started to form. It took them years to transition to a new system. Do not re-invent accounting with your own terms. International commerce runs on it and it has figured out a lot of the edge cases.
      - fauigerzigerk 6y ago
        Accounting professionals can only ever look at user interfaces. If there is a suspicion of fraud then a court can ask expert witnesses to look into the software itself. The law does put some constraints on what accounting software must and must not allow users to do (e.g change data without leaving a trace). But I'm not aware of any specific legal requirements regarding data representation or mandating the use of specific algorithms where mathematically equivalent ones exist.
- PhasmaFelis 6y ago
  > What's wrong with fixing inconsistencies? Nothing, if you can convince the entire user base to do it at the same time. If you decide to unilaterally fix inconsistencies, you've just made it impossible to understand what anyone is saying without additional metadata saying which version you're using. And if you start telling learners that your "fixed" version is all there is, hiding the actual standard that most of the world uses, you are basically lying to them and setting them up to fail.
- steventhedev 6y ago
  It's wrong in the sense that anyone who's studied standard accounting will look at your books and consider them to be incorrect. This is important if you want to share your books or reports with your local tax office, who will begin investigating you for committing tax fraud. It's the same reason why no one fixes the HTTP "Referer" header typo. You can, but if you do then you'll have difficulty communicating with the outside world.
  - verytrivial 6y ago
    > look at your books I think OP is encoding the sign-reversal internally though, right? It "displays" the two incorrectly classified account types exactly per the standard convention instead of re-applying the convention at every operation. All reports would follow the 'Classic' conventions. At least that was my reading!
    - navaati 6y ago
      It doesn't, the Equity account displays a negative number if the company is in the green (it decreases when you emit stocks), the Expense account displays positive numbers (it increases when you spend money), the Income account displays negative numbers (it decreases when you earn money). In beancount, the accounting equation is Expense+Income+Equity=0 and all signs are always left intact (there is only addition). So you start a company with a seed capital of $5. You borrow $5 to the bank, buy an expensive apple for $10, sell it for $15 and give the money back to the bank with an interest of $1, then close the exercise and carry the profits (don't distribute dividends). Your ledger is: Initial capital Assets:Cash +5 USD Equity:Seed -5 USD Borrow to the bank Assets:Cash +5 USD Liabilities:Bank -5 USD Buy an apple Assets:Apples +10 USD Assets:Cash -10 USD Sell the apple Income:Sales -5 USD Assets:Apples -10 USD Assets:Cash +15 USD Reimburse the bank Liabilities:Bank +5 USD Expenses:Interest +1 USD Assets:Cash -6 USD Close the exercise # beancount does that for you for any time period btw Expenses:Interest -1 USD Income:Sales +5 USD Equity:PreviousProfit +4 USD Notice how every transaction balances to 0 just by summing it, no need to remember anything. Now, you're at the beginning of the next exercise. To know your accounts you just compute a sum of every operation to it, again no special case. So your accounts are: Expenses 0 USD Income 0 USD # as expected at beginning of exercise Assets:Apples 0 USD Assets:Cash 9 USD Liabilities:Bank 0 USD Equity:Seed -5 USD Equity:PreviousProfits -4 USD And yet again, the sum of all of that is 0. Personally I like it, not having any special cases. Yes, it may confused an accountant (because they learned the special cases by heart ! Somebody coming with a fresh mind has no reason to be confused, it's all just conventions !) but it's simpler for me and just as consistent.
- juped 6y ago
  There's a lot wrong with fixing consistencies.
- dragonwriter 6y ago
  > What's wrong with fixing inconsistencies? There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.) > Established accounting terms are from 500 years ago when people had trouble with subtraction. People still have trouble with substraction compared to addition, especially with large numbers.
- Lazare 6y ago
  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.

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

gowld 6y ago

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

mariomariomario 6y ago
Generally Accepted Accounting Principles
bdowling 6y ago
> What's wrong with fixing inconsistencies? In general, nothing. It's just not the software developer's job. If the accounting profession decided to change certain terms to fix inconsistencies, that would be fine.
- fauigerzigerk 6y ago
  I think that's missing the point of the original article. Of course you have to present a view of the accounts that is consistent with accounting rules and conventions. But that doesn't necessarily mean you have to adopt that external view as an internal model for any software you're writing.
  - inopinatus 6y ago
    At audit time the world of “holy shit what were these people thinking?” will be colossal, because we do not get to pretend that a system is a black box at audit time. If those records don’t make sense to an accounting professional, then they’re fucked up, and that’s all she wrote. The world of audit has seen a million shysters try to falsify their books under the guise of alternative methods, and they are not interested in some self-serving hubris from programmers about re-inventing their own profession. So this guide isn’t just philosophically off beam. It could get someone fired or sued. Probably not prosecuted though. Probably.
    - 3pt14159 6y ago
      Yeah I've worked on so many systems that dealt with money. Telephone invoicing, business accounting, ticket sales, etc. One of the businesses I worked for did online invoicing and they initially started off without double ledger accounting. I was employee 30 or so and I kept repeating "we need double ledger accounting" every month or so. Nobody really listened to me (to be fair I was young, but this was after the telephone invoicing job) until the cracks started to form. It took them years to transition to a new system. Do not re-invent accounting with your own terms. International commerce runs on it and it has figured out a lot of the edge cases.
    - fauigerzigerk 6y ago
      Accounting professionals can only ever look at user interfaces. If there is a suspicion of fraud then a court can ask expert witnesses to look into the software itself. The law does put some constraints on what accounting software must and must not allow users to do (e.g change data without leaving a trace). But I'm not aware of any specific legal requirements regarding data representation or mandating the use of specific algorithms where mathematically equivalent ones exist.
PhasmaFelis 6y ago
> What's wrong with fixing inconsistencies? Nothing, if you can convince the entire user base to do it at the same time. If you decide to unilaterally fix inconsistencies, you've just made it impossible to understand what anyone is saying without additional metadata saying which version you're using. And if you start telling learners that your "fixed" version is all there is, hiding the actual standard that most of the world uses, you are basically lying to them and setting them up to fail.
steventhedev 6y ago
It's wrong in the sense that anyone who's studied standard accounting will look at your books and consider them to be incorrect. This is important if you want to share your books or reports with your local tax office, who will begin investigating you for committing tax fraud. It's the same reason why no one fixes the HTTP "Referer" header typo. You can, but if you do then you'll have difficulty communicating with the outside world.
- verytrivial 6y ago
  > look at your books I think OP is encoding the sign-reversal internally though, right? It "displays" the two incorrectly classified account types exactly per the standard convention instead of re-applying the convention at every operation. All reports would follow the 'Classic' conventions. At least that was my reading!
  - navaati 6y ago
    It doesn't, the Equity account displays a negative number if the company is in the green (it decreases when you emit stocks), the Expense account displays positive numbers (it increases when you spend money), the Income account displays negative numbers (it decreases when you earn money). In beancount, the accounting equation is Expense+Income+Equity=0 and all signs are always left intact (there is only addition). So you start a company with a seed capital of $5. You borrow $5 to the bank, buy an expensive apple for $10, sell it for $15 and give the money back to the bank with an interest of $1, then close the exercise and carry the profits (don't distribute dividends). Your ledger is: Initial capital Assets:Cash +5 USD Equity:Seed -5 USD Borrow to the bank Assets:Cash +5 USD Liabilities:Bank -5 USD Buy an apple Assets:Apples +10 USD Assets:Cash -10 USD Sell the apple Income:Sales -5 USD Assets:Apples -10 USD Assets:Cash +15 USD Reimburse the bank Liabilities:Bank +5 USD Expenses:Interest +1 USD Assets:Cash -6 USD Close the exercise # beancount does that for you for any time period btw Expenses:Interest -1 USD Income:Sales +5 USD Equity:PreviousProfit +4 USD Notice how every transaction balances to 0 just by summing it, no need to remember anything. Now, you're at the beginning of the next exercise. To know your accounts you just compute a sum of every operation to it, again no special case. So your accounts are: Expenses 0 USD Income 0 USD # as expected at beginning of exercise Assets:Apples 0 USD Assets:Cash 9 USD Liabilities:Bank 0 USD Equity:Seed -5 USD Equity:PreviousProfits -4 USD And yet again, the sum of all of that is 0. Personally I like it, not having any special cases. Yes, it may confused an accountant (because they learned the special cases by heart ! Somebody coming with a fresh mind has no reason to be confused, it's all just conventions !) but it's simpler for me and just as consistent.
juped 6y ago
There's a lot wrong with fixing consistencies.
dragonwriter 6y ago
> What's wrong with fixing inconsistencies? There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.) > Established accounting terms are from 500 years ago when people had trouble with subtraction. People still have trouble with substraction compared to addition, especially with large numbers.
Lazare 6y ago
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.