Show HN: Transity – Plain Text Accounting(feram.io)
feram.io
Show HN: Transity – Plain Text Accounting
https://www.feram.io/blog/2018-06-05_transity_the_future_of_plain_text_accounting/
140 comments
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.
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.
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.
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> No more confusing debit / credit / asset / liability mumbo jumbo
How is separating what you have (assets/liabilities) from your revenues/expenses confusing? It's basic tools to get a view of the profitability vs the Balance sheet (what the company owns) vs the cash flow.
The idea of looking at it in terms of transaction is interesting, I recommend looking at https://martin.kleppmann.com/2011/03/07/accounting-for-compu... for a good take on this idea.
Edit: typo
How is separating what you have (assets/liabilities) from your revenues/expenses confusing? It's basic tools to get a view of the profitability vs the Balance sheet (what the company owns) vs the cash flow.
The idea of looking at it in terms of transaction is interesting, I recommend looking at https://martin.kleppmann.com/2011/03/07/accounting-for-compu... for a good take on this idea.
Edit: typo
this just seems way more confusing to me than debits and credits.
Hey madhadron, you sound like you understand bookkeeping. So I have a quick question. After using Mint (from Intuit) I have everything balanced & tagged and 99% automated. I have reports, ways to export, daily/monthly/yearly totals, breakdowns by types, handle liabilities & debts, i can project net, see assets over time, etc etc. Why wouldn't a business just use mint? After watching vidoes on GnuCash like you recommend - it is like watching someone make Mint by hand. When people out there get a check (income), do they open GnuCash and start typing stuff? Really?? Mint on the otherhand, detects the income by scanning all accounts, automatically categorizes it, etc etc.
GnuCash - I could see mistakes everywhere. I don't see how this is much different than what an accountant would do in 1740 england. Why not have it all automated -- with computers??
https://www.youtube.com/watch?v=aqAaScYVeRQ
GnuCash - I could see mistakes everywhere. I don't see how this is much different than what an accountant would do in 1740 england. Why not have it all automated -- with computers??
https://www.youtube.com/watch?v=aqAaScYVeRQ
The way this is formulated it looks like an automated response from an advertisement bot.
Also you know that Mint is a proprietary company which keeps and uses your data as it pleases, right? That's a huge difference to any open source tool which allows you to keep your company's data inside your company. If it uses a good file format you can also automate everything if desired.
Second, Mint sadly is not supported in many countries. If you are in the US, fine. But if you are not, e.g. your corp has a shop in Germany, then you simply can't use it at all.
I think the basic idea though is the difference between the "pay someone else to solve your problems" vs "solve problems yourself" approaches/mindsets. Each of them has their clear advantages and disadvantages and I hope we don't have to reiterate them here.
Also you know that Mint is a proprietary company which keeps and uses your data as it pleases, right? That's a huge difference to any open source tool which allows you to keep your company's data inside your company. If it uses a good file format you can also automate everything if desired.
Second, Mint sadly is not supported in many countries. If you are in the US, fine. But if you are not, e.g. your corp has a shop in Germany, then you simply can't use it at all.
I think the basic idea though is the difference between the "pay someone else to solve your problems" vs "solve problems yourself" approaches/mindsets. Each of them has their clear advantages and disadvantages and I hope we don't have to reiterate them here.
"The way this is formulated it looks like an automated response from an advertisement bot."
Yes. That is what a happy user sounds like.
Yes. That is what a happy user sounds like.
Intuit has a history of squeezing their users:
https://web.archive.org/web/20080321021644/http://www.infowo...
https://www.cnet.com/news/intuit-products-phone-home-more-of...
Also, your company's accounting information can be sensitive, and hence you may not want to share that information with Intuit (and whoever they choose to share/sell it to).
> Mint on the otherhand, detects the income by scanning all accounts, automatically categorizes it, etc etc.
Does this mean that you literally hand over your online account log in details to Intuit? Or how is this "scanning" done?
> GnuCash - I could see mistakes everywhere. I don't see how this is much different than what an accountant would do in 1740 england. Why not have it all automated -- with computers??
What kind of mistakes were you noticing? (in the Youtube video below, I assume?)
https://web.archive.org/web/20080321021644/http://www.infowo...
https://www.cnet.com/news/intuit-products-phone-home-more-of...
Also, your company's accounting information can be sensitive, and hence you may not want to share that information with Intuit (and whoever they choose to share/sell it to).
> Mint on the otherhand, detects the income by scanning all accounts, automatically categorizes it, etc etc.
Does this mean that you literally hand over your online account log in details to Intuit? Or how is this "scanning" done?
> GnuCash - I could see mistakes everywhere. I don't see how this is much different than what an accountant would do in 1740 england. Why not have it all automated -- with computers??
What kind of mistakes were you noticing? (in the Youtube video below, I assume?)
"Does this mean that you literally hand over your online account log in details to Intuit? Or how is this "scanning" done?"
Yes. They use your banks credentials and scan the accounts. It is really awesome. Because you can centralize 20+ accounts into one flow in an automated fashion ++ you don't need a bookkeeper. Ironically, it is actually more secure since I can catch things within minutes.
"Also, your company's accounting information can be sensitive, and hence you may not want to share that information with Intuit (and whoever they choose to share/sell it to)."
Worse! Intuit does all my TAX RETURNS. Their tax system is absolutely worth it. I trust them more than "Jeff" at my local small bookkeeper firm. They handle a large percent of american's taxes. [Yes, yes I understand their lobbying is terrible].
Yes. They use your banks credentials and scan the accounts. It is really awesome. Because you can centralize 20+ accounts into one flow in an automated fashion ++ you don't need a bookkeeper. Ironically, it is actually more secure since I can catch things within minutes.
"Also, your company's accounting information can be sensitive, and hence you may not want to share that information with Intuit (and whoever they choose to share/sell it to)."
Worse! Intuit does all my TAX RETURNS. Their tax system is absolutely worth it. I trust them more than "Jeff" at my local small bookkeeper firm. They handle a large percent of american's taxes. [Yes, yes I understand their lobbying is terrible].
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.
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!
> Yes. They use your banks credentials and scan the accounts. It is really awesome.
Interesting. Is your bank OK with you handing out your web bank login to 3rd party?
I found it strange how LinkedIn could trick people into handing over their email password. But the web bank login..!?
Interesting. Is your bank OK with you handing out your web bank login to 3rd party?
I found it strange how LinkedIn could trick people into handing over their email password. But the web bank login..!?
Does this mean that you literally hand over your online account log in details to Intuit? Or how is this "scanning" done?
Yes, mint screen scrapes any bank that doesnt have an api. The sheer number of sites it works with is impressive. I have moved away from it, because if the security concerns, but I wish there was a self hosted open source solution that had connectivity into everything you could want.
Yes, mint screen scrapes any bank that doesnt have an api. The sheer number of sites it works with is impressive. I have moved away from it, because if the security concerns, but I wish there was a self hosted open source solution that had connectivity into everything you could want.
[deleted]
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.
Maybe it's just me, but I stopped reading here b/c this language struck me as unnecessarily antagonistic. Just some feedback.
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.
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?
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.
I tried using GUI tools with Git when I started but after I took the time to learn the core operations, using the CLI became a lot faster and less scary.
After using other Atlassian products and being very disappointed, I can't even imagine using a GUI built by them.
After using other Atlassian products and being very disappointed, I can't even imagine using a GUI built by them.
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)
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)
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.
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.
> 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.
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.
Maybe I should learn how to use SourceTree, but using an abstraction over git kind of makes me nervous because I don't know what it's doing in the background. I suppose it would be pretty simple to learn what it's doing, but I just prefer knowing exactly what git commands I'm running.
I use the IntelliJ IDE family's visual conflict resolution tool so I guess it wouldn't be a big step to start using SourceTree. Realistically the only git commands I use are add, commit, rebase, push and pull.
I use the IntelliJ IDE family's visual conflict resolution tool so I guess it wouldn't be a big step to start using SourceTree. Realistically the only git commands I use are add, commit, rebase, push and pull.
I think it would be fair to say that a lot of people have a love/hate relationship with git.
I've found a lot of people seem to hate it. I like using it in the command line personally, I find that 99% of the time I am using the same commands day in day out so I don't have to do anything particularly hard using the git CLI.
my absolute favorite command is: git add -p {insert some path here}.
personally, I don't know why people claim that mercurial is so much more intuitive, but I also don't think that something that is clearly a personal preference based on previous experience warrants an ideologic war.
personally, I don't know why people claim that mercurial is so much more intuitive, but I also don't think that something that is clearly a personal preference based on previous experience warrants an ideologic war.
If you like that just wait until you've tried
git -c interactive.singleKey=true commit --verbose --patchNope, I enjoy using it too. It might have a learning curve but afaic for a tool I use every day in my full time job productivity == good ux.
I think pijul is a counterexample to this claim. Category theory was used to find the mathematically optimal semantic (i.e. interface) for the category of files and patches (i.e. version control) and so the need to plan the command line interface has been minimized. A GUI would still require a substantial amount of work. I wouldn't go so far as to defend the somewhat exaggerated claim in the original article but I still think CLIs are easier than GUIs.
That doesn't really change the equation. You've just front-loaded the work into the categorical analysis of version control (and the implied "learn category theory" phase).
PS: I'm cheering for Pijul from the sidelines. :)
PS: I'm cheering for Pijul from the sidelines. :)
It is hardly a controversial statement, particularly in the context of something entirely text oriented like accounting.
It would be different if they were expressing the same sentiment for something like a 3D graphics editor...
It would be different if they were expressing the same sentiment for something like a 3D graphics editor...
Stopped here also. Bad sign. Different tools for different jobs, no need to get emotional.
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.
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.
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.
> 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.
The OP is emotional/opinionated, doesn't mean we should follow suit.
Regardless of his tone, he built a small CLI tool to do basic bookkeeping that can simplify double-entry bookkeeping with transaction actions/tags.
Take it or leave it. But heavily "attacking" him is a useless practice. Maybe if you don't like it just don't upvote it and move on with your life. This toxicity is not doing good for the community here.
Regardless of his tone, he built a small CLI tool to do basic bookkeeping that can simplify double-entry bookkeeping with transaction actions/tags.
Take it or leave it. But heavily "attacking" him is a useless practice. Maybe if you don't like it just don't upvote it and move on with your life. This toxicity is not doing good for the community here.
I'm not sure what toxicity you're referring to, as I didn't read all HN comments. If you think my comment is also toxic, then I think you may have a bit odd expectations. Just because feedback isn't all happy-buffed doesn't make the feedback toxic. I assume you agree that if I show you something and you don't like it and tell me why, that your act isn't toxic, right?
Plus it's a "Show HN" thread which the whole idea is, that people give feedback.
Posts like "I had this problem and solved it this way" are generally well regarded, the issue with the post here is, that the author didn't just explain what his problem is, but implied that most GUI apps are bad and that his accounting method is way more superior to what everyone else uses.
If you have this high confidence in yourself and your creations, then you should also be able to take some negative feedback on it.
Plus it's a "Show HN" thread which the whole idea is, that people give feedback.
Posts like "I had this problem and solved it this way" are generally well regarded, the issue with the post here is, that the author didn't just explain what his problem is, but implied that most GUI apps are bad and that his accounting method is way more superior to what everyone else uses.
If you have this high confidence in yourself and your creations, then you should also be able to take some negative feedback on it.
What are the benefits of double-entry bookkeeping?
I'm no expert in this area, but I do know accountants, Google can direct you to posts like this Quora thread [1] and while people usually don't accept this as a valid argument, a method that is to this day still widely used from small to huge businesses, seems IMHO to require more than just a "It made sense [...] but not in times of computers"-statement.
Also on the whole topic of running a business, you're honestly better off just hiring an accountant to do the work for you, so you can really spend time on your core business.
[1] https://www.quora.com/What-are-the-merits-of-double-entry-sy...
Also on the whole topic of running a business, you're honestly better off just hiring an accountant to do the work for you, so you can really spend time on your core business.
[1] https://www.quora.com/What-are-the-merits-of-double-entry-sy...
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.
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.
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...
Nice intro here : https://www.accountingcoach.com/debits-and-credits/explanati...
> I'm not sure why the OP is getting s%%t from the community.
OP states, in large font, that Transity is "The Future of Plain Text Accounting". If you're going to make a bold statement like that, then people are going to be critical.
OP states, in large font, that Transity is "The Future of Plain Text Accounting". If you're going to make a bold statement like that, then people are going to be critical.
"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.
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 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.
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.
You'd have 5 main accounts there.
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.
Income:Job
Asset:Bank1
Asset:Bank2
Expenses:whatever
Liabilities:whatever
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.
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.
So, again, thanks a lot for that last line, which helped me out.
I'd want to keep my checking account in ledger and real world matching. So either use a virtual account to indicate that some money, while existing in checking, is actually allocated to something else (this is a budget, basically). You can also create asset accounts for what people owe you. Once they pay you you move it from what they owe you to your checking account. For this one, you might have a couple transactions like:
The end result is that your checking account is always accurate. Then, as maxerickson says, use virtual accounts to handle mark where the needs to go next or what it's intended for. Also examine ledger's budgeting capabilities for this.
https://www.ledger-cli.org/3.0/doc/ledger3.html#Effective-Da...
2018/06/01 Roommate owes me
Assets:Accounts Receivable 100.00 USD
Income:Roommate
2018/06/06 Roommate paid me
Assets:Checking 100.00 USD
Assets:Accounts Receivable
The end result is that your checking account is always accurate. Then, as maxerickson says, use virtual accounts to handle mark where the needs to go next or what it's intended for. Also examine ledger's budgeting capabilities for this.
https://www.ledger-cli.org/3.0/doc/ledger3.html#Effective-Da...
Thanks for the detailed recommendations! I've read the documentation on virtual accounts but haven't wrapped my mind around them yet. I'll have another go at it.
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).
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.
Thanks. I've had a hard time understanding the documentation on virtual accounts, but I'll have another look at it.
Consider watching this little series on Khan Academy and then sketching out your start of year balance sheet and a month's income statement.
https://www.khanacademy.org/economics-finance-domain/core-fi...
This might clarify the account types (assets, liabilities, equity, income, and expense) as structuring the income/balance reports, and accrual basis accounting as the reason to have "accounts payable/receivable."
Consider also thinking of your accounts as nodes in a directed graph. When you credit account 1 and debit account 2, you draw an edge from 1 to 2, representing a transaction. The credit is the "source" and the debit the "target."
(Double entry means you record a transaction as two updates with opposite charge, so credits and debits are listed separately. This is basically an error-correcting heuristic from 15th century Italy, which is still a good practice.)
So when you send an invoice to a client, that's a transaction. You obtain an asset taken from another entity. So you credit a revenue account and debit an asset account called "accounts receivable" (it's not "cash"). When you receive the payment, you credit accounts receivable and debit cash.
https://www.khanacademy.org/economics-finance-domain/core-fi...
This might clarify the account types (assets, liabilities, equity, income, and expense) as structuring the income/balance reports, and accrual basis accounting as the reason to have "accounts payable/receivable."
Consider also thinking of your accounts as nodes in a directed graph. When you credit account 1 and debit account 2, you draw an edge from 1 to 2, representing a transaction. The credit is the "source" and the debit the "target."
(Double entry means you record a transaction as two updates with opposite charge, so credits and debits are listed separately. This is basically an error-correcting heuristic from 15th century Italy, which is still a good practice.)
So when you send an invoice to a client, that's a transaction. You obtain an asset taken from another entity. So you credit a revenue account and debit an asset account called "accounts receivable" (it's not "cash"). When you receive the payment, you credit accounts receivable and debit cash.
I'll try to cover the accounts payable/receivable parts at least. One of the major points of modern bookkeeping is accrual accounting, which means that we recognize economic transactions independently of the cash transaction. Since the economic transaction occurs before the cash transaction, we can't increase the cash balance so we use a short term receivables account. I realize that this explanation isn't great, so I'll try to provide an example.
Consider that you sell a product worth $1000 on the first of January and you issue an invoice to your customer that is due 30 days later (net 30 days). As of January first the economic transaction has taken place and needs to be recorded to stay consistent with the principles of accrual accounting. As we've provided the customer with a product but haven't received payment yet, we've in reality given the customer a short-term loan of $1000 which has to be recorded. Accounts payable is the overview of all of these "short-term loans" given to our customers. The ledger entry for this transaction would increase revenue and also increase this short term loan as shown below.
January 1:
c: revenue $1000 (income statement)
d: accounts receivable $1000 (balance sheet)
Whenever the customer pays for the product we have to update our balance to reflect that the loan has been paid and that the customer no longer has any outstanding debt to us. To do this we credit (decrease) accounts receivable by $1000 and debit (increase) cash on hand by $1000. Note that the second entry doesn't touch the income statement as the revenue has already been recognized.
January 30:
c: accounts receivable $1000
d: cash $1000
The final balance of our accounts at the end of the 30 day period will be:
revenues: $1000 (credit)
accounts receivable: 0
cash: $1000 (debit)
Accounts payable is the same thing, but in reverse. When purchasing from a supplier on netX terms, we've been given a short-term, interest free, loan which we have to record until we pay it. I hope this helps.
Consider that you sell a product worth $1000 on the first of January and you issue an invoice to your customer that is due 30 days later (net 30 days). As of January first the economic transaction has taken place and needs to be recorded to stay consistent with the principles of accrual accounting. As we've provided the customer with a product but haven't received payment yet, we've in reality given the customer a short-term loan of $1000 which has to be recorded. Accounts payable is the overview of all of these "short-term loans" given to our customers. The ledger entry for this transaction would increase revenue and also increase this short term loan as shown below.
January 1:
c: revenue $1000 (income statement)
d: accounts receivable $1000 (balance sheet)
Whenever the customer pays for the product we have to update our balance to reflect that the loan has been paid and that the customer no longer has any outstanding debt to us. To do this we credit (decrease) accounts receivable by $1000 and debit (increase) cash on hand by $1000. Note that the second entry doesn't touch the income statement as the revenue has already been recognized.
January 30:
c: accounts receivable $1000
d: cash $1000
The final balance of our accounts at the end of the 30 day period will be:
revenues: $1000 (credit)
accounts receivable: 0
cash: $1000 (debit)
Accounts payable is the same thing, but in reverse. When purchasing from a supplier on netX terms, we've been given a short-term, interest free, loan which we have to record until we pay it. I hope this helps.
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.
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.
I found that this tutorial [1] was really helpful to help me understand how it works, in layman's terms. I followed it with hledger [2], but it should work with any double-entry bookkeeping system. You can also find a lot of resources here [3].
[1] http://www.dwmbeancounter.com/tutorial/Tutorial.html
[2] http://hledger.org/
[3] http://plaintextaccounting.org/
[1] http://www.dwmbeancounter.com/tutorial/Tutorial.html
[2] http://hledger.org/
[3] http://plaintextaccounting.org/
Accounting is not my area of expertise, but I have been learning it -- in simple terms -- by doing my personal accounts. When I started, I found these distinctions confusing, but I assumed they were wise. Now I find them arbitrary and annoying, although I am less confused by them.
I suspect there will be a third stage where I will learn their true value. But I also strongly expect that the value lies in them being a common language that other accountancy uses. If so, then they will never be useful in my own personal accounts.
I suspect there will be a third stage where I will learn their true value. But I also strongly expect that the value lies in them being a common language that other accountancy uses. If so, then they will never be useful in my own personal accounts.
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 my personal finances (though I prefer the double-entry). I wouldn't run a business on it though.
I might use a single-entry ledger for my personal finances (though I prefer the double-entry). I wouldn't run a business on it though.
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 making account types so so fundamental. From the POV of my account book "Assets:InTheBank" behaves just like "Liabilities:CreditCard". True, the later balance is almost always negative, but it is the minus sign and not the word "Liabilities" that matters.
Similarly for transactions, a plus or a minus in front of a delta is less confusing to me than the equivalent accountant-jargon. But here, for some reason, I have more sympathy for accountants and their jargon.
[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 making account types so so fundamental. From the POV of my account book "Assets:InTheBank" behaves just like "Liabilities:CreditCard". True, the later balance is almost always negative, but it is the minus sign and not the word "Liabilities" that matters.
Similarly for transactions, a plus or a minus in front of a delta is less confusing to me than the equivalent accountant-jargon. But here, for some reason, I have more sympathy for accountants and their jargon.
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.
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.
I see. Thst makes more sense.
I took an intro accounting class in a community college as well as microeconomics in high school, so I have an inkling where this stuff comes from. I look askance at stuff like "contra assets" too.
But yes: boiled down, those are legacy words indicating positive or negative.
I took an intro accounting class in a community college as well as microeconomics in high school, so I have an inkling where this stuff comes from. I look askance at stuff like "contra assets" too.
But yes: boiled down, those are legacy words indicating positive or negative.
Further to the sibling reply on Pacioli groups, you might find Ellerman interesting. I copy a link [1] but he has lots of material on his website, including a book. He discusses the group perspective of double entry and gets some extensions on e.g. multidimensional accounting mostly targeted towards his interest in property theory.
[1] http://www.ellerman.org/the-math-of-double-entry-bookkeeping...
[1] http://www.ellerman.org/the-math-of-double-entry-bookkeeping...
Sure, but that just means they're creating a product for a specific market -- one whose area of expertise isn't accounting or finance. This is something we should encourage, rather than nitpicking the wording.
Those are extremely basic financial terms. If you (meaning the generic you, not you specifically) can't understand them you really shouldn't be doing your own accounting.
It would be like creating a niche programming IDE for people who don't understand the term "computer" or "programming" or "code."
It would be like creating a niche programming IDE for people who don't understand the term "computer" or "programming" or "code."
And that's exactly what e.g. Zapier and Airtable Blocks do ... and quite successfully so.
In specialized communities there is a lot of gatekeeping just by their slang. If I can explain something in plain english without using numerous technical terms, I've mastered the first hurdle to make it more accessible.
In specialized communities there is a lot of gatekeeping just by their slang. If I can explain something in plain english without using numerous technical terms, I've mastered the first hurdle to make it more accessible.
A cursory view of their homepages reveals a large amount of tech "lingo" that require a fair amount of computer savvy, so nothing at all like what I'm describing.
I am not nitpicking at all. All of the things the author said are "mumbo jumbo" are fundamental to keeping proper books. Proper bookkeeping is also regulated so it is not just my opinion.
Agreed. If you haven't spent the time to understand what debits and credits are in a double-entry book keeping system, then you really shouldn't be trying to do accounting.
There's a large use case for simple personal bookkeeping that doesn't require double-entry accounting.
Most people have some fixed recurring bills (insurance, rent, subscriptions, etc.), some variable recurring bills (utilities, etc.), standing payments like savings, and monthly spends like groceries.
For them (myself included) something that lets you simply input recurring expenses and your income and show a running tally is pretty much all that's needed, add some simple transaction tracking and you're there. Basically all you really want is two things:
1) Given $2000 at payday, how much of that is available to spend if $X is going towards known expenses.
2) The day before payday I have $Y left in my account. Where did I spend the $2000-$X?
Most people have some fixed recurring bills (insurance, rent, subscriptions, etc.), some variable recurring bills (utilities, etc.), standing payments like savings, and monthly spends like groceries.
For them (myself included) something that lets you simply input recurring expenses and your income and show a running tally is pretty much all that's needed, add some simple transaction tracking and you're there. Basically all you really want is two things:
1) Given $2000 at payday, how much of that is available to spend if $X is going towards known expenses.
2) The day before payday I have $Y left in my account. Where did I spend the $2000-$X?
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.
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...
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.
You have just understood it, intuitively.
About that, isn't the difference between "debit" and "credit", and between "asset" and "liability", just a minus sign?
Also worth check out http://plaintextaccounting.org/
Personally I don't like the yaml-like syntax. I use beancount myself, and with fava (https://github.com/beancount/fava) as the UI.
Personally I don't like the yaml-like syntax. I use beancount myself, and with fava (https://github.com/beancount/fava) as the UI.
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
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.
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
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.
The Beancount/Fava combo is just fantastic. Awesome plugin system, multi-currency, powerful but simple sql-type query language, extremely well tested, active developers, python.
I think throwing out the terms credit/debit is a mistake. Everyone operates on GAAP and we shouldn't deviate.
Not only that, there are some really useful properties of the double entry system: 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.
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.
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.
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.
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:
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)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.
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.
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:
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.
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
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.
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.
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.
What you've described is literally not double-entry. Double-entry is based on the concepts of two accounts being modified by a related set of similarly-sized transactions (i.e., the credit and debit actions). The idea is that you can separately replay the sets of transactions for each account and at the end they reconcile (i.e., balance) because the accounts are modified separately.
You've presented a system in which one transaction modifies 2 accounts. If there's an error in the code, you've got no way of knowing it without manually checking the calculations by hand.
You've presented a system in which one transaction modifies 2 accounts. If there's an error in the code, you've got no way of knowing it without manually checking the calculations by hand.
Not only that, you lose the ability to modify three accounts in a single transaction.
How do you handle recording sales taxes? In Canada, for a business, every transaction will require splitting the tax component into a separate account so that it can be fed into the quarterly GST return. This happens both on the sales side, where you record the taxes you collected, and on the purchases side, where you record the taxes you paid to your suppliers.
How do you handle recording sales taxes? In Canada, for a business, every transaction will require splitting the tax component into a separate account so that it can be fed into the quarterly GST return. This happens both on the sales side, where you record the taxes you collected, and on the purchases side, where you record the taxes you paid to your suppliers.
Definitely agree and I think it would have usable if it kept debits/credits.
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?
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.
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.
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.
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).
> 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).
I have recently learned a technical term for the scenario you're describing: 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."
"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."
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).
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).
Ledger can output to CSV, so yes. But, not having QuickBooks, I couldn't tell you what it wants in the CSV and what needs to be altered from ledger's output.
I have the same issue. In addition, for a medium-sized operation, it becomes necessary at some point for more than one person to be updating the system at the same time. That’s when I switched from GNUCash to QuickBooks Online.
I also have a single member LLC, but can't understand the advantages of using a cli tool over Quickbooks. Beyond the obvious transactions list and graphs of income and expenses, Quickbook self-employed estimates quarterly taxes and even allows me to make payments to the IRS directly via eftps.gov. At tax time, it exports all transactions tagged and categorized to TurboTax.
from where/how are you getting your data in?
I'm not the parent, but it's fairly straightforward to get data into the ledger format.
I have written a handful of Python scripts to convert CSV credit card statements (Chase, credit unions, etc) to ledger. Additionally, pdfquery can be used to extract data from PDF statements.
I have written a handful of Python scripts to convert CSV credit card statements (Chase, credit unions, etc) to ledger. Additionally, pdfquery can be used to extract data from PDF statements.
I'm not sure what your point of reference is for the question, but at least for personal finance tracking I think such tools work well. I have a long history with apps such as Quicken and Mint, and some years ago I migrated to plain text (https://www.ledger-cli.org/) and have not felt any lack of functionality. I think the type of person who would even consider these types of tool also tends to value the flexibility of being able to get data in and out of the system however they want.
I use beancount for personal finances.
I've only recently moved to it in fact, previously used tools like YNAB and so on, but this approach seems to be a bit more flexible, especially around managing investments etc
I think you need to have the mindset for it, I've always reconciled my transactions and like to keep an overview of everything, so people saying it's tedious etc doesn't wash with me, in an odd way I sort of enjoy it
I've only recently moved to it in fact, previously used tools like YNAB and so on, but this approach seems to be a bit more flexible, especially around managing investments etc
I think you need to have the mindset for it, I've always reconciled my transactions and like to keep an overview of everything, so people saying it's tedious etc doesn't wash with me, in an odd way I sort of enjoy it
Probably an interesting read for you: https://docs.google.com/document/d/1e4Vz3wZB_8-ZcAwIFde8X5Cj...
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:
> 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:
6-5-2018 Gave food to Bart Simpson, while on vacation
Expenses:bart 1 orange ; :vacation:
Assets:foodAnd Ledger has an [Emacs mode](https://github.com/ledger/ledger-mode).
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.
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.
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.
Simple recurring transactions is like the one feature I really need from a tool like this.
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.
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.
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.
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.
> 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.
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.
>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:
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.
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 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.
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 )
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).
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
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
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).
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).
>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).
> the author didn't care even a little to understand why accounting is done with a double entry system
I don't know where you got this idea from. I got an impression the author knows a few things about accounting.
I don't know where you got this idea from. I got an impression the author knows a few things about accounting.
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.
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.
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.
Does it work for any bank in any country?
Sorry, we only cover US and Canada right now.
I've written a tool that can import data from my various bank accounts and credit cards. It's semi-automatic. Uses machine learning to guess the correct account but I can quickly change it. I then put the finishing touches on by hand.
I was thinking of using ML for this approach too but tbh most of my transactions are predictable, just a simple hashmap of Payee->Account works just as well.
Cleaning up the payees is the trickier part.
I guess in cases like Amazon, where you might buy a plethora of things across different accounts, ML might be helpful
Cleaning up the payees is the trickier part.
I guess in cases like Amazon, where you might buy a plethora of things across different accounts, ML might be helpful
The payees in my case are numerous enough that a dictionary would be too much to maintain. I don't actually clean up the payees, although I have thought about it. At the moment I leave the payee string so that if I use register on my bank account, for example, it looks exactly like my bank statement. I generally don't care what shop I bought groceries at. Those payee strings also sometimes contain interesting information like the location of the shop, so I wouldn't want to lose that.
+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
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
Why do you prefer YAML to JSON in this context?
The article doesn't say which version, though.
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?
If you want something way simpler, http://galvez.github.io/plainbudget :)
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)
If you are interested, drop me an email, I would love to discuss more about fintech (I run a fintech startup)
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).
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).
> 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.
Math predates computers, let's just stop using that too!
Double entry is not that complicated and computers or not, it just works.
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.
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:
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):
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):
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:
† https://orgmode.org/worg/org-tutorials/weaving-a-budget.html
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:...
apply account personal
2018/06/05 Gym
Expenses:Gym 54.00 USD
Assets:Checking
end apply account
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
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
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
† https://orgmode.org/worg/org-tutorials/weaving-a-budget.html
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.
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.
Same here! I keep live reports in a iterm2 hotkey window.
I tried to use Ledger, but it fails to handle multi currency ac ounting properly. Is the Transity well suited for that?
This is great!
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.