Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AGI increases under TCJA in 2018, the excess business loss rule, and possible implications for Tax-Calculator and taxdata #2516

Closed
donboyd5 opened this issue Dec 11, 2020 · 3 comments

Comments

@donboyd5
Copy link
Contributor

donboyd5 commented Dec 11, 2020

Summary

This is related to #2513.

In a project related to the TCJA and New York with @MattHJensen, I have learned that Tax-Calculator causes AGI to increase substantially in puf.csv relative to prior law. I believe it is a result of the TCJA's business loss rule. The increases are especially pronounced among AGI millionaires and negative-AGI returns.

This raises several issues that might make sense to explore and address:

  • The losses available to be capped, embedded in puf.csv, may be too large, which could mean that growfactors are too large, or that stage 2 weighting inadvertently weighted large-loss records too much, or that the economy changed in ways that cannot be easily captured by growfactors and weighting. I suspect the first and third reasons. (I give two ways of looking at this below - a comparison to JCT that suggests they may not be too high, and a comparison to reported Historical Table 2 data, which suggests they may not be too high.)
  • On the other hand, the losses available to be capped may be plausible in taxdata, but people may have changed their behavior in ways that avoided or evaded the rule, in which case it might make sense to have a behavioral lever that allows implementing this behavior.
  • Limited losses can be carried forward. If they are as large as the data suggest, it implies that maybe taxdata should have a provision to create a pool of unused prior excess business losses.
  • The CARES act retroactively suspended the excess business loss rule back to 2018, through 2020, which means people can amend their returns for 2018 and 2019 and get refunds. It would be in effect again for 2021 through 2025. This raises a philosophical question about what to do in Tax-Calculator - undo the rule, or not, for 2018 and 2019, and what to do about 2020? An option to disallow might make sense; in any event it probably needs explicit thought.

Details
The first table below shows 2017 law and 2018 law calculated using Tax-Calculator applied to puf.csv advanced to 2018. (Note: The qbid limit is NOT set to false in TCJA.json.) AGI under 2018 law is $70.7 billion higher than under 2017 law. We can break it into three components: (1) minor changes to Social Security in AGI, (2) limits on above-the-line adjustments, (3) and the majority of the effect, driven by whatever affects the mysterious ymod1:

image

The next table shows that the $70.3 billion increase is predominantly in the highest and lowest AGI ranges. This, presumably, is related to the millionaire increases discussed in #2513. I use ranges used in SOI Historical Table 2 because this is based on work I am doing in relation to that and is convenient:

image

This led to a search for (a) large changes between 2017 law and 2018 law in big items that might be embedded in ymod1, and (b) large values for other items even if they did not change, especially for very high and very low agi records. I sorted records by how much AGI changed between the two laws, and then within a record I sorted variables according to whether they were important concepts (AGI is at the top) or whether their values were large.

Here are a few important variables to pay attention to:

image

Here is information about the record with the biggest AGI change between the two laws:

image

It's pretty clear that its large AGI change is related to its large e00900 business loss, even though the loss was the same under the two laws.

The agi change on the second-largest agi-change record is pretty clearly related to its large e02000 rent/royalty... loss.

image

Same for the third largest change:

image

Many additional records showed similar things. This was enough to figure out that large losses were a major cause and the internet filled in the rest - this appears to be the result of TCJA's excess business loss limit as mentioned at the start.

This raises several questions:

First, are the losses we have in the data too large?

JCT estimated the impact of this provision as about a $16 billion increase in FY 2019 after it was up and running. With puf.csv, I estimate it raises iitax by $11.5 billion (counter to my initial expectation, this is less than JCT estimated):

image

So this seems comforting. But one last bit of information, which is less comforting. The table below shows iitax calculated under 2017 law and TCJA, and also an estimate of actual iitax in 2018 constructed from reported Historical Table 2 data. Here, we have $58 billion more iitax among millionaires than was reported. Of course people's behavior may have changed in ways that caused actual tax to be lower, or we may simply have capped losses too m uch. I suspect the latter.

image

@MattHJensen
Copy link
Contributor

MattHJensen commented Dec 12, 2020

Hi @donboyd5, thanks a lot for investigating this issue and reporting what you found.

The CARES act retroactively suspended the excess business loss rule back to 2018, through 2020, which means people can amend their returns for 2018 and 2019 and get refunds. It would be in effect again for 2021 through 2025. This raises a philosophical question about what to do in Tax-Calculator - undo the rule, or not, for 2018 and 2019, and what to do about 2020? An option to disallow might make sense; in any event it probably needs explicit thought.

To handle this specific part of the issue, my initial reaction is to undo the rule for 2018, 2019, and 2020, justified by Tax-Calculator's general intention to calculate and report liabilities rather than receipts in a given year. We could achieve this by changing the baseline values for the ALD_BusinessLosses_c here. Users who wish alternative behavior could modify baseline parameter values as part of their calculator setup.

@donboyd5, does this make sense to you? Does anyone else have a view on it?

@donboyd5
Copy link
Contributor Author

donboyd5 commented Dec 12, 2020

Yes, @MattHJensen, that does make sense to me.

Meanwhile, I've made progress understanding the underlying data. I looked at positive and negative weighted sums of e00900 and e02000 in the default puf for 2017 (puf.csv advanced to 2017 using stages 1, 2, and 3), and compared them to IRS reported values for 2017 in IRS Publication 1304 Table 1.4.

e00900 (business and professional income) looks reasonably close to the IRS values.

e02000 (rents, royalties, ...) is actually much LOWER than the IRS values. To get the IRS values I had to add the IRS totals for rents & royalties, partnership / S Corporation income, and estate & trust income (I verified against 2011 data and reports that this is the proper total).

Copied below are (a) a table of the loss values for e02000 from the default PUF for 2017, (b) a summary table I calculated from the IRS tables in the manner just described, with rows at bottom summarizing high, low, and middle ranges, and (c) a comparison table of just those 3 ranges.

image

image

image

As you can see, the difference is very significant - $45 billion. Based on 2017 values, rent/royalty... losses available to be limited in the actual data (IRS) were far greater than those in the puf. Thus, the exclusion actually would have a bigger tax impact than we would estimate from the puf. (I realize CARES undid this but it is still worth thinking about.) Not shown here, positive e02000 values in the puf also are quite a bit too low ($814b total in puf vs $973b in IRS).

Because e02000 weighted sums in the 2011 puf documentation (booklet) matched the sums calculated from IRS Publication 1304 Table 1.4 for 2011, I believe the puf data started out being correct in 2011 but the default process of growing the puf to 2017 ended up making losses way too low in the puf in 2017. This suggests that some combination of revisions to growfactors or weighting of this variable is needed.

Looking ahead to 2018, per the IRS, actual loss values of e0900 (business...) grew by 16.8% from 2017, while the growfactor (ASCHL) only grew 4.7%, so that might benefit from some rethinking. Loss values of e02000 (rent...) grew by 7.9% but the growfactor (ASCHEL) was 2.6%; while that's a pretty good sized gap, the bigger issue is the huge difference in the 2017 starting point. There could behavioral factors affecting 2018 but I think they would work to drive actual losses (reported) down, not up - that is, people, knowing (or at least expecting) that their losses would be capped might have moved some into 2017 or recharacterized things.

Another thing I have learned, not really relevant to this thread but relevant to the NY project is that I did not pay enough attention to targeting these two variables and as a result reweighting that I did (not reflected in the puf analysis above, because that uses default weights) increased some of the losses by too much, thereby creating too many capped losses, thereby overstating 2018 tax liability among millionaires. So now I know how to fix it.

@jdebacker
Copy link
Member

This looks like an issue for TaxData. Closing this issue here. @donboyd5, if still relevant, you may want to move to the TaxData repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants