Address issue with VAT and sales tax data/calculation from OECD dataset

[robbieorvis]

A while back, we had a discussion about the OECD IO database tax values we were using, in which we discovered that the taxes are not representative of value added taxes (for example, see: https://www.oecd.org/sti/ind/2673344.pdf or 4.2 on p. 15 of the Guide available here: https://stats.oecd.org/DownloadFiles.aspx?HideTopMenu=yes&DatasetCode=TIVA_2021_C1). They are instead taxes paid by producers on commodities that are inputs to production. This is reflected by the fact that the tax percentages from the OECD database are very low (for example, in the 2021 IO dataset, the Basic metals industry has total output of 284 billion and the tax amount is 3.2 billion, about 1%.

We are therefore significantly underestimating changes in tax revenue/expenditures from within the IO model (taxes are calculated separately for fuels, so we are okay here).

The OECD maintains a nice dataset of VAT by country, available here: https://www.oecd-ilibrary.org/sites/1ca62ced-en/index.html?itemId=/content/component/1ca62ced-en#tabnote-d1e60836.

The World Bank also has some data here: https://data.worldbank.org/indicator/GC.TAX.GSRV.VA.ZS

Currently taxes are computed as corporate taxes in the EPS using input data that calculates domestic taxes as a share of value added (io-model/DToPaSoVAbIC). Unfortunately, the data from the OECD is in producers prices, not purchasers prices, so it doesn't reflect any VAT, meaning we can' simply adjust this input variable to have a higher percentage, because the overall value added figure doesn't capture the increased amount.

To correctly address this data issue, we probably need to add a value added tax in between output and direct purchases.

In other words, total demand by ISIC code ($) = domestic output by ISIC code (1+VAT).

Finally, especially with the new import/export substitution, it may be important to account for import duties. I have not explored the need here or whether or not data exists to do anything in particular.

[robbieorvis]

Also, here are definitions from the OECD:

Producers' prices:

The producer’s price is the amount receivable by the producer from the purchaser for a unit of a good or service produced as output minus any VAT, or similar deductible tax, invoiced to the purchaser; it excludes any transport charges invoiced separately by the producer.

It also excludes supplier’s retail and wholesale margins and separately invoiced transport and insurance charges. (A producer’s price for a product is the basic price plus any non-deductible tax on products paid by the producer less any subsidies on products received by the producer.)

Purchasers' prices:

The purchaser’s price is the amount paid by the purchaser, excluding any deductible VAT or similar deductible tax, in order to take delivery of a unit of a good or service at the time and place required by the purchaser; the purchaser’s price of a good includes any transport charges paid separately by the purchaser to take delivery at the required time and place.

The amount paid by the purchaser in order to take delivery of a unit of a good or service at the time and place required by the purchaser. It excludes any VAT (or similar deductible tax on products) which the purchaser can deduct from his or her own VAT liability invoiced to customers. It includes supplier’s retail and wholesale margins, separately invoiced transport and insurance charges and any VAT (or similar deductible tax on products) that the purchaser cannot deduct from his or her own VAT liability.

A purchaser’s price for a product is the producer’s price plus supplier’s retail and wholesale margins, separately invoiced transport and insurance charges and nondeductible taxes on products payable by the purchaser.

Purchasers’ prices are the prices most relevant for decision-making by buyers.

See here: https://stats.oecd.org/glossary/detail.asp?ID=2144 and https://stats.oecd.org/glossary/detail.asp?ID=2202#:~:text=A%20purchaser's%20price%20for%20a,for%20decision%2Dmaking%20by%20buyers.

[jrissman]

Thanks for adding this issue.

We likely will add a separate VAT (and/or sales tax) step in the I/O model. Adding it to the sectors individually was how we did it before, but that would not be the right structure for us to use today. For instance, policies now affect overall production, which isn’t specific to the equipment in each sector (EV chargers, etc.). So, for example, so explicitly add VAT on EV chargers to the Transportation sector would be double-counting after we add VAT to the output of each ISIC code.

A sales tax is charged on the entire value of goods and is paid at the last step by the business or consumer buying the product for their use. So it will be based on applying the tax rate to the "Output" I/O data.

Within a VAT taxing area, like the EU, VAT is charged at each step in a supply chain on the incremental value added during that step. So it will be based on applying the "VAT" tax rate to the "Value Added" I/O data.

We'll probably need structure for both and input data files that let you specify either a VAT tax rate, a sales tax rate, or both (though I don't know if there are any jurisdictions that use both). You will probably just leave the data set to zero for a jurisdiction that doesn't have a given tax type, so there is no need for a toggle lever.

If an item is imported:

• If it's a sales tax region, the item is subject to sales tax upon sale to end user, similar to a domestically-produced item.

• If it's a VAT region, the VAT is charged (at the typical VAT rate) on the full value of the imported item, essentially cumulating the value added to the product at all previous production steps. If what is being imported a finished good, that makes it rather similar to a sales tax. If raw materials or parts are being imported, they will have other value-added steps occurring within the VAT area on which VAT will be charged following import.

Note that these are separate from special import duties that a country may levy on imports of particular goods or from particular countries, such as anti-dumping provisions the U.S. levied on Chinese exports of solar panels. Sometimes these can be avoided by producing or shipping via a different country, such as Vietnam. I think these are different from the VAT/sales tax issue and are harder to model because they may vary based on which country exported the item (i.e. China or Vietnam). OECD data does include trade flows between individual countries, but it isn't a complete set, and it would be a lot of additional input data and data processing for a relatively minor effect. So I'm inclined just to focus on getting the VAT and sales tax representation right, and maybe add the ability to model additional import duties later if need be. (I do see the value in modeling that - the U.S. tariffs on Chinese-made solar panels are a good example. We'd want to be able to show how that impacts the domestic solar market.) Maybe we just use a weighted average import duty and handle the processing of the numerous bilateral trade flows entirely in the input data. This might deserve its own GitHub issue, leaving this one for VAT and sales tax.

[robbieorvis]

This all sounds great, Jeff. My only comment is that we just make sure we don’t double count given that some VAT is included in output based on VAT paid on input commodities. I’m not sure we would need to do anything differently, but just flagging that.

[jrissman]

Megan and I analyzed the structure closely just now. We think that for a VAT region:

• The current structure is correct for domestic producers
• We have added VAT charges on imports
• We will add VAT rebate on exports, but it requires #183 to be done first (calculation of non-energy exports)
• Robbie is correct that the current data in io-model/DToPaSoVAbIC reflects taxes only on intermediate inputs, and the differences in apparent rate by ISIC code stem, in large part, from differences in the amount of intermediate inputs purchased per unit value added generated by each ISIC code. That's not what we want in this variable - we want pure VAT tax rates. So we will be replacing the OECD's OTXS data entirely with VAT rates, likely from the OECD VAT table Robbie linked to.

After some consideration, we think it is best to represent sales tax regions via the equivalent VAT tax structure. Producers will be able to pass on the costs to their suppliers. For example, an automaker in a sales tax region will pay less to its steel supplier than if it were in a VAT region because the steel supplier doesn't have to pay the tax, so the ultimate tax burden ought to land on approximately the same ISIC codes.

To calculate sales tax explicitly is hard because we (1) need to sum change in output, then (2) specify the fraction of each ISIC code's output that is subject to sales tax, which is only final goods sold to end users (which can include businesses in many cases), but not intermediate inputs. These data aren't available from OECD directly. We could make this estimate using the "total" TTL variable from the OECD input-output database, but the required assumptions would add at least as much inaccuracy as simply representing the sales tax as an equivalent VAT.

This all refers to non-energy goods. We already handled taxes, imports, and exports on energy products separately, which is not part of this issue.

[jrissman]

Also note that while in theory, sales taxes in the U.S. and similar jurisdictions are supposed to exempt intermediate inputs, such as materials that go into making a product, in practice, this is messy, complicated, and varies by state. This report by Ernst & Young explains the problem and has some relevant data on the extent of, in their view, improper double-taxation of business inputs.

None of that matters because we're going to treat sales tax regions as via the equivalent VAT structure. But if we were to try to model sales tax directly, we might need to account not only for the theoretical ideal sales tax, but for the way sales taxes really are implemented, which is messier and not worth doing.

[robbieorvis]

This all makes sense. We could come up with a decent proxy determining the share of output from value added by ISIC code and then calculating a weighted VAT by ISIC code that is meant to represent the correct percentage. I agree with not adding the structure to do it explicitly and I think this approach would get you a decent estimate. We should probably add some detail about this in the About tab for the relevant file.

[mkmahajan]

The issue of tax accounting came up during a conversation I had with Robbie, where we looked together at the current structure in the Macroeconoic Feedbacks sheet. After looking at it a bit more this morning, I have two other thoughts on representing taxes.

1. We currently calculate the Macro Change in Government Revenue as the sum of changes in domestic corporate tax revenue (value add * VAT or sales tax rate) and changes in individual income tax revenue. However, I think we would also want to account for any increases in corporate income taxes paid, since that is separate from a VAT or sales tax. Robbie pointed out that corporations can usually deduct the amount of VAT paid from their corporate income taxes, so we'd likely want to use the higher of these two terms.
2. I'm not sure we're correctly capturing the Macro Expenditure Changes right now. All 'Change in Domestic Corporate Tax Revenue' is assigned to 'Macro Change in Domestic Industry Expenditures by ISIC Code.' But consumers are paying a portion of those taxes for the goods that they purchase. I think we would want to apportion the additional VAT or sales tax paid by the fraction of goods purchased by entity (which we already calculate in io-model/FoGPbEaIC). But what is trickier is determining what adjustments may be needed to account for when the tax is paid. For example, I believe manufacturers can deduct previously paid VAT at each step, but final consumers cannot deduct previously paid VAT.

Robbie expressed interest in joining for the first half hour or so of today's session to chat over these pieces together, since they're a bit complicated to think through.

[jrissman]

I'm attaching to this GitHub comment the Word document Megan and I began working on to clarify the definitions of specific economic variables and precisely how to calculate them, as well as what the I/O model expects as its inputs, and the clear "to do" items we identified. We didn't have time to finish this document is complete before I had to go to a meeting, so when we next work on this, we should (1) ensure we feel comfortable with everything already in the document, (2) add anything missing to the document that we might need for model accuracy, then (3) implement it in Vensim.

2022-04-22 Calculating Economic Variables in EPS v01.docx

When we are done, we should double-check to ensure the following variables are being calculated correctly:

• Change in Domestic Output by ISIC Code
• Change in Domestic Corporate Tax Revenue by ISIC Code

We also might want to do some renaming of things on the "Macroeconomic Feedbacks" sheet to clarify them, and possibly remove the prefix "Macro" from variable names and instead just use names that describe more thoroughly what the variables are. But that is optional.

[jrissman]

OECD database documentation with variable definitions: http://stats.oecd.org/wbos/fileview2.aspx?IDFile=e57f76c1-1e5b-4a39-879b-28e5c5ef9cc7

[jrissman]

Commit d374929 separates VAT and sales tax ahead of the I/O model and assigns it to government. This allows the I/O model to take in Output by Industry at Basic Prices (i.e. after these taxes are removed from industry revenue), as the I/O model and OECD data expect.

The VAT and sales tax on indirect and induced economic activity is now calculated on the "Macroeconomic Feedbacks" sheet and is fed into the I/O model.

Remaining items to consider are:

• Whether to add corporate income taxes to the model. It is difficult to determine the correct base to which to apply a corporate income tax rate, as it is a subset of the OECD's "Gross Operating Surplus and Mixed Income" statistic and is not broken out, plus we don't calculate profits / profit margins in the EPS, so finding the change in the taxable income might be difficult. Also, note that there are severe loopholes that enable corporations to shelter some or all of their taxable income from corporate income tax, so even if we did calculate corporate taxable income, it might be incorrect to apply the corporate income tax rate to all of it due to the loopholes.

• Currently, from the "Macroeconomic Feedbacks" sheet, government gets the both the change in individual income taxes (from changes in worker compensation) and the change in VAT and sales tax from indirect and induced sales. These changes to government cash flow are fed back into the I/O model. We should verify whether we need to remove these same tax amounts from the entities paying these taxes (i.e. consumers/labor for the individual income tax changes and businesses and domestic consumers for the VAT/sales tax changes). (VAT and sales tax aren't charged on exports, so foreign entities don't pay those taxes.)

• Currently, Direct Change in Cash Flow by Entity includes changes in Labor/Consumer cash flow, which are heavily dominated by changes in their expenditures. There is a tiny contribution there from changes in their earnings, calculated in each separate sector. This is dwarfed by the changes in Labor/Consumer earnings calculated on the "Macroeconomic Feedbacks" sheet and is probably duplicative of some of those earnings. We might want to assign all payments within the sectors to specific ISIC codes, not to labor and consumers, if they are earnings (i.e., wages and compensation), since we handle changes in wages based on changes in Output from each ISIC Code. (We can continue to assign changes in expenditures, both energy and non-energy expenditures, to labor/consumers in each sector.)

[jrissman]

Also, we need to update the placeholder data in VoSTR VAT or Sales Tax Rate with real data. Megan indicated she would handle that. The model expects this tax rate in the same format no matter whether the modeled region is a VAT region or a sales tax region.

The VAT and sales tax systems are equivalent in the amount of revenue raised and charge on the entire value of a good just once (at least, for idealized tax systems, which is what we are modeling). The notion that EU VAT rates are higher than U.S. sales tax rates because VAT is charged on a lesser share of a good's total value is incorrect.

[robbieorvis]

To clarify: this means that we can use either VAT rates or sales tax rates in the input data and the model will work correctly?

[jrissman]

Yes, it will work correctly, subject to the three bulleted caveats in my post just above. The only one of those with any bearing on VAT or sales tax is the second of the three. It is possible that no change is needed in response to that bullet - it just requires further review.

The first bullet can likely be deferred, as it is a feature we simply haven't built yet. We could make a new issue for it (since this issue is meant to pertain to VAT and sales tax).

The third bullet is minor and doesn't pertain to tax at all. We can discuss it further sometime, but it doesn't really relate to the topic of this thread.

So my view is that we should conduct sufficient review to feel comfortable about bullet 2, put real tax rate data into VoSTR, close this issue, and open new issues covering the other two bullets, which we can prioritize as low or high as appropriate. I don't think the next EPS release necessarily need wait on those other two issues, given that I won't be able to work on EPS for a month. But I'm open to other opinions.

[robbieorvis]

Got it. I’m not sure I fully understand the second bullet, but it sounds like it’s mostly for you internal tracking so that’s fine.

For the first bullet, isn’t profit equal to value added – taxes – labor costs? Or is that too simplified? I think of profit as equivalent to gross operating surplus, but I might be mis-defining it.

[jrissman]

I moved the discussion of corporate income taxes to a new, dedicated issue (#224). Let's use this GitHub issue for VAT and sales tax.

[jrissman]

I know today isn't a workday for me, but I really wanted to try to resolve bullet 2 (above) before heading out on vacation, because it is the last thing for 3.4 that is tricky and particularly needs my attention. Here is my reasoning on it:

• The I/O model expects as an input the change in revenue by ISIC code after subtracting out any VAT or sales tax (i.e. that money goes to government and doesn't count as industry revenue).

  • Note that this is different from how we handle payments to labor, payments for equipment, and other expenses of running a business, which are supposed to be included in the change in revenue by ISIC code that goes into the I/O model.

• In a new piece of code, we now separate out the change in sales tax or VAT from the change in industry revenue on the Cross-Sector Totals sheet ahead of the I/O model. This applies to all ISIC codes, not just Industry Category ISIC codes. (Energy suppliers already had their sales/fuel taxes separated out ahead of the I/O model even prior to 3.4., so that isn't part of the new code.) This is done by multiplying the VAT or sales tax rate by the change in revenue that comes directly out of the various modeled sectors.

• The I/O model calculates indirect and induced demand for products from all ISIC codes. We don't have that available to us until after the I/O model.

• On the Macroeconomic Feedbacks sheet, we calculate Change in Domestic Output by ISIC Code based on the total change in domestic Value Added by ISIC Code, which is the sum of the value added changes due to direct, indirect, and induced effects, so it is holistic. For industry category ISIC codes, we adjust industrial production based on this change in domestic output (on Industry - Main).

  • Therefore, the revenue impacts of the indirect and induced output should be included in the revenue changes coming out of the Industry sector, so sales tax or VAT on that indirect and induced output is already being correctly separated out and assigned to government ahead of the I/O model.

  • However, for the ISIC codes that don't correspond to any industry category (such as education, real estate, consulting services, social work, finance and insurance, etc.), I don't see any place where we are separating and assigning to government the VAT or sales tax on induced and indirect output.

  • But do these things even incur VAT or sales tax? We don't pay sales tax on school tuition, the purchase of a home, consulting services, social work, etc. I do think certain services (such as getting a haircut) often have sales tax charged, but I think those are unusual exceptions that likely represent a tiny, tiny share of the non-industry-category ISIC codes' output. For simplification, and because the EPS isn't designed to model hair salons, we can probably disregard those exceptions.

  • But we are currently charging VAT or sales tax on the direct output of those non-industry ISIC codes. So I've gone ahead and excluded the non-industry-category ISIC codes from VAT or sales tax entirely, rather than build a way to charge VAT or sales tax on the indirect and induced output of the non-industry-category ISIC codes.

• On the Macroeconomic Feedbacks sheet, we are currently calculating VAT or Sales Tax Collected on Indirect and Induced Sales by ISIC Code, then summing that with the change in government revenue from change in individual income taxes, and assigning to government near the beginning of the I/O model.

  • However, above, we just wrote that the VAT or sales tax on indirect and induced output for industry categories should already be included in what is coming out of the Industry sector because we adjusted the production of the Industry sector based on the I/O model outputs.

  • Therefore, it appears to me that adding the VAT or sales tax on induced and indirect output to government cash flow is double-counting this addition to government cash flow.

  • So I've removed this. It now only feeds back the change in individual income tax revenue from the Macroeconomic Feedbacks sheet into the I/O model.

• I've left a placeholder section for Corporate Taxes with some comments and a reference to issue #224 (regarding corporate income taxes) to explain what's going on.

[jrissman]

Here is the difference made in the "Change in GDP" graph from the fixes noted above (plus a different, minor fix to the calculation of Change in VAT). This is for the NDC scenario. The graphs look pretty similar, but note the Y-axis scale is different (the first graph scale goes up to $900 billion and the second graph scale goes up to $800 billion).

Prior to fixes:

After fixes:

[jrissman]

I think that fully resolves bullet 2.

Bullet 3 is pretty minor and not related to VAT or sales tax. Therefore, I'm going to make a separate issue for it and tag it that for possible inclusion in 3.5 rather than holding up the 3.4 release for it.

We still need real data instead of placeholder data in VoSTR VAT or Sales Tax Rate. @mkmahajan will be handling that. Once we have real data in that variable (and acronymn key updated), we can close this issue.

[jrissman]

Actually, aside from adding real data to VoSTR, there is one more thing to check. Megan and Robbie, can you take a look?

On the Industry - Main sheet, now that we have this structure:

Perhaps we no longer need this structure:

We don't want to double-adjust the output of the same ISIC codes. But I'm cautious about removing the second adjustment because we calculate it with great care on the Macroeconomic Feedbacks to include only indirect and induced effects, and to incorporate the effects of the Buy In-Region policy lever (which is tricky). The first (new) adjustment above is just based on changes in output from the I/O model and includes direct, indirect, and induced effects, which I believe we want in this context, as we have no other place where we are adjusting industrial output to account for direct policy effects. (It also already includes the effects of the buy in-region lever, which acts early in the I/O model.) So even though it's simpler, I'm feeling pretty confident we want to keep the first of these two adjustments.

The main question in my mind is whether to keep or get rid of the second adjustment. I'm leaning toward getting rid of it because I think it's double-counting, but I just don't have time to review with the thoroughness to be sure.

(We would still keep that adjustment in the Buildings and Transport sectors, which rely on a similar structure. I'm only thinking about the Industry sector here.)

Can you review the relevant code and decide whether or not to remove one of these two adjustments (presumably, remove the second adjustment)? (If it's not clear, I can look into it more after my vacation.)

[robbieorvis]

Hi Jeff, we can take a look while you're out, sure, but may need to discuss when you're back in case we have issues understanding.

Regarding the earlier discussion of what to do for non-industry ISIC codes, we should probably look at a couple of policy scenarios (e.g. NDC) to see what the magnitude of cash flow changes is for those sectors relative to the others, just to make sure it's a small share. Because if it isn't small, we probably can't just dismiss them. I agree that generally speaking we'd expect them to be small except that government and consumer spending is largely in these categories, and if we have a policy package with a large growth in labor or consumer savings, I could see the resulting induced cash flows to the services sector being quite large.

[jrissman]

Regarding the earlier discussion of what to do for non-industry ISIC codes, we should probably look at a couple of policy scenarios (e.g. NDC) to see what the magnitude of cash flow changes is for those sectors relative to the others, just to make sure it's a small share.

The point is not that these cash flows are small. The point is that most of the output of those ISIC codes is not subject to sales tax.

[robbieorvis]

Right, but I’m not sure about that assumption. A lot of services have VAT, and we need to remember to look not just at the US but also internationally. I am not sure that is a valid assumption.

[jrissman]

Okay, that's fine. I am glad we are on the same page now.

If we want to, we can introduce a new input variable that specifies what share of the output of each ISIC code is subject to sales tax. That share would be near 100% for the industry category ISIC codes, near zero for (say) education or government services, and somewhere in the middle for other non-industry ISIC codes. If you prepare that input variable, I can incorporate it into the model when I get back. This would handle industry and non-industry ISIC codes uniformly with regard to sales tax, instead of assuming 100% of industry output is subject to sales tax and 0% of non-industry output is subject to sales tax.

[robbieorvis]

If we subscripted the VAT tax rate by ISIC code, would this be strictly necessary? It seems like that would give us more flexibility and reduce input variables? Also, I’ve seen some data for, e.g. India, that different sectors have different VAT rates.

[jrissman]

Yeah, subscripting the VAT rate by ISIC code would work equally well for this, as well as allowing different VAT rates for different ISIC codes.

The structure needs a small update then because right now it just assigns zero VAT to the non-industry ISIC codes, but that would be an easy update.

[robbieorvis]

Let’s just go ahead with that, which gives us the flexibility to hunt down some data on this point in the meantime, and leaves the door open to situations in other regions.

From: Jeff Rissman @.> Sent: Thursday, May 12, 2022 12:05 PM To: Energy-Innovation/eps-us @.> Cc: Robbie Orvis @.>; Author @.> Subject: Re: [Energy-Innovation/eps-us] Address issue with VAT and sales tax data/calculation from OECD dataset (Issue #221)

Yeah, subscripting the VAT rate by ISIC code would work equally well for this, as well as allowing different VAT rates for different ISIC codes.

The structure needs a small update then because right now it just assigns zero VAT to the non-industry ISIC codes, but that would be an easy update.

— Reply to this email directly, view it on GitHubhttps://github.com/Energy-Innovation/eps-us/issues/221#issuecomment-1125173486, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SLYVKT3WX267W7BOETVJUT3DANCNFSM5SQKISPA. You are receiving this because you authored the thread.Message ID: @.**@.>>

[mkmahajan]

Thanks for this, Jeff!

I took a look at the code you highlighted, and I don't actually think we want to remove the second portion. At the top of the "Calculating Change in Imports and Production for Nonfuel Industries" section of code, we are calculating the Change in Passthrough Expenses as Share of Nonenergy Industry Output by ISIC Code. Here, we're taking the nonenergy industry expenses passed through to buyers and dividing by output in order to come up with a percentage. The only reason we see the BDMFL disable macroeconomic feedback loops here is because we want to divide by output in the policy case rather than in the BAU case. But the calculated Change in Passthrough Expenses as Share of Nonenergy Industry Output by ISIC Code is just a percentage change based on direct passthrough expenses.

Further down where we see the second instance of BDMFL, we calculate the change in production to to indirect and induced macroeconomic effects. I think this is correctly capturing the direct effects only in the top portion, then the indirect and induced effects later on.

However, I'd like a check on that logic! Maybe Robbie and I can find time to review this new feature together.

I did also find one other place that I think needs adjustment. When we programmed this feature, we calculated collected VAT or sales tax as the (Change in Nonenergy Industry Revenue by ISIC Code – Exports of Nonenergy Products) * the tax rate. The reasoning was that all of our costs in the model (cost of building components, vehicles, power plants, etc.) should have tax included, so our cash flows should already include all collected VAT or sales tax.

However, that is not true for the Change in Nonenergy Industry Revenues due to Production Changes by Purchasing Entity. This is simply calculated as the Percent Change in Production due to Policies * BAU Output, which does not include VAT or sales tax. Therefore, I think we need to add in VAT or sales tax collected on this additional production when we calculate the Change in Nonenergy Industry Revenues due to Production Changes by Purchasing Entity. This will ensure consistent treatment of when we account for taxes.

[mkmahajan]

Yesterday, Robbie and I walked through this feature together. We both agree that both of the sections of code Jeff flagged should remain in the model. We also agree that an additional adjustment is needed to apply VAT or sales tax to the revenue caused by changes in production.

Related to that note, I spotted an additional place I believe we need an adjustment. Here, we calculate the Change in Passthrough Expenses as Share of Nonenergy Industry Output by ISIC Code by dividing the change in passthrough expenses (which already account for taxes) by Output (which does not account for taxes).

I think we would want to remove taxes from the passthrough expenses, then divide by output.

Finally, I went ahead and subscripted VoSTR by ISIC code and modified the code to apply tax to all ISIC codes. Note that for now, I put in the average US sales tax rate. I have looked for a central source that would allow us to determine which services to apply tax to. However, the US is quite complicated in that every state has different sales tax rates and exemptions, so it's very hard to come up with assumptions here.

As Jeff pointed out above, However, I don't think we are currently accounting for VAT or sales tax on induced and indirect output for services that don't correspond to one of our 25 industry categories. I think we may want to add some code to the Macroeconomic Feedbacks sheet to handle this.

Robbie and I discussed holding the 3.4 release until after Jeff is back so we can be confident in these changes before launch. But I am going to go ahead and:

• Modify the code to remove taxes from passthrough expenses before calculating the change in production
• Modify the code to apply taxes to revenue from changes in production
• Come up with some final assumptions for service industries in the VoSTR file

I am a little less sure about an adjustment for services in the Macroeconomic Feedbacks sheet, so will hold off on that.

[jrissman]

I took a look at the code you highlighted, and I don't actually think we want to remove the second portion. At the top of the "Calculating Change in Imports and Production for Nonfuel Industries" section of code, we are calculating the Change in Passthrough Expenses as Share of Nonenergy Industry Output by ISIC Code. Here, we're taking the nonenergy industry expenses passed through to buyers and dividing by output in order to come up with a percentage. The only reason we see the BDMFL disable macroeconomic feedback loops here is because we want to divide by output in the policy case rather than in the BAU case. But the calculated Change in Passthrough Expenses as Share of Nonenergy Industry Output by ISIC Code is just a percentage change based on direct passthrough expenses.

Further down where we see the second instance of BDMFL, we calculate the change in production to to indirect and induced macroeconomic effects. I think this is correctly capturing the direct effects only in the top portion, then the indirect and induced effects later on.

However, I'd like a check on that logic!

I reviewed this today together with Megan and agree that this reasoning and the structure are correct.

[jrissman]

I did also find one other place that I think needs adjustment. When we programmed this feature, we calculated collected VAT or sales tax as the (Change in Nonenergy Industry Revenue by ISIC Code – Exports of Nonenergy Products) * the tax rate. The reasoning was that all of our costs in the model (cost of building components, vehicles, power plants, etc.) should have tax included, so our cash flows should already include all collected VAT or sales tax.

However, that is not true for the Change in Nonenergy Industry Revenues due to Production Changes by Purchasing Entity. This is simply calculated as the Percent Change in Production due to Policies * BAU Output, which does not include VAT or sales tax. Therefore, I think we need to add in VAT or sales tax collected on this additional production when we calculate the Change in Nonenergy Industry Revenues due to Production Changes by Purchasing Entity. This will ensure consistent treatment of when we account for taxes.

Megan showed me the fix she made for the items above and I agreed that it looked good.

[jrissman]

However, I don't think we are currently accounting for VAT or sales tax on induced and indirect output for services that don't correspond to one of our 25 industry categories. I think we may want to add some code to the Macroeconomic Feedbacks sheet to handle this.

Megan and I together built this feature today, completed in commit bf80272.

That completes the last outstanding item for this issue, so I'm closing the issue.