Re: Tracking owed taxes
On Jul 23, 2015, at 00:34, Simão Mata sima...@gmail.com wrote: My first thought was to write a transaction from Assets:Checkings, where I get my salary, to Liabilities:OwedTax but then Assets:Checkings no longer matches the exact value I have on my online banking. First, you definitely want Assets:Checking to match the actual checking account. Second, this is an incorrect use of a Liabilities account, which should almost always have a negative balance. What I do is write a transaction from Liabilities:OwedTaxes to Expenses:Taxes. Then when it comes time to actually pay taxes, the transaction goes from Assets:Checking to Liabilities:OwedTaxes which clears out the balance. You also mention that a certain part of your Checking account is unavailable to you because it is set aside for taxes. Rather than actually moving money to a separate account (either in your ledger or at your physical bank), you just add Assets + Liabilities (remember that Liabilities are negative in Ledger) to see what funds are not yet set aside to pay taxes (or other debts). Nathan -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Reimbursement tracking
On Jan 12, 2015, at 4:05 PM, David Glasser glas...@davidglasser.net wrote: However, this doesn't support the case where there are four different accounts involved; eg, let's say I pay a healthcare expense with a credit card, cash, or another bank account from the one that i have FSA reimbursement set up with. I really just want to be able to say show me the sum of all FSA:R1234 postings, no matter what account they are to. You can do this with ledger bal --pivot FSA --depth 2 %FSA The pivot command prepends “FSA:R1234” to the applicable accounts. Depth 2 collapses anything deeper. Then %FSA restricts to only those that have an FSA tag. As previously mentioned, use --empty to include tag values even if they sum to zero. Nathan -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Multiple tags with --pivot
I find it useful for a couple of things: If health expenses always have a Patient (metavalue) tag, I can break down my health expenses by who got sick. If I tag expenses as Tax:Health, Tax:Charitable, etc, I can get a breakdown of expenses by where I can deduct them on my taxes. Nathan On Oct 31, 2014, at 12:58 PM, Martin Blais bl...@furius.ca wrote: I'd also like to understand Ledger's --pivot better: it's really just requesting for another aggregation dimension, right? From the docs, it appears to be like a SQL GROUP-BY clause. What do people on this list use it for? On Thu, Oct 30, 2014 at 10:07 PM, Vikas Rawal vikasra...@gmail.com wrote: Is it possible to use more than one tag with —pivot? Vikas -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rounding in ledger
On Oct 6, 2014, at 9:46 PM, Martin Blais bl...@furius.ca wrote:
On Mon, Oct 6, 2014 at 10:57 PM, Nathan Grigg nat...@nathangrigg.net wrote:
On Oct 6, 2014, at 8:30 PM, Martin Blais bl...@furius.ca wrote:
I like the idea that the tolerance can be inferred automatically from the
smallest digit in the input instead of using a fixed value. I should
implement that in Beancount as well, there's no reason it couldn't do
it.This should be a very easy change to make.
At the moment Beancount uses 0.005 regardless of unit... this is a known
pending issue (I don't have any Japanese users yet I suppose). I've been
thinking that a per-commodity tolerance could be selected instead, i.e., a
map of commodity to tolerance value, but while better, this is also
unsatisfying.
I wonder if inferring like Ledger works in all cases though; consider this
case:
Assets:Fidelity:Fund11.27534 FUND {1.2357 USD}
Assets:Fidelity:Cash -13.93 USD
The precise cash amount is 13.932937638 USD.
How many digits should this use?
Ledger would infer 2 digits of precision for USD and 5 for FUND. The price
portion does not affect precision. Ledger also has a D directive to specify
the minimum precision per currency.
I'm not sure what that means... there is no need for any precision on units
of FUND, the balance amount of that leg is in USD calculated as 11.27534 x
1.2357. In USD. The balance residual is 11.27534 x 1.2357 + -13.93. The only
precision that matters is that of USD.
Does it use the precision inferred on units of FUND in any way?
If so, how?
In Ledger, the precision is not per-transaction, but file-wide. (Because Ledger
process the file in one pass, this means that the precision may increase, but
never decrease, as it processes the file.) So Ledger would infer from this
posting that FUND should always be measured and displayed to 5 digits of
precision (or at least from now on).
Which brings up an interesting option for inferring the precision: the
maximum number of digits from all legs without cost/price conversions. And
this should be calculated for each group of postings whose balance amounts
are in a common commodity. That sounds right to me.
The debited cash is 13.93, this would be the _actual_ amount debited by the
fund manager, so it can't be anything else.
In this example, I would argue that you would want the _minimum_ number of
digits to be used.
(But certainly not the minimum if you're using an integer number of
shares...)
If we can come up with a rule that works well in all cases I'll implement it.
To be honest, I would prefer to explicitly specify precision, although this
makes it harder to work correctly out of the box.
Why? Because you fear not having a minimum will create pathological cases
where a user will insert a balance against an integer number of dollars and
make a mistake on the cost that will go undetected?
2014-09-09 *
Assets:Invesments ...
Assets:Cash -1000 USD
Just curious. What cases do you see as problematic?
I don't have anything particular in mind. I just like having control. But I
don't feel strongly here.
I hadn't considered per-transaction precision, but if you go that route, one
thing you will need to think about in that case is what to do for this:
2014-09-09 *
Assets:Invesments 5 FUND @ $2.50233
Assets:Cash
Nathan
--
---
You received this message because you are subscribed to the Google Groups
Ledger group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ledger-cli+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Rounding in ledger
Sorry to bring up an old topic. I followed this with some interest back when we discussed it, but my own thoughts hadn't yet crystalized, so I was silent. Now I have thoughts to share. Martin Blais: I think the question should be phrased in terms of what precision you want to represent numbers _internally_. Isn't a worthy goal to attempt to replicate the same precision as the real-world accounts they represent? I agree. To me, display precision is much less important than the internal representation. Martin again: Rounding should occur at the point of calculating the balance amount, that is, the amount that is used to balance against the rest of the postings of the transaction. I agree again, but disagree with how this is implemented in both ledger and beancount (I am not familiar with hledger). In particular, I think that the only way to avoid strange situations is for every transaction to balance exactly, as in A+B=0 to the full precision of the internal representation. Let's ignore the concept of elided values and start by thinking only about the whether a transaction balances. There are two cases. Case 1: Single currency. Postings should balance exactly. 2014-01-01 * transfer Assets:Bank1$1.00 Assets:Bank2 $-1.001 It seems pretty obvious that this should trigger an error. Ledger gets this right because it requires all transactions to balance to the maximum precision specified in the document (not quite, we'll get to this later). Beancount, with its fixed tolerance, lets this through (Even $-1.01 would pass). Even if the tolerance is exposed as an option, you give the user the opportunity to screw things up. Case 2: Multiple currencies. 2014-01-01 * buy AAA Assets:Investments 2 AAA @ 10.1234 EUR Assets:Bank -20.25 EUR The 2 AAA and the -20.25 EUR are actual amounts. The quoted rate may have been 10.1234, but the truth is, you bought at 10.125 EUR (sucker!) Note that this need to adjust price due to rounding does not arise solely from overprecise pricing, but also when you purchase fractional shares. 2014-01-01 * buy VPMCX Assets:Investments 9.66 VPMCX @ 103.52 USD Assets:Bank 1000.00 USD Again, the $1000 and the 9.66 shares are exact quantities. They do not represent something that has been rounded. You do not have an extra, invisible 0.0032 USD lying around. It is the $103.52 that is wrong. So one solution is to simply record the share price you paid instead of the share price you were quoted. This is the same as Martin Machlmayr's suggestion to use '@@' instead of '@'. But as Martin also pointed out, there is value in using '@', namely, your cost basis can match the bank's report, the pricedb gets an accurate market price, and you get an extra check that you haven't mistyped a number. A different solution is for the program to replace the cost basis that you specify with the true cost, as long as it is close enough. But this doesn't solve the problem that you might want to attach the bank-reported cost to the posting, or see it in reports. One final solution, and what I have settled on for now, is a rounding account. I insert one manually (with elided amount), but the program could easily do this for you. It sweeps away whatever is left over, and has accumulated 0.12 USD (in expenses) for me so far this year. The alternative is that my double-entry accounting ledger is out of balance by 12 cents per year. (Maybe not a big deal, but it bugs me.) The point is, no matter how you decide to round the amounts, you have to account for the rounding in some way or accept the fact that your system is out of balance. Note that either of these automated solutions could probably be implemented using beancount plugins. Weird things happening If you don't require each transaction to balance, you easily drift away from overall balance. In Ledger: D 1.00 USD 2014-01-01 Test assets 1 CAD @ 1.005 USD liabilities 2014-01-02 Test assets 1 CAD @ 1.005 USD liabilities % ledger bal liabilities 2014-01-01 Test liabilities -1.00 USD-1.00 USD 2014-01-02 Test liabilities -1.00 USD-2.01 USD Here is another: 2014-01-01 Test assets 1 CAD @ 1.005 USD liabilities -1.00 USD 2014-01-02 Test assets 1 CAD @ 1.005 USD liabilities -1.00 USD 2014-01-03 Test assets 1 CAD @ 1.005 USD liabilities -1.005 USD % ledger bal -B 3.015 USD assets -3.005 USD liabilities 0.010 USD This second example is curious because if you put the third transaction at the beginning, the other two now fail to balance, because the precision becomes 3 decimal points before they are read, whereas before the precision switched from 2 to 3 partway through. Eliding postings Once you have what it means to balance figured out, it is easy to complete a transaction with an
Re: Rounding in ledger
On Oct 6, 2014, at 3:58 PM, Martin Blais bl...@furius.ca wrote: On Mon, Oct 6, 2014 at 5:20 PM, Mike Charlton mikekc...@gmail.com wrote: Thank you for posting this. Your second example explains weirdness that I was seeing but couldn't comprehend. So to put it succinctly, ledger balances as long as the rounded amounts balance. Perhaps I don't understand all of the nuances, but I have to say that I don't like that. If a transaction is off by a fraction of a cent, then that *does not balance* for me! Then you will never be able to balance anything that has a price or a cost. There has to be rounding somewhere. Strictly speaking, the price-adjustment option would be possible in ledger, which uses rational numbers as internal representation, allowing for exact balancing. But ledger is ill-equipped to solve this problem for other reasons, for example, its lack of lot matching. Beancount could solve this by attaching a total cost to each inventory, in addition to a per-share cost (with the stipulation that | total cost - number * share cost | tolerance). You still have to face the fact, however, that if you have three shares worth $0.333 each, with a total cost to you of $1.00, and you sell these one at a time at the same price but you receive $0.33 each, even though their price has not changed, there is a penny that has disappeared. Is that an expense due to rounding or a capital loss? Again, it doesn't really matter, but I feel like I should pick one. I haven't decided whether or not having an elided expense account or simply reporting the exchange rate that was actually used is better. Note that an elided expense account effectively disables any balance checks. This is not a solution. If it is built into the system, the elided expense account can also balance check. That is, insert a 'Expenses:Rounding' transaction, but only if the difference is less than some tolerance (and only if there is a price/cost) The question is whether Expenses:Rounding is better than having the ability to run a report listing all transactions which don't quite balance, so you feel good about your overall balance being out of whack. Simon Michael: Correction: ledger reg liabilities. Yes, thanks. Nathan -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rounding in ledger
On Oct 6, 2014, at 8:30 PM, Martin Blais bl...@furius.ca wrote:
I like the idea that the tolerance can be inferred automatically from the
smallest digit in the input instead of using a fixed value. I should
implement that in Beancount as well, there's no reason it couldn't do it.This
should be a very easy change to make.
At the moment Beancount uses 0.005 regardless of unit... this is a known
pending issue (I don't have any Japanese users yet I suppose). I've been
thinking that a per-commodity tolerance could be selected instead, i.e., a
map of commodity to tolerance value, but while better, this is also
unsatisfying.
I wonder if inferring like Ledger works in all cases though; consider this
case:
Assets:Fidelity:Fund11.27534 FUND {1.2357 USD}
Assets:Fidelity:Cash -13.93 USD
The precise cash amount is 13.932937638 USD.
How many digits should this use?
Ledger would infer 2 digits of precision for USD and 5 for FUND. The price
portion does not affect precision. Ledger also has a D directive to specify the
minimum precision per currency.
The debited cash is 13.93, this would be the _actual_ amount debited by the
fund manager, so it can't be anything else.
In this example, I would argue that you would want the _minimum_ number of
digits to be used.
(But certainly not the minimum if you're using an integer number of shares...)
If we can come up with a rule that works well in all cases I'll implement it.
To be honest, I would prefer to explicitly specify precision, although this
makes it harder to work correctly out of the box.
Case 2: Multiple currencies.
2014-01-01 * buy AAA
Assets:Investments 2 AAA @ 10.1234 EUR
Assets:Bank -20.25 EUR
The 2 AAA and the -20.25 EUR are actual amounts. The quoted rate may have
been 10.1234, but the truth is, you bought at 10.125 EUR (sucker!)
Note that this need to adjust price due to rounding does not arise solely
from overprecise pricing, but also when you purchase fractional shares.
2014-01-01 * buy VPMCX
Assets:Investments 9.66 VPMCX @ 103.52 USD
Assets:Bank 1000.00 USD
Again, the $1000 and the 9.66 shares are exact quantities. They do not
represent something that has been rounded. You do not have an extra,
invisible 0.0032 USD lying around. It is the $103.52 that is wrong.
But is it wrong, really? Is the cost basis calculated with 103.52 USD or
103.519668737 USD?
Correct or not, I think the bank and govt assume a cost basis calculated
using 103.52 USD, so that's the correct one.
Also, when you calculate your capital gains later, which of the prices should
you use?
Again, I think 103.52 is what you're supposed to use.
I agree that 103.52 is what the bank will use and what you are supposed to
use.
So one solution is to simply record the share price you paid instead of the
share price you were quoted. This is the same as Martin Machlmayr’s
suggestion to use ‘@@' instead of ‘@'. But as Martin also pointed out, there
is value in using ‘@‘, namely, your cost basis can match the bank’s report,
the pricedb gets an accurate market price, and you get an extra check that
you haven’t mistyped a number.
A different solution is for the program to replace the cost basis that you
specify with the true cost, as long as it is close enough. But this doesn’t
solve the problem that you might want to attach the bank-reported cost to
the posting, or see it in reports.
Both of these worry me, as per my other email, because that propagates cost
basis that is unexpectedly exact. I'd rather use the rounded, inexactly
calculated cost basis.
I'm pretty sure I agree.
One final solution, and what I have settled on for now, is a rounding
account. I insert one manually (with elided amount), but the program could
easily do this for you. It sweeps away whatever is left over, and has
accumulated 0.12 USD (in expenses) for me so far this year. The alternative
is that my double-entry accounting ledger is out of balance by 12 cents per
year. (Maybe not a big deal, but it bugs me.)
The point is, no matter how you decide to round the amounts, you have to
account for the rounding in some way or accept the fact that your system is
out of balance.
Note that either of these automated solutions could probably be implemented
using beancount plugins.
Yes, you could.
However, using a plugin you would have to compute each transaction's balance
amounts sum twice, which is somewhat expensive, so if this is a great
solution, I would consider adding it in the interpolation routine itself to
avoid the cost and use the one already computed. I'm not convinced this
should always be done though. (See at the end of this message.)
Weird things happening
If you don’t require each transaction to balance, you easily drift away from
overall balance. In Ledger:
D 1.00 USD
2014-01-01 Test
assets 1
Re: ledger vs hledger vs beancount or how to choose the right cli client
On Sep 7, 2014, at 8:12 AM, Martin Blais bl...@furius.ca wrote: I see 2.0beta: https://pypi.python.org/pypi/beancount Note that 'pip' disregards beta versions by default, which is why the 1.0 was installed. The same thing happens for me. Use 'pip --pre' when installing to allow prerelease versions. Nathan -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Changes to capital gains/losses makes final cost irrelevant
I am in favor of the recent changes to Equity:Capital Gains, etc, which allow
you to book the gains to whichever account you want. The downside is that the
final cost is now ignored. Here is an example:
2014-06-30 Sell stock
Assets:Stock -40 TWTR {$30} @ $50
Assets:Cash $2,000
Income:Capital Gains $-800
Now, change $50 to $5,000, and it still balances. The stock counts as quantity
* cost, and the gain/loss is quantity * ( basis-cost), and the gain/loss is
added to the total transaction, the end result is that the stock counts as
quantity * basis.
The first solution that comes to mind is some kind of special syntax that
allows you to capture the loss or gain.
2014-06-30 Sell stock
Assets:Stock -40 TWTR {$30} @ $50
Assets:Cash $2,000
Income:Capital Gains @@
This has the meaning “book gain/loss to Income:Capital Gains”. (The exact
syntax is not important for now; this is the first thing that came to mind.)
This will guarantee that the split between actual cash and gain/loss happens as
desired. In fact, you could even elide the other amount:
2014-06-30 Sell stock
Assets:Stock -40 TWTR {$30} @ $50
Assets:Cash
Income:Capital Gains @@
Thoughts?
Nathan
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: payee limiting question
On Jul 30, 2014, at 7:13 AM, Martin Blais bl...@furius.ca wrote: So then what does this one mean: ledger reg assets:receivable @CBI Is it to be or'ed? Yes -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Tracking contributions to an account
On Jul 21, 2014, at 6:34 AM, Martin Blais bl...@furius.ca wrote: I read up a little bit on HSAs out of curiosity. As far as I can tell, it looks like it behaves like an IRA where there's no withdrawal penalty when you take money out to pay for medical expenses. (Is this right?) Yes, that is right, except change “withdrawal penalty” to “withdrawal penalty or US federal tax”. I’m facing the same question with 401k as well, but the Health Savings Account is more complicated because you can’t just assume that every account increase is a contribution (like you probably can with a 401k). It is really just a regular account, and you might have interest or a refund from your doctor. Nathan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Tracking contributions to an account
On Jul 20, 2014, at 10:45 PM, Martin Michlmayr t...@cyrius.com wrote: Yes, you can match tags: ledger -f d reg tag(Taxes) =~ /^HSA*/' For me, this is matching everything with the “Taxes” tag, regardless of what I use for the regular expression. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Tracking contributions to an account
On Jul 21, 2014, at 8:26 AM, Jostein Berntsen jber...@broadpark.no wrote: On 21.07.14,06:45, Nathan Grigg wrote: On Jul 20, 2014, at 10:45 PM, Martin Michlmayr t...@cyrius.com wrote: Yes, you can match tags: ledger -f d reg tag(Taxes) =~ /^HSA*/' For me, this is matching everything with the “Taxes” tag, regardless of what I use for the regular expression. This should work: ledger reg tag taxes=HSA.* Yes, that works. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Tracking contributions to an account
I’ve been thinking about how to track transfers into a certain account, for example, a Health Savings Account or 401k. For example: 2014-06-01 Transfer Assets:Health Savings $500 Assets:Checking 2014-06-10 Doctor Expenses:Health $200 Assets:Health Savings 2014-07-01 Interest Assets:Health Savings $0.25 Income:Interest For tax purposes, I care about the total amount transferred in ($500 in this case). Solution 1: Tags. 2014-06-01 Transfer Assets:Health Savings $500 ; Taxes: HSA Contribution Assets:Checking Now leger bal Assets:Health Savings” and “%Taxes=HSA Contribution” gives me $500. The downside is that tags can be difficult to work with. (For example, can you match a tag value by regex? Not that I can see) Solution 2: extra accounts. I’ve put them under Expenses, because that seems most apt, but still a little weird. 2014-06-01 Transfer Expenses:HSA:Contribution $500 Expenses:HSA:Transfer -$500 Assets:Health Savings $500 Assets:Checking Now leger bal “Expenses:HSA:Contribution gives me $500. The downside is that this is more verbose. You also have a more or less meaningless account in Expenses:HSA:Transfer. You can use automated transactions to clean up data entry, but it still may not be worth it. Also, I’m soured on automatic transactions since rediscovering bug 983 http://bugs.ledger-cli.org/show_bug.cgi?id=983. Does anyone else try to solve this problem? Is there a solution I’m overlooking? Nathan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 'equity' cannot accept virtual and non-virtual postings to the same account
On May 19, 2014, at 5:04 PM, Martin Michlmayr t...@cyrius.com wrote: 2014-05-19 * Booking tithe Assets:US:BofA:Checking -300 USD Assets:US:BofA:Checking:Tithe300 USD Now you're creating an account that doesn't exist, which I don't find ideal. The real problem is that you've created an artificial dependency between Tithe and your Checking account. The good thing about an accounting system is that you can treat your finances as one big pot of money, and Expenses:Groceries doesn't care which account you use to pay for it. Another way to think about this case is that you have a liability, because you owe tithe. But you also have the money still, which is an asset. 2014-05-19 * Booking tithe Assets:Tithe 300 USD Liabilities:Tithe -300 USD 2014-05-20 * Paying tithe Expenses:Tithe 300 USD Assets:Tithe -300 USD Liabilities:Tithe 300 USD Assets:Checking -300 USD Michlmayr would complain that Assets:Tithe isn't actually an account, but neither are your Expenses, so I'm okay with that. Blais would probably use Virtual:Tithe instead, as would I, as a way to distinguish between real assets and pretend assets. Although I would argue you do have a very real $300 set aside, it just doesn't happen to live in an account. You could also just use an unbalanced virtual account for Liabilities:Tithe, but then you have to stop and think about what the difference between --real and --virtual is, whereas in this case, it is clear what you mean by what is my balance excluding Assets:Tithe? Of course a real accountant would just do this: (accrual based accounting) 2014-05-19 * Booking tithe Expenses:Tithe 300 USD Liabilities:Tithe -300 USD 2014-05-20 * Paying tithe Liabilities:Tithe 300 USD Assets:Checking -300 USD But this records the expense on a different day than when you actually paid it. That would be a problem if, for example, you live in the US and wanted to claim a tax deduction for the tithe, in which case you must claim the deduction for the year the tithe was actually paid (cash based accounting). Nathan -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Aligning Ledger commodities in Vim
Hi, I wrote a Vim command to align the commodity values of Ledger transaction. It might be useful to someone else on here. https://github.com/nathangrigg/vim-ledger/commit/80955bb07 Nathan -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
