I've been using Ledger for almost nine years, both for my personal accounts and now my business accounts. I wrote some introductory articles about it, and further articles about how I use it day-to-day:
Have you ever thought about using a natural language interface with ledger? For example, the Mac/iOS calendar app Fantastical lets you create an event by typing or dictating a sentence like "lunch with mike at 2 on Tuesday at Wendy's", and the app will parse the input to create an event with the right parameters.
I ask after reading your vacation write-up. Seems like the input side could have been a lot easier if you had a speech or text NLP interface to ledger. "$10 entertainment expense paid from MasterCard today," for example. That could be the holy grail for people who are not inclined to keep a detailed ledger, or for situations where input is difficult. (Theoretically you could email/iMessage/SMS/slack that string and have it picked up by your ledger file.)
Ledger sort of has that built in, actually, but it only works if you have a similar transaction in the past. For example, I can say this on the command line:
Interesting, thanks. I had in mind a system that would basically regex match a string and add an entry to the ledger (similar, but it would probably be a bit more flexible than the built in system).
Separately, I saw you have also worked on a similar system for food logging. That got me thinking...what else could you track with a plain text file in this format? Fitness/workout info came to mind, as well as rewards points, sleep tracking, any others? Would be cool to have a single system to track all these things, which could be linked up to APIs like Fitbit, myfitnesspal, etc.
I don't use that system anymore, actually. I switched to LoseIt, primarily because of the extensive food database. Most of the time I can just scan a barcode or search for a particular thing and it's in there.
Convenience trumps plain text in this case because, unlike with finance, there's no bank statement to refer back to if you fall off the data entry wagon for a day or two. That data is instead just completely gone.
I use and love ledger, and wrote a Ruby wrapper a few years ago called reckon that applies Naive Bayes to your bank CSV (kind of link Mint.com) and outputs a ledger input file.
I just want to thank you for writing reckon. I'm a totally blind software developer and find ledger much easier to use then any program with a GUI for keeping track of my mony and budgeting. A large part of what I do is use reckon to enter my creditcard transactions from a CSV export.
I've used ledger for years, but it's not a 'real' double entry system, despite what the manual says. It's more halfway between cash and double entry. The 'auto balancing' for example, which is sold as its big feature, doesn't make sense from a double accounting perspective - the whole point is to not have it be 'auto'. Other basic things are missing - the difference balance and profit/loss accounts, for example. It's fine for personal and small business accounting, but if you've had training in real accounting some things will be confusing (because of terms meaning something else) and don't expect your accountant to be able to work with your reports if you haven't set up your system in cooperation with him/her.
You could definitly write:
2015/10/12 Exxon
Expenses:Auto:Gas $10.00
Liabilities:MasterCard $-5.00
Liabilities:Visa $-5.00
It's still valid. However it would fail if you put a 5 and 4 here if your expense is 10.
I'm still not sure how it decides between active and passive (since Expenses and Liabilities could also be other words like the german ones: "Ausgaben", "Verpflichtungen" and the program works with them, too but It can't know if its active or passive. so I don't know what would happen if I make a transaction on two aktivas, like Bank to Cash or Bank to Fund)
No, which is why I still use it for small subbudgets that only I neex to work on :) And look, it's a fine tool for that, but you still need real accounting experience to use it according to gaap. The way the manual describes, and how many convenience functions are structured, isn't.
I wanted to be able to group all my assertions together. This means the assertion needs to be able to retroactively calculate the balance on a given date. ledger-cli's assert doesn't support this. hledger does, but, well, I'm not a Haskell guy and the whole Haskell ecosystem seemed...cumbersome...to install.
uledger supports a useful-to-me subset of ledger-cli, primarily nested accounts, multiple currencies and out-of-order assertions and transaction entry. It has a bunch of tests and a very simple web balance interface. My favourite feature is the accounting-equation balance feature:
as a side note: both ledger [0] and hledger [1] support time tracking/keeping. of all the various tools I tried to use for personal stuff it has been the most convenient one for me (it helps that I also use it for accounting) and I'm using it consequently from day 1 on! you can apply the same reporting/balancing to your time keeping as you do to your accounting.
Has anyone tried to marry the time tracking in ledger with org-mode in emacs? I haven't looked at the emacs mode for ledger yet, so forgive me if it is in there. I would really like to work in org-mode and somehow end up with ledger output without having to manually move all the data.
Been using ledger for 9 years as well (hledger lately.) Never have a hitch. The only complaint I have is that I can't (easily) keep AR in sync with online invoicing software. minor though. Would love to have some git-style integration with my bank and other accounts. `ledger pull savings` or `ledger pull invoices`
I like that interface idea. There is ledger-autosync (in Debian and on GitHub[0]), which should pull transactions from with accounts with OFX. I haven't tried it as none of my accounts are reachable through OFX.
If your bank supports OFX/QFX download, you can still use ledger-autosync. You can manually download as many transactions as you like, and it will only import the new ones.
YNAB is not double-entry. In fact I interviewed with them one time and they asked me how I would design it, and I started outlining how I run my ledger-based YNAB-like system with double-entry accounting. Their response was something along the lines of "wish we had thought of that, it would have been easier."
Wait, it isn't? My understanding of double entry is that asset moves across accounts are recorded in both accounts, so if I were to, say, pay a credit card bill, I show a debit from my checking account and a credit to my card account.
YNAB is double-entry but not the way you would normally do it (note, I have no idea how it is implemented under the hood, I'm just referring to how I explain YNAB's system to myself). YNAB essentially puts your accounts (assets and liabilities) on one side of the balance sheet and the budgets on the other. It is double-entry in the sense that every transaction is either between two accounts, or between an account and a category (a budget account), so there are two sides to every transaction.
However, in "normal" double-entry accounting, you would not have assets and liabilities on the same side of the balance sheet, and the way YNAB does this leads to some strange behavior. For example, if your net wealth (assets and liabilities) is negative, you need a negative budget ("pre-YNAB debt"). So now you have in your budget both money you plan to spend on actual expenses, and debt.
You could, in principle, design a YNAB-like double-entry accounting system where your assets balance against equity and debt, and where the money that is "available to budget" matches the actual money you have available, regardless of whether that money originates from equity or debt. That would be closer to the normal understanding of double-entry accounting.
You'd do the same in cash accounting. Otherwise you're recording wrong values, as compared to the actual account statements. Double entry means balancing active and passive sides for all activities, asset and debt. When you buy a laptop with a credit card, you add (for example - the details depend on legal requirements, how much detail you want to capture etc) an entry with 1000 on the passive side, in the cc account, 500 on the active side (asset it's not worth what you paid for it any more) and 500 under depreciaton. Then when you pay the bill, you reduce the cc account and the checking account. Each of these operations individually are balanced, ie they sum to 0.
that's in fact the way I learned it and ynab doesn't look like it.
however I didn't seen many people who use double accounting for their personal budget?
maybe i didn't seen enough people yet, since it looks like that a lot of hn'er using double accounting...
Double accounting for personal budgets is too much overhead, which is why ledger is a nice middle ground. I doubt many ppl reading this use double accounting for their personal finances - by the time you need that, you'll have someone else do it for you, and they won't be dicking around with ledger...
There's another open source project worth checking out called BeanCount. The author, Martin Blais, originally wrote it in Python to serve similar double entry bookkeeping needs as those from the ledger-cli community. He seems to be continuing development of it, or at least porting portions of it (plugins?) to a variety of languages.
> Why would you use something like this over say a spreadsheet?
Because doing double entry accounting with the kind of reporting, balance checking, automatic addition of balancing entries, etc., that ledger-cli provides is difficult.
And because its plain text, it works quite well with the same kind of version control, diffing, etc., tools used for code.
> Is it really much easier than opening a browser and running Google Docs???
* ledger is for double-entry accounting. Doing that in a spreadsheet can be a huge pain. When you then want to query the data in different ways, that will add a ton of complexity to your spreadsheet.
* It is plain text, so you can keep your data in version control.
* It has awesome reporting capabilities. These are builtin, so you don't have to create them from scratch.
Spreadsheets are nice and simple, but once you do anything moderately complex you are asking for bugs under all of your hidden formulas.
Keep in mind that this is a ledger, not a spreadsheet. You record transactions in a text editor. The ledger-cli program is simply a report generator. From the perspective of an "accounting application", what you might think of as the meat of the program is actually the text editor. There are plugins for emacs and vim to do text highlighting and insert dates, etc, but it's basically free form editing.
In a way, it's exactly what you are thinking would be superior: why not use some general purpose tool for data entry and then write some macros for generating reports? It's just using a text editor rather than a spreadsheet.
The text editor is actually quite a bit better suited to this kind of entry than a spreadsheet. Have a look at the examples at the website. Since the journal is also just a text file, you can easily use a version control systems on the data -- this has saved me more times than I care to mention.
So, yes, it really is easier than just about everything else you could imagine. If you are interested in double entry accounting, I highly recommend it.
A spreadsheet used like this is almost always a database in disguise, but it's way too easy to delete a row or cell by mistake. Also double-entry bookkeeping does not lend itself well to a spreadsheet model. And as others said: open source, version control, and extreme ease. For someone like me who types a lot and lives on the command line, it's infinitely quicker than firing up a spreadsheet program.
Well something like quickbooks its much more transparent and Ledger isn't constantly trying to upsell you some service :-) Agreed on the spreadsheet, its balance checking is really the key feature here that spreadsheets don't do.
The simplicity of simple text files means you don't have to worry about your files not being readable by a future you. Which is not the case of every 'gui' dual-entry accounting system to date. Seriously, pick any system you could have used in 2000 and figure out if you can read its files now.
> Seriously, pick any system you could have used in
> 2000 and figure out if you can read its files now
Back then I used Gnucash. It's simple XML, and I wrote some Perl to pull a report on it recently. MoneyDance, which I use now, seems to have some kind of binary format, but will export XML, CSV, etc etc...
Well, you might want a computer to do all of the work and that's easier via a command line app (for most programmers) than doing it all in VBA including parsing a bunch of files and generating the entries.
As for the GUI, still needs to be built on top of something, why not this.
This actually looks really cool and I'm interested in checking it out. I've often thought about how cool it would be to have double entry accounting for every day life.
What is "all the work" here? MoneyDance (which I've used for a few years now) imports directly from Amex, my checking account, and three different credit card accounts... It generally classifies correctly, but then I want to manually review each transaction classification manually as some snacks or electronics are business expenditures, some are not... My accounts are generally pretty complicated, but I'm yet to find a use-case that MoneyDance (or GnuCash, back in the day) can't support...
I'm a programmer, and I love programming, but not everything needs my time and attention to program. I also (no longer) run my own mail server, just because I can.
MoneyDance doesn't appear to be a double entry system. The nice thing about double entry bookkeeping, is it allows some pretty complicated cash-flow tracking - so setting up your accounts for a small business or consultancy is a bit easier.
I'm curious about this. I thought double entry book-keeping was mostly an artefact of manual/analog book-keeping. Humans are notoriously error-prone, and it's easier to avoid errors when two sets of numbers are supposed to balance out (ideally, exactly).
How is double entry beneficial once all transactions are documented digitally? Could you give a somewhat concrete example? (Contrived or otherwise)?
You can think of double entry accounting as unit tests for your financial books. It definitely does help in making sure that you don't make mistakes when you enter the data, but where it really shines is analysis after the fact.
In Japan, the government actually gives me concessions for submitting my documents for income tax as double entry accounting. This is because it saves them huge amounts of money. So, if I document an expense that I want to get a deduction for, they can easily check that there is a corresponding withdrawal from the bank account to pay that expense. Especially for complicated areas, like my payroll, where I have up to 5 bank accounts in play (some of them off shore), it's absolutely the only way they can go back and understand what the heck is going on.
Similarly, for me, I have sometimes gone back and discovered that I got an exchange rate wrong. Fixing that mistake is a nightmare (especially if you have to pay capital gains tax in a LIFO or FIFO manner -- you have to record the capital gains or losses for each "lot" of currency that you purchased). Double entry accounting will totally save your butt as you ripple through all your transactions changing the exchange rate for the foreign currency. If you get it wrong (i.e. over or underspend a particular "lot"), the numbers won't balance at the end.
Is it necessary for your average person? Obviously not. As your finances become more complicated it kind of goes like this: intellectually interesting -> super cool -> crap, how did I get by without this? -> there is absolutely no other way to do it and not get arrested for tax evasion.
Double-entry refers to the number of accounts related to a transaction, rather than the process of entering it twice.
When you think about it, all transactions have naturally (at least) a from and a to account. In the simplest example, I move $100 from one checking account to another. This is a pain to model in a spreadsheet, where I literally create two entries, but very easy to model in an electronic dual-entry system where I create a single transaction with a from and a to end point, and an amount.
Consider if I decide to buy a stock from my checking account. The from is my checking account, and then there are two "to" accounts - an account which models the value of the stock, and an account for the vendor's charges for the purchase. I might decide to aggregate all such bank charges to a single virtual account for this purpose. In this case, that virtual account would be the same as a "category" in a spreadsheet based model.
It can also make budgeting and cash-flow visualization easier. I have a virtual account called "Holiday Budget", which makes a transaction to another virtual account called "Spent on Holidays" of $x every month. Whenever I spend money on a holiday item from my checking account, the "from" is my checking account, and the "to" is my "Holiday Budget". This keeps my net-worth and budgeting reports very simple - they say I spend the same $x on holidays every month - while accounting for some very lumpy spending. I can easily see if I'm over or under budget by looking at the value of the virtual account "Holiday Budget" at any point.
It makes recording the value of unconventional assets easier. When I buy a laptop, I create a new account for the laptop, and transfer the money from my checking account to the virtual account that represents the value of the laptop. Every month, I draw down money from the laptop account in to an account called "depreciation". This helps me keep my budget reports insulated from lumpy spending too.
A big use-case as well for me is the purchase of expensive refundable plane tickets - essentially, I buy personal futures in plane tickets when I see a good price. The virtual accounts that dual-entry allows means that when I buy a refundable ticket, I treat it as an asset in a virtual account until it's used. Again, this helps me track my spending and budgetting more effectively.
> A big use-case as well for me is the purchase of expensive refundable plane tickets - essentially, I buy personal futures in plane tickets when I see a good price. The virtual accounts that dual-entry allows means that when I buy a refundable ticket, I treat it as an asset in a virtual account until it's used. Again, this helps me track my spending and budgetting more effectively.
I would like to hear more about this. Do you have alerts set up? Does this end up saving you money? Do you get to re-schedule the flight an unlimited number of times (pushing the future out) or do you have to cancel and rebuy periodically? Can you use exercise the option early?
It's far less sophisticated than this. A route I take regularly costs ~$2700-$5000. I refuse to pay more than $3000 so I tend to book all the dates I might travel ~6 months in advance, and cancel them if I don't need them, which costs about $50.
In outline, that's not wrong, though in detail it might be because the $ are still, presumably, actually in your checking account. But that's correctable, with the right account structure. Instead of just "Checking" and "Holiday Budget", make it "Assets:Checking" and "Assets:Checking:Holiday Budget" (I'd prefer "Holiday Fund").
Because Holiday Budget isn't a real account, and my checking one is. If money didn't leave the checking account, it would show an incorrect budget if I marked that it had.
A lot of the things you'll think to do in an electronic system, with tags and tables and so on, can ultimately be modeled by accounts in a double entry system, and probably just as powerfully once you add things like "virtual accounts" and the like.
At some point, it's sort of like greenspun's 10th rule - any sufficiently advanced money tracking system will implement a version of double entry accounting in it.
All I found was an FAQ entry from MoneyDance talking about how underneath it's double entry, but they try their hardest to hide that fact from the users. So, yeah, I guess technically it's double entry, but not in a way that is immediately obvious for a lot of use cases.
> I've often thought about how cool it would be to have double entry accounting for every day life.
I have a hard time imagining something that is less cool than accounting. It's certainly a good idea though.
You need to be shown it. It's the same as with people doing only Java hearing about REPL. It's weird at first, but once you get it, you don't want to go back.
Yes. At the risk of over-explaining: I meant my comment as a sideways remark that Hacker News is full of hackers, many of whom believe a cool program is its own reward, whether it's needed commercially or not. I did not mean to disparage the question or the questioner.
Granted, this is the extreme, but in my mind this is simply the manifestation of the "do one thing well" mantra of *nix. The basic chains of tools allowing extensibility and chaining from one to another because they're so well-rounded in their own right.
This has always been a thing (reduction to absurdity); these days you just see it more often as javascript libraries for anything you could possibly want.
I tried to do this with a spreadsheet years ago, for single entry check balancing. Formulas, if this, if that, it got out of control. It made me a believer of using something already existing if that suffices. I do like creating things, but not that, and not in a spreadsheet.
That said, if that works for you, then that's exactly what you should do.
Experts prefer plain-text formats and command-line tools because with a little bit of elbow grease you can always do things the program creator never thought of or chose not to support.
> Experts prefer plain-text formats and command-line tools
Sure. Expert computer users prefer Lynx for web-browsing, expert Windows and Apple developers prefer vim and gcc, expert fiction writers prefer using emacs, and professional accountants use command-line accountancy tools...
I think I got Poe'd here - I'm not sure if you're serious or not, because the only thing that sounds stretched to me is the Lynx one. Of adoption of CLI among professional accountants I know nothing about, but the rest pretty much checks out.
In my experience, Windows developers (if they don't come from the *nix world) after often very uncomfortable with the command line (or anything non-Windows), and I doubt many authors know anything about emacs...
> and I doubt many authors know anything about emacs...
You'd be surprised. There's a list of writers who use Emacs floating somewhere around the interwebz, Vernor Vinge being a notable example. I can't find it right now, but few of those authors are mentioned here: http://irreal.org/blog/?p=4651.
I don't doubt it for a second, but these people are outliers. This would be like me advocating how Wordperfect is widespread among authors, based on the fact that George RR Martin still uses it.
"The command line" isn't really involved here - they're arguably GUIs rendered in the terminal. Another term is "Captive User Interface", although a text editor is one of the few places I don't mind it.
90% of the features overlap. Depending on your particular needs, one or the other may be preferred, e.g. multiple currencies. I use hledger for the Haskell street cred. ;)
I have been using Ledger for a long time and it has really been a wonderful tool. The reports are great. I even made a little Python script so I can easily make entries from terminal on my phone!
Sorry, I am not used to commenting here and didn't realise it wouldn't notify me.
I use Prompt by Panic http://www.panic.com/prompt/ on my iPhone to do SSH sessions. Since it was hard for me to type in entries to my Ledger data file I put together a script with Python that could have stored merchants and just sort of make the process easier.
I can type in `ql -m sd -t 50` and it will add a full entry for the grocery store that I frequent. The project on Github is here: https://github.com/robotmachine/QuickLedger
To clarify, it is just a command line tool that I made with mobile SSH in mind-- not a mobile app. Hope that helps.
Thanks a lot, looks cool! At the moment I'm using Nebulous Notes to write to a "mobile" ledger, then I merge that to the main ledger. This has the advantage I can add entries also offline. I'd love to move something more automated though and your project might definitely help. :)
To my knowledge I am the sole user of my QuickLedger project -- so I'd be very interested to hear how it works for another's use case. Any feedback would be great! If you fork I'd like to know so I can see what someone does with it.
Pythonista would make possible to run QuickLedger on the mobile, and it could be expanded to automatically update the main ledger, hosted on another machine or on some Dropbox-like container.
Is it possible to attach a receipt (say scanned PDFs) to a Ledger entry? I am interested in ledger, would like it to be the accounting system for my side business, a bit more bookkeeping feature such as the receipt attachment would be great for tax filing purpose.
Edit: I know that Ledger uses plain text for each entry. Though I kind of wonder how do you guys keep those receipts.
I do something similar, although I name my receipts/documents with yyyymmdd-friendlyname.pdf for ease of lookup.
For my IT consulting business, I also wrote a wrapper that rejects entries that don't have a receipt tag which allows me to catch any entries that I haven't complied 100% with my practices (and tax office won't get upset in an audit).
I also autogenerate the ledger entries from the receipt name (and prompt for description/expense account/$$ with logic for handling common items like fuel etc).
I've played with PDF metadata so my entire receipt scanning => ledger is automated from just the PDF document but haven't reached a satisfactory setup there.
I've used Ledger extensively for a side business as well as for timekeeping for work. It's incredibly powerful and incredibly unforgiving.
If you want to keep PDF, JPG, etc. receipts with it, just put them in the same directory and note them in a comment. Additionally, use a VCS that does binaries well. Git does not.
Your "unforgiving" comment is actually exactly what makes me nervous about using this (a command line util) vs a GUI application. I feel like (and this may be a total misconception) my poor typing abilities are better caught in a GUI than cmd line, unless the application itself has something built in (like git's fuzzy commands), where most UI applications, at least on Mac, are sort of validated by the OS level field validation.
Ledger has a 'strict' mode, where you basically pre-define the accounts you plan on using. That will at least stop you from typoing account names (perhaps like a pre-populated drop-down list in a UI?). Manual entry errors (too many/not enough zeros) are probably just as easy to make on the CLI/in a GUI though.
I use https://github.com/nuex/t, which generates ledger timelog entries as documented here http://www.ledger-cli.org/2.6/ledger.html#Using-timeclock-to.... I've tracked approx 2000 billable hours using this method over the last couple of years. When I invoice, timelog entries are archived into a separate file, so my active timelog ledger file records unbilled time.
This is very interesting. I'm involved in an open source project to create a Ruby gem to extract bank data from multiple banks and offer it via a CLI and a Ruby API. We fetch the data either from bank APIs (which often we discover through reverse engineering of mobile apps) or simple web scrapping.
The project is still under heavy development but we already have support for 3 main banks in Spain. We also have managed to integrate it with Slack and other apps.
I have been very interested by ledger lately, is there a wrapper, somewhere, that would ease interactions with my bank account and/or allow me to plot reports graphically across time?
The TextMate bundle has several reports built in that use R and ggplot to plot reports across time. Perhaps other editor support packages have similar features.
I have this particular repo set to push when I commit, so I commit when I'm done doing data entry for the session. When I push my reporting web app automatically updates it's postgresql database so I can go run reports and look at the data.
For me, just a master branch. Commit before/after destructive or cross-cutting changes, and "once in a while" in the course of adding regular activity. Also I use a script to mount a remote on an encrypted file system and push to it, for backup.
I used ledger-cli, but as I constantly deal with several currencies, I can't rely on it. Unfortunately, none of the open source accounting system I know support multi-currency accounting well.
It can be done, but it is tricky, especially if you have to report capital gains as FIFO. The documentation is in ledger is misleading/wrong (or was the last time I looked). I have been meaning to write a blog post on this topic for ages (a year???).
Warning: This may be wrong. I just grabbed it randomly out of a test file I was using to try this out and I don't have time to verify it. However, I think it will put you on the right track even if it is wrong (also not sure how to get it formatted correctly here). Anyway this is the kind of thing you have to do:
2014/09/04 Exchange Currency
; Note that the next line generates 20 GBP, not 10 GBP as you might expect
; This is so that the excess is captured by the capital gains account at the bottom
; Also note that the @ 0.50 GBP is not actually used by ledger in this case
; You could put @ 5000 GBP and it would do the same thing. The rate is
; determined by the lot price.
Assets:CDN -20.00 CDN {1.00 GBP} @ 0.50 GBP
; It is unfortunate that you can't get ledger to calculate or assert the next value
Assets:GBP 10.00 GBP ; Proceeds without commission
Expenses:Commissions 0.20 GBP
Assets:GBP -0.20 GBP ; Balance the commission
Income:Capital Gains
The main things you have to understand are that you need to specify the lot price in the transaction. Second, you must specify the price of the transaction. The P line is only used for calculating current value -- it will not set the price of the transaction correctly (if you don't specify it, I think it sets it to whatever the P line is set to when you run the report, which is clearly wrong). Also, you have to calculate either the total proceeds for the balancing account or the capital gains. Also, very unfortunately, with this scheme you can not use the @@ method of specifying the price. I do the math and calculate the result and let ledger calculate capital gains, because that seems the most reasonable thing to do. Some people feel very strongly that a human should calculate the capital gains by hand and enter that value. Either way should work.
Hopefully the above should unstick you. If you are using average method for capital gains, it is dramatically simpler, but I don't have an example handy.
Printing reports with the lot prices is incredibly useful as the lots should balance out to zero. If they do not, then you have an error somewhere (and boy does that suck). It's also very frustrating when doing FIFO or LIFO that you constantly need to run the report to show you how much you have left in each lot, and then go and figure out which lots are the next ones to use. I think this can be automated, but I haven't gotten around to doing it.
Yes it will. The trick is that the currency you use for capital gains always has to be the same. Also, my colleague mentioned that you might be trying to do this without recording the capital gains. You have to have a capital gains account, or else it will not balance. You can report in any currency you want with the -X flag.
I'm busy for the moment, but I will send you email tomorrow with some better information. I'm GMT+9 so depending on where you are, probably while you are sleeping ;-) It will get me off my butt to write a blog post about it.
I'd be glad to get help here, but I think this is just an unsolved problem. Discussed it on google group. I think I understand it relatively well, and even wanted to fix it, therefore I doubt multiple currencies can be handled with the current version of ledger; but would be glad to find a workaround.
I don't have it installed now, so an example just out of my head: suppose I have 100 USD; I exchange 50 USD to EUR at 1.2 rate. Then I spend 20 EUR on food. Then I exchange remaining EUR to USD at 1.1 rate. Now, if we generate a balance report, do you say it will be balanced?
What do you mean 'it will be balanced'? In double entry accounting, every ledger entry needs to balance. You have three entries. Whether they balance depends on how you enter them. What is the specific problem in your example?
I mean that balance report had 0 total. More precisely, I want to convert everything to a single currency, and than have 0 balance. I.g. I want to check my net worth in USD, or my net worth in EUR. To see capital gains/losses.
If I'm understanding you correctly you expected to see a line item in your balance report stating your losses due to the change in the exchange rate between USD and EUR? Ledger definitely supports that, you just need to make sure to arrange your accounts and transactions accordingly to capture that information. See the "Currency Trading Accounts" method:
After every entry, your total system balances to 0. Of course you have to enter all your entries, and not use the 'auto balancing' and unit conversion things that ledger recommends because they don't make sense. If you use ledger just as a, well, ledger, you can do what you want, of course after specifying exchange rates, just like you'd do in a real accounting system.
You don't understand. I mean I want to enter facts as they are, included real currencies used in transactions. But when I review balance, net worth I want them presented a single currency I choose.
No, you don't understand. What you're asking doesn't make sense, but I'll admit it's not obvious when you've never done 'real' double entry accounting. What you need to enter are the 'real facts', it's only at balance time that you can make a 'net worth' in one currency, depending on a given exchange rate.
I'd like to be able to access a ledger over the web, but really maintaining the ledger in a text editor, putting it in version control, etc., are, I find, a pretty efficient workflow, better than a more typical web UI for this particular use.
A "web UI" that consisted largely of a browser-hosted text editor with, perhaps, some ledger-specific affordances, some facilities for pre-defined reports plus a way to create new reports with customer ledger commands, and a decent history interface (possibly backed by a traditional VCS) would be nice, though.
It's got a high hack and giggle factor, but obviously horrible usability for anyone off the command line - which includes your accountant/tax advisor.
Here in New Zealand essentially every start-up uses Xero - a SaaS accounting system that works extremely well and now has over 600k paying customers.
It means one set of data, permanently in the cloud, and a host of integrations to other players.
Founders open up access at different levels - we can give read-only to directors and some investors, advisor-level access to accountants and bookkeepers and so forth.
Frankly it's part of the NZ advantage right now (120000 or so of those customers are here) - we seem to be spawning a large series of smart, low cost B2SMB SaaS businesses, who are not just following Xero's own path, but also using the tool to improve the way they do business.
> Here in New Zealand essentially every start-up uses Xero - a SaaS accounting system that works extremely well and now has over 600k paying customers. It means one set of data, permanently in my butt, and a host of integrations to other players.
Not everyone thinks it's a good thing. For instance, with Ledger, you don't have to be a customer. It's available for free. Anything that works good without SaaS is better done without SaaS.
There are a bunch of legit accounting packages out there. No need to re-invent the wheel or (in this case) clean the parade ground with a toothbrush. Off the shelf SME accounting package or if you really need it a proper ERP. Anything else is likely to end in tears.
Unless its for your one man show...in which case go wild with the CLI / Excel custom rolled solutions & sundry DIYs.
Comparing ledger to cleaning the parade ground with a toothbrush is misunderstanding the feature set. Similar to comparing it to Excel custom rolled solutions. This is a true double-entry accounting system that happens to have a CLI.
It definitely does not have the feature set of a proper ERP, but it can effectively be used in place of an SME accounting package.
Out of curiosity, what makes an accounting package "legit" in your eyes?
[edit] I see that 3 other comments asked a variation on the "legit" question. At least in my case this is not intended as an attack, but rather actual curiosity about what a professional SME accounting package can do that ledger can't; as far as open-source accounting packages go, ledger has a reputation for being able to produce reports that others can't.
Don't worry. I knew I'd catch grief. I know HN is strong on CLI love and thin on actual accounting experience. ;)
>This is a true double-entry accounting system that happens to have a CLI.
Double entry has existed in paper format since before the dawn of time. Its not particularly revolutionary (CLI or not) in fact its bare minimum for sanity. Hence my comment that this is barely a step above Excel.
>actual curiosity about what a professional SME accounting package
Copy paste from other questions:
Is it widely used? Can you get staff with a couple years experience using ledger? Will accounting staff be productive using the interface? Does it cope well with multiple simultaneous users? Is it compatible with other software? Can you get local support? Can you export/import to other packages? Are the fringe case glitches known?
All these things matter with finance software, even for fairly small operations.
>as far as open-source accounting packages go
To be honest I wouldn't go for an open source one (as much as I like FOSS etc). Accounting software is really an area where you want to follow the herd (unlike usual HN mindset). Straying from the herd has terrible risk/reward. e.g. Yes you might save $100 on the software by using FOSS, but when the auditors show they take twice as long to deal with the unfamiliar stuff and charge you an extra $2000. Or worse they find a glitch that is new. In the IT world you file a ticket for that. In the accounting world you end up with a massive bill to get outside help to salvage the accounting records. Followed by another massive bill from the auditors attempting to audit said salvaged records. But yeah...you totally saved that $100 on the initial purchase. (Exaggeration obviously, but you get my point).
>it can effectively be used in place of an SME accounting package.
I'd not attempt it, as per above. Seen way to many horror shows.
I have actual accounting experience so by your first point I am qualified to comment.
I doubt CLI snobbery is a factor; that would be infantile. I suspect others downvoted you for taking the default position that the status quo is the best prospect - hardly a hacker's point of view and certainly not in keeping with the startup community.
Had Rod Drury agreed with you, he might never have started Xero.
My finding is that once one is trained in the basics of double-entry book-keeping, accounting standards, finance and taxation, then any package that keeps appropriate records and generates the right reports will do. To which end, Ledger seems a perfectly reasonable choice for a micro business or self-bootstrapped lean startup. Comparing it to an ERP platform is a non sequitur. A better discussion might be around the transition triggers.
Moreover, Ledger could serve as the accounting module of a larger system that benefits from double-entry book-keeping, such as a trading platform or two-sided network business. I say that with confidence because I'm building one.
By the way, a little historical research: double-entry was invented in the fifteenth century; hardly the dawn of time.
>I suspect others downvoted you for taking the default position that the status quo is the best prospect
In my line of work I get to see a variety of approaches to accounting. This is not a game where the bleeding edge wins. In fact those do a lot of bleeding and zero winning.
>Comparing it to an ERP platform is a non sequitur.
Oh come one dude. I specifically said people should get a proper ERP if its need in my opening post. At no point did I compare this to an ERP. So please...chill with the latin, especially the false kind.
As for your other points. You list the "trading platform" as an example of this being successful. Sure. You could use this to effectively run a kitchen pantry too. Its still no good as a commercially accounting package for day to day use though.
My philosophy on this is, if/when my business grows to the point where I can't handle the bookkeeping anymore, I'll switch to something that I can hire out. And if that means paying someone to hand-jam in a year of transactions from my ledger files, so be it, but likely I'll write some translation software to make it happen.
Until that point, I'll keep doing my books myself with ledger :)
One small caveat as someone in the same boat. If you have to declare capital gains on transactions from multiple currencies, the "currency account" system that ledger uses is a bit strange for some accountants. I do my own book keeping, but I have an accountant who deals with the government ;-) He calculates capital gains in a way that I would say is arguably wrong. However, I trust that his way will be accepted by the government, which is all that matters ;-)
> Is it widely used? Can you get staff with a couple years experience using ledger? Will accounting staff be productive using the interface? Does it cope well with multiple simultaneous users? Is it compatible with other software? Can you get local support? Can you export/import to other packages? Are the fringe case glitches known?
I know that Accountants are conservative, but there will never be any new accounting software if all accounting software used needs to meet these requirements.
Lastly, I think a lot of people thought "one man show" meant a business with only one employee, while it is clear after your response that you meant one book-keeper. Ledger will not be used at any company with "Accounting staff" (plural). The largest organization I'm aware of that uses it is a free software non-profit that has moral reasons for avoiding proprietary software.
Is it widely used? Can you get staff with a couple years experience using ledger? Will accounting staff be productive using the interface? Does it cope well with multiple simultaneous users? Is it compatible with other software? Can you get local support? Can you export/import to other packages? Are the fringe case glitches known?
All these things matter with finance software, even for fairly small operations.
> Can you get staff with a couple years experience using ledger?
It mostly (from the anecdotes I've seen) seems to be used by people who don't have dedicated accounting staff.
> Will accounting staff be productive using the interface?
See previous answer; the "accounting staff" using it are usually programmers, either independent business persons keeping their own books or using it for personal accounts.
They're probably more productive using text-editor + source control + CLI than they would be with a traditional GUI.
> Does it cope well with multiple simultaneous users?
That's an issue mostly offloaded to the VCS, where needed.
>either independent business persons keeping their own books or using it for personal accounts.
Hence my comment in the initial post that its fine for one man shows. Those can carve their records on stone tablets if they like. Their tax accounting might charge them double for having to deal with the results but thats their problem.
>In quality software, known glitches are fixed.
Except when you're deal with companies using accounting software. There you frequently see outdated software. At least the commercial packages come with forced updates. Which are a god-send because you sure as hell don't want accounting staff trying to do IT updates...much like ahem you don't want IT staff attempts accounting stuff...like here.
Ledger only reads data you stored in text files. You can't really get much more flexible than that. Give me another package's installation and a weekend, and I'll throw you a compatibility layer. Can you say the same about those other packages?
Cool. Now do the same in a commercial context without a HN hacker on standby? Say with a mediocre skill unmotivated IT department. Sane management takes one look at it and rather pays the 100 USD for a commercial package than dealing with their mediocre IT implementing some ledger/VCS/HN special edition. Thats 100 USD very well spent...
Actually I'm an auditor. Meaning 1) I've see a lot of accounting packages and 2) I need to deal with whatever is in place.
On a good day thats a standard package. On a bad day its IT people attempting to play accountants which works about as well as heart surgeons flying jetliners. Nothing against heart surgeons...they just have no business flying jetliners.
Sad part is that I can program too, so I can usually see why the programmer did something & it makes sense from an IT mindset. :/
>can be used to argue against going against the grain of anything.
Accounting software is particularly conservative. Straying from the herd has terrible risk/reward.
Is it widely used? Can you get staff with a couple years experience using ledger? Will accounting staff be productive using the interface? Does it cope well with multiple simultaneous users? Is it compatible with other software? Can you get local support? Can you export/import to other packages? Are the fringe case glitches known?
All these things matter with finance software, even for fairly small operations.
Again - thats IT/HN mindset. Who is going to train the accountants to deal with git conflicts? Or are you just going to employ and IT guy that babysits the VCS when you could just spend $100 more to get an accounting package with built in networking? This is all about how this will be practically done in a business context, not whether a hn hacker can throw together a clever hacked solution.
Is it widely used? Can you get staff with a couple years experience using ledger? Will accounting staff be productive using the interface? Does it cope well with multiple simultaneous users? Is it compatible with other software? Can you get local support? Can you export/import to other packages? Are the fringe case glitches known?
All these things matter with finance software, even for fairly small operations.
https://www.petekeen.net/finance