
Show HN: Transity – Plain Text Accounting - adius
https://www.feram.io/blog/2018-06-05_transity_the_future_of_plain_text_accounting/
======
madhadron
There are several things wrong here:

1\. The author doesn't understand bookkeeping. 2\. The author doesn't somehow
believes that emulated teletypes are a good substrate for building user
interfaces. 3\. The author has spent significant time writing a bookkeeping
tool for his business instead of doing something that will move the business
forward.

If you're thinking about writing an open source accounting program, spend time
mastering GnuCash first. If you feel like you can't do what you need with that
and cannot possibly extend it in the way that you need, then write your own.

~~~
adius
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 ), but it was always a nasty hack and so
I wrote my own. Just like you said.

~~~
bokstavkjeks
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 which can involve 5-15 different
ledger accounts for a single employee.

The next bit can probably be solved through the notes part, but how would you
attach invoices and documentation with Transity?

How do you do accounts payable or receivable with it? In addition to the
balance sheet sum, the accounts pay/rec should also show the balance for each
individual customer and supplier.

~~~
hollerith
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

------
lquist
_CLI tools also have the advantage that their developers don 't have to waste
their time building and maintaining a useless GUI, but can instead use the
time to improve the tool itself_

Maybe it's just me, but I stopped reading here b/c this language struck me as
unnecessarily antagonistic. Just some feedback.

~~~
jeremymcanally
Well, it's also non-sensical. A CLI "interface" needs a lot of thought and
work behind it, too, unless you want to end up loathed by your users as
something like git is.

~~~
mikeyjk
I don't think it is fair to say that git users loathe it overall. I enjoy
using git, is this not a common experience?

~~~
madhadron
I regard the command line as a last resort if I can't do something in
SourceTree. After spending time with a quality source control client, any
command line interface feels like wading through quicksand.

~~~
grimgrin
This is likely an insult to git but it’s really similar to vim in that regard.
After using ST2 or TextMate for so long, many people aren’t interested in
learning (remembering?) how to use vim’s modals/commands.

A lot of people probably did start with SourceTree or a git plug-in in Visual
Studio etc

My git workflow is very much tied to aliases. Customization is a hot thing for
many people

(but really you should probably read the fugitive.vim docs in their entirety)

~~~
madhadron
I go the other way. After twenty years of unix, the first few without X11, I
have become very clear on what is cruft and history and what is actually
making my life better.

SourceTree didn't exist when I started using git, but it makes the day to day
operations of source control much easier and more precise than the command
line. I spent enough years in a command line debugger that I am thrilled to
have good debugger integration in my IDE.

It's easy to get into a machismo thing where you regard the shell and a
teletype emulator as the "natural" interface to the computer, but it's really
an incredibly abstracted interface already, and if you spend some time
thinking about what you're actually doing, there's usually a GUI or library
for an actual language that is what you really want. It just may not exist.

~~~
xorcist
> It's easy to get into a machismo thing where you regard the shell

Unspoken presumptions about how the CLI is harder to use and GUIs somehow more
natural (because graphics) is usually a sign of not understanding neither.

I spend most of my time in my editor and at the command line because it's
_easier_ to use. I don't have to learn thousands of little clickable widgets
just to get the job done (which tend to change with every version of the
tool).

That said, there are good and bad user interfaces with CLI tools, just like
with GUI tools.

What's more interesting however, is how tools shape the way you think. CLI
tools tend to feel like processing data, whereas with GUI tools you feel like
maneouvering a large machine. The former tends to lead to fewer mistakes at
scale.

------
csomar
I'm not sure why the OP is getting s%%t from the community. He built a simple
application, probably out of love of software development. It is not complete
or perfect. It is also probably not the best use of his business time. But we
do waste time on other stuff too.

This CLI app could be useful to me for a subset of accounting I do. Yes, it
won't be able to track VAT accounts. It won't amortize my expenses. But if I
needed that for a critical business I'm running, I'd not use a hobby project.

The CLI is useful. Double Entry bookkeeping is useful but as things scale it
gets _very_ confusing even for the best of accountants. This program is simple
and can give you a solution if you are looking for very simple bookkeeping.

~~~
eXpl0it3r
You can't expect to just get happy feedback, especially from a rather critical
thinking community such as HN and when you then write dismissively about
stuff, you shouldn't be surprised when it's held against you.

> CLI tools also have the advantage that their developers don't have to waste
> their time building and maintaining a useless GUI, but can instead use the
> time to improve the tool itself.

It's fine if you like CLI apps and find it painful maintaining a GUI
application, but it's not helpful to write it as a general statement. CLI
"GUI" tools also require quite a bit of work and I'd claim that an experienced
GUI developer will spend less time on creating a GUI app, than the author had
spent to get their CLI "GUI" app display as wanted.

> It made sense in former times as this layout makes it easier to add up the
> amounts by hand, but not in times of computers.

Double booking keeping isn't just a relic from the past. There are big
benefits to it and just because it doesn't fit into simple account keeping,
doesn't mean we can just pretend that it's useless, because computers!

In summary you simply should not write your opinions as if they were facts.
You can do so if you want, but then you need to be prepared to get some
critical feedback.

~~~
Bromskloss
What are the benefits of double-entry bookkeeping?

~~~
maxerickson
It simplifies reporting and error checking.

Because you are explicitly tracking what you receive, what you have and what
you spend, the accounting system can check that the numbers line up.

~~~
kpil
There are also a whole system of account categories and mandated systems for
reporting.

Nice intro here : [https://www.accountingcoach.com/debits-and-
credits/explanati...](https://www.accountingcoach.com/debits-and-
credits/explanation/1)

------
stevievee
_" 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.

~~~
TeMPOraL
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 accounting articles linked by various
accounting software sites, I still don't get any of it.

I'd love a cheat-sheet or plain-English example of how to model the following
with GAAP: I'm an individual, I have couple bank accounts, get a salary and
occasional invoice, I pay for various stuff, I sometimes use cash. I do not
own shares in companies. I want to do budgeting, including some sort of
"envelopes" or "virtual accounts" so that I can earmark some money for
particular use. I tried to build something like that with Ledger CLI several
times now, but I always bounce off the confusion about terminology, and not
knowing what goes into "Equity", what into "Liabilities", etc., and why does
everything expect me to have "accounts payable" and "receivable"...

Knowing what's the proper, idiomatic representation of such financial system
would go a long way towards me understanding what the hell all those terms
mean.

~~~
maxerickson
You'd have 5 main accounts there.

    
    
      Income:Job
      Asset:Bank1
      Asset:Bank2
      Expenses:whatever
      Liabilities:whatever
    

And then each transaction moves the money from one account to another.
Income->Asset, Asset->Expenses, etc. Value moves into the system from income,
Expenses are (more or less) transactions where value moves out of the
accounting system. You track your salary but probably not the hours you work
and that you spent $50 on food (Asset->Expenses:Food) but not the food.

Equity is mostly just the offsetting account for balances that aren't tracked
more specifically. So beginning balances are booked against equity instead of
coming from some source of income.

Liabilities are amounts that you owe. When you buy something on credit, you
are receiving the thing, so you book a transaction (booking an expense against
the liability). Then later you book another transaction to pay for the thing
(booking a decrease in assets against the liability).

Accounts receivable and accounts payable come up because businesses care about
how (and when) they recognize payments and non payments and so on. For
personal accounting just put money you owe as a liability and money you are
owed as an asset.

~~~
gglitch
Thanks for this outline. I've been a happy user of Ledger for several months
now, but have been stymied about how to model a scenario in which several
family members pay me in advance for a bill we collectively owe that's payable
in the future, and in which their payments end up in my checking account. I
now see that I should have set up the future sum payment as a local, temporary
liability, each family member's deposit payments to me as a local, temporary
asset other than my checking account (making my local checking balance diverge
from that reported by my bank -- but to my benefit!), then the future sum
payment as a transfer from the local temporary asset to the local temporary
liability, and bringing all accounts to their correct balances and realigning
them with my bank.

So, again, thanks a lot for that last line, which helped me out.

~~~
maxerickson
You could use virtual accounts for that, posting the received funds to your
checking account and also to a virtual account that you eventually balance
with the purchase (which would also have both real and virtual postings).

~~~
smichael
It's easy to confuse "virtual accounts" (imaginary accounts or subaccounts)
with "virtual postings" (unbalanced postings), but remember these are
different things with different uses. You can post to either kind of account
with either kind of posting.

------
yegle
Also worth check out
[http://plaintextaccounting.org/](http://plaintextaccounting.org/)

Personally I don't like the yaml-like syntax. I use beancount myself, and with
fava ([https://github.com/beancount/fava](https://github.com/beancount/fava))
as the UI.

~~~
erikb
This is what I was always looking for. Also loving the approach of having the
UI separated.

I also don't like the yaml format for the simple reason that not all necessary
information is in one line. No idea why a transaction can't be written into
one line.

Also for people who love plain text, one can checkout the banking format
(comes from German banks, so most info is only available in German but here's
a summary):
[https://en.wikipedia.org/wiki/FinTS](https://en.wikipedia.org/wiki/FinTS)

Gnucash should also support it, but with my bank it always fails. It's
certainly not a format I would use for local storage, but it's a good source
of structure and edge cases when one thinks about developing or modifying an
existing format.

------
marcrosoft
I think throwing out the terms credit/debit is a mistake. Everyone operates on
GAAP and we shouldn't deviate.

~~~
hosh
Not only that, there are some really useful properties of the double entry
system: [https://arxiv.org/abs/1407.1898](https://arxiv.org/abs/1407.1898)

That's defining a group called the Pacioli Group. One thing that is relatively
easy to do with this group is to quickly verify consistency in the
transactions. That is something you lose with a single-entry system.

~~~
adius
Transity isn't a single entry system. By using transactions to model financial
flows it implicitly enforces that the amount is credited to the "from" account
and debited to the "to" account. Therefore it's basically double entry by
design.

I'm really interested if someone can show me a use case where this system is
less powerful / safe than a classic double entry system.

~~~
Mister_Snuggles
The problem is that this breaks down when faced with problems more complex
than simple examples.

What about cases where there are multiple "to" accounts? For example, you
might go to Best Buy and purchase a computer and a video game. In this case,
the "to" would be split between two separate accounts (assuming you do your
books this way).

This is a contrived example, but in the business world this type of
transaction is very common. An example involving selling a taxable service
(think of a haircut) might look like:

    
    
        Debit Cash    
        Credit Service Income
        Credit Sales Tax Payable (this is remitted to the government)

~~~
captainmuon
I don't know if it is implemented in this tool, but there is no reason that
you could not have multiple "to" fields in a transaction.

In double bookkeeping, you must have balanced books, but you do not note which
bookings occur together. The transactional scheme seems strictly superior
because you automatically know which debits and credits or losses and gains go
together. You automatically have balanced books. I think you sould be able to
even generate double bookkeeping from transactional bookkeeping automatically.

~~~
Mister_Snuggles
The data model is somewhat secondary to the accounting model, however the data
model has to be rich enough to support the accounting model.

In the traditional accounting model you have two major things:

1\. The Ledger, which is the current state of your accounts. Generally each
account is a page (or more) in the ledger which lists the debits and credits
for that account.

2\. The Journal Entries, which are the source documents that feed into the
Ledger. Each Journal Entry groups all of the related debits and credits into
one balanced entry. Since each Journal Entry is balanced, the Ledger ends up
balanced.

Some software packages follow the accounting model very closely in their data
model, others make some different choices. Some software, usually professional
software, has a Ledger of accounts and uses Journal Entries to record activity
in those accounts and requires that you run a process to post the journal
entries. Professional software typically has modules for sales, purchasing,
etc, that create the Journal Entries for you. Other software "fakes" some or
all of the Ledger (typically the Asset/Liability accounts are in the Ledger
and the Income/Expense accounts are "fake"), this type of software is usually
aimed at home users. In both cases, all entries are done as a balanced journal
entry with multiple lines.

Back to the accounting model:

A sale involving VAT, for example, might look like this in Journal Entry form:

    
    
        2018-06-06   Sold a haircut and shampoo to Bob
           Cash                   DR $21.00
             Haircut Sales                  CR $10.00
             Product Sales                  CR $10.00
             VAT Collected                  CR  $1.00
           Cost of Goods Sold     DR $8.00
             Inventory On Hand              CR $8.00
    

The first line is basically the header and it groups all of the entries
related to that one sale. In this case, a customer paid cash for a product and
a service. Because they bought a product, we also reduced the value of the
inventory that we have on hand. And, because I'm in Canada, both of these
items are eligible for VAT, so I had to record how much VAT I collected on
behalf of the Government - I'll need these records later when it's time to pay
up.

You can't really support that kind of entry if your data model has only one
From field and only one To field - you've be creating five entries that aren't
tied together. To support this, your data model needs to let you create one
entry with multiple From and To fields. Once you get to this point, you're at
the journal entry model that real accounting software uses.

~~~
captainmuon
Thanks for your very clear answer!

My point was basically, most or all of the interesting information is stored
in the journal. You could hide the legder from a non-technical user, or even
generate it on-the-fly. I think this is the distinguishing idea in OP's
program. That the data model has only one "from" and one "to" field is
incidential and could be fixed.

------
sushisource
No judgement, but can someone explain to me the use case for this sort of
thing? I'd imagine for anything other than the simplest stuff, you're going to
start using something a bit more powerful, and for the simple stuff - who with
the skills and knowledge of this type of tool really needs to do small time
pocketbook budgeting?

~~~
hannibalhorn
I can't speak to Transity, but I use HLedger for my entity (nothing fancy,
just a single member LLC.)

I can keep my ledger in git, I don't need to pay for or even learn to use
QuickBooks, I can quickly write a script to import data from basically
anywhere, and I can use all the standard tools in my toolbox (grep, diff,
python) to visualize and work with the data.

I'm sure mainstream accounting programs add value as the organization grows,
but I spent a few minutes playing with Quickbooks and I was ready to just use
Excel when I discovered the whole plain text accounting thing. And it's been
working well for me.

~~~
ams6110
I used ledger to keep the books as treasurer for a small non-profit for a few
years. It worked really well for me but the problem came with handing it off
to the next person or thinking about involving an accountant to do the annual
reports. Very few are going to be able to deal with a text file of journal
entries. QuickBooks is the standard for all small business accounting, like it
or not.

~~~
_emacsomancer_
I've never actually used it (or Quickbooks), but does ledger have any way of
exporting something that could imported by Quickbooks?

> Very few are going to be able to deal with a text file of journal entries.
> QuickBooks is the standard for all small business accounting, like it or
> not.

I always find this lowest-common-denominator as de facto standard depressing.
It's how we end up with word processing documents as a standard for exchange
and collaboration (and word processors are horrible environments to create
in).

~~~
gglitch
I have recently learned a technical term for the scenario you're describing:
[https://en.wikipedia.org/wiki/Nash_equilibrium](https://en.wikipedia.org/wiki/Nash_equilibrium)

"Informally, a strategy profile is a Nash equilibrium if no player can do
better by unilaterally changing his or her strategy. To see what this means,
imagine that each player is told the strategies of the others. Suppose then
that each player asks themselves: 'Knowing the strategies of the other
players, and treating the strategies of the other players as set in stone, can
I benefit by changing my strategy?'

If any player could answer "Yes", then that set of strategies is not a Nash
equilibrium. But if every player prefers not to switch (or is indifferent
between switching and not) then the strategy profile is a Nash equilibrium.
Thus, each strategy in a Nash equilibrium is a best response to all other
strategies in that equilibrium.

The Nash equilibrium may sometimes appear non-rational in a third-person
perspective. This is because a Nash equilibrium is not necessarily Pareto
optimal."

~~~
_emacsomancer_
Thanks for this. I've been pondering whether the word-processing/QuickBooks
strategy is a Nash equilibrium (at least from my admittedly shallow
understanding of the term). So lots of people produce documents using Word or
LibreOffice - so that's their strategy. Some group of people produce documents
using LaTeX. I'm not sure that I see how this is a Nash equilibrium. The LaTeX
people in some situations might gain an advantage by switching to the Word
strategy for better interoperability. The Word people (in almost all
situations) could gain an advantage by switching to the LaTeX strategy for the
sake of using a sane paradigm.

Rather the word-processing situation (and likely the QuickBooks situation,
though I know much less about accounting software) seems to be something like
maximizing the lowering of perceived entry cost (in terms of learning to use
the software) over all other factors (with resulting increasing in complexity
for more advanced functions and poor flexibility).

------
toomim
Hm, the article asserts that Ledger doesn't have tags:

> Sub accounts vs. Tags > But what if the expense is part of another category
> as well, like expenses for your vacation? Well, you'd be at a loss. There is
> no good way to model this in ledger-likes without getting really hacky.

But that's not true. Ledger has tags. You specify a tag with:

    
    
        :tagname:
    

For instance:

    
    
        6-5-2018 Gave food to Bart Simpson, while on vacation
            Expenses:bart     1 orange    ; :vacation:
            Assets:food

~~~
_emacsomancer_
And Ledger has an [Emacs mode]([https://github.com/ledger/ledger-
mode](https://github.com/ledger/ledger-mode)).

------
athrun
I can only speak for me, but modeling financial flows in terms of transactions
and not accounts is much more intuitive than the classical alternative.

I'm a long time Buxfer user, which also works like this. It's not that I don't
understand double entry bookkeeping, I've used GNUCash for a long time before
moving away. It is indeed _very_ powerful and flexible, but it always was too
much of a chore to maintain and next to impossible to get other family members
to contribute.

I'm not sure this "transaction model" would be appropriate for business
accounting, but IMHO it works very well for Personal Finance.

~~~
kungtotte
I played around with the buxfer demo a bit, and one thing wasn't really clear
to me: is it possible to schedule fixed payments? There was some kind of
reminder system, but does it automatically add the transaction or will I have
to log in to manually add those transactions?

Simple recurring transactions is like the one feature I really need from a
tool like this.

------
Uplink
THANK YOU!

I had the ideas used in this project in my head, but I've been putting off the
work forever now.

I LOVE YOU FOREVER for using transactions as the central operation rather than
double entry accounting, and I love you even more for adding the ability to
tag transactions. I can not put off work for a web interface instead, which is
a lot less work to put off :)

I haven't tried it yet, but it's now high on my list for when I get home from
work.

------
joyinsky
Basically the problem here is that the author didn't care even a little to
understand why accounting is done with a double entry system.

Basically what he was trying to do here was a expense and income administrator
with tags. That it's just a part of what bookkeeping and accounting is.

Nice try. But you can't replace what works and what has been done for
reliability and confidence since 1400 at least by the masters of trade.

~~~
sly010
> 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 they "close the books" by transferring all balance to
first profit/loss accounts then to equity. The financial year then starts with
0 profit an 0 loss. Afaik nobody does this anymore. Today you just keep all
accounts running (don't "close them) and you generate repots by selecting a
date range and let the computer calculate profits and losses for that range.

Besides, most commercial software already hides debit and credit from you. I
would risk that most accountant don't know their debits and credits, it's just
one of those things you learn at accounting school before you start working in
the industry.

I agree one should not write an accounting system without understanding the
full details and history of the domain, but I disagree that 1400 year history
proves anything. In fact even after reading through the Pacioli Group article
I still don't see the advantages. It's only advantage is that it makes it
harder to make a mistake _on paper_.

~~~
bokstavkjeks
>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 to understand the larger and more
complex transactions. I'd think you'd be hard pressed to find an accountant
that _doesn 't_ know their debit and credit. An accountant that doesn't know
their debits and credits is like a software developer that only knows Scratch.

Most commercial software doesn't hide debit/credit, and if it does, you should
run away as fast as you can. How do you produce the required documentation for
your auditor if the software hides debit and credit?

EDIT: To continue a bit.

>It used to be that companies have a handful of yearly profit/loss accounts
and every year they "close the books" by transferring all balance to first
profit/loss accounts then to equity. The financial year then starts with 0
profit an 0 loss. Afaik nobody does this anymore. Today you just keep all
accounts running (don't "close them) and you generate repots by selecting a
date range and let the computer calculate profits and losses for that range.

All companies still do this. It's part of the closing entries at the end of
the FY. It's not just that the FY starts with 0 profit and 0 loss, but that
that is the entire point of the financial statements. A company has three
financial statements: the balance sheet, the income statement, and the cash
flow statement. For this example, only the income statement and the balance
sheet are relevant.

The balance sheet can be seen as a snapshot of a company. It shows what the
company owns (assets) divided into short- and long-term assets, as well as how
they paid for it (liabilities and equity). The concepts that it balances
assets + liabilities + equity = 0 (debit is positive and credit is negative)
is the foundation for the balance. The income statement shows a company's
results over a given time frame, usually a year. You can consider the balance
sheet permanent and the income statement temporary. Consider a company with
the following results per 31.12:

    
    
        assets: $10.000 (d)
        liabilities: $7 500 (c)    
        equity: $500 (c)
        net revenue: $5.000 (c)
        costs: $3.000 (d)
        profit/loss: $2.000 (c)
    

It's clear that the entire ledger balances per 31.12 as the sum of debit is
equal to the sum of credit accounts. We also see that the company owns $10.000
worth of assets which is mainly paid for through debt, and that they have a
profit of $2.000 since the profit is credit. As the income statement is
supposed to reflect the performance over a given period and the balance is
supposed to balance, the solution is to transfer the profit to equity to
record the profit in the (permanent) balance sheet and reset the (temporary)
income statement so that they can record their next fiscal year. To do this
they record debit profit/loss $2.000 and credit equity $2.000.

It's also not just a matter of recording the entry, which is fairly easy on
modern accounting systems, but as it involves the distribution of profit (and
touching equity for that matter) it typically needs the signature of the
board.

I was an external auditor and when we did the closing entries for our clients
we would require the CEO's or chairman's signature on a printed version of the
final entries.

> I agree one should not write an accounting system without understanding the
> full details and history of the domain, but I disagree that 1400 year
> history proves anything.

Accounting isn't just a field that has had 1400 years to develop methods to
solve the problem in the domain. It's a field that has had 1400 years to build
regulations and exceptions. It's also a field which requires a lot of
individual judgement. Take, for example, VAT. Here in Norway, the actual VAT
law text is about 10% of the text in the handy _VAT exceptions and judgement
calls_ book we had in the office.

Writing accounting software that is actually useful for an extended period of
time is incredibly difficult due to how accounting laws change all the time.
Double the effort if you want the software to make tax returns as well. The
company that developed the software we used had personal relations with almost
all of their customers and would ask for feedback all the time. They probably
shipped three versions during the busy season I was there.

I'm admittedly a fan of double-entry bookkeeping as it's conceptually easy
(once learned) to map out complex transactions on a piece of paper.

99% of accounting is bog-standard, but that last 1% is complex as all hell. It
can't really be ignored either as it can end up costing you or your client a
significant amount of money, or even jail time.

I can't really state specifics, but I had a client whose bookkeeper failed to
stay up to date on a very specific subset of a rather specific law which ended
up costing the client millions in extra taxes. To put it in perspective, they
suddenly had back-taxes for more than their company made in a year in
revenues. This change was so specific that there wouldn't have been any
consequences if they had done it a few weeks earlier. I'm rambling a bit here,
but the point is, if you want to write a new type of accounting software, be
__really __sure you know what you 're doing.

~~~
sly010
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).

~~~
bokstavkjeks
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).

------
billfruit
After trying to use GNU cash for some time, I got the feeling that a personal
accounting app needs to be a web based service, to enable it to be used while
on the move/travelling, because I found myself building up a huge backlog of
entries to be made in to the system in these situations. After about a month
of use, I gave up, since the overhead of jotting down transactions and later
entering into the system. I doubt GnuCash or any accounting system like that
could possibly have integrated apis for pulling in transaction details from
every bank, in every country of the world, atleast presently.

Now a days I use a smartphone app called walnut, which mines your SMSes for
transaction data and builds up a ledger by itself, without the need for
interfacing with banks directly, because in my country atleast all banks
provide SMS trails for transactions.

~~~
jessedhillon
I work for Plaid. You can sign up and get a dev token that has sufficient
permission to access your own bank accounts. Then you can download your
transactions and format them for GNU Ledger or whichever other format you
prefer.

~~~
billfruit
Does it work for any bank in any country?

~~~
jessedhillon
Sorry, we only cover US and Canada right now.

------
airstrike
+1 for YAML. Thanks for not using JSON.

Now I want to see someone take, say, Tiffany & Co's latest 10-Q⁽¹⁾ and run it
through this.

__________

¹
[https://www.bamsec.com/filing/9824618000198?cik=98246](https://www.bamsec.com/filing/9824618000198?cik=98246)

~~~
ericsoderstrom
Why do you prefer YAML to JSON in this context?

------
perfunctory
I have a question for people who understand accounting. Isn't the reason for
debit/credit split the fact that negative numbers were not yet
invented/widely-known at the time? Would accounting look different if it was
designed today?

------
jgalvez
If you want something way simpler,
[http://galvez.github.io/plainbudget](http://galvez.github.io/plainbudget) :)

------
Immortalin
Pivot and build an accounting API!

If you are interested, drop me an email, I would love to discuss more about
fintech (I run a fintech startup)

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

~~~
Jtsummers
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).

------
JustSomeNobody
> If this looks (and sounds) confusing or too complicated, you're not alone!
> It made sense in former times as this layout makes it easier to add up the
> amounts by hand, but not in times of computers.

Math predates computers, let's just stop using that too!

Double entry is _not_ that complicated and computers or not, it just works.

------
Hello71
everyone is complaining about the accounting here, but I just want to say that
100 FONT WEIGHT AT #666 ON WHITE IS NOT AN ACCEPTABLE CONTRAST RATIO FOR BODY
TEXT, especially if you do not provide your own font. even on a 1920x1080 IPS
display with 1.1x scaling, using my preferred font, Noto Sans, font-weight 100
is extremely difficult to read for long stretches. DejaVu Sans's 100 is
slightly thicker, but is still not acceptable for body text at that color.

------
Jtsummers
So I like the idea of using YAML versus ledger's format (very slightly, I'm
used to ledger's format so it's not a pain point, but YAML offers some ways to
make things a bit easier especially for newer folks). However, I could see a
fairly trivial mapping between YAML and Ledger being developed by quicker
programmers than I in less than a weekend (there's already a way to spit out
s-expressions from ledger).

hledger makes some strong assumptions (IIRC) about your accounts being in
assets, liabilities, income, equity, expenses. But I may be thinking of
beancount for that. If I'm remembering correctly, hledger will let you do
whatever you want, but some of their built in reports (like balance sheet)
assume liabilities and assets as top-level accounts.

However, ledger allows you to do things like:

    
    
      personal:expenses:...
      personal:assets:...
      club:expenses:...
      wife:expenses:...
    

And you can specify what the prefix should be for all transactions in a region
like:

    
    
      apply account personal
      2018/06/05 Gym
          Expenses:Gym       54.00 USD
          Assets:Checking
      end apply account
    

So everything in there is now in my personal set of accounts, eliding the
prefix (which can become cumbersome). If you use this† as an example, putting
things into separate code blocks via org-mode makes it trivial to conduct
accounting for multiple entities.

Query: Does Transity allow for money to come from or go to multiple places?
Suppose I'm traveling for work and need a more detailed accounting of my
spending (they don't reimburse alcohol, perhaps):

    
    
      2018/06/05 Place with good cocktails    ; 50 USD is on me
          Work:Expenses:Travel:Food        20.00 USD
          Work:Expenses:Travel:Drinks      50.00 USD
          Liabilities:Work:CC
    

(with a note that I have to cover that 50 USD when paying off the card next
month). I do this sort of thing just on regular shopping. I may spend a bunch
of money at the store that's gifts for my girlfriend along with clothes for
me. I like to know how much I've spent so I'll split it (this is more a
personal curiosity thing, along with trying to stick to a budget).

I don't want to have to enter a _from_ / _to_ pair that's redundant (repeating
the same _from_ ) for things I split like this.

Additionally, there's no need for this "perspective" aspect. If I move money
to an account, its balance goes up. If I move money from it it goes down. If I
am managing my girlfriend's accounts in ledger (or she is, but it's pushed
into a common household file):

    
    
      2018/06/05 GF       ; lunch last week
          Jared:Assets:Cash         10.00 USD
          GF:Assets:Cash
    

In the report hers looks like it went down, mine like it went up. There's no
need for me (if I'm managing _multiple_ entities) to bother treating that 10
USD like it came from my income account. It _is_ income, but it _came_ from
the GF's cash account. The income account is really only needed when you _don
't_ control or track the accounts money comes from. Your job, a gift from an
uncle, lottery winnings, etc.

Same thing with a business. If I own my own LLC and "pay" myself a salary out
of it (I'm assuming I also pay out my health insurance or something in this, I
don't know, I don't do payroll), let's say:

    
    
      2018/06/05 Paycheck
          Jared:Assets:Checking          2000.00 USD
          Jared:Expenses:HealthInsurance  100.00 USD
          JSLCC:Expenses:PayrollStuffs    200.00 USD
          JSLLC:Assets:Checking
    

In all the reports, everything _looks_ right. It's done, no need to worry
about perspectives.

† [https://orgmode.org/worg/org-tutorials/weaving-a-
budget.html](https://orgmode.org/worg/org-tutorials/weaving-a-budget.html)

~~~
smichael
That's correct about hledger: a few reports make assumptions about the top
level account names. Until the dev-droids make this customisable, account
aliases can be a workaround.

~~~
Jtsummers
Thanks for hledger. I haven't explored its capabilities fully, but I have it
running on my laptop at all times (a window in my tmux config displays various
reports on my accounts like current balance, uncleared balance, uncleared
transactions, etc.). I find it helps me to be mindful of my money if it's only
a couple keypresses away.

~~~
smichael
Same here! I keep live reports in a iterm2 hotkey window.

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

------
qengho
This is great!

