Spin-off fails pass-thru parent holding period to child inv.

[Dean]

FM is amazing and rock-solid. I depend on it daily. There are very few bugs. Here's an important one, particularly at tax-prep time.

Potential under-estimation of capital gains holding period for spin-offs

[Edit | Investment Data | Spin-off]

Although the dialog successfully creates a child investment from a parent investment, it fails to capture the holding period of the parent. This error understates the holding period of the CHILD and may produce a spurious capital gains holding period value on Capital Gains - FIFO report.

Example from my transaction set [symbols altered for posting here]: Purchase date of PARENT (in FM transaction set) several years prior to PARENT spin-off of CHILD on 3/3/2007. Sold CHILD on 8/17/2007.

Capital Gains - FIFO report mis-categorizes CHILD as STCG. Should be LTCG.

Attempted repair: Closed CHILD. Saved investments and portfolio. Removed CHILD.dat. Exited FM. Started FM. Opened portfolio. Selected PARENT investment in Portfolio Editor. Ran the spin-off dialog. Created new CHILD from PARENT. Entered all appropriate information as shown in Help facility. Downloaded the remaining distribution (dividend) and sale transactions for CHILD. Ran the Capital Gains - FIFO report. Same error.

Aside: On download of CHILD transactions, there was a 'purchase' item from my brokerage firm on the spin-off date. As this was redundant with the 'purchase' created via the spin-off dialog of FM, I did not accept the the broker's 'purchase' item [left it's box unchecked]. After download, the Investment Transactions custom report is clean. All appropriate data and cash-account offset entries are present and accurate.

Thank you for reviewing this situation. 'tis the season to tally Capital Gains!

All the best,

Dean

[Mark]

Hi Dean,

You raise a good point. As a quick background, the spin-off dialog is used to record 2 transactions:

1) A "Return of Capital" distribution in the parent
2) A purchase in a new child investment

Both of these are recorded on the same date, so as to keep your portfolio value consistent across the date of the spin-off. The value of the Return of Capital distribution is the same as the value of the purchase in the child. The Return of Capital distribution lowers the cost basis in the parent, and the purchase establishes the cost basis of the child.

This method does establish the cost basis date in the child on the date of the spin-off. There is nothing special about this purchase, it is just as if you bought the shares in the child on this date. You can record all of this without using the spin-off dialog, and the results would be the same. I'll have to give some thought to how to deal effectively with this acquisition date problem. Some ideas:

1) Change the purchase date in the child to the date you originally purchased the parent shares. If you purchased the parent over multiple transactions, this could mean breaking the purchase up into multiple transactions on these dates. The down side to this approach is that your portfolio value is not consistent, because you would be owning the child before you actually got it, and would inflate your overall portfolio value totals for this time period.

2) Modify FM to track a "cost basis" purchase date which is different than the actual purchase date. This seems like the best solution, but it isn't available today. This would need to be implemented in such a way as to not cause too much confusion for normal buys/sells.

If you have any thoughts or other ideas on a good way to implement this support, please let me know.

[Dean]

Mark,

Thanks for your reply. Here are some possible solutions:

1st implement a manual override for the Short Term / Long Term designation. This is vastly superior to entering false purchase dates.

-- not knowing the internals of FM, I don't know if it would be possible to restrict such overrides to the context of spin-off. I suspect not.

2nd revise the transaction object, adding the necessary new field(s) for "basis purchase date" (which could be imported from the parent transaction in the spin-off procedure, and would serve as the date the CG holding-period determination).

-- sounds like a much bigger step. Again, not knowing the hidden aspects of your data model nor the internals of your implementation, I am only guessing

3rd -- I suppose you could remove the capital gains reports from the program. But since that is a major selling feature (one of the main ones that I need, for example) -- this seems like a bad solution.

4th -- you could warn users that the CG reports are unreliable, and instruct them (even include a tutorial or a script) to export all capital gains basis reports to a spreadsheet (e.g. Open Office, etc) and edit appropriately. This less unsatisfactory than #3, but also opens several cans of worms for your marketing and for support problems down the road (for example, how many scripts for how many versions of open and proprietary programs would you support for this essential feature of your software?).

I realize this is a challenging issue.

----------------

In summary: This is a dangerous bug. It is already causing folks to generate bad capital gains reports that may be off by tens of thousands of dollars -- and if they don't know the tax law, or are out-of-time, and rely on these reports, they could make serious errors in their tax computation and financial plans. I was fortunate to notice them before acting on the report. Please escalate this issue. I am willing to contribute time to the project. I want FM to thrive. It has great potential.

Dean

[Mark]

Hi Dean,

Thanks for the ideas. It seems the best solution so far is to implement a feature to have a separate 'cost basis' date that differs from the 'purchase' date. The spin-off dialog would have to query the user which accounting method they've been using, and then enter possibly more than 1 purchase in the child. For example, there could be one purchase for long term and one for short term. Actually, you would need 1 transaction for every short term holding in the parent, as some of them may become long term at different points, so they would each have a different 'cost basis' date. You could lump all the outstanding long term shares into a single long term purchase in the child. This is a big change, but seems manageable.

[Mark]

Hi Dean,

I was curious how Quicken handles this situation, so I did some research. Quicken gives you 2 choices, you can either record the spin-off as taxable, in which case it handles it the same as Fund Manager does today, by recording a Return of Capital and a single child purchase on the spin-off date.

Quicken also offers a non-taxable spin-off, where it records both a RofC and purchase for every open lot in the parent. These 2 transactions are dated the same as the original parent purchases. This works fine for the capital gains reports, but has the drawback that if you were to look at the portfolio value on any date after a parent purchase and prior to the spin-off, the portfolio value is overstated by the amount of the spin-off. This doesn't seem like an ideal solution for this reason.

Both of these methods can be achieved in Fund Manager today. The spin-off dialog can be used to record the first (taxable) method, or the non-taxable method could be accomplished with manual entry of the Return of Capital and child purchases. This non-taxable method could be a lot of work to enter, especially if you have many transactions.

It seems a good solution would be to modify the spin-off dialog to allow the user to choose between a 'taxable' and 'non-taxable' spin-off. The taxable case would be the same as how it is handled today. The non-taxable case would record 1 or more purchases in the child, dated the same as the spin-off date, but each of these purchases would have a separate 'cost basis' date, which is the same as the dates where the parent was originally purchased. One purchase could lump all the long term open shares, and then there would be one purchase for each short term open share. There would also still be a single Return of Capital distribution in the parent on the spin-off date. The non-taxable case would also have to prompt the user for which accounting method they've been using, as that would determine which shares were still open on the spin-off date.

[Mark]

Just wanted to post an update to this... Version 9.0 will support tax-free spin-offs (in addition to the current taxable ones).

A new "Transfer In" transaction will be included in 9.0 and the tax-free spin-off will utilize this new transaction type. The Transfer In transaction allows a separate acquisition date/value from the tax cost basis date/value. The tax-free spin-off will record 1 Transfer In transaction per open lot in the parent at the time of the spin-off. Each Transfer In transaction will have a cost basis date the same as the original purchase date of the parent's open lot.