Show HN: Transity – Plain Text Accounting • Hacker News Board

Re: Show HN: Transity – Plain Text Accounting

#131

Post by nucleardog » Wed, Jun 06, 2018, 9:23 PM UTC

TeMPOraL wrote: post #62

stevievee wrote: post #5

"Simple - No more confusing debit / credit / asset / liability mumbo jumbo" It is just "mumbo jumbo" to you because accounting/finance is not your area of expertise.

Somebody should write a proper "accounting for regular people" guide, because I too find those terms confusing - and also completely separated for any experience ever that I had with money. And it only gets worse from there, with "accounts receivable" and "accounts payable". Is that an American thing? I try not to fall into the trap of being proud of my own ignorance; but after many hours of reading introductory acco…

One thing I can suggest is since you're not actually beholden to following any sort of GAAP for your personal book keeping... is it's fine to do whatever works for you. Use your best judgement. Unless you're doing this accounting for the joy of the task in and of itself, then you've got a set of problems you're trying to solve or questions you're trying to answer and following GAAP doesn't necessarily get you any closer to those solutions in any meaningful way.

I'd echo someone else's recommendation to have one place in your hierarchy that has a balance that matches up with each physical account so you can check your work when you've entered all your transactions. Beyond that, you're basically programming a system for processing the math related to your money. You can figure it out.

I'd been muddling my way through for years due to the same inability to find any good "accounting for regular people" before I met my SO who is a CPA. Her response to my accounting methods were basically "It's wrong, but it will work just fine."

Want to allocate the money in an account to some things? Create some subaccounts, move money into them. What kind of account? Asset! Asset all the things! People sending money that's going into your chequeing account to pay future bills? Create a subaccount (you guessed it - asset) and put the money into that. Your chequeing account's balance matches up, that money is separated.

Perfect is the enemy of good.

Re: Show HN: Transity – Plain Text Accounting

#132

Post by avodonosov » Wed, Jun 06, 2018, 11:52 PM UTC

I tried to use Ledger, but it fails to handle multi currency ac ounting properly. Is the Transity well suited for that?

Re: Show HN: Transity – Plain Text Accounting

#133

Post by adrianratnapala » Thu, Jun 07, 2018, 12:04 AM UTC

adrianratnapala wrote: post #27

hosh wrote: post #19

Earlier quoted context omitted.

Some mathematicians had constructed a group (Pacioli Group) to analyze the characteristics of using such a system. One thing a double-entry system can do that a single-entry cannot is to quickly verify the consistency of the transactions. The specific names of "debit", "credit", etc. are jargon. The properties that allow for quick verification works on more complex transactions. I might use a single-entry ledger for…

This is going far beyond my own knowledge. I only use double-entry. Or at least I use a style where everything is a transaction that adds up to zero -- there can be more than two accounts in a transaction. I don't even understand single-entry. [UPDATE: I am now pretty sure there is a serious misunderstanding my paragraph above, but think it is more constructive to note it, than to delete it.] My main objection was to…

Let me explain my update from yesterday so it doesn't just hang there as a useless tease.

My comment assumed that double-entry accounting meant that every transaction adds up to zero. But cgio links to which claims http://www.ellerman.org/the-math-of-double-entry-bookkeeping... that definition is a common misunderstanding.

What cgio means by double-entry is adding up debits and credits as separate unsigned numbers, as opposed to a single signed one. The fact that the numbers only ever increase can help you verify the books.

Indeed I've experienced the pain of signed numbers first hand when keeping accounts with pen-and-paper. I can't remember how exactly it worked, but it was something to do with how if I had monotonically increasing values, I could have put a strict time bound on where a missing entry had to be.

Re: Show HN: Transity – Plain Text Accounting

#134

Post by chris_wot » Thu, Jun 07, 2018, 3:13 AM UTC

kungtotte wrote: post #123

chris_wot wrote: post #108

Earlier quoted context omitted.

Which means you have to take out money from one account and transfer it into another. Which means that you need to understand that you must debit an expense as it decreases the owners equity credit balance, and then you must understand that it causes a credit on your bank account. If you don't have this, then you won't be able to work out where you spent your $X amount of money.

I don't need to understand any of that for simple personal finance. A transaction with a negative amount with a to and from field is all that I need . If I see 15 bucks each month going to "Spotify" I don't have to be a CPA to work out that I spend 15 bucks a month for Spotify...

Which is an expense, and it takes money out of your bank account and into the Spotify expense account.

You have just understood it, intuitively.

Re: Show HN: Transity – Plain Text Accounting

#135

Post by sly010 » Thu, Jun 07, 2018, 4:06 AM UTC

bokstavkjeks wrote: post #125

sly010 wrote: post #106

Earlier quoted context omitted.

> You can't replace what works and what has been done for reliability and confidence since 1400 at least by the masters of trade. I am not sure that is true. Isn't the world full of examples of quite the opposite? Especially because it's 1400 years old an because it was created for pen an paper work. We have computers now. e.g. It used to be that companies have a handful of yearly profit/loss accounts and every year…

>I would risk that most accountant don't know their debits and credits I've worked in accounting and this is just not true. The ledger is stated in debit/credit and all transactions are done in debit/credit. Even if modern accounting software can automate some of it it still requires the accountant to verify the transaction. Hell, most accountants I know even draw up good ol' T-accounts on paper every once in a while…

Plaintext accounting systems (albeit not the one posted) have a model of a ledger transaction that is basically a list of "postings". Each posting is something moving from or moving to an account. In any transaction you can have many postings with negative or positive values, but the total negatives and positives has to balance. Some software restricts you to predefine accounts to be sub accounts of equity, asset or liability but for the most part there are no other restrictions, it's very flexible, you can set up whatever system you want.

E.g. ( from ledger cli documentation )

   2004/09/29  Circuit City
    Assets:Reimbursements:Company XYZ         $100.00
    Liabilities:MasterCard                   $-100.00
    Company XYZ:Expenses:Computer:Software    $100.00
    Company XYZ:Accounts Payable:Your Name   $-100.00

What I genuinely don't understand is how is this not equivalent to:

   2004/09/29  Circuit City                      DEBITS    CREDITS
    Assets:Reimbursements:Company XYZ         $100.00
    Liabilities:MasterCard                              $100.00
    Company XYZ:Expenses:Computer:Software    $100.00
    Company XYZ:Accounts Payable:Your Name              $100.00

My understanding is that as long as you don't use negative numbers the two forms have the same expressiveness.

Please note that I am only challenging the method of encoding, not the rest of accounting. How you set up and manage a chart of accounts and how you take real world transactions and code them into your system IS very important and I very much acknowledge 1400 years of evolution on that front.

This topic genuinely interests me and I have questions. If you don't mind please drop me an email (it's in my profile) I have a few questions.

p.s. Accounting standards vary. I work with startups in the US (little to no standards).

Re: Show HN: Transity – Plain Text Accounting

#136

Post by bokstavkjeks » Thu, Jun 07, 2018, 7:27 AM UTC

sly010 wrote: post #135

bokstavkjeks wrote: post #125

Earlier quoted context omitted.

>I would risk that most accountant don't know their debits and credits I've worked in accounting and this is just not true. The ledger is stated in debit/credit and all transactions are done in debit/credit. Even if modern accounting software can automate some of it it still requires the accountant to verify the transaction. Hell, most accountants I know even draw up good ol' T-accounts on paper every once in a while…

Plaintext accounting systems (albeit not the one posted) have a model of a ledger transaction that is basically a list of "postings". Each posting is something moving from or moving to an account. In any transaction you can have many postings with negative or positive values, but the total negatives and positives has to balance. Some software restricts you to predefine accounts to be sub accounts of equity, asset or…

Oh, I get what you mean now. A system like you show is essentially debits/credits, yes. For a lot of the smaller accounting systems, they actually print the GL in the format you show where negative numbers are equivalent to credit and positive to debit. As long as you use the same accounts it should be equivalent.

>p.s. Accounting standards vary. I work with startups in the US (little to no standards).

That's true. Here in Norway, all financial statements are publicly available regardless of company size, so they have to adhere to NGAAP (or IFRS if they're big enough).

Re: Show HN: Transity – Plain Text Accounting

#137

Post by hjek » Thu, Jun 07, 2018, 11:37 AM UTC

nucleardog wrote: post #129

dec0dedab0de wrote: post #99

Earlier quoted context omitted.

Worse! Intuit does all my TAX RETURNS. Tax returns are generally a lot less sensitive than bank/credit card statements. Plus they have your plain text credentials too, so if they get hacked someone could transfer money out of your bank account.

And my understanding is generally that your bank will disclaim liability for any "fraud" that occurs due to you intentionally and willingly sharing your credentials.

Exactly!

Re: Show HN: Transity – Plain Text Accounting

#138

Post by fiatjaf » Thu, Jun 07, 2018, 2:58 PM UTC

This is amazing. Thank you for making this. I agree: account-based accounting is not the perfect form, transactions can be much clearer. People here are suffering from status quo bias.

Re: Show HN: Transity – Plain Text Accounting

#139

Post by Jtsummers » Thu, Jun 07, 2018, 6:31 PM UTC

fiatjaf wrote: post #138

This is amazing. Thank you for making this. I agree: account-based accounting is not the perfect form, transactions can be much clearer. People here are suffering from status quo bias.

To be clear, most accounting tools still have you recording transactions in a journal (including ledger-cli, the one they were specifically comparing Transity to). Money moves between accounts, but you record it as transactions showing the from and to information.

The accounts are the things you want to review after you record a transaction, to ensure balances are correct (validate your checking account with what the bank says it should be) and to understand your financial situation (current net worth and cash flow).

Re: Show HN: Transity – Plain Text Accounting

#140

Post by hollerith » Sat, Jun 09, 2018, 3:44 AM UTC

bokstavkjeks wrote: post #82

adius wrote: post #73

Earlier quoted context omitted.

1. Feel free to back up your claim, otherwise I'm not sure how you come to that conclusion 2. It has a user interface … just not graphical 3. Well, I guess we just have different opinions on where forward is 4. I've been working with GnuCash, Ledger and Hledger and I've written several scripts to extend them (e.g. to support timestamps and not just dates, which shouldn't be asked too much for an accounting tool ), bu…

I can only answer 1 from the perspective of a non-US, very junior, auditor with little experience, but I'll try. I don't see how it handles complex transactions very well. A simple example would be VAT. Assume a 25% VAT (which is standard here). If you sell a product for $1000 cash in hand the relevant transaction would be: C: Revenues $800 C: VAT payable $200 D: Cash $1000 An even better example would be payroll whi…

A single transaction can contain multiple "transfers", so this next should handle your example. (I don't know the name of any organizations that collect VAT, so I used "vat-authority".)

    transfers:
      - from: robert-q-customer
        to: john:cash
        amount: 1000 usd
      - from: john:payable
        to: vat-authority
        amount: 200 usd