"Failed to categorize posting 1"

[wshar...@gmail.com]

I'm a long-time Ledger user but new to beancount.  I moved, because I think I see functionality I can use right now (so thanks!).

I'm starting by trying to handle some investments, and I'm stuck on a seemingly simple transaction that gets the above error.  

The goal:

• Open a few accounts for a stock.  In this case, I have an account of certificated shares and an account of book-entry shares at a broker.
• Acquire shares as certificates, and then move them to book entry.

The code (excerpted and cleaned*)

1970-01-01 open Assets:Certs:AAPL

1970-01-01 open Assets:MYBroker:AAPL

1983-01-05 * "A Note"

    Assets:Certs:AAPL        20 AAPL {34.31 USD, 1983-01-05}

    Assets:Cash:Basis

1983-04-05 * "A Note"

    Assets:Certs:AAPL        18 AAPL {47.57 USD, 1983-04-05}

    Assets:Cash:Basis

1983-05-10 * "stock move"

    Assets:MYBroker:AAPL           20 AAPL {1983-01-05}

    Assets:MYBroker:AAPL           18 AAPL {1983-04-05}

    Assets:Certs:AAPL          -20 AAPL {1983-01-05}

    Assets:Certs:AAPL          -18 AAPL {1983-04-05}

; zero local shares now

1983-05-11 balance Assets:Certs:AAPL 0 AAPL 

If I run bean-report filename print on that (real) file, i get "beancount:84:      Failed to categorize posting 1", where 84 points to the first leg of the "stock move" transaction.  I also get the same error on line 85, the second leg.  If I swap the first two legs with the second two, the error follows the "MBroker" legs.

The subsequent balance assertion obviously fails.

Any tips?  It's probably obvious, but I can't see it.

Thanks,

Bill

* Has anyone ever made a routine to "clean"--remove PII--from a beancount file?  I don't really want to share my financial information, but I know it's often useful to share actual data files.  It would be nice to have a script that could take entries such as Assets:Certificate:AAPL and turn turn it into something like Assets:LevelA1:LevelB1 or the like.
  

[Bill Harris]

I copied the previously-posted excerpt to a file and ran it to see if it worked.  That showed me I left out one line from the original file.  Here's the code that works:

1970-01-01 open Assets:Certs:AAPL

1970-01-01 open Assets:MYBroker:AAPL

1970-01-01 open Assets:Cash:Basis

1983-01-05 * "A Note"

    Assets:Certs:AAPL        20 AAPL {34.31 USD, 1983-01-05}

    Assets:Cash:Basis

1983-04-05 * "A Note"

    Assets:Certs:AAPL        18 AAPL {47.57 USD, 1983-04-05}

    Assets:Cash:Basis

1983-05-10 * "stock move"

    Assets:MYBroker:AAPL           20 AAPL 

    Assets:MYBroker:AAPL           18 AAPL

    Assets:Certs:AAPL          -20 AAPL

    Assets:Certs:AAPL          -18 AAPL 

; zero local shares now

1983-05-11 balance Assets:Certs:AAPL 0 AAPL 

What seems to be key is dropping the date specifier on the MYBroker shares.  

Is it safe to assume that the bought date (and the basis) comes along with the stock move?  I didn't think it did, and I haven't found a report that shows that yet.

Bill

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/-8YsnPkuLLc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/9c9dcc5f-72bf-44b2-aaf9-4e0c07cbff77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Bill Harris                   
http://makingsense.facilitatedsystems.com/

[Martin Blais]

On Tue, Aug 28, 2018 at 10:38 AM Bill Harris <wshar...@gmail.com> wrote:

I copied the previously-posted excerpt to a file and ran it to see if it worked.  That showed me I left out one line from the original file.  Here's the code that works:

1970-01-01 open Assets:Certs:AAPL

1970-01-01 open Assets:MYBroker:AAPL

1970-01-01 open Assets:Cash:Basis

1983-01-05 * "A Note"

    Assets:Certs:AAPL        20 AAPL {34.31 USD, 1983-01-05}

    Assets:Cash:Basis

1983-04-05 * "A Note"

    Assets:Certs:AAPL        18 AAPL {47.57 USD, 1983-04-05}

    Assets:Cash:Basis

1983-05-10 * "stock move"

    Assets:MYBroker:AAPL           20 AAPL 

    Assets:MYBroker:AAPL           18 AAPL

    Assets:Certs:AAPL          -20 AAPL

    Assets:Certs:AAPL          -18 AAPL 

; zero local shares now

1983-05-11 balance Assets:Certs:AAPL 0 AAPL 

What seems to be key is dropping the date specifier on the MYBroker shares.  

It checks, but it didn't work.

 

Is it safe to assume that the bought date (and the basis) comes along with the stock move?  I didn't think it did, and I haven't found a report that shows that yet.

It did not.

Use bean-doctor to view how the transaction gets completed and booked:

bean-doctor context stockmove.beancount 16

Hash:46c2aeba25e78d18ef8072dafabe47ae

Location: /home/blais/r/q/beancount-data/user/wharris13/stockmove.beancount:14

------------ Balances before transaction

  Assets:MYBroker:AAPL

  Assets:Certs:AAPL                       20 AAPL {34.31 USD, 1983-01-05}

  Assets:Certs:AAPL                       18 AAPL {47.57 USD, 1983-04-05}

------------ Transaction

1983-05-10 * "stock move"

  Assets:MYBroker:AAPL   20 AAPL

  Assets:MYBroker:AAPL   18 AAPL

  Assets:Certs:AAPL     -20 AAPL

  Assets:Certs:AAPL     -18 AAPL

------------ Balances after transaction

* Assets:MYBroker:AAPL                                            38 AAPL

  Assets:Certs:AAPL                       20 AAPL {34.31 USD, 1983-01-05}

  Assets:Certs:AAPL                       18 AAPL {47.57 USD, 1983-04-05}

* Assets:Certs:AAPL                                              -38 AAPL

But let's get back to your first question.

The failure to categorize is in the booking: the first stage of booking is to attempt to associate each posting to a currency group. USD with USD. EUR with EUR, etc. as those may all occur on the same transaction. Then it will proceed in interpolating a single missing amount in each currency group.

In your example, you have an inventory with a negative number of AAPL shares and two augmenting legs (the first two). It has no way to know that these are to be  priced in USD, so it says "I don't know which currency this is, I failed to categorize those. If you add {USD, <date>} on the first two legs, they will categorize, and the other two will be booked against the inventory state and also get categorized as such (without having to put USD on them).

Finally, the partial specification, say, just specifying the date, is used to narrow down the lot against the list of possible lots in the Inventory of the account before applying the transaction, but NOT against the list of other postings. That would be an interesting power to add to the booking system, as it could disambiguate this case.

More constraints could potentially be added to make a tighter booking system: one could assume a single currency group in each transaction when there's at least one posting at cost. One could also assume that in that account a commodity is never priced in terms of two different currencies. But frankly, the book constraints code is really already complicated enough... these seem like corner cases to me. It would be nice if they could be inferred, but it's definitely a lot of work to handle all the potential cases properly.

I would say:

- If this isn't a common occurrence, just put all the information about costs explicitly.

- If this is a common occurrence, write a plugin that will automatically insert the missing informations based on your assumptions.

I hope this helps,

 

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAOBquGqaearjAvRWor%3DeXXnz2US31o5_okTiz8srBo_Yv3N93Q%40mail.gmail.com.

[Bill Harris]

Martin,

Thanks.  In short (and in my words), I failed to associate assets properly.  When I added both dates and costs to assets, it worked.

I figured it might be useful to create a "canonical" (for my current purpose) file that covers what I think I want to do right now: track a set of related investments through ISO acquisition, splits, spin-offs, and sales.  I've attached the file, and it seems to work.  I thought I'd see if you or others had suggestions of ways to make it more idiomatic Beancount before I expanded it to my full situation, and I did have a couple of questions:

• Do the options, commodities, and open sections look reasonable?  I think they do.
• It seems easy to think I should have a separate "basis" account for each lot, but that's just the value of the asset (the stock).  
• This example covers an employee stock purchase plan.  As such, some of the cost of acquisition was borne by the company and some by me.  I needed to initialize a cash account to pay for my shares, but I didn't want to recreate my entire financial system as of the time, so I simply dumped an arbitrary $10K into checking.  
• Does this seem like an idiomatic way to do that?  Do you have a better suggestion?
• From the Language Syntax manual, I thought padding might work, but, if so, I obviously don't understand the pad command (see the commented lines in "Make cash available").  What am I doing wrong?
• The remaining sections--Acquire initial shares, Transfer shares to book-entry, Stock split, Stock sale, and Spin-off of AB--all seem to work, so I presume they're okay, right?
• That company also granted "free" "anniversary" shares.  I presume I would treat them the same way, except that the cost of those shares would all be paid out of income from the company, right?
• For an ISO, there are two issues:
• Tracking the ISO before it's exercised:  I don't have any open ISOs, and so I can ignore that.
• Tracking shares purchased through an ISO: that's just like the "anniversary" shares, right?  The cost is all borne by the company.
• Finally, in Trading with Beancount, you show a PnL account you've created to track capital gains, and you associate it with the broker.  I could see wanting to know (in the language of this example) PnL for AA and AB separately, too.  That's easy to do with sub-accounts, but I might also want to track PnL for AA and AB, even when some of those assets are held in certificates and the rest at BrokerA.  Have you found a best practice for doing that sort of thing?

Bill

[Martin Blais]

On Thu, Aug 30, 2018 at 11:38 AM Bill Harris <wshar...@gmail.com> wrote:

Martin,

Thanks.  In short (and in my words), I failed to associate assets properly.  When I added both dates and costs to assets, it worked.

I figured it might be useful to create a "canonical" (for my current purpose) file that covers what I think I want to do right now: track a set of related investments through ISO acquisition, splits, spin-offs, and sales.  I've attached the file, and it seems to work.  I thought I'd see if you or others had suggestions of ways to make it more idiomatic Beancount before I expanded it to my full situation, and I did have a couple of questions:

• Do the options, commodities, and open sections look reasonable?  I think they do.

Yes. Looks right to me.

 

• It seems easy to think I should have a separate "basis" account for each lot, but that's just the value of the asset (the stock).  

The basis is stored along with each lot, you don't need to account for it any other way.

• This example covers an employee stock purchase plan.  As such, some of the cost of acquisition was borne by the company and some by me.  I needed to initialize a cash account to pay for my shares, but I didn't want to recreate my entire financial system as of the time, so I simply dumped an arbitrary $10K into checking.  
• Does this seem like an idiomatic way to do that? 

Yes, and no. 

The method you use is fine, but don't use an arbitrary amount for no reason, that might just be misleading.

You can just leave it to zero, with the value of the account going negative (that's more obviously remind you you're not tracking it).

• Do you have a better suggestion?

Or... choose a real date to start with, and set the balance - as you did - to the real account balance on that date, and there onwards start ingesting the transactions for that account.

 

• From the Language Syntax manual, I thought padding might work, but, if so, I obviously don't understand the pad command (see the commented lines in "Make cash available").  What am I doing wrong?

Balance entries are defined to apply first in each day (they're sorted like that).

Your Pad entry must have a date before that.

Make it on 1/4 and it'll work.

Use this to confirm it: bean-query <filename> print

 

• The remaining sections--Acquire initial shares, Transfer shares to book-entry, Stock split, Stock sale, and Spin-off of AB--all seem to work, so I presume they're okay, right?

Looks right to me! 

• That company also granted "free" "anniversary" shares.  I presume I would treat them the same way, except that the cost of those shares would all be paid out of income from the company, right?

I bet you their cost showed up on your W2.

Yes.

 

• For an ISO,

huh-ho.

I haven't dealt with ISOs in Beancount. (Take my answers with a grain of salt below.)

There are some people on this list with ISO, maybe they can chip in with some real experience.

I went out and read about those a bit; they look like zero-valued call options vested to you over time.

Here's my limited understanding:

- you are "granted" some total amount of options

- these are "vested" to you over a schedule; they hvae zero value (you can't sell the options, there's no time value, only intrinsic)

- if you exercise, you buy (with after tax money) the options; that's the cost basis, e.g. B.

- when you exercise them, there's no tax consequence (if the stock at vesting time is worth Sv, you only pay B, and Sv - B is not taxable yet)

- say later on, you want to sell those stock and the stock is worth St then

- when you actually sell them, you're taxed a special variant of capital gains tax on St - B

(Hopefully I got some of this right.)

Beancount doesn't do anything special for taxes, it just allows you to track cost basis; 

it's up to you to know that account so-and-so is to be reported in some particular way.

 

• there are two issues:
• Tracking the ISO before it's exercised:  I don't have any open ISOs, and so I can ignore that.

I would definitely track those as they grant and vest.

Do this by creating currencies.

I do this myself for tracking shares from my employer (they're RSU, not ISO, but it still applies all the same).

I want to know how much remains that's unvested, for instance.

Create an an unvested currrency at zero price:

2013-01-28 commodity GOOG.UNVEST

  name: "Unvested award of Google Class C shares."

  export: "IGNORE"

  assetcls: "Unvested"

  strategy: "N/A"

2013-01-28 price GOOG.UNVEST   0 USD

(Ignore the metadata, or if you're really curious check out how I use it to update a Google Sheets doc for investing:

http://bitbucket.org/blais/beancount/src/tip/beancount/projects/export.py)

Then I have accounts to keep track of total received awards and :

2013-01-28 open Income:US:GoogleInc:Awards                             GOOG.UNVEST

2014-01-28 open Expenses:GoogleInc:Vested                              GOOG.UNVEST

Then if I receive a new award, that's deposited in a per-award account:

2017-03-20 open Assets:US:GoogleInc:Unvested:C123456

2017-03-20 * "Award C1234567 (for $XXXXX based on stock price of XXXXX USD)"

  Assets:US:GoogleInc:Unvested:C123456                                  XX GOOG.UNVEST

  Income:US:GoogleInc:Awards                                           -XX GOOG.UNVEST

Then each time you vest, I receive the stock and,spend away some of the corresponding unvested amounts, as a fictional example:

2017-03-25 * "Conversion into shares" #award-C123456

  doc: "2017-03-29.Restricted_Stock_Release_Detail_Report.C123456.pdf"

  Assets:US:Broker:GOOG                    2 GOOG {612.3400 USD}

  Assets:US:GoogleInc:GSURefund

  Assets:US:GoogleInc:Unvested:C123456    -5 GOOG.UNVEST

  Expenses:GoogleInc:Vested                5 GOOG.UNVEST

(The above conversion is special to how my employer implements RSUs; they sell a portion of the received shares to convert for taxes and you receive the remaining shares and the cash difference. In this example, 5 shares are vested, 3 are sold to pay for the taxes (on W2), 2 are deposited to the account, and the "GSURefund" account is debited. That account is filled up in another transaction paired with each conversion, for which a pay stub is received that details all the tax amounts (federal, state, medicare, etc.) and net amount deposited to this GSURefund transfer account. The non-converted amount is sent as a check later and I assert the remainder is 0 i.e., refund has been paid.)

Anyhow, maybe ignoring the last bit, everything above could remain the same.

Here's one example of how you could do this, you may have to get a little creative with commodities:

;; Example tracking of ISO options.

;; Define three commodities: unvested options, vested options, and actual shares.

2013-01-28 commodity ACME.UNVEST

  name: "Unvested award of Acmeshares."

2013-01-28 commodity ACME.ISO

  name: "Vested ISO option of Acme shares."

2013-01-28 commodity ACME

  name: "Acme Inc. equity shares"

2013-01-28 price ACME.UNVEST   0 USD

2013-01-28 price ACME.ISO      0 USD

;; Define accounts to track awards.

2013-01-28 open Income:US:AcmeInc:Awards     ACME.UNVEST

2014-01-28 open Expenses:AcmeInc:Vested      ACME.UNVEST

2014-01-28 open Expenses:AcmeInc:Exercised   ACME.ISO

;; Define broker accounts. These should correspond to real accounts somewhere

;; (e.g., Schwab, ETrade, or otherwise).

2013-01-28 open Assets:US:Broker:Cash          USD

2013-01-28 open Assets:US:Broker:Options       ACME.ISO

2013-01-28 open Assets:US:Broker:ACME          ACME

2013-01-28 open Income:US:Broker:VestedOptions ACME.ISO

;; Track awards like this;

2017-03-20 open Assets:US:AcmeInc:Unvested:C123456

2017-03-20 * "Award C1234567 (for $XXXXX based on stock price of XXXXX USD)"

  Assets:US:AcmeInc:Unvested:C123456    1000 ACME.UNVEST

  Income:US:AcmeInc:Awards             -1000 ACME.UNVEST

;; When an option vests, spend it and deposit it to your broker account.

2017-03-25 * "Vesting" #award-C123456

  Income:US:Broker:VestedOptions         -15 ACME.ISO

  Assets:US:Broker:Options                15 ACME.ISO

  Assets:US:AcmeInc:Unvested:C123456     -15 ACME.UNVEST

  Expenses:AcmeInc:Vested                 15 ACME.UNVEST

;; Later on when you exercise the option, save the amount you paid as the cost

;; basis.

2017-03-25 * "Exercise" #award-C123456

  Assets:US:Broker:Options               -10 ACME.ISO

  Expenses:AcmeInc:Exercised              10 ACME.ISO

  Assets:US:Broker:ACME                   10 ACME {200.00 USD}

  Assets:US:Broker:Cash                -2000 USD

 

• Tracking shares purchased through an ISO: that's just like the "anniversary" shares, right?  The cost is all borne by the company.

Here's another example of the same, this time tracking each of the awards with its exercise price as the cost basis and using less accounts (perhaps a bit simpler), taking care not to use USD for unvested, unexercised things:

;; Example tracking of ISO options.

;; Define four commodities: unvested cash,  unvested options, vested options, and actual shares.

2013-01-28 commodity USD.UNVEST

  name: "Unvested dollars (worthless, used to track exercise price of ISOs)."

2013-01-28 commodity ACME.UNVEST

  name: "Unvested award of Acmeshares."

2013-01-28 commodity ACME.ISO

  name: "Vested ISO option of Acme shares."

2013-01-28 commodity ACME

  name: "Acme Inc. equity shares"

2013-01-28 price ACME.UNVEST   0 USD

2013-01-28 price ACME.ISO      0 USD

2013-01-28 price ACME.ISO      0 USD

;; Define accounts to track awards.

2013-01-28 open Income:US:AcmeInc:Awards     USD.UNVEST

2014-01-28 open Expenses:AcmeInc:Exercised   USD.UNVEST

;; Define broker accounts. These should correspond to real accounts somewhere

;; (e.g., Schwab, ETrade, or otherwise).

2013-01-28 open Assets:US:Broker:Cash          USD

2013-01-28 open Assets:US:Broker:Options       ACME.ISO

2013-01-28 open Assets:US:Broker:ACME          ACME

;; Track awards like this, keeping track of the cost basis;

2017-03-20 open Assets:US:AcmeInc:Unvested:C123456

2017-03-20 * "Award C1234567 (for $XXXXX based on stock price of XXXXX USD)"

  Assets:US:AcmeInc:Unvested:C123456    1000 ACME.UNVEST {200 USD.UNVEST}

  Income:US:AcmeInc:Awards           -200000 USD.UNVEST

;; When an option vests, spend it and deposit it to your broker account.

2017-03-25 * "Vesting" #award-C123456

  Assets:US:AcmeInc:Unvested:C123456     -15 ACME.UNVEST {200 USD.UNVEST}

  Assets:US:Broker:Options                15 ACME.ISO {200 USD.UNVEST}

;; Later on when you exercise the option, save the amount you paid as the cost

;; basis.

2017-03-25 * "Exercise" #award-C123456

  Assets:US:Broker:Options               -10 ACME.ISO {200 USD.UNVEST}

  Expenses:AcmeInc:Exercised            2000 USD.UNVEST

  Assets:US:Broker:ACME                   10 ACME {200.00 USD}

  Assets:US:Broker:Cash                -2000 USD

One advantage of that second example is the cost basis. 

Note that I'm careful not to price it in USD, I wouldn't want the value to show up on the balance sheet, because it's not exercised.

You could even automate some of the regular legs by writing a plugin if some of the redundancy bothers you.

 

• Finally, in Trading with Beancount, you show a PnL account you've created to track capital gains, and you associate it with the broker.  I could see wanting to know (in the language of this example) PnL for AA and AB separately, too.  That's easy to do with sub-accounts, but I might also want to track PnL for AA and AB, even when some of those assets are held in certificates and the rest at BrokerA.  Have you found a best practice for doing that sort of thing?

Sum these things as an SQL query. You can use regular expressions  in the account name 

e.g.

select account, sum(position) where account ~ 'Assets:Broker.*:PnL'

or something like that.

You can define those as custom queries with a Query directive, so after that they're easy to run by name, e..g

bean-query $L run isopnl

 

Also consider adding some of the more pedantic plugins for more certainty

sellgains

onecommodity

etc.

Overall the examples in the files are much simpler than the reality, but the system extends to a lot more, it's quite powerful.

For example, these days I'm buying put protection on options and trying to generate income to compensate by selling near-dated calls and puts on indexes, even went through assignment for the first time a few weeks ago, tracking everything has been no problem. The only quirks are that I'm creating a new commodity name for each option, and in the long run that might not make sense, maybe I'll want to automate some of that, either in my importer or with a plugin. OTOH it's convenient because each option purchase has a unique strategy for it (hedging/protection, income, etc.) and I'm able to add metadata to the commodity directive and that metadata gets joined in with the positions and automatically exported to my google sheets, where I have a Strategy column and I can filter the list of positions per-strategy, and even plot the risk profile.

In the past I have had cases of dividends, cost basis adjustments, transfers, currency changes, and a bunch of other things.

It works.

The main missing feature for investments IMO is automatically merging cost basis for doing average cost tracking.

Everything else works, despite the fact that sometimes, as in your thread, you may have to provide it with a bit info than it seems.

Interpolation could be improved for sure, with more assumptions (sacrificing some generality).

I hope this helps,

 

Bill

--

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/d29804b8-04c3-4dc7-a8e2-25549db1ede0%40googlegroups.com.

[Bill Harris]

Thanks, Martin, for the comprehensive response!  I'll catch a few highlights right now.

I think my original showed a stock split in which I destroyed the original shares and added new ones with the same date, something like

2001-06-01 * "stock split"

    Assets:BrokerA:AA           -20 AA {40.00 USD, 2001-01-05} 

    Assets:BrokerA:AA           -18 AA {50.00 USD, 2001-04-05}

    Assets:BrokerA:AA           40 AA {20.00 USD, 2001-01-05} 

    Assets:BrokerA:AA           36 AA {25.00 USD, 2001-04-05}

I sense this maintains the issue date of the original shares on the new 40 AA and 36 AA while keeping them as distinct lots.  That seems useful to me if they are certificates, for the 40 sh. could be a different piece of paper from the 36 sh.  It could be important if you direct the sale of specific lots: "Sell 20 sh. AA acquired at 20 USD").  (As I understand it, once you start selling by lot, then it's hard to sell by average cost.  It's even harder to change what you did years ago.)

To make that a bit easier, I added labels to the certificates.something like this:

2001-06-01 * "stock split"

    Assets:Cert:AA           -20 AA {40.00 USD, 2001-01-05, "C1"} 

    Assets:Cert:AA           -18 AA {50.00 USD, 2001-04-05, "C2"}

    Assets:Cert:AA           40 AA {20.00 USD, 2001-01-05, "C3"} 

    Assets:Cert:AA           36 AA {25.00 USD, 2001-04-05, "C4"}

Except that's not how it works, right?  Typically they'd just send out the new, incremental shares:

2001-06-01 * "stock split"

    Assets:Cert:AA           -20 AA {40.00 USD, 2001-01-05, "C1"} 

    Assets:Cert:AA           -18 AA {50.00 USD, 2001-04-05, "C2"}

    Assets:Cert:AA           20 AA {20.00 USD, 2001-01-05, "C1"} 

    Assets:Cert:AA           18 AA {25.00 USD, 2001-04-05, "C1"}

    Assets:Cert:AA           20 AA {20.00 USD, 2001-01-05, "C3"} 

    Assets:Cert:AA           18 AA {25.00 USD, 2001-04-05, "C4"}

That updates the basis on C1 and C2 and adds the new C3 and C4.  Now each labelled stock has the right date and basis.

But that's not how it works, either, right?  Typically they'd just send out one certificate for 38 sh.:

2001-06-01 * "stock split"

    Assets:Cert:AA           -20 AA {40.00 USD, 2001-01-05, "C1"} 

    Assets:Cert:AA           -18 AA {50.00 USD, 2001-04-05, "C2"}

    Assets:Cert:AA           20 AA {20.00 USD, 2001-01-05, "C1"} 

    Assets:Cert:AA           18 AA {25.00 USD, 2001-04-05, "C1"}

    Assets:Cert:AA           38 AA {22.37 USD, 2001-01-05, "C3"} 

Now C3 has a basis that's 22.3684210526 USD (or 22.37 USD -- the weighted average of the new 20 and 18 AA).

Is that the way you'd track it?  (I realize that's both a tax and a Beancount accounting question.)  I think both the IRS and Beancount would be happy, at least if I never sell, oh, 25 sh. of C3 and keep the remaining 13 AA out of that lot.  Even if I did, in a practical sense, that probably leads to a de minimus" error, I'm hoping.

If those lots were at a broker, then I'd now have 76 sh. AA there.  I would do myself a service by identifying the lot to sell as being from one or more of C1, C2, and/or C3, and I would make my life a bit easier (in an audit, at least) if I sold C3 all at one time.  Make sense?

I don't think I've ever done that with a certificate, but, once it's lumped at a broker, it might be easy to do inadvertently.

On Fri, Aug 31, 2018 at 7:40 PM Martin Blais <bl...@furius.ca> wrote:

I hope this helps,

Quite a bit; thanks!

Bill

--

Bill Harris                   

[Bill Harris]

Ooh...not quite.  I put the weighted average basis on C3, which I think is correct.  What acquisition date should I use?  I think the tax word is "Various", but Beancount doesn't seem to like that.  Perhaps the best choice is to use the latest of the underlying dates -- April, in this case -- and add a note to treat the acquisition date manually on the tax return.

Sound reasonable?

Bill 

[Martin Blais]

I think it's up to you how to track it. Using unique labels will (a) allow you to easily specify lots when you sell, i.e., you just use the label, as in {"C2"} on a reducing posting, and (b) ensure that the lots with distinct labels won't get merged (even if they have the same cost and acquisition date). The thing that matters is that you keep the cost basis correctly. Personally I like your first method best (with no labels).

If those lots were at a broker, then I'd now have 76 sh. AA there.  I would do myself a service by identifying the lot to sell as being from one or more of C1, C2, and/or C3, and I would make my life a bit easier (in an audit, at least) if I sold C3 all at one time.  Make sense?

I always identify specific lots when I sell (if I'm allowed to).

 

I don't think I've ever done that with a certificate, but, once it's lumped at a broker, it might be easy to do inadvertently.

On Fri, Aug 31, 2018 at 7:40 PM Martin Blais <bl...@furius.ca> wrote:

I hope this helps,

Quite a bit; thanks!

Bill

--

Bill Harris                   

--

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAOBquGq7XN0-kTHcMO%3D_EpP3AvrzgsHm-oRKkgO_UsWR1ziizQ%40mail.gmail.com.