There isn’t anything too exceptional about the Splitwise Tax model, other than that is a rough and ready estimator. It uses a macro-level estimate (not a more accurate and sophisticated micro-estimate) to estimate changes in revenue based on changes in the tax code. This is necessary to have the beautiful, interactive, and relatively quick visual response that the calculator has to changes in the tax code. Our tax model also is built from entirely public data, and linearly interpolates to fill in holes in its knowledge.
It does not calculate any economic impacts or budgetary impacts of the tax code – that sort of projecting is best left to experts, and is obviously significantly more speculative.
The model is plotted on an x-axis log scale, used for clarity and breath. We choose not to show very low AGI taxpayers or very high AGI tax payers to keep a manageable dynamic range.
I am very grateful to the NBER’s wonderful TAXSIM 9 program, which helped me check my work on understanding the tax code and taught me about how the system works.
We realize that the y-axis values we chose can have a big impact in perception, and we spent some time before settling on a -25% to
50% 75% (updated 4-14 by popular request) tax frame. Using a very large frame (say, to 100%) makes the graphic hard to read, hard to edit, and visually unbalanced. When the average tax goes below the scale, the pop-up shows the tax rate. The 50% maximum top rate made things look better, but we do plan to add an advanced option at some stage to allow users to go above this 50% rate. 4-14-2012: we’ve made the new default 75%, and we don’t expect to change it again, except perhaps as an advanced option.
We currently only show brackets and taxes for an average family of four, but we plan to change that as soon as possible.
We launched version 1.0 of the model on 4/12, and welcome corrections or suggested improvements. Changes will be posted below.
Comments and Flaws
Mortgage interest deduction: we seems to be a bit high relative to other studies of the cost, relative to existing published studies. One limitation of the model is that we can’t predict how many people would choose to just use a standard deduction, but we assumed all of the people who itemized would continue to itemize and would just lose the deduction.
Buffet rule: Our result seems to be in between published studies of the rule, which have claimed figures as low as $4B per year and as high $50B per year. We do not have a good sense of the variance of rates paid by individual tax payers, but we simply apply the rule to the “average” taxpayers we have sample data for above 1M dollars. Ours is a relatively rough estimate, and I haven’t studied the details, so I don’t have a position on which of these rival studies is more accurate.
EIC: I have a function that calculates this directly, but due to the details of the qualifications and under-claiming (and over-claiming) of the credit, I rescaled its effect on the budget to internally match the IRS data. I’m not sure it would be possible to do this any other way.
We show a mix of itemized and unitemized returns in the graph, so it’s not possible to specify the exact number of kids. We’re working so that you’ll soon be able to browse in these modes.
Some technical notes:
The model specifically works by using 2012 standard deduction and exemption features and using 2009 deduction data to deal with the fraction of deductions itemized and how much was itemized at each level.
“Income before taxes” is technically AGI, Adjusted Gross Income, which does include some deductions. Most of the data is derived from this IRS data from 2009 (and these two files, one outlining the deductions itemized and another. Obviously, this makes the data somewhat out of date, so it is scaled linearly to be equal to the 2012 projected revenues of $1165 billion for personal income tax.
The number of children assumed was derived from Census data.
version 1.1 posted 9:45pm Saturday 4/14/2012. Brackets now allowed up to 75%. Voting now allowed without social plugin (but non-logged in votes may be screened after the fact if we suspect foul play).
version 1.0 posted 1pm Thursday 4/12/2012.