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

[WIP] Corporate Income Tax Distribution #1482

Closed
wants to merge 7 commits into from

Conversation

yuying27
Copy link

This PR is to replace PR #286 and update PR #1479

I update the tax-calculater from master branch and fix the pep8 problem.

Besides the function modifications, I write a brief description "CIT_description.pdf" discussing current results and problems. Also, I create a notebook "Corp_Inc_Tax_Test.ipynb" for testing purpose.

I modify several lines in the test files to pass the py.test.

All the codes in comments within function.py are alternative ways to distribute the tax. Basically, only keeping stock gains and dropping all the loss.

The TPC paper I refer to.

@codecov-io
Copy link

codecov-io commented Jul 14, 2017

Codecov Report

Merging #1482 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1482      +/-   ##
==========================================
+ Coverage   99.95%   99.96%   +<.01%     
==========================================
  Files          37       37              
  Lines        2481     2512      +31     
==========================================
+ Hits         2480     2511      +31     
  Misses          1        1
Impacted Files Coverage Δ
taxcalc/calculate.py 100% <100%> (ø) ⬆️
taxcalc/utils.py 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 14a7d8a...b1e8d7a. Read the comment docs.

@martinholmer
Copy link
Collaborator

@yuying27, Now your code passes the PEP8 and py.test tests, but you have failed to add new tests for the code you want to add. As as result, your pull request results in an increase in untested statements from 8 to 35. You need to add new tests so that the number of untested statements stays unchanged at 8.

It looks as if you need to do what the README documentation says to do:

Before developing any code changes be sure to read completely the Contributor Guide and then read about our coding style and testing procedures.

@yuying27
Copy link
Author

@martinholmer Thanks for illustrating this to me. I am trying to add more tests. Is there a way to check whether my added new tests work well to pass the above reports? Or I can only check it out after I make another pull request?

@martinholmer
Copy link
Collaborator

@yuying27 asked:

Is there a way to check whether my added new tests work well to pass the above reports?
Or I can only check it out after I make another pull request?

Don't create another pull request. Just keep working on the one you have now. Make changes on your local branch, test them, and then do:

git commit -a -m "[commit-message]"
git push origin [branch-name]

The push will automatically update your GitHub pull request and rerun the tests.

But if you want to see how your new tests are affecting coverage on your local computer before you do a commit, then execute the following commands in the tax-calculator directory.

coverage run -m py.test -v -m "not requires_pufcsv" > /dev/null
coverage html --ignore-errors
open htmlcov/index.html

That third command is how to open the coverage report in your default browser on a Mac. If you're working on some other OS, you will need to do something other than the third command to view the HTML coverage report.

@yuying27
Copy link
Author

@martinholmer Got it! Thanks a lot!

@martinholmer
Copy link
Collaborator

@yuying27, Thanks for adding the #1482 tests to maintain the number of untested statements at eight.

This is the first of several comments I expect to make about more substantive #1482 issues.

First of all, we have a long-standing policy of minimizing the number of binary files included in the repository.

So, the CIT_description.pdf should be removed from this pull request. If you want to document the approach (beyond the source code) you could put this text in a pull request #1482 comment. If you honestly think there is a permanent need for this extra documentation, then put this text into a citax_doc.md or citax_distribution.md (Markdown) file. It seems to me that the info in the CIT_description.pdf file doesn't add much to well-documented source code, so I'd favor improving the source-code comments and just removing the CIT_description.pdf file from the pull request.

The same for the Corp_Inc_Tax_Test.ipynb binary file. You say in #1482 that I create a notebook "Corp_Inc_Tax_Test.ipynb" for testing purpose[s]. Using a notebook as you develop a pull request is just fine, but it has no place in the final pull request. All the testing of the new code should in the new pytest unit tests you add to the pull request. So, please remove the notebook. It would be fine to store it someplace other than the Tax-Calculator repository and point to it in your #1482 comments. For a good example of this approach, see taxdata issue 106 by @andersonfrailey.

And second of all, you have not followed the Tax-Calculator coding style, a link to which is on the README page displayed every time you open Tax-Calculator on GitHub. That page says, among other things, this:

If you want to propose code changes, follow the directions in the Contributor Guide on how to clone the Tax-Calculator git repository. Before developing any code changes be sure to read completely the Contributor Guide and then read about our coding style and testing procedures.

When I follow these directions with your proposed #1482 code, I get this:

PYLINT utils.py
************* Module taxcalc.utils
utils.py:1287: [C0330(bad-continuation), ] Wrong continued indentation (add 1 space).
                                        (res['c04470'] > res['standard'])), 0)
                                        ^|
utils.py:1291: [C0330(bad-continuation), ] Wrong continued indentation (add 1 space).
                                                   (res['c04470'] > 0)), 0)
                                                   ^|
utils.py:1281: [C0111(missing-docstring), create_corpinctax_table] Missing function docstring
utils.py:1303: [C0103(invalid-name), create_corpinctax_table] Invalid variable name "df"
utils.py:1305: [C0103(invalid-name), create_corpinctax_table] Invalid variable name "df"
utils.py:1308: [C0103(invalid-name), create_corpinctax_table] Invalid variable name "df"
utils.py:1311: [C0103(invalid-name), create_corpinctax_table] Invalid variable name "df"
utils.py:1322: [C0103(invalid-name), create_corpinctax_table] Invalid variable name "df"

and this:

PEP8 current_law_policy.json
current_law_policy.json:3442:1: W293 blank line contains whitespace
current_law_policy.json:3456:23: E231 missing whitespace after ','
current_law_policy.json:3456:27: E231 missing whitespace after ','

These coding-style problems need to be fixed.

And finally, a third issue. Over a year ago, @MattHJensen renamed the individual income tax variable as iitax. The thinking at the time was that eventually there would be a corporate income tax variable that would be called citax. Can you go through your proposed code to use this kind of terminology? And remember, calculated variables are all lower-case (with internal underscores if you need to separate words) per standard Python coding style. So, for example, you should rename the utility function from create_corpinctax_table to something like create_citax_table. Also, rename the CORP_TABLE list as something like citax_columns and move it into the the create_citax_table function. That list doesn't seem to be used anywhere else.

Let me know if you have any questions or think some of these suggestions are not good ones.

I look forward to your revised pull request #1482.

@yuying27
Copy link
Author

yuying27 commented Jul 19, 2017

@martinholmer Thanks for your quick and clear reply!

First of all, we have a long-standing policy of minimizing the number of binary files included in the repository.

I remove the files from pull requests, and write my concerns in below comments. These two files are not necessary for tax-calculator. They only present current results for discussion use.

And second of all, you have not followed the Tax-Calculator coding style

Coding style is fixed.

And finally, a third issue. Over a year ago, @MattHJensen renamed the individual income tax variable as iitax.

I change the variable name, previously share_corptax_burden, into citax . And relative codes are modified as well.

@yuying27
Copy link
Author

Formula:

Labor = e00200 + e00250 + e07240 + e03150 + e01400 + e01700 + e02400 + e02100 + e00900 + e02000
Normal = 0.4 * (e00650 + p23250 + p22250 + e02100 + e00900 + e02000) + (e00300 + e00400 + e00600)
Supernormal = 0.6 * (e00650 + p23250 + p22250)

Aggregated labor income:
agg_labor = (Labor * s006).sum()
Aggregated normal income:
agg_normal = (Normal* s006).sum()
Aggregated supernormal income:
agg_supernormal = (Supernormal * s006).sum()

Each taxpayer’s Corporate Income Tax distribution:
citax = share_from_labor + share_from_normal + share_from_supernormal
Where:
share_from_labor = 20% * revenue_collected * Labor / agg_labor
share_from_normal = 20% * revenue_collected * Normal / agg_normal
share_from_supernormal = 60% * revenue_collected * Supernormal / agg_supernormal
revenue_collected = 100,000,000,000

revenue_collected is the dollar amount of Corporate Income Tax collection. Here it is set to 100,000,000,000 for simplification.

Current Results and Problems:

  s006 expanded_income c00100 citax
0 17,004,988 -119,449,251,743 -124,010,604,527 -21,010,701,485
1 17,004,489 152,378,742,352 104,334,599,094 -3,341,672,388
2 17,006,659 273,930,511,045 175,573,308,821 -1,887,380,105
3 17,004,285 400,560,764,101 271,106,279,282 -4,505,952,036
4 17,006,306 558,266,448,736 414,184,451,276 -4,527,702,496
5 17,005,655 754,021,373,929 606,937,232,387 -6,706,744,655
6 17,005,634 1,008,755,132,796 867,768,894,634 -8,918,370,179
7 17,004,128 1,379,302,477,097 1,262,046,738,827 -9,160,920,710
8 17,006,254 2,054,398,833,868 1,913,134,661,073 -8,773,837,161
9 17,006,552 6,272,407,565,288 5,954,268,152,193 168,833,281,214
sums 170,054,950 12,734,572,597,467 11,445,343,713,062 100,000,000,000

As shown above, if we sort the Corporate Income Tax Burden by expanded_income, the top 10% will take more than 168% of corporate income tax burden.

The main reason is the existence of capital gain/loss (variables p23250 and p22250). p23250 has a range from -234 million to 294 million. p22250 has a range from -121 million to 315 million. But the range of expanded_income is -147 million to 295 million.

p23250 and p22250 account for large proportion (they contribute to both normal and supernormal income) in our calculation. They distort whole tax burden distribution as a consequence.

In order to get a more reasonable distribution, I think we ought to modify the formula we get from TPC. Either dropping some extreme negative terms or reducing the weights of capital gain/loss would be feasible.

For example:
If we drop all negative numbers of p23250 and p22250 and replace them with 0. The tax burden distribution becomes following, which is more reasonable:

  s006 expanded_income c00100 citax
0 17,004,988 -119,449,251,743 -124,010,604,527 490,430,670
1 17,004,489 152,378,742,352 104,334,599,094 581,459,979
2 17,006,659 273,930,511,045 175,573,308,821 867,182,127
3 17,004,285 400,560,764,101 271,106,279,282 1,256,845,639
4 17,006,306 558,266,448,736 414,184,451,276 1,649,399,316
5 17,005,655 754,021,373,929 606,937,232,387 2,427,109,116
6 17,005,634 1,008,755,132,796 867,768,894,634 3,310,081,758
7 17,004,128 1,379,302,477,097 1,262,046,738,827 4,783,993,442
8 17,006,254 2,054,398,833,868 1,913,134,661,073 7,556,810,895
9 17,006,552 6,272,407,565,288 5,954,268,152,193 77,076,687,060
sums 170,054,950 12,734,572,597,467 11,445,343,713,062 100,000,000,000

@martinholmer
Copy link
Collaborator

I'm taking a long weekend to a lake-side cottage in Canada, so I'll be out of the office until next Wednesday, July 26th. And then I'll be out of town over a long end-of-the-month weekend. All this means that, even though I'm very interested in discussing some of the substantive issues that your pull request #1482 raises, I probably will not have time to do that until early August. We will restart our conversation then, OK?

@rickecon
Copy link
Member

We need a special tag for great @martinholmer issue and PR comments.

@yuying27
Copy link
Author

@martinholmer No worries. Enjoy your long weekend!

@martinholmer
Copy link
Collaborator

@yuying27, I have a few more questions/comments about pull request #1482:

(1) Why are there two new functions instead of just one? Why not put the logic that you currently have in the AggCorpIncTax function in the new DistCorpIncTax function? And this would allow you to eliminate the three new calculated agg_* variables, which don't seem add anything important. Or am I missing something?

(2) A coding style suggestion: prefer 1e11 to 100000000000. The latter has too many zeros to count easily (especially for old eyes). And now that I actually count all the zeros in the current code, why $100 billion?

@yuying27
Copy link
Author

yuying27 commented Aug 2, 2017

@martinholmer , welcome back!

(1) Why are there two new functions instead of just one?

The reason is DistCorpIncTax is an iterated function, while AggCorpIncTax is not. The three new agg_* variables are necessary inputs for DistCorpIncTax. Actually I tried to combine them together at first, but I failed to obtain the three agg_* via an iterated function: the loop only gives one number from each input array, rather than keeps the whole arrays. So I have to build the AggCorpIncTax, which is a non-iterated one, to get the three agg_* . And as an iterated function, those variables need to be arrays with same length as e*****. Then I add three new variables agg_*.

(2) A coding style suggestion: prefer 1e11 to 100000000000

I can definitely change this. $100 billion is just a random number for testing the distribution.

@martinholmer
Copy link
Collaborator

martinholmer commented Aug 3, 2017

@yuying27 said:

The TPC paper I refer to.

I'm confused after looking at this TPC paper. Is the intention of pull request #1482 to emulate the assumptions and methods (as closely as possible) described in this TPC paper? If not, what is the methodological approach being used in #1482?

@yuying27
Copy link
Author

yuying27 commented Aug 3, 2017

@martinholmer Yes. I try as closely as possible to emulate the methods in this TPC paper. Some variables are missing in our Puf so I skip them. But the distribution results polarize in an extreme way, so I think some adjustments are needed.

@martinholmer
Copy link
Collaborator

@yuying27 said about distributing corporate income tax revenue to individuals in PR #1482:

I try as closely as possible to emulate the methods in this TPC paper. Some variables are missing in our puf.csv so I skip them. But the distribution results polarize in an extreme way, so I think some adjustments are needed.

Thanks for the clarification; you should probably edit your first #1482 comment to make that clear.

I have a few questions about how you have tried to implement the TPC approach.

(1) Given that the logic you propose to add to Tax-Calculator distributes total corporate income tax liability each year among the sample individuals, where does the Tax-Calculator user specify the total corporate income tax liability for each year? It seems to me that TPC and we are so short of relevant data that the result of this distribution of the total across individuals is highly speculative (to put it politely). Given that situation, it is essential for Tax-Calculator to work so that users "turn on" the corporate income tax logic only when they want it. In other words, the default mode of Tax-Calculator operation should be zero total corporate income taxes in total, and therefore, no corporate income tax distributed to individuals. This is the way Tax-Calculator works now, and we should always be able to run Tax-Calculator that way. So how do you propose users specify positive total corporate income tax liability amounts by year?

My next questions are about this proposed code:

     labor = ((calc.records.e00200 + calc.records.e07240 +
               calc.records.e03150 + calc.records.e01400 + calc.records.e01700 +
               calc.records.e02400 + calc.records.e02100 + calc.records.e00900 +
               calc.records.e02000) * calc.records.s006).sum()
     normal = 0.4 * ((calc.records.e00650 + calc.records.p23250 +
                      calc.records.p22250 + calc.records.e02100 +
                      calc.records.e00900 + calc.records.e02000) *
                     calc.records.s006).sum() + ((calc.records.e00300 +
                                                  calc.records.e00400 +
                                                  calc.records.e00600) *
                                                 calc.records.s006).sum()
     supernormal = 0.6 * ((calc.records.e00650 + calc.records.p23250 +
                           calc.records.p22250) * calc.records.s006).sum()

(2) Given that the TPC paper says on pages 13-14:

Labor income for purposes of distributing the corporate income tax includes wages, employee retirement contributions, distributions (excluding rollovers) from defined contribution plans and defined benefit plans, and the employer’s share of Social Security and Medicare taxes (i.e., FICA). Labor income also includes the labor component of self-employment and partnership income, assumed to be 80 percent of the SECA base.

So, your definition of labor includes wages (e00200), retirement contributions (e07240 and e03150), retirement distributions (e01400 and e01700), but I don't see employer share of FICA and I don't see "the labor component of self-employment and partnership income" (which TPC heroically assumes is "80 percent of the SECA base").

Why are you including total OASDI benefits (e02400)? Are you interpreting social security benefits as a "distribution from a defined benefit plan"? If so, I'm not sure this is consistent with the TPC approach.

Why are you including the term e02100 + e00900 + e02000? I don't see the sum of Sch F, Sch C and Sch E income anywhere in the TPC definition of labor income.

(3) I also have questions about both the TPC specification and your specification of normal and supernormal income, but I've asked enough questions for one comment. Let's clear up the questions I've posed so far and I'll ask my other questions in a subsequent comment.

@yuying27
Copy link
Author

yuying27 commented Aug 4, 2017

@martinholmer

(1) Given that the logic you propose to add to Tax-Calculator distributes total corporate income tax liability each year among the sample individuals, where does the Tax-Calculator user specify the total corporate income tax liability for each year? It seems to me that TPC and we are so short of relevant data that the result of this distribution of the total across individuals is highly speculative (to put it politely). Given that situation, it is essential for Tax-Calculator to work so that users "turn on" the corporate income tax logic only when they want it. In other words, the default mode of Tax-Calculator operation should be zero total corporate income taxes in total, and therefore, no corporate income tax distributed to individuals. This is the way Tax-Calculator works now, and we should always be able to run Tax-Calculator that way. So how do you propose users specify positive total corporate income tax liability amounts by year?

I fully understand your confusion. This is also what I felt (speculative, politely) about distributing corporate tax to individuals. I did not have a clear idea when I wrote the code, but your words enlighten me. I agree that we should set the default mode of Tax-calculator without corporate income taxes. And giving users a choice to turn on the corporate income taxes with an input amount. Besides, for passing Fiscal Year, we are able to prepare actual taxes amount. For example, 343.8 billion for FY2015.

So, your definition of labor includes wages (e00200), retirement contributions (e07240 and e03150), retirement distributions (e01400 and e01700), but I don't see employer share of FICA and I don't see "the labor component of self-employment and partnership income" (which TPC heroically assumes is "80 percent of the SECA base").

I do not have proxies for employer's share. Do you have any suggestion?

Why are you including total OASDI benefits (e02400)? Are you interpreting social security benefits as a "distribution from a defined benefit plan"? If so, I'm not sure this is consistent with the TPC approach.

Yes, I assume social security is a "defined benefit plan", so I include e02400 in the calculation. To be honest, I am not sure neither.

Why are you including the term e02100 + e00900 + e02000? I don't see the sum of Sch F, Sch C and Sch E income anywhere in the TPC definition of labor income.

I use these as proxies of "the labor component of self-employment and partnership income". Actually I am not sure the exact meaning of "80 percent of the SECA base". So I include the active and passive income as proxies here.

Another thing good to mention is I tried to include e00250 based on TPC, but we do not have it in current Puf.
All variables are selected based on my best understanding of TPC paper. I know there are lots of limitations and questions to talk about. Open to all kinds of guidance, suggestion and discussion.

@martinholmer
Copy link
Collaborator

@yuying27 said:

I fully understand your confusion. This is also what I felt (speculative, politely) about distributing corporate tax to individuals. I did not have a clear idea when I wrote the code, but your words enlighten me. I agree that we should set the default mode of Tax-calculator without corporate income taxes. And giving users a choice to turn on the corporate income taxes with an input amount. Besides, for passing Fiscal Year, we are able to prepare actual taxes amount. For example, 343.8 billion for FY2015.

OK, we are in agreement on this. So, how shall we implement this mode of operation?

@yuying27 said:

I do not have proxies for employer's share. Do you have any suggestion?

You need to search the functions.py code for the keyword "employer".
We compute the employer share of OASDI payroll tax on wages and salaries.

@yuying27 said:

Yes, I assume social security is a "defined benefit plan", so I include e02400 in the calculation. To be honest, I am not sure neither.

I haven't completely read the TPC paper, but the notion that those with labor earnings have some of the corporate income tax shifted to them is probably based on the notion that corporations are paying them less wage and salary income than they would be is there was no corporate income tax. Is that a correct understanding of the TPC approach?

If so, then social security should not be viewed as a defined benefit plan because it has nothing to do with an all-in measure of labor compensation. Unless you can explain to me why I'm confused about this, it seems like you should drop OASDI benefits from the labor variable. There is no indication that TPC is adding this amount into the labor variable, is there?

@yuying27 said:

I use these as proxies of "the labor component of self-employment and partnership income". Actually I am not sure the exact meaning of "80 percent of the SECA base". So I include the active and passive income as proxies here.

Again, you need to read the functions.py code, especially the parts about payroll taxes on self-employment income (that is, SECA, or "self-employment contribution act", I guess).

@yuying27 said:

Another thing good to mention is I tried to include e00250 based on TPC, but we do not have it in current puf.csv file.

Why did you try to include e00250 in the labor variable? Where is it that TPC says they included it in the definition of labor?

@yuying27
Copy link
Author

yuying27 commented Aug 4, 2017

@martinholmer

OK, we are in agreement on this. So, how shall we implement this mode of operation?

I wonder we could add another parameter in current_law_policy.json? And the default value can be set to zero.

You need to search the functions.py code for the keyword "employer".
We compute the employer share of OASDI payroll tax on wages and salaries.

Again, you need to read the functions.py code, especially the parts about payroll taxes on self-employment income (that is, SECA, or "self-employment contribution act", I guess).

I will go through the codes before I provide further updates.

I haven't completely read the TPC paper, but the notion that those with labor earnings have some of the corporate income tax shifted to them is probably based on the notion that corporations are paying them less wage and salary income than they would be is there was no corporate income tax. Is that a correct understanding of the TPC approach?

I don't think TPC mentions the reason. I will go back to check again and see if I miss any explanation of it.

If so, then social security should not be viewed as a defined benefit plan because it has nothing to do with an all-in measure of labor compensation. Unless you can explain to me why I'm confused about this, it seems like you should drop OASDI benefits from the labor variable. There is no indication that TPC is adding this amount into the labor variable, is there?

I have no problem of dropping OASDI here. But I am confused about how to measure the defined contribution plans and defined benefit plans. If OASDI is not the case, then which benefits fit the desciption?

Why did you try to include e00250 in the labor variable? Where is it that TPC says they included it in the definition of labor?

I found in this document, e00250 is mentioned as "other earned income". I do not find more information about this variable in neither NBER nor Puf, so I keep it with a question mark for discussion. If this is a kind of income, I think we should include it in labor income.

I will get back once I finish learning the function.py you mentioned. Thanks for your patient explanation!

@martinholmer
Copy link
Collaborator

@yuying27 said in response to question by @martinholmer:

OK, we are in agreement on this. So, how shall we implement this mode of operation?

I wonder we could add another parameter in current_law_policy.json? And the default value can be set to zero.

This makes a lot of sense. Why don't you add a new policy parameter with this info:

    "_CIT_total_revenue": {
        "long_name": "Total corporate income tax revenue",
        "description": "Total corporate income tax revenue to be distributed to individual income tax filing units.",
        "section_1": "Other Taxes",
        "section_2": "Corporate Income Tax",
        "irs_ref": "",
        "notes": "",
        "row_var": "FLPDYR",
        "row_label": ["2013"],
        "start_year": 2013,
        "cpi_inflated": false,
        "col_var": "",
        "col_label": "",
        "value": [0.0],
        "validations": {"min": 0.0}
    },

@martinholmer
Copy link
Collaborator

@yuying27 said:

I haven't completely read the TPC paper, but the notion that those with labor earnings have some of the corporate income tax shifted to them is probably based on the notion that corporations are paying them less wage and salary income than they would be is there was no corporate income tax. Is that a correct understanding of the TPC approach?

I don't think TPC mentions the reason. I will go back to check again and see if I miss any explanation of it.

If so, then social security should not be viewed as a defined benefit plan because it has nothing to do with an all-in measure of labor compensation. Unless you can explain to me why I'm confused about this, it seems like you should drop OASDI benefits from the labor variable. There is no indication that TPC is adding this amount into the labor variable, is there?

I have no problem of dropping OASDI here. But I am confused about how to measure the defined contribution plans and defined benefit plans. If OASDI is not the case, then which benefits fit the description?

The more I think about this, the more I doubt the TPC logic of adding pension benefits of any kind into the labor variable. Do they really want us to believe that by increasing the corporate income tax, individuals who are no longer employed by corporations, but are receiving either social security benefits and/or private pension benefits, will experience some of the corporate income tax increase? I don't understand how that can happen? I can imagine that corporate employees could see lower wages and salaries in the long run. But how is the corporate income tax shifted to retirees? I don't get it.

So, unless I'm missing something here (and that is a real possibility), we should remove all pension and social security benefits from the labor variable used to distribute total corporate income taxes.

@martinholmer
Copy link
Collaborator

@martinholmer said:

Why don't you add a new policy parameter with this info:

   "_CIT_total_revenue": {
       "long_name": "Total corporate income tax revenue",
       "description": "Total corporate income tax revenue to be distributed to individual income tax filing units.",
      "section_1": "Other Taxes",
      "section_2": "Corporate Income Tax",
      "irs_ref": "",
      "notes": "",
      "row_var": "FLPDYR",
      "row_label": ["2013"],
      "start_year": 2013,
      "cpi_inflated": false,
      "col_var": "",
      "col_label": "",
      "value": [0.0],
      "validations": {"min": 0.0}
  },

On further thought, it seems as if we want to have the aggregate CIT variable be the change (from current-law) in total corporate income tax revenue. Also, seems as if we should add a boolean switch to toggle between long-term shifting assumptions and short-term shifting assumptions. So the new policy parameters would be something like this:

    "_CIT_revenue_change": {
        "long_name": "Change in total corporate income tax revenue",
        "description": "Change in total corporate income tax revenue relative to revenue under current-law policy. This total change will be distributed to labor and capital income according to the shifting assumptions specified by the _CIT_long_term parameter.",
        "section_1": "Other Taxes",
        "section_2": "Corporate Income Tax",
        "irs_ref": "",
        "notes": "",
        "row_var": "FLPDYR",
        "row_label": ["2013"],
        "start_year": 2013,
        "cpi_inflated": false,
        "col_var": "",
        "col_label": "",
        "value": [0.0],
        "validations": {"min": 0.0}
    },

    "_CIT_long_term": {
        "long_name": "Long-term shifting assumption concerning corporate income taxes",
        "description": "Long-term assumption uses TPC shares to split between labor income, normal capital income, and supernormal capital income.  Short-term assumption is that all shifted to capital income with TPC shares used to split between normal and supernormal.",
        "section_1": "Other Taxes",
        "section_2": "Corporate Income Tax",
        "irs_ref": "",
        "notes": "",
        "row_var": "FLPDYR",
        "row_label": ["2013"],
        "start_year": 2013,
        "cpi_inflated": false,
        "col_var": "",
        "col_label": "",
        "value": [True]
    },

@feenberg
Copy link
Contributor

feenberg commented Aug 7, 2017 via email

@martinholmer
Copy link
Collaborator

@feenberg said:

I think TPC is thinking that a higher corporate tax reduces the demand for labor, which would reduce the equilibrium wage, all other things constant.

Maybe. Where in the paper do they say that?
But more importantly, if you are correct, then this sort of corporate income tax analysis has no place in a ten-year static tax analysis. The economic logic you think TPC is using is something that is appropriate for the OG-USA growth model.

Given all the obvious flaws in the TPC approach and given that none of us understand, for certain, everything that is going on in the TPC approach, I see this pull request as being premature. I think it should be closed (without merging) and our corporate income tax efforts be focused on understanding what the research literature says about the incidence of the corporate income tax. Then once we have a firm understanding of the research literature, we can have a discussion about whether we should introduce kind of analysis into one of the models, and if so, how best to introduce the corporate income tax analysis.

@MattHJensen @feenberg @Amy-Xu @andersonfrailey @hdoupe @GoFroggyRun @yuying27

@Amy-Xu
Copy link
Member

Amy-Xu commented Aug 8, 2017

Thanks to @feenberg Dan for weighing in and thanks to Martin @martinholmer for careful review on this PR. The initial reason for Yuying @yuying27 to open this PR is to replace the ages-old #286, adapting some of the assumptions and logics to current data input and TC utilities.

The referred TPC paper apparently has many assumptions that not everyone agrees with. I propose we consult Alan Viard at AEI for explanations or improvements on some TPC assumptions, since the distributing corporate tax would be a nice function to have. @martinholmer Martin, do you think that's an acceptable way to proceed with this PR?

@yuying27
Copy link
Author

yuying27 commented Aug 8, 2017

@martinholmer said:

The more I think about this, the more I doubt the TPC logic of adding pension benefits of any kind into the labor variable. Do they really want us to believe that by increasing the corporate income tax, individuals who are no longer employed by corporations, but are receiving either social security benefits and/or private pension benefits, will experience some of the corporate income tax increase? I don't understand how that can happen? I can imagine that corporate employees could see lower wages and salaries in the long run. But how is the corporate income tax shifted to retirees? I don't get it.

So, unless I'm missing something here (and that is a real possibility), we should remove all pension and social security benefits from the labor variable used to distribute total corporate income taxes.

I read TPC paper again, and do not get any clue why distributions from defined contribution plans and defined benefit plans should be include in labor income. My understanding is TPC treats pension as a kind of wage employees should have received. But TPC does not consider the time differences between paying for pensions as an active employee and receiving the pension as a retiree. So current employee's wages and current retiree's benefits are both included in the labor income.

@feenberg said:

Social Security Benefits could be valued as an asset, and the accumulation
of PIA added to income (like saving) and benefits paid subtracted from
income (as dis-saving). That isn't what most people would like to see
though. Once benefits are treated as income, then it makes some sense to
make them subject to effects on the accumulation of PIA.

I agree. TPC considers these benefits as an asset/income.

@martinholmer
Copy link
Collaborator

@Amy-Xu said:

The referred TPC paper apparently has many assumptions that not everyone agrees with.

Yes, but more importantly the TPC paper seems to not explain its economic mode of corporate income tax shifting. Nobody who has looked at the paper can point to a page that explains the economic mechanism(s) that lead to labor bearing a substantial portion of the corporate tax burden. That is a pretty basic thing that nobody can point to in the paper. We need to know things like this before we can begin to figure out how to implement this in Tax-Calculator.

@Amy-Xu also said:

I propose we consult Alan Viard at AEI for explanations or improvements on some TPC assumptions, since the distributing corporate tax would be a nice function to have. @martinholmer Martin, do you think that's an acceptable way to proceed with this PR?

I think that would be fine, but that, by itself, is not enough. The staff working on this needs to read and understand the key papers in the economic research literature on this topic.

@Amy-Xu
Copy link
Member

Amy-Xu commented Aug 9, 2017

@martinholmer said:

The staff working on this needs to read and understand the key papers in the economic research literature on this topic.

I totally agree. @yuying27 Yuying, could you start on a literature review for this topic? Feel free to post anything relevant.

@yuying27
Copy link
Author

yuying27 commented Aug 9, 2017

@Amy-Xu

@martinholmer said:
The staff working on this needs to read and understand the key papers in the economic research literature on this topic.

I totally agree. @yuying27 Yuying, could you start on a literature review for this topic? Feel free to post anything relevant.

Absolutely, I am reading the OTA paper to see if there is any useful information. Let me know if you have any suggestion.

@martinholmer
Copy link
Collaborator

I don't have access to WSJ articles behind their paywall. Can somebody who does, send me via private email the contents of this article? It is not a research paper, but it does interview scholars including Alan Auerbach and mention a number of research papers.

@MattHJensen @feenberg @Amy-Xu @yuying27

@Amy-Xu
Copy link
Member

Amy-Xu commented Aug 10, 2017

@martinholmer Thanks for looking into the background of this issue. I just sent an email with a PDF attached.

@martinholmer
Copy link
Collaborator

@Amy-Xu said:

Thanks for looking into the background of this issue. I just sent an email with a PDF attached.

Thanks, @Amy-Xu

@yuying27
Copy link
Author

@martinholmer A quick update.

Different papers have different views on how to cut the corporate tax burden.

U.S. Treasury department believes 63% of the corporate income tax burden is distributed to supernormal capital income, 17% is distributed to normal capital income and 18% is distributed to labor income. The rest 1% is not a burden.
According to the paper, labor income is measured as wages and salaries, earnings from self-employment, employer-provided health insurance, 60% of retirement distributions, and employer contributions to payroll taxes.
Normal capital income is measured as 37% of positive realized capital gains, 37% of the capital share of active income from closely held businesses, the capital share of passive income from closely held businesses, taxable and tax exempt interest, and 30% of retirement distributions.
Supernormal capital income is measured as 63% of positive realized capital gains, 63% of dividends, and 63% of the capital share of active income from closely held businesses. And 10% of retirement distributions.

Joint Committee on Taxation staff assumes 25% of corporate income taxes are borne by domestic labor and 75% are borne by owners of domestic capital.
The labor compensation includes each worker’s total compensation package and not just based on cash wages. It is defined as the sum of the worker’s wages as reported on the tax return, payroll taxes paid by the employer on behalf of the worker, employer contributions to health insurance plans, and untaxed voluntary contributions to retirement plans made by the worker.

For the labor income and capital income definition, as well as the weights assigned, different articles vary from each other. So I think in our formula, it’s better to focus on one paper. Otherwise, we will lose the consistency.

I will look for more recent papers on CIT topics.

@martinholmer
Copy link
Collaborator

@yuying27 said after providing links to and short summaries of Treasury and JCT papers:

For the labor income and capital income definition, as well as the weights assigned, different articles vary from each other. So I think in our formula, it’s better to focus on one paper. Otherwise, we will lose the consistency.

Thanks for the links and summaries, but what I'm more interested in is economic analysis of the effects of a reform-induced change in corporate income tax (CIT) revenue. The Treasury and JCT papers, like the TPC paper, focus on the distribution mechanics. Eventually, we will have to address issues of mechanics, but before we do that we need to understand what the most recent thinking is on the economic analysis, both theoretical and empirical.

The most recent review of theoretical and empirical issues I could find, is this paper:
K. Clausing, "In Search of Corporate Tax Incidence", Tax Law Review (2012). This paper also includes new empirical research.

Do you want to begin there? Or can you suggest a better article to begin with?

@MattHJensen @feenberg @rickecon @jdebacker @Amy-Xu

@yuying27
Copy link
Author

@martinholmer

Do you want to begin there? Or can you suggest a better article to begin with?

Definitely. I will start with this article.

@martinholmer
Copy link
Collaborator

Please add any further discussion of corporate income taxes to issue #1515.

@MattHJensen
Copy link
Contributor

MattHJensen commented Aug 20, 2017

This is a comment on distributional mechanics, so I am leaving it here rather than #1515.

@feenberg said:

If wages are lower, doesn't it make some sense that (long run) pensions
will be lower?

@yuying27 said:

But TPC does not consider the time differences between paying for pensions as an active employee and receiving the pension as a retiree. So current employee's wages and current retiree's benefits are both included in the labor income.

These two comments are inline with my understanding, which is that TPC assumes higher labor income will lead to higher pensions and ignores the time difference. I think it is reasonable to focus on the "phased in" effect rather than the transition. This is similar to how most of our users -- to my knowledge -- use long-run capital gains elasticities rather than short-run elasticities, even when conducting 10-year revenue estimates.

@MattHJensen
Copy link
Contributor

This is a comment on distributional mechanics, so leaving it here rather than #1515.

In this PR, the shares on labor, normal returns, and supernormal returns are all hardcoded. I believe these should be parameterized. Our long-standing objective has been to parameterize important assumptions, and these are certainly important assumptions.

An ideal implementation would also allow for different values for current law and the reform, as these parameters are not policy invariant.

@martinholmer
Copy link
Collaborator

The discussion in issue #1515 indicates that the approach to corporate income taxes (CIT) in pull request #1482 is not the best approach. I suggest #1482 be closed and that a new pull request be created that implements as a behavioral response the kind of CIT approach discussed in #1515.

Does that make sense?

@MattHJensen @feenberg @yuying27 @Amy-Xu @andersonfrailey @hdoupe @GoFroggyRun

@MattHJensen
Copy link
Contributor

Yuying was a summer intern at OSPC and she did fantastic work reviewing how other modeling projects handle these issues and then developing a prototype for Tax-Calculator. I am going to contact her via email to see if she has any feedback on this discussion and/or would like to continue working on this feature in her spare time. If she does not have the time, we will need to find a new owner for this project. I would like to give Yuying an opportunity to comment, though, before closing the PR.

@martinholmer
Copy link
Collaborator

@MattHJensen said:

Yuying was a summer intern at OSPC and she did fantastic work reviewing how other modeling projects handle these issues and then developing a prototype for Tax-Calculator. I am going to contact her via email to see if she has any feedback on this discussion and/or would like to continue working on this feature in her spare time. If she does not have the time, we will need to find a new owner for this project. I would like to give Yuying an opportunity to comment, though, before closing the PR.

Sounds quite sensible.

@yuying27
Copy link
Author

yuying27 commented Sep 9, 2017

@martinholmer said:

I suggest #1482 be closed and that a new pull request be created that implements as a behavioral response the kind of CIT approach discussed in #1515.
Does that make sense?

I read #1515 . It makes sense to me that we need a different structure of whole piece. Please feel free to close the pull request so that we can start a new model with behavioral interaction soon.

@MattHJensen said:

Yuying was a summer intern at OSPC and she did fantastic work reviewing how other modeling projects handle these issues and then developing a prototype for Tax-Calculator. I am going to contact her via email to see if she has any feedback on this discussion and/or would like to continue working on this feature in her spare time. If she does not have the time, we will need to find a new owner for this project. I would like to give Yuying an opportunity to comment, though, before closing the PR.

Thanks for giving me this opportunity! I hope I have made some help in solving this more-than-two-year old issue.

@martinholmer
Copy link
Collaborator

Pull request #1482 is being closed for the reasons outlined in this comment in the discussion of open issue #1515.

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

Successfully merging this pull request may close these issues.

7 participants