|
|
posted: April 9, 2017
tl;dr: When you couple two complex systems, complexity increases more than additively...
This is not a blog post about the merits of Obamacare. Certainly I think all reasonable folks can agree that its goal (affordable healthcare) is admirable. Rather, it is another blog post about design complexity vs. design simplicity (see “Elegant Simplicity in Software” and “Coding Simplicity”). The best designs and systems, in my experience, are those that achieve “elegant simplicity”. All sorts of undesirable outcomes and unintended consequences result when a system is too complex. One of those undesirable consequences is the major bug I found in TurboTax, in the Obamacare calculations.
TurboTax checking for updates...and bug fixes
At its core, Obamacare is nothing more than what economists call “price discrimination” for health insurance policies. Price discrimination means selling the exact same product (e.g. a health insurance policy) to different consumers at different prices. With Obamacare, the price is based on the consumer’s income: consumers who earn more pay more for the same policy. The way it's implemented is via a subsidy from the government to the consumer: the government doesn’t actually set the price of the insurance policies, they just give subsidies based on income to consumers to buy the policies. There’s nothing particularly new about this, as it is also (sort of) the way that college tuition is priced in the U.S., although much of that subsidy comes in the form of student loans. If everything in the U.S. were sold this way, it would allow the U.S. to effectively achieve income equality: if Jane earns twice as much as Dick but Jane has to pay twice the price that Dick pays for everything, Dick and Jane will have the same purchasing power. In effect, their incomes would be equal.
The concept behind Obamacare is simple. The problem is that it effectively links two systems that are each incredibly complex by themselves: the U.S. tax code and the U.S. health insurance system. The U.S. tax code long ago passed beyond the ability of a single human being to fully comprehend it. Tax calculation and tax compliance is a full-time job for a large number of people in this country (accountants and tax attorneys), there are companies whose main business is tax preparation, and every individual taxpayer in the country spends many hours a year figuring out his or her taxes, meaning multiple billions of man-hours each year are spent on tax compliance. Health insurance is also massively complex, with eligibility requirements, enrollment deadlines, policy differences, individual deductibles, plan deductibles, copays, coinsurance, differences in prices for individual health services (in-network vs. out-of-network), limits on the use of services, etc. Few people like either system and few people would say either system is “fair”, in part because no one fully understands either system.
To buy a health insurance policy in the Obamacare era, if you don’t work for a company that does this on your behalf, you go onto the healthcare.gov website before the year starts and, in effect, prepare your income tax statement for the year ahead based on best-guess estimates. This embeds the complexity of the U.S. tax code in healthcare.gov and the purchase of health insurance, which is one of the reasons why the site is so problematic and so widely reviled. The results of precomputing your taxes determine whether a consumer is eligible for a subsidy, which most consumers apply to their monthly insurance policy premiums during the year (note: the bug I found does not apply for this case). However, since the data entered are only estimates, after the year is over consumers compute and file their actual tax returns, and recalculate the subsidy they actually should have received. The difference between the estimated subsidy and the actual subsidy is trued up as part of the final tax calculation: the difference can cause money to flow in either direction, to the consumer or to the government. So there is also linkage from the health insurance system back into the tax code. In effect, these two very complex systems are now coupled. TurboTax, the widely used tax calculation software package, is now more complex than it was because of this coupling.
The TurboTax bug
Not having a clear idea of how much money I would earn last year, I bought my family health insurance policy on healthcare.gov without requesting the monthly subsidy in advance. This is permitted; it means that the subsidy calculation is done once, when filing the tax return after the year is over. The TurboTax bug is in the Health Insurance section in the Form 1095-A entry section, Part III, column C, which is labeled “Monthly Advance Payment of Premium Tax Credit”. If you enter all zeros (or blanks) for the twelve monthly boxes in that column, which would be the case if a taxpayer didn't receive any advance subsidies, TurboTax erroneously does not bother to do the final subsidy calculation. However if you enter any non-zero value at all in any of those boxes (such as $1), the subsidy calculation kicks in immediately and the tax/refund due is recalculated. I used the downloaded TurboTax Premier 2016 MacOS form of TurboTax, so I have no idea whether the bug applies to other versions of TurboTax; I suspect it may, if they share source code among their different application versions.
The impact
It took me several hours to stumble upon the bug, realize it was a bug and not operator error, figure out a workaround, report it to TurboTax, and provide various information that they requested. They have not (yet) informed me of the final resolution; I suspect it is not in their best interest to do so. I’ve fired up TurboTax several times since reporting the bug, and the updates I received have not fixed it, so I suspect it’s still present in the product. There’s a chance that something in my data that triggered the bug, although given its nature I highly doubt it. I think it very likely applies to other TurboTax Premier 2016 MacOS users, and perhaps users of TurboTax on other platforms. The impact on individuals affected by this bug could be significant: the subsidies are greater for lower-income individuals, and someone at the lower end of the income scale could be missing out on thousands of dollars. But the lower one’s income, the more likely it is that one would take the advance subsidy, in which case the bug isn’t triggered. It’s probably a small fraction of TurboTax users who are affected, but in all of those cases this error is in the government’s favor.
A bug in IRS Form 1095-A: only 18 seconds to prepare it?!
The bug has definitely shaken my confidence in TurboTax. To be fair, TurboTax is faced with an impossible tax: turning the massively complex U.S. tax code into error-free computer code. I’ve seen other limitations in TurboTax due to tax code complexity: arcane areas that have not been codified in the product yet where TurboTax basically says “read the tax forms yourself”; and prior-year reconciliations where TurboTax basically says “to get the biggest possible refund you’ll have to recalculate last year’s taxes, or you can just skip this”. I know that TurboTax contains errors; this just happens to be the first time I’ve found one myself. It does cause me to wonder what happens when tax returns are incorrect because of TurboTax errors: I suspect in the vast majority of cases neither the government nor the taxpayer even knows, because of the complexity of the tax code. Maybe no one even cares; maybe it is like umpiring errors over the course of a 162-game baseball season: over a large sample size, roughly half the errors are going to be in your favor and half against you, so why bother trying to get everything perfect?
As this bug illustrates, coupling two complex systems together yields additional complexity and errors because of the linkage between the two. I would love to see one or both systems replaced with a design that is “elegantly simple”, but that would run counter to what I’ve seen over my lifetime: both the U.S. tax code and the health insurance system have grown dramatically in complexity. The real question is whether one or both of these systems will ultimately fail due to complexity.
Update as of March 24, 2018: TurboTax did fix this issue in the next year's release, in TurboTax Deluxe 2017. In that release the Form 1095-A entry screen is fully dynamic, recalculating on the fly as values are entered, and the calculation works even when no values are entered into Column C. TurboTax acknowledged receiving my report of the issue, but then went completely silent, never telling me what the issue status was, whether they confirmed the bug, or when they were going to fix it. So I never got any sort of thanks from Intuit for reporting the issue.😢