One of the fundamental principles of bookkeeping is that all transactions must only be expressed in a single functional currency in a set of books. The transaction must sum to zero.
Even cashless transactions (barter) should be recorded in units of the functional currency at "fair market value." In my country (USA) the primary taxing agency (the Internal Revenue Service) insists on this, so I'm highly motivated to comply.
The PTA solutions all seem to turn this principle on its head with accounts in units (commodities) other than the functional currency. There seem to be workarounds like "@" symbols to attach costs in the functional currency (or another commodity). Then there are numerous report parameters to try to undo the mixed transactions. I find the documentation very difficult to follow with lots of jargon that is outside of mainstream accounting principles.
I've tried hledger. As long as I'm dealing with dollars only, I'm fine. I'm having trouble moving on to stocks, foreign currencies, and crypto.
Part of it is the complexity of the reporting, but not all.
I'm also the sort of person who is not comfortable totaling pounds and newtons. When you do that, you can end up crashing expensive spacecraft into Mars. [Nov. 10, 1999: Metric Math Mistake Muffed Mars Meteorology Mission | WIRED]
I think starting from Ledger, PTA tools have always tried to provide some optional conveniences above and beyond traditional double entry bookkeeping. If your data represents higher level concepts (eg, currencies/commodities and conversion rates) explicitly, this can enable more compact/convenient/meaningful notation, and more flexible reports. Many people new to accounting find it intuitive and useful to record "what actually happened", and let the tool figure out conversions as needed.
But ideally, these conveniences are always optional and it's always possible to convert them to more standard DEB entries if needed.
So, why does the PTA community reject the functional currency principle?
I wonder, what does this rejection look like, exactly?
Plus, even if the rejection is real ... If you want to use just a single functional currency in your journal, you totally could - nobody would stop you, and all the tools would work just fine.
I'm having trouble moving on to stocks, foreign currencies, and crypto.
Perhaps it would help to think about them this way: as long as you provided enough information to compute either the cost or value (or ideally both) of all those things in your chosen currency, ledger/hledger would happy use this information to give you reports that use one currency. Most of the time it is as easy as adding --value=then,<currency> to your hledger reporting commands.
How can ledger/hledger know how much BTC was on 2022-02-02? It could either be a price directive (P 2022-02-02 BTC $500), or a total cost that was specific to the transaction you made (10 BTC @@ $5000 , assuming $500 per BTC), or a unit cost that was specific to the transaction you made (10 BTC @ $500).
There it is. I believe this is the absolute minimum necessary to work with multiple commodities in PTA.
You can tell us the use-case that you are struggling with ("I want to record that I did X on YYYYMMDD, and then did Y at a later date, and finally Z, and I want the report to show me T"), and perhaps we would be able to help.
I agree that's an important rule in all accounting standards (IFRS, etc.) So, if one wishes to comply with the most prevalent accounting standards, then single currency accounting is a must. PTA tools enable single currency accounting as well.
However that rule arises out of (a) path dependence and (b) inability to handle complexity.
Because using more than one currency introduces complexity and the very real probability that the books won't balance, it was necessary in the past to use only one currency even if that came at the cost of accuracy. It was a trade-off.
With modern tools the complexity is gone and with the Selinger method the issue of books not balancing is gone.
So now, one can have accuracy at the same time as simplicity and balanced books.
Do note that it isn't only PTA tools which offer multi-currency accounting, but many other double-entry accounting tools do so as well (e.g., GnuCash).
The rigidity of most of our old protocols often stems in the little knowledge at the time, and the constrained affordance in tooling at the time. This cuts across many industries. With innovation in the industry's substrate, some principles may no longer be necessary. e.g. in software, there was once it was absolute creed to care about how much memory your application consumes; these days, it's "okay" text editors use 1GB+ RAM — it's actually not okay; I think it's preposterous; but …you see my point?
With accounting I assume the "register in one currency" rule was made for simplicity when balancing the books because this was calculated semi-manually. These days, we don't need to worry about that.
Now… we can confidently mix apples and oranges because the tooling we have can now tell the value of an apple in terms of an orange — it's actually quite cool when you think about it
I started out trying to reply to each comment, but was chastised by the software saying single replies were preferable. I've already replied to @simonmic, so now I'll finish with a combined comment.
@adept
"Rejection" meant not accepting that all accounts should use the same unit of measure.
I don't have an issue providing cost & quantity (Quantiy @@ Dollars) information as I acquire and dispose of assets, my issue is reporting. When I request a balance sheet or an income statement, it would be nice to see everything in dollars (my functional currency) that meet Generally Accepted Accounting Principles. I really don't want to see inventories of Euros or widgets. If there's a magic parameter string, I'd love to have it.
In my country (USA) all regulations expect a single standard in $USD. They can even imprison you if you don't meet the standard. It may be a path dependence, but adherence is mandatory.
I do think that mixed unit computations are complex and a source of may software errors. There are currently 31 open issues for hledger on Github dealing with "conversion", many of them labelled as "A-BUG". I believe that the simplicity of computations in a single unit is good for bookkeeping whether manual or software.
I've read Selinger's paper. As far as I can tell, a single functional currency offends him simply because it is not "symmetrical". The fact remains that books in a single functional currency have handled multiple currencies simply and accurately for centuries.
@igbanam
Even in this age of highly capable machines, mixed unit computations are a very common source of software errors - both logical and accumulated rounding errors in conversion. From my perusal of the Issues in hledger's Github repository, this is not a trivial problem.
Finally, I'm glad to use the @@ notation when entering fungible assets. Just tell me the magical parameter string I can use in hledger to create a balance sheet and an income statement in my government mandated single currency - $USD.
Just tell me the magical parameter string I can use in hledger to create a balance sheet and an income statement in my government mandated single currency
If you recorded things in a single currency.. then none needed!
But otherwise: usually some combination of
-B (convert posted amounts to their @/@@ cost),
-V (value in my base currency at period ends) or -X CUR (value in specified currency)
and --infer-market-prices if you don't have enough P market price records.
Occasionally other variants like --value=then mentioned by @adept might be preferable.
I looked at the --value parameter. value=then will be the right approach if the value is correctly inferred from the transaction by assuming I paid a fair market value. According to the manual, this is not always straightforward. First, if there is a P directive, that will take precedence. The manual further states, "There is a downside: value reports can sometimes be affected in confusing/undesired ways by your journal entries. If this happens to you, read all of this Value reporting section carefully, and try adding --debug or --debug=2 to troubleshoot. This is followed by many paragraphs of caveats.
I haven't encountered specific errors yet, I was referring to the issues flagged as bugs related to conversion on Github. If it was easy, these issues/bugs wouldn't be there.
@simonmic
So far, I have been doing single currency, and it has worked fine.
However, even if I am in a single currency, I'd like to properly deal with capital gains (hopefully not losses) on stocks (another "commodity"). Currently my broker figures this out based on my chosen method (FIFO was my default choice) and sends me (and the IRS) the result of this calculation. I don't even find the word "fifo" when I search the manual, though there are apparently add-ons that will help with this (eg hledger-lots).
Maybe the best strategy is to just have an "asset:stockbroker" amorphous blob and trust the broker to do all the work for capital gain calculations that I can post to hledger annually.
If it was easy, these issues/bugs wouldn't be there.
Yes and no. It's normal for all software to have bugs, and they will be more or less serious for different people depending on what they're doing. Not sure which ones you are seeing exactly.
Re that warning you quote. Some of my warnings may be a bit over severe compared to normal experience. This is a reference manual and I am trying to get people to avoid things that occasionally lead to bafflement and wasteful support requests. I think in this case I'm warning that --infer-market-prices could be confusing at times, since its operation is not so visible. This is the reason that P directives take precedence and are IMHO preferable if you want maximum predictability. (In practice, once you're experienced with the tool either is fine, it's easy to troubleshoot and to build confidence in reports.)
Yes - for now you'll find it in the issue tracker, and (latest writing) a big comparison of lot tracking methods at Lot tracking in PTA - Joyful Systems.
I'm curious myself how you can record cost basis and track and report gains accurately per lot with "single currency" accounting, without @ notation. If it's possible to handle the scenarios on the above page, I'd like to add this method there.
You must do something like "@ notation" even if you are following the single currency principle.
As far as recording transactions, the cost and quantity are always recorded in the journal. The cost (in the single currency) is posted to the ledger, and the quantity and cost go into whatever inventory control system the business uses.
The ledger postings will always be in your single currency which means everything is balanced (transactions and account totals) without unit conversions. I consider this a very nice feature as do all bookkeepers dating back to Luca Pacioli who wrote in 1494:
"No final balance’ can be agreed when the total of the debit balances does
not equal the total of the credit balances. Were you to add up all the debit entries,
perhaps more than 10,000 of them on a separate sheet and, in the same way, add up all
the credit entries, they should total the same amount. Otherwise, an error has been
made posting to the Ledger."
It's sort of a 15th century approach to assertions.
31 bugs with currency/commodity conversion sounded too bad to be true, so I decided to repeat the experiment.
Well, a good 13 of the 31 are related to csv conversion, json conversion and have nothing to do with currency/commodity conversion -- this is just from reading titles, and I suspect that searching the tickets for the context in which "conversion" was mentioned would bring this number up (or down?) even further.
Sure, it was a crude search. But my point is that it included significant bugs which (in my opinion) would have been less likely in a single currency world. And if you include the 89 closed issues, there were many more.
My opinion remains, the PTA world would have been better off if it had not eschewed the single currency principle.
In my country (USA) all regulations expect a single standard in $USD. They can even imprison you if you don't meet the standard. It may be a path dependence, but adherence is mandatory.
I noted this, and PTA allow you do do so. hledger has a "strict mode" that allows you to declare which commodities may be used. Just add "USD" as the only declared commodity, and use strict mode as the default via the config file.
If all your assets are based in a single country, then great. You're all set.
I do think that mixed unit computations are complex and a source of may software errors.
There are two kinds of "complexity". One is simply handling multiple commodities. This is very difficult to do on paper, keeping track of commodity pricing at different times, etc. This particular form of complexity gets removed with digital computers.
The second kind is what I noted when I said that "books won't balance". Selinger notes that naive methods of multi-currency handling will result in situations where the books don't balance.
The Selinger method makes sure that multi-currency transactions always balance.
The fact remains that books in a single functional currency have handled multiple currencies simply and accurately for centuries.
Single functional currency accounting methods have made accounting simple for centuries, yes, but not accurate. Changes in price of GBP cannot be reflected accurately in an automated fashion if all of your books are in USD. You'll need to manually account for forex losses and gains. Single functional currency trades off accuracy for simplicity. With computers + the Selinger method you can have both: accuracy and simplicity and the beauty of double-entry accounting.
There's no reason inherent in double-entry accounting why it should be restricted to a single currency. It is a convention and a legal requirement (thanks to laws that codify following specific standards based on conventions). But it isn't a conceptual requirement.
Clients would like to receive the invoice in their currency and not in INR.
At the same time, we need to record our income in INR.
We need file reports about payments received from overseas clients with details of currency to the government.
We have bank accounts in other countries and the bank account statements will be in relevant currencies. In order to reconcile the bank account ledger we need transactions to be posted in relevant currencies
We need to track foreign exchange loss or gain when we move money from bank account in one country to an account in another country.
I'd like to add that "single functional currency" means that your reports (balance sheet, etc.) need to be in a single currency, but internally in your books may use multiple currencies:
Quoting from Wikipedia:
Businesses may enter into transactions (sales, payments, etc.) in multiple currencies. Each qualified business unit (QBU) of the business translates these items to its functional currency at an appropriate exchange rate. It then prepares periodic reports of its position (balance sheet) and activity (income and cash flow statements) in that functional currency.
Thank you for your comments. I'll make a couple of points.
When I say I want my books to adhere to the single currency principle, I have apparently confused people.
The single currency principle means that a transaction entered in the journal is expressed in a single currency and the accounting equation holds without any unit conversions.
This is a very nice feature for computers because inherently precise fixed point calculations can be used. Mixed unit transactions inevitably require floating point calculations and their inevitable rounding errors.
The single currency principle means that the accounts in the Balance Sheet and Income Statement are all in a single currency.
The single currency principle does not mean you do not track inventories of fungible commodities in your system. Of course you must do this.
The Selinger method.
The "naive" examples of single currency failure Selinger presented are not the way real world multicurrency books are managed while adhering to the single currency principle. Selinger's examples are a straw man argument and should simply be taken as an example of how not to do it.
Selinger's complaint that the single currency principle is an offense to symmetry makes no sense to me. It amounts to some bizarre currency DEI.
Why multi-currency accounting is needed.
All good points but easily done without abandoning the single currency principle.
Just because Selinger created some defective examples doesn't mean bookkeepers should abandon single currency with its inherent apples to apples simplicity, accuracy and precision.
This is saying that foreign currency transactions are translated to the functional currency (using the exchange rate) before being posted and reported. This is exactly how the single currency principle is carried out.
Of course, it doesn't mean you stop tracking the balance of your foreign currency bank account. At the end of the accounting period you must calculated the currency gain/loss and post that as well. Easy-peasy and entirely balanced and accurate without abandoning single currency.
