The current approach to forecasting earnings should be improved to begin with BEA data and CBO forecasts, make adjustments for relevance by firm type (and industry, in the future), and then adjusted to align with IRS historical results. I expect the methodology to proceed as follows (with possible changes):

1. Begin with BEA data on corporate and noncorporate profits before tax, and use the forecasts for these from CBO.
2. Add back depreciation and net interest to get gross profits.
3. Use IRS SOI tables to split corporate profits into C corporations, S corporations, RICs and REITs, and to split noncorporate profits into farm sole proprietorships, nonfarm sole proprietorships and partnerships.
4. Use IRS SOI tables to split C corporation profits into those held by firms in taxable and nontaxable status.
5. Make adjustments to resemble actual gross profits for each firm type, in particular regarding real unreported income.

Note that this may involve splitting the Corporation class into those with positive net income and with negative net income. This would be further complicated by changes in the tax base, which could be problematic.

Another potential approach would be to begin with IRS information for 2013 and explicitly forecast each component of it. These would include

• Business receipts (sales, etc.)
• Interest income (taxable and tax-exempt)
• Rents and royalties
• Capital gains and losses
• Dividends from domestic corporations
• Dividends from foreign corporations (handled by the CFC and DomesticMNE classes)
• Other receipts
• Cost of goods sold
• Compensation of officers
• Salaries and wages
• Repairs
• Bad debts
• Rent paid
• State and local taxes paid
• Interest paid
• Charitable contributions
• Amortization (should be handled by Asset class, mostly)
• Depreciation (handled by Asset class)
• Depletion
• Advertising
• Pension plans, profit-sharing, etc.
• Employee benefit programs
• Domestic production deduction (already done)
• Net operating loss deductions
• Other deductions

All of these could be set to grow at the same (or separate) rates, unless it is explicitly modeled.

Of these approaches, I think the latter is likely better, as we have explicit initial values for 2013.

The interest model, both for C corporations and pass-throughs, could use serious work to improve it. This work includes modest substantive changes as well as larger refactoring. First, an overview of the economic logic behind it:

The model assumes the existence of an optimal net debt-to-asset ratio. This is consistent with existing evidence, with mild/modest deviations around severe recessions. We assume that debt originated in any given year is retired at a fixed rate, eta, and that interest paid on that debt henceforth is at the original interest rate prevailing at that time. The interest rate on corporate debt is the 10-year Treasury bond rate plus Moody's Baa corporate bond premium. The firm also earns some interest income from its debt assets, which we assume are Treasury bonds (or pay T-bond rates). The historical data for corporate debt assets and liabilities come from the Financial Accounts, and interest rate and premiums are available from FRED.

We apply a nearly identical process for pass-through businesses, except that we only model the debt liability component because interest income from pass-through debt assets is taxed as interest income on the individual income tax.

The first stage of the process is calculating the adjustment factors (corporate and noncorporate) to rescale net interest based on the Financial Accounts data to match net interest based on IRS data. This could be improved by jointly calculating the adjustment factor and the debt retirement rate eta, which is currently assumed to be 0.4. (This value of eta was picked to approximately match existing data, but it should rightly be calculated instead.)

We calculate interest paid and received in the baseline very similarly to how we calculate it for the adjustment factors. These functions are in interest_model.py. These functions include no policy parameters. Part of refactoring should make the reform interest model functions, which are located in responses.py, capable of handling this.

We calculate the reform using the functions in responses.py because previous versions of BRC calculated the baseline and then the reform. These calculations are somewhat more complicated. They first calculate the baseline path of net debt, debt liabilities, and debt assets. They then calculate the marginal tax shield from debt, which is the tax rate in the baseline and is the tax rate multiplied by (1 - haircut) in the reform (with the haircut being the larger of the haircut on the net interest deduction and the haircut on the interest deductibility of new debt). It then applies the debt semi-elasticity to the change in the marginal tax shield to calculate the new optimal net debt and debt liabilities; I assume that debt assets are unchanged, as this is typically due to cash on hand being stored in liquid assets. Given the optimal path of debt, it then calculates originations of new debt, with originations limited to being nonzero. Using the new originations, we calculate the net interest deduction similarly to how we do in the baseline functions, but with modifications to incorporate the haircuts on the net interest deduction, on interest paid on old debt, and on interest paid on new debt.

Currently, without a change in policy, the "reform" functions located in responses.py produce the same results as the "baseline" functions located in interest_model.py. However, we need to switch to using the reform functions in general. Although not a problem pre-TCJA, this will become a problem post-TCJA, as we will need to make some assumption about the elasticity of borrowing to even calculate the new baseline (because CBO does not provide corporate debt forecasts from which to forecast the new baseline). We will also need to add a parameter limiting the net interest deductibility to some fraction of earnings (specifically, EBITDA), which the TCJA set at 30 percent. Although this is not binding for the representative firm, it will be binding if we split the representative firm into separate representative firms for each industry and net profit/loss status.

@andersonfrailey @hdoupe @martinholmer @Abraham-Leventhal @lucassz

Does anyone have suggestions about how to proceed? I would be happy to discuss this in person if that's easier.

With the international tax model built, we should consider a profit shifting response, in which earnings and profits booked in CFCs respond to the tax shield from doing so. Use Dowd et al. (2017) (https://www.sciencedirect.com/science/article/abs/pii/S004727271730018X) for the semi-elasticities. Changes in profits booked in CFCs would come from profits booked in foreign branches, and perhaps from profits booked domestically.

This lays out the steps for updating to a new baseline.

1. Prepare the necessary methodological changes

• International tax model
• Section 163(j) interest limitation

2. Change policy_current_law.json to post-TCJA parameters.

3. Change partial equilibrium forecasts to use response to TCJA as baseline.

• Debt financing shares
• Repatriation rates

4. Update economic forecast to current CBO forecast.

5. Continue making methodological changes to improve accuracy, and compare to CBO forecast for corporate tax revenue.

One potential improvement on the model may be splitting pass-through businesses into S corporations, partnerships, and nonfarm sole proprietorships. This would be a useful step toward later splitting these by industry.

Unlike C corporations, all data should be for all of each business type, rather than just those with net income.

Data on S corporations would come from https://www.irs.gov/statistics/soi-tax-stats-table-1-returns-of-active-corporations-form-1120s

Data for partnerships would come from https://www.irs.gov/statistics/soi-tax-stats-partnership-statistics-by-sector-or-industry

Data for nonfarm sole proprietorships would come from https://www.irs.gov/statistics/soi-tax-stats-nonfarm-sole-proprietorship-statistics

Data on these are available beyond 2013, so we should start with 2014 data.

This GitHub organization (Open-Source-Economics) is becoming a home for the Policy Simulation Library, and it will be renamed PSLmodels on December 3rd. Starting then, I'd like for every project in PSLmodels to either be in PSL or be in the process of joining PSL.

BRC is very welcome in PSL! If the project is interested in joining, could you please let me know by Dec 3 and begin (if not finish) conforming to the PSL Criteria? If the project is not interested in joining, I'll help move this repo to a different organization or remove it.

Please let me know how you'd like to proceed -- I'll be keeping an eye on this issue, and I'm also happy to join a call to discuss.

@martinholmer discovered that changing the depreciation method for 25-year property from GDS to Economic had no effect on depreciation. Initially, I was stumped by why this was occurring, as the code seemed to be perfectly capable of changing the depreciation method for the 25-year class.

The reason this had no effect is that in the data from CCC, there is no property with a class life of 25 years.

Under GDS, only 2 property types have lives of 25 years. From IRS publication 946:

25-year property. This class is water utility property, which is either of the following.

• Property that is an integral part of the gathering, treatment, or commercial distribution of water, and that, without regard to this provision, would be 20-year property.
• Municipal sewers other than property placed in service under a binding contract in effect at all times since June 9, 1996.

However, in the tax depreciation rules I took from CCC, they classified "Water supply" and "Sewage and waste disposal" as having 20-year class lives. This seems probably incorrect, although not necessarily so, as 20-year property includes "Municipal sewers not classified as 25-year property."

Fairly soon, I plan to open a PR to completely reorganize BRC. The new structure will use a number of objects, described below, instead of the current approach.

The new BRC will use the following classes:

• Data: This class serves as a convenient means of accessing the various datasets necessary to run BRC. Its use is mostly for convenience.

• Asset: This absorbs all of the activity that was previously done by ccr_model.py. This produces and saves the relevant information.

• Debt: This runs the net interest calculations, which we previously spread across 2 files.

• CorpTaxReturn: This is a corporate tax return. It extracts the relevant tax information from associated Asset and Debt objects as well as earnings and calculates tax liability (corporate tax revenue).

• Corporation: This executes all of the calculations and holds all objects specific to the corporate income tax.

• PassThrough: This executes all of the calculations and holds all objects relevant to recalculating net business income for each type of pass-through.

• Investor: This acts as the interface with Tax-Calculator. It produces the MTRs and distributes changes in corporate after-tax income and pass-through business income.

• Response: This object calculates the firm's responses. The use of it throughout is a bit clunky right now, and the legal response is deprecated (and commented out).

• BusinessModel: This includes 2 Corporations (baseline and reform), 2 PassThroughs (baseline and reform), 2 Investors (baseline and reform), and potentially a Response. The combination of a baseline and a reform path is necessary to the computation of the responses and the distribution of the changes to the corporate income tax and pass-through net income. I am open to suggestions for changing the structure of this class or breaking it up.

The new structure will provide additional flexibility and should hopefully run more quickly. Moreover, the use of distinct Corporation and PassThrough objects will allow a future expansion to separate by industry.

It is important to note that this does not fix everything; I want to do more refactoring after this. But this should make it easier to refactor and for others to access, understand, use and modify the model.

The recent changes to Tax-Calculator to make it more object-oriented will cause the code in BRC that interfaces with taxcalc to no longer work. All of the code to interface with taxcalc can be found in usercode_taxcalc.py.

I think this should be fixable by changing each call of calc.records.variable either to calc.array('variable') (when extracting an array of values) or to calc.set_array('variable', new_variable_values) (when setting new values for each series).

However, I would appreciate if someone more familiar with the recent changes to Tax-Calculator could assess whether this approach to updating BRC is correct and advisable.

@martinholmer @hdoupe @MattHJensen

When running the tests, I receive the warnings

PytestUnknownMarkWarning: Unknown pytest.mark.requires_pufcsv - is this a typo? You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/latest/mark.html

It looks like something changed in taxcalc that has deprecated this. @martinholmer, do you know what needs to change for this?

The current approach to the corporate AMT relies on a number of different estimates, as well as a steady-state assumption for the baseline. These estimates include values about transition rates between AMT liability status from the 1990s and accumulated PYMTC carryforwards. These will not be applicable if we split C corporations by industry. Consequently, the model should be modified to estimate these parameters based on observed data/trends, rather than to pull external estimates. The model also relies on assumptions about taxable income, which may not be entirely accurate for large changes to definitions of taxable income. However, given that the corporate AMT has been repealed, it is unlikely to matter much.

The TCJA made a handful of changes relevant to corporate AMT model. In addition to repealing the AMT, it made the PYMTC refundable for 2018-2021, and repealed it thereafter.

If we're improving the model, we should use data from https://www.irs.gov/statistics/soi-tax-stats-table-23-returns-of-active-corporations, which provides data on the corporate AMT and corporations subject to it.

This issue is intended to list potential changes to policy parameters.

Interest deductibility:

• Split out interest income and interest paid deduction.
• Drop net_intPaid_corp_hc
• Add parameter for inclusion of corporate interest income (or not).
• Consider parameter for inclusion of corporate interest expense (although redundant).
• Add parameters for section 163(j):
  • Indicator for whether adjusted taxable income is before/after depreciation/amortization/depletion
  • Share of adjusted taxable income against which to offset net interest

Portfolio income parameters:

• Share of capital gain/loss (on financial assets) included in taxable income
• Share of municipal interest income included in taxable income

International parameters:

• FDII deduction rate (probably useless)
• Compute FDI share in DomesticMNE class

I've been thinking about whether it may be useful to break up BRC into 3 separate components:

1. A corporate tax model (corporate-tax).
2. A pass-through business tax model (name ideas?), which would recalculate pass-through business income and update the inputs in Tax-Calculator for e00900, e00900p, e00900s, e26270 and e02000.
3. A business behavioral response model, which would update corporate investment and optimal debt based on corporate income tax parameters, update noncorporate investment and optimal debt based on the business tax parameters and individual income tax results (MTRs) that apply to pass-through businesses, and shift business activity between the corporate and noncorporate sectors based on the relative tax rate differential that would result from switching entity form (although in reality the effect could operate both through business entity choices and relative competitive advantages created by the tax rate differentials).

@martinholmer, @MattHJensen, do you have any thoughts on whether this is worthwhile?

Based on a suggestion by @martinholmer, this issue documents the major barriers to running time in BRC.
The following are the functions that take more than 5 seconds to execute, in order in which the functions are first called.

calcDepAdjustment

• Called twice in ccr_model.py.
• Executes in 19.49 seconds.

annualCCRdeduction

• Called four times overall: twice in gen_baseline.py and twice in gen_reform.py.
• Executes in 19.45 seconds.

get_mtr_nc_list

• Called twice overall: once in gen_baseline.py and once in reform_implementation.py.
• Executes in 161.42 seconds.

inv_response

• Called once as a response function.
• Executes in 21.05 seconds.

legal_response

• Called once as a response function. Slow because it calls get_mtr_e_list()
• Executes in 269.63 seconds.

get_mtr_e_list

• Called twice in legal_response function.
• Executes in 131.73 seconds

distribute_results

• Called once as part of evaluating total cost.
• Executes in 43.78 seconds

@MattHJensen @hdoupe @andersonfrailey

After the refactoring in #50, it's time to create a new to-do list for BRC.

1. Refactor the mini_combined.py file
   This file acts as a workhorse for calculating the cost of capital. This is very similar to what B-Tax does, and as such it may be useful to make it to some degree interchangeable with B-Tax. However, my mini version is distinct from B-Tax in that I use different equations for calculating the cost of capital; my equations allow for nonconstant tax rates, something certainly relevant in the context of the expiration of that pass-through exclusion (Section 199A) in the TCJA.

2. Alternate version of the legal response
   I'm not satisfied with the current approach. In reality, any effect should not occur instantaneously, and it needs to occur without overlapping the investment effect.

3. Improve the AMT model
   The current version is reasonable from economic modeling, but I want to run some further tests to ensure that it is robust to larger changes in tax rates.

4. Add an international tax model
   With the new structure of BRC, I image the best approach to implementing this will involve creating a new class, the MultinationalEnterprise, to handle changes in profit shifting and the TCJA's new international taxation provisions.

5. Deal with the other_params dictionary
   These parameters are tricky to deal with because they involve some strange changes. It may be helpful to refactor the entire approach to handling policy parameters in BRC.

6. Switch to one year at a time
   With the new structure, this should be somewhat easier to do. It may also make it easier to deal with the other_params issue.

I expect there are a number of structural changes that need to be made as well. @martinholmer @andersonfrailey @hdoupe, would you care to list some of those areas that need to be refactored further?

At our previous meeting, I (hopefully) explained the order of building the baseline for BRC. The current version starts with the corporate tax revenue forecast from CBO, subtracts off the AMT (forecast with the PYMTC), adds back the PYMTC and the FTC (forecast individually, but soon to be done through the international tax model), divides by the statutory rate less the GBC "adjustment rate" (estimated based on historical data) to get taxable income, adds back the domestic production deduction (forecast individually), and adds back depreciation (forecast individually) and net interest (forecast based on historical data and the forecast of the capital stock) to get earnings.

As an alternative, we could just do this backing out prior to 2014 (start year of BRC), and then advance each component individually. The growth factor for corporate earnings would come from CBO's forecast for corporate profits, the growth factor for noncorporate earnings would come from CBO's forecast of proprietors' nonfarm income, the growth factor for business investment would come from CBO's forecast of nonresidential fixed investment, and the net interest deduction, AMT/PYMTC and other minor components could be forecast based on these main factors.

This alternative approach seems very doable, and it would be consistent with the approach currently used in Tax-Calculator. If implemented, it would also be easier to separate the BRC calculations from the construction of the data, which would be sent over to taxdata.

@martinholmer @andersonfrailey @hdoupe @Abraham-Leventhal @lucassz, what do you think of this approach?

In the corporate tax return, the net loss from noncapital assets is related to the sale of assets relevant to the business. This should be renamed, but will not affect results.

I've been working on changes to two components of the model, which when incorporated will alter the model results.

The first is redoing the collection and preparation of data for the Asset class. This replace the process of producing the investment and capital stock results based only on the original data, without using B-Tax computations as intermediates. Furthermore, it also redoes the collection of depreciation tax rules, which previously just used the work already done in B-Tax. Categorizing BEA asset classes by IRS asset classes at times is tricky and requires some judgment. Consequently, the new version includes reference information to the IRS classifications used.

The second major change will be to add the components of the international tax model. I plan to add the classes before integrating them into the rest of Business-Taxation. These will potentially also alter results.

@martinholmer, is there a convenient way to overwrite the test results stored in CSV files?

The international model should receive 3 types of improvements:

1. Improve data collection in code so it can be done by industry.

2. Add profit-shifting response. From issue #141:

With the international tax model built, we should consider a profit shifting response, in which earnings and profits booked in CFCs respond to the tax shield from doing so. Use Dowd et al. (2017) (https://www.sciencedirect.com/science/article/abs/pii/S004727271730018X) for the semi-elasticities. Changes in profits booked in CFCs would come from profits booked in foreign branches, and perhaps from profits booked domestically.

3. Add FDII calculation. From issue #128:

• DEI = Gross income excluding subpart F, GILTI income, financial services income, dividends from 10% owned foreign corporations, domestic oil and gas extraction income, foreign branch income, and any deductions allocable to those excluded income categories.
  In the actual model, this is income less constructive taxable income, dividends from foreign corporations and foreign branch income and deductions.
• FDDEI: Similar to DEI, except only the portion of activities from selling goods, services or property to foreign unrelated parties or for foreign use by related parties.
• DII = DEI - 0.1 * QBAI
  FDII = DII * FDDEI / DEI
• Deduction = FDII * 0.375
  We don't actually have sufficient information to accurately calculate DEI and FDDEI separately, but we can approximate the ratio FDDEI / DEI using the share of sales by US MNE parent companies to foreign parties. Essentially, we would compute this using:
• DEI = Net income (pre-tax) of US parents - Net income (pre-tax) of foreign affiliates of US MNEs
• DII = DEI - 0.1 * Net PPE of US parents
• FDDEI / DEI = Sales of US parents to foreign affliates and persons / Total sales of US parents

For balance sheet of parents, use the file PartI-L1-M2, sheet Table I.L 1. This has asset information on US parents by industry. For balance sheet of affiliates, use the file Part II-B1-B12, sheet Table II.B 11. This has asset information on majority-owned foreign affiliates by industry of US parent. For all foreign affiliates, the balance sheet information is not provided by industry of the parent company.

For income of parents, use the file Part I-N1-P1, sheet Table I.N 1 for the income statement and sheet Table I.O1 for sales to domestic and foreign recipients. For income of majority-owned foreign affiliates, use file Part II-D1-D13, sheet Table II.D 11. For income of all foreign affiliates, use the file Part 1-D1-D12, sheet Table I.D 10.

The Pandas developers seem to be planning to quit supporting Python 2.7 at the end of 2018 as described here. In the coming months the Tax-Calculator developers would like to transition Tax-Calculator to be a Python 3.6+ project.

Will this project find it acceptable to have access to only Python 3.6 taxcalc packages?

@codykallen, The first paragraph of the blog post says:

it certainly would be helpful to get software firms to clarify the exact effect the Senate’s new [TCJA] rules for intangible assets will have on their tax bill

The blog post presents some formulas and poses this question:

Is there a chance the tax bill isn’t great for multinational companies?

Is this a reasonable analysis of the Senate bill?

With the basic infrastructure for the international tax model added, the following are some additional modifications to make.

1. Add a repatriation response.

• Repatriation rate of current CFC income, based on current tax shield.
  • Use a semielasticity with respect to the tax shield.
  • Or assume full repatriation with no tax shield, and adjust repatriation rate in between.
• Repatriation rate of accumulated foreign earnings. This may be somewhat arbitrary, and dependent on tax holidays. Consider some alternatives.

2. Add additional policy/economic parameters.

• Fraction of non-repatriated CFC income included in taxable earnings
• FDII exclusion rate
• Fraction of nondividend foreign income eligible for FDII
• Fraction of domestic income eligible for FDII
• GILTI tax rate
• Tangible return rate for GILTI (10%)

3. Add more CFC details.

• Tangible assets (grow at same rate as foreign income)
• Figure out GILTI liability

4. Have domestic and foreign earnings grow at different rates.

I wanted to open this issue to start a discussion on some of the concrete next steps we can do to get BRC ready for integration with Tax-Calculator. Here are a few things I think need to get done, would love if y'all could add to the list.

1. Save some output from the current version of BRC to be used for regression testing after any changes we make.
2. Move all of the data prep steps into TaxData
3. Refactor BRC to use this preprocessed data
4. Build a class interface for BRC (similar to the Calculator class in taxcalc, unless we want to work BRC directly into the current Calculator class)
5. Refactor the functions used in BRC (as needed)

cc @codykallen @martinholmer @hdoupe @Abraham-Leventhal @lucassz

@codykallen, as we discussed on the phone last week, one of the PSL criteria is to give users of a PSL model an example program that uses the model to generate results and also to give users the example's expected results (so they can see that everything is working correctly on their computers).

Here are a few suggestions about how you might consider doing that.

First, how about putting the code in the combined_corporate_model.ipynb notebook into a text file called example.py? This script would be executed at the operating-system command line like this:

$ python example.py > example_actual.res

And then users can compare the example_actual.res contents with the example_expect.res file in the repository. Users can do that using their favorite graphical diff utility.

Second, in the new example.py code, you need to print the results (which all seem to be pandas DataFrame objects) using the to_string DataFrame method. So, for example, if dfx is a DataFrame object, then instead of just dfx to see the contents in a notebook, do this instead:

print(dfx.to_string(float_format='%8.1f'))

That float format assumes you've already scaled the dfx contents to billions of dollars and that you want to round results to the nearest one-tenth of a billion dollars. Vary the float format as you see fit.

And finally, it will be far more helpful to users if you specify a reform in the example.py file (so that the reform-induced change in revenue is something other than zero).

Let me know if you have any questions.

This is intended to list the FDII computation and potential data to use for it.

Items to compute:

• FDII: Income eligible for the deduction (second-to-last step)
• DEI: Deduction-eligible income
• DII: Deemed intangible income
• FDDEI: Foreign-derived deduction-eligible income
• QBAI: Tangible assets

Steps in the computation:

• DEI = Gross income excluding subpart F, GILTI income, financial services income, dividends from 10% owned foreign corporations, domestic oil and gas extraction income, foreign branch income, and any deductions allocable to those excluded income categories.
  In the actual model, this is income less constructive taxable income, dividends from foreign corporations and foreign branch income and deductions.
• FDDEI: Similar to DEI, except only the portion of activities from selling goods, services or property to foreign unrelated parties or for foreign use by related parties.
• DII = DEI - 0.1 * QBAI
• FDII = DII * FDDEI / DEI
• Deduction = FDII * 0.375

We don't actually have sufficient information to accurately calculate DEI and FDDEI separately, but we can approximate the ratio FDDEI / DEI using the share of sales by US MNE parent companies to foreign parties. Essentially, we would compute this using:
DEI = Net income (pre-tax) of US parents - Net income (pre-tax) of foreign affiliates of US MNEs
DII = DEI - 0.1 * Net PPE of US parents
FDDEI / DEI = Sales of US parents to foreign affliates and persons / Total sales of US parents

Forthcoming work will split the single Corporation into different Corporations for each industrial sector (with some subsectors). We will thus have a Corporation for each of the following, along with identifying codes:

                  'FARM': 'Farm',
                  'FFRA': 'Forestry, fishing, and related activities',
                  'MINE': 'Mining',
                  'UTIL': 'Utilities',
                  'CNST': 'Construction',
                  'DMAN': 'Durable goods manufacturing',
                  'NMAN': 'Nondurable goods manufacturing',
                  'WHTR': 'Wholesale trade',
                  'RETR': 'Retail trade',
                  'TRAN': 'Transportation',
                  'INFO': 'Information',
                  'FINC': 'Credit intermediation (Finance)',
                  'FINS': 'Securities, commodity contracts, and investments (Finance)',
                  'INSU': 'Insurance',
                  'REAL': 'Real estate',
                  'LEAS': 'Rental and leasing',
                  'PROF': 'Professional, scientific, and technical services',
                  'MGMT': 'Management of companies',
                  'ADMN': 'Administrative and waste management services',
                  'EDUC': 'Educational services',
                  'HLTH': 'Health care and social assistance',
                  'ARTS': 'Arts, entertainment, and recreation',
                  'ACCM': 'Accommodation and food services',
                  'OTHS': 'Other services, except government'

This will require adjusting the Corporation class to accept industry codes and use different results for each industry. It will also require adjusting the net interest deduction model to handle different industries, including different adjustment factors, to be applied to the original data as is now the case for the capital and investment data.

It will also require adjusting the AMT parameters to apply separately for each industry; it may be advisable to reuse some of the parameters across industries. The same need will apply when calculating the FTC parameters, although the FTC model could also use some revision.

The current version of the NID model begins with debt assets and liabilities from the Financial Accounts, computes estimated interest income and interest expense, and rescales to match the net interest deduction in SOI data. However, the SOI data include debt assets and liabilities, so it seems unnecessary to rely on the FA for such measures, especially as the FA does not provide breakdowns by industry.

A revised approach would simply take debt assets and liabilities from the SOI balance sheet data, estimate the relevant risk premiums, and forecast from those. This would also simplify the interest model, as interest would then only be based on current liabilities and interest rates, not historical originations and interest rates.

Here is the Asset constructor:

    def __init__(self, btax_params, corp=True, data=None, response=None):
        # Create an associated Data object
        if isinstance(data, Data):
            self.data = data
        else:
            self.data = Data()
        # Check inputs
        if isinstance(corp, bool):
            self.corp = corp
        else:
            raise ValueError('corp must be True or False')
        self.response = response     <-----------------------------------------------------
        if corp:
            self.adjustments = {'bonus': 0.60290131, 'sec179': 0.016687178,
                                'overall': self.data.adjfactor_dep_corp,
                                'rescalar': self.data.rescale_corp}
        else:
            self.adjustments = {'bonus': 0.453683778, 'sec179': 0.17299506,
                                'overall': self.data.adjfactor_dep_noncorp,
                                'rescalar': self.data.rescale_noncorp}
        if isinstance(btax_params, pd.DataFrame):
            self.btax_params = btax_params
        else:
            raise ValueError('btax_params must be DataFrame')

The above code does not check the type of the response argument (which is a clear code improvement opportunity).

How can I generated an object to pass to the Asset constructor via the response argument?

Under pre-TCJA law, corporations were allowed a deduction for dividends received from taxable domestic corporations. The general deduction rate was 70%, with an 80% rate for dividends from a 20%-owned corporation and a 100% rate for dividends from a corporation in the same affiliated group.

The TCJA reduced the 70% rate to 50% and the 80% rate to 65%.

Implementing this may be tricky, as we lack information on the sources of the dividends received from domestic corporations. Moreover, the IRS information is the amount of the income net of the deduction. I think the best approach to modeling this will be to assume the 70% rate was used in general, and to back out dividends received in earnings_prep.py. We would not be able to model the 100% deduction for dividends received from affiliated corporations, but this should not be particularly important, as the TCJA does not change it, and policies to change it would have little effect on revenue (although larger effects on how corporate organizations register their subsidiaries).

This issue is to discuss two options for modeling the new section 163(j) limitation on interest expense. It limits the deduction to interest paid to the sum of interest income, floor plan financing (not relevant in general), and 30 percent of adjusted taxable income. Adjusted taxable income is taxable income before:

• Business interest income or expense
• Net operating loss deductions
• Income or deductions not allocable to the trade or business (not relevant)
• Depreciation, amortization or depletion (prior to 2022)
  Interest expense in excess of the limitation becomes interest expense the following year.

The major problem with explicitly modeling this provision is that the revenue relies on firm heterogeneity, and thus representative firm approaches will not well, and may not work at all. For example, using representative firms for each major industry, the limitation is only binding in the following industries beginning in 2022 (and in no industries prior to then):

• Utilities
• Printing and related support activities
• Transit and ground passenger transportation
• Hospitals, nursing and residential care facilities
  The resulting estimates for the fraction of interest paid deductible are still close to 1, but should be in the ballpark of 0.8.

Simply using the fraction of interest deductible policy parameter likely gets closer to the actual effect of the provision, but could have incorrect implications for modeling responses (although perhaps not unreasonably so).

When writing a test for the Data class update_rescaling method, I noticed a few improvement opportunities.
Here is the code now:

    def update_rescaling(self, corplist, ncorplist):
        """
        Updates the rescaling factors associated with the DataFrame
        """
        assert len(corplist) == 14
        assert len(ncorplist) == 14
        self.rescale_corp = corplist
        self.rescale_noncorp = ncorplist

As far as I can see the two arguments passed in and both the Data class attributes rescale_?corp are all numpy arrays. Given that, wouldn't it be less confusing to replace corplist with something like corparray and replace ncorplist with something like ncorparray?

Also, I don't understand the docstring. What is meant by the phrase "factors associated with the DataFrame"?
The factors are associated with the Data class, right? So, maybe it would be clearer to say something like this:
Updates the rescaling factors in the Data class object

One of the trickiest potential areas when dealing with policy parameters is how to design policy parameters to allow for flexible changes to depreciation rules without having too many parameters, as to make it unreasonably difficult.

When building this model, I generally followed the approach in CCC, which allows for changes based on class lives, with depreciation policy parameters tied to the class life. However, this approach doesn't allow for changes to the life, which is important for potential policy changes. For example, an early version (although not the final version) of the TCJA planned to reclassify the 39.5 year class (nonresidential structures) as 25 year property. One could also want to make changes to the tax rules for specific asset types, without altering the rules for other assets with the same class life.

A previous version of Business-Taxation had reform parameter reclassify_gds_life and reclassify_ads_life, which allowed for changing the lives from one length to another (e.g. 39.5 years to 25 years). But handling this was cumbersome, and it would not be applicable in the Policy class as currently structured.

Perhaps it would be useful to have 2 types of reforms. One would be a standard reform dictionary (as currently done in Tax-Calculator), and the other would be specific to depreciation rules, allowing for changes by class life, by specific asset type, and by minor asset class.