Add a Fair Share Tax

[andersonfrailey]

This is the same as PR #890, the only difference is it uses a new branch that has been updated to match the master branch. It still addresses issue #862.

I've changed the name of the BuffettRule function to FairShareTax and some of the code to match the codebase.

I'm still working on making our output more on par with the other revenue estimates. This is what I currently have (billions of dollars):

2016	2017	2018	2019	2020	2021
29.29	30.04	31.03	31.74	32.95	34.44

[codecov-io]

Current coverage is 98.12% (diff: 100%)

Merging #904 into master will increase coverage by <.01%

@@             master       #904   diff @@
==========================================
  Files            13         13          
  Lines          1813       1814     +1   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           1779       1780     +1   
  Misses           34         34          
  Partials          0          0          

Powered by Codecov. Last update be55c2c...64e3df8

[martinholmer]

@andersonfrailey said:

This is the same as PR #890, the only difference is it uses a new branch that has been updated to match the master branch. It still addresses issue #862.

Thanks for the clarification of the function and parameters naming. If this pull request #904 is meant to replace pull request #890, then you should close (without merging) pull request #890 so as to eliminate any possible confusion.

[martinholmer]

@andersonfrailey said:

I'm still working on making our output more on par with the other revenue estimates. This is what I currently have (billions of dollars):

 2016    2017    2018    2019    2020    2021
29.29   30.04   31.03   31.74   32.95   34.44

You need to tell us the values of the three _FST_* policy parameters that you used to compute the above estimates. Under current-law policy (which has no Fair Share Tax), the values are:

_FST_tentRate      0.0
_FST_minAGI        1000000 (one million dollars)
_FST_phaseRate     1.0

[andersonfrailey]

@martinholmer the only parameter changed was _FST_tentRate. It is now 0.3.

[martinholmer]

@MattHJensen said in issue #862:

The final FST would be the excess, if any, of the tentative FST over the sum of the taxpayer’s (1) regular income tax (after certain credits) including the 3.8-percent net investment income tax, (2) the alternative minimum tax, and (3) the employee portion of payroll taxes.

@andersonfrailey, Are we just abstracting from the after-only-certain-credits aspect of the reform. It looks as if pull request #904 includes all the credits in the income tax liability. Is that what you and Matt agreed to do? If so, fine. I'm just trying to clarify things in my own mind.

Also, Matt's description quoted above is different than the logic you have in pull request #904 with respect to "the employee portion of payroll taxes."

First, the _payrolltax variable includes the net investment income tax amount, NIIT, so you can't be multiplying _payrolltax by one half and expect to get the correct answer.

And second, there is an ambiguity about what exactly is the "employee share" of the Self-Employment Tax (payroll taxes collected on self-employment income). Does the Fair Share Tax reform regard half or all of the Self-Employment Tax as being the "employee share"? The self-employed worker actually does pay all of the Self-Employment Tax. Remember that the whole Self-Employment Tax is included in the _payrolltax variable.

And a couple of questions about the _FST_AGI_thd parameter. The information in issue #862 seems to suggest that this parameter is inflation indexed and is, in the first reform year, one million dollars for all filing units types except it is half a million dollars for married filing separately. So, shouldn't the _FST_AGI_thd parameter be indexed by filing unit type? And shouldn't it be inflation indexed in years after the first reform year? Or maybe your reform JSON file specifies it that way, which goes back to an earlier question I posed about the exact nature of the reform you are analyzing.

[martinholmer]

@andersonfrailey said about the Fair Share Tax reform he simulated:

the only [policy] parameter changed was _FST_tentRate. It is [in the reform] 0.3 [instead of 0.0].

Thanks for the clarification. So, my other (more recent) questions about pull request #904 are still relevant.

[andersonfrailey]

@martinholmer

Are we just abstracting from the after-only-certain-credits aspect of the reform. It looks as if pull request #904 includes all the credits in the income tax liability. Is that what you and Matt agreed to do? If so, fine. I'm just trying to clarify things in my own mind.

Yes, we are abstracting from that aspect of the reform.

First, the _payrolltax variable includes the net investment income tax amount, NIIT, so you can't be multiplying _payrolltax by one half and expect to get the correct answer.

Thanks for pointing this out. For the next push I plan on using half of _ptax_was for the employee share of payroll taxes, as used in the ExpandedIncome function to find the employer share. Thoughts?

As for the employee share of the Self-Employment Tax, the proposal does not specify whether half or all of the Self-Employment Tax will be used when calculating FST. I'm inclined to use half of the Self-Employment Tax, though I have yet to find evidence that the Clinton team or other models do.

So, shouldn't the _FST_AGI_thd parameter be indexed by filing unit type? And shouldn't it be inflation indexed in years after the first reform year?

I have changed the default for the parameter to be indexed for inflation. I will also add an index for filing unit type.

[martinholmer]

@andersonfrailey said:

For the next push I plan on using half of _ptax_was for the employee share of payroll taxes, as used in the ExpandIncome function to find the employer share. Thoughts?

Yes, this is correct, but incomplete as you realize when you say:

As for the employee share of the Self-Employment Tax, the proposal does not specify whether half or all of the Self-Employment Tax will be used when calculating FST. I'm inclined to use half of the Self-Employment Tax, though I have yet to find evidence that the Clinton team or other models do.

Half sounds reasonable. Any contrary thoughts from @MattHJensen or Dan @feenberg?

@andersonfrailey also said:

I have changed the default for the [FST threshold] parameter to be indexed for inflation. I will also add an index for filing unit type.

OK, we'll look forward to the next version of pull request #904. Remember that when the FST_thd parameter is inflation indexed it will be greater than one million in 2017, which I'm assuming is the first year of the FST reform. So you will have to do two things: set the FST_trt to 0.30 and set the FST_thd to 1000000 beginning in 2017. When you do that with the above logic corrections, can you present again (like you did in #890) the aggregate revenue effects from Tax-Calculator and compare those estimates with other estimates.

[martinholmer]

@andersonfrailey, I forgot to mention that there is yet another subitem in the _payrolltax variable: the Additional Medicare Tax, which is a 0.9% tax on high earnings (see the source code for details) that has no employer share. It may be true that we will need to add another subtotal variable to allow you to compute the employee share of the _payrolltax total. If you see it that way, please let me know and I will add the extra variable.

@MattHJensen

[andersonfrailey]

The latest push uses the variables added in #909 to compute the employee share of payroll taxes, assuming half of the self-employment tax is used for the calculation.

It moves the FairShareTax function above the BenefitSurtax function to avoid any conflict with the _iitax variable.

It renames _FST_minAGI to _FST_AGI_thd to match the codebase. Additionally, _FST_AGI_thd is now indexed for inflation and marital status.

My revenue estimates after setting _FST_tentRate to 0.3 and the 2017 _FST_AGI_thd back to 1000000 and 500000 in 2017 along with estimates from other models are below.

Model	2016	2017	2018	2019	2020	2021	Total
TPC	2.2	2.4	4.7	10.2	12.5	12.8	44.8
Treasury (2016)	6.7	-.093	1.2	2.8	3.7	3.9	17.37
Treasury (2017)	0.0	7.8	-.062	1.3	3.1	4.0	15.58
Joint Committee on Taxation	4.8	5.3	5.7	6.1	6.4	6.7	35
Avg. of other Estimates	3.4	3.6	2.7	5.1	6.4	6.8	28.18
TC	16.16	17.01	17.48	17.76	18.34	18.98	105.73

With the new variables for payroll taxes the TC estimates have moved slightly closer to the others, but are still pretty far out there.

[martinholmer]

@andersonfrailey, Pull request #904 is starting to look good. After discussing the _FST_* policy parameters with @MattHJensen, we want to suggest something a little different from the way things are now. The suggested changes are meant to achieve two goals. The first is to adhere more closely to the Contributor Guide's parameter naming conventions. And the second is to avoid the need to specify an infinite FST phase-in rate when specifying a FST reform where the "tentative" tax is paid in full whenever AGI is above the lower AGI threshold.

The suggested set of _FST_* policy parameters are as follows:

_FST_AGI_thd_lo   : now called _FST_AGI_thd
_FST_AGI_trt      : now called _FST_tentRate
_FST_AGI_thd_hi   : replaces _FST_phaseRate

Does this make sense? If not, let's discuss this further. If so, can you make these changes in current_law_policy.json and in the new FairShareTax function logic?

Also, can you post here the Fair Share Tax reform dictionary that you are using to specify the reform?

Thanks for all the work on this. This is going to be an important addition to Tax-Calculator.

@feenberg @Amy-Xu @GoFroggyRun

[andersonfrailey]

@martinholmer @MattHJensen

Could you clarify a little more what the functionality of _FST_AGI_thd_hi will be? I'm envisioning it as the level of AGI above which the entirety of the tentative tax is paid. In the case of a reform where you must pay the entirety of the tax if you exceed the lower threshold period, _FST_AGI_thd_hi and _FST_AGI_thd_lo will be equivalent. Alternatively, if the reform wanted the tax to be phased in it will be the level of AGI where the tax is fully phased in.

In the Clinton proposal, for example, _FST_AGI_thd_hi would be equal to $2 million (or $1 million if married filing separately.

From TPC:

The amount of FST payable (i.e., the excess of tentative FST over regular tax) would be phased in linearly starting at $1 million of AGI ($500,000 in the case of a married individual filing separate return). The FST would be fully phased in at $2 million of AGI ($1 million in the case of a married
individual filing a separate return).

And here is the reform dictionary I've been using:

buffettReform = {
    2017: {'_FST_AGI_trt': [0.3],
           '_FST_AGI_thd_lo': [[1000000, 1000000, 500000, 1000000, 1000000, 500000]]
    }
}

[martinholmer]

@andersonfrailey asked:

Could you clarify a little more what the functionality of _FST_AGI_thd_hi [parameter] will be? I'm envisioning it as the level of AGI above which the entirety of the tentative tax is paid. In the case of a reform where you must pay the entirety of the tax if you exceed the lower threshold, _FST_AGI_thd_hi and _FST_AGI_thd_lo will be equivalent [that is, have the same numerical value]. Alternatively, if the reform wanted the tax to be phased in it will be the level of AGI where the tax is fully phased in [which means _FST_AGI_thd_hi > _FST_AGI_thd_lo].

Yes, this is exactly the way I'm thinking about these three FST parameters. And just to be extra clear, if _FST_AGI_thd_hi > _FST_AGI_thd_lo, then the actual FST liability is computed by linear interpolation between those two thd values with the actual liability being zero when AGI equals _FST_AGI_thd_lo and increasing linearly to being the full or tentative liability when AGI equals _FST_AGI_thd_hi.

Does all that make sense?

@MattHJensen

[martinholmer]

@andersonfrailey, I don't understand why there are so many changed files (56) in pull request #904. Shouln't there be just a handful?

Here's how to fix this problem: (1) checkout master, (2) make sure your local master is up-to-date with the GitHub master, (3) checkout your FairShareTax branch, (4) merge master into FairShareTax branch (git merge master), (5) resolve any conflict encountered in the merge, (6) test the updated code on the FairShareTax branch, (7) commit any changes you make, and (8) push the new FairShareTax branch to GitHub (git push origin FairShareTax).

This process has many steps, but each one is fairly simple. If you have any questions about this, ask @MattHJensen or @Amy-Xu for advice.

[andersonfrailey]

The latest push implements the _FST_AGI_thd_hi parameter proposed by @martinholmer and @MattHJensen and merged the most recent master branch with the FairShareTax branch.

I've set the default values for _FST_AGI_thd_hi to $1,000,000 for filers that are married filing separately and $2,000,000 for all others to match the Clinton proposal.

I'm still getting revenue estimates that are abnormally large compared to others:

2017	2018	2019	2020	2021
17.01	17.48	17.76	18.34	18.98

I used the new PUF as well as this reform dictionary:

buffettReform = {
    2017: {'_FST_AGI_trt': [0.3],
           '_FST_AGI_thd_lo': [[1000000, 1000000, 500000, 1000000, 1000000, 500000]],
           '_FST_AGI_thd_hi': [[2000000, 2000000, 1000000, 2000000, 2000000, 1000000]]
    }
}

[martinholmer]

@andersonfrailey, Pull request #904 looks much cleaner now; thanks for getting it in sync with the latest on the master branch. I guess the major outstanding question is why does the reform raise so much more than other models are estimating.

But before focusing on that, I have one question about the calculation of the Fair Share Tax in this code:

        if (c00100 >= FST_AGI_thd_hi[MARS - 1] or
                FST_AGI_thd_hi[MARS - 1] == FST_AGI_thd_lo[MARS - 1]):
            fst = max(tentFST - _iitax - employee_share - NIIT, 0.0)
        else:
            fst = max((((c00100 - FST_AGI_thd_lo[MARS - 1]) /
                     (FST_AGI_thd_hi[MARS - 1] - FST_AGI_thd_lo[MARS - 1])) *
                     (tentFST - _iitax - employee_share - NIIT)), 0.0)

Why is the NIIT amount being subtracted from the tentative FST amount?
Isn't NIIT already part of _iitax?

@MattHJensen @feenberg @Amy-Xu @GoFroggyRun

[andersonfrailey]

@martinholmer said:

Why is the NIIT amount being subtracted from the tentative FST amount?
Isn't NIIT already part of _iitax?

Yes you're correct. I missed that in the C1040 function. After correcting for that the new revenue estimates I'm getting are:

2017	2018	2019	2020	2021
30.01	30.67	31.04	31.89	32.96

[martinholmer]

@andersonfrailey said:

Yes you're correct [about NIIT already being in _iitax]. I missed that in the C1040 function. After correcting for that the new revenue estimates I'm getting are:

 2017   2018   2019   2020   2021
30.01  30.67  31.04  31.89  32.96

So, fixing that makes the estimates even further away from those generated by other models. Right?

Your earlier summary of other estimates was:

MODEL         2016  2017  2018  2019  2020  2021
TPC            2.2   2.4   4.7  10.2  12.5  12.8 
Tsy(2016)      6.7  -0.1   1.2   2.8   3.7   3.9
Tsy(2017)      0.0   7.8  -0.1   1.3   3.1   4.0
JCT            4.8   5.3   5.7   6.1   6.4   6.7

Does anybody have any ideas about why the other models generate such different estimates?

@MattHJensen @feenberg @Amy-Xu @GoFroggyRun

[martinholmer]

@andersonfrailey, I can confirm on my own computer your $30.01 billion revenue increase for 2017.

[MattHJensen]

Does anybody have any ideas about why the other models generate such different estimates?

Here's one idea:

Both TPC and Treasury may be stacking this proposal after other reforms, in particular a limitation on itemized deductions. Neither explicitly state the stacking order, but the FST does appear below the itemized deduction limitations in their tables.

The JCT estimate is not so easy to explain away since the FST appears to be analyzed alone.

[martinholmer]

Shall we merge this (pull request #904) now and possibly investigate the differences between Tax-Calculator and the JCT model?

@MattHJensen

[andersonfrailey]

@martinholmer said:

So, fixing that makes the estimates even further away from those generated by other models. Right?

Correct.

@MattHJensen said:

Both TPC and Treasury may be stacking this proposal after other reforms, in particular a limitation on itemized deductions. Neither explicitly state the stacking order, but the FST does appear below the itemized deduction limitations in their tables.

I'll run the calculator again this time with a few of the other tax proposals mentioned in in the TPC and Treasury proposals and see what if any affects they have on the taxcalc estimates.

[martinholmer]

@andersonfrailey said:

I'll run the calculator again this time with a few of the other tax proposals mentioned in the TPC and Treasury proposals and see what if any affects they have on the taxcalc estimates.

That would be good. Meanwhile, I'm going to merge this pull request #904 into the master branch so that pending merges don't introduce "conflicts with the base branch." Thanks for all the work on this @andersonfrailey. We can all continue to investigate cross-model differences on the master branch.

@MattHJensen @feenberg @Amy-Xu @GoFroggyRun

[MattHJensen]

Tax Foundation has a very similar estimate to TC.

http://taxfoundation.org/sites/default/files/docs/TaxFoundation-FF496.pdf