zakpatterson

Awesome

This is actually a bit of an annoying problem for us! All the 1040 instructions say to round all figures at the end. So it is expected that you would have a few cases of 1.49 + 1.49 = 3 showing as 1 + 1 = 3.

But the freefilefillableforms supported by IRS rounds all input and then does addition based on that. For now we just maintain all cents and do math with the precise numbers, then round at the end when the numbers need to go into the forms. We have some work in the pipeline now to make that user-configurable too.

Partial year residency is an annoying issue. This is not one of the ways we're solving it though!

Can you elaborate about consequences?

You might not know the edge case exists, but out of all the people that have that edge case hopefully there is one that does know about it and can implement the fix.

Also I'd be curious to know what edge cases you're thinking about. Many people just have a W-2 and a few 1099s. If someone has a complex business or some other concern they're probably at least partially aware.

It's hard for me to understand what you mean.

First of all I'm one of the maintainers on the project. Handling people between two tax-brackets doesn't seem like a problem.

A spreadsheet might be simple for you dealing with your own taxes, but you can't email your spreadsheet to tens of thousands of people and have them all improve upon it and share it amongst each other so all of them can benefit. That's the vision here, I don't know if it will succeed, but that's what we're trying to accomplish.

Open source can solve this problem.

Any service you choose might be missing your edge case. But if you can see all the code and figure out where to plug in your edge case, then you can contribute it for all users in the future to enjoy.

We've already seen people show up and implement features we hadn't researched yet. I encourage you to check it out.

I think there are multiple hurdles to getting e-file to work.

The biggest hurdle in my view is that e-file requires an intermediary between the payer and the IRS. One of the benefits of this program is that it runs on the user's computer without a backend.

Ideally the IRS would allow people to e-file without an intermediary. There is www.freefilefillableforms.com, made by intuit, and we may be able to interface with that.

But for now we just haven't figured this part out yet, and we'd probably need community help to get there.

It's admittedly minimalist on purpose, but you can get a 1040 PDF on your phone, that's pretty nice. What would you change?

No data transacts to any server. It's just a static client side site that stores data in your browser's LocalStorage. And it does run on desktop as a standalone application (5 MB!)

Schedule D is implemented, and the long-term capital gains worksheet calculations are done, but 8949 and individual non-reported positions are not implemented yet.

Ideally an open-source project where hundreds of contributors can add small contributions based on their specific knowledge might produce a viable non-commercial option.

Thanks for that feedback, having source material links in the comments is definitely a good idea.

I've added an issue to track that based on your feedback:

https://github.com/ustaxes/UsTaxes/issues/458

And another issue about floating point:

https://github.com/ustaxes/UsTaxes/issues/457

I have doubts about the floating point issue just because all values on the tax forms are calculated using floats and then rounded to the nearest whole dollar. But if there's even a possibility that an intermediate calculation could flip a x.49 to a x.50 and change the rounding, then I agree we should switch to a library.

About the contributor guide, we just tried to write it to be as welcoming as possible to new contributors. With respect to "'ask in discord' for the actual content of the tax calculations", I'm just not sure what you mean. That document isn't really relevant to tax calculations. We will give the document another look though based on your feedback.

Thanks for those points. How would you suggest prioritizing implementation of each item?

It has been nice working with new contributors that have specific knowledge of such issues. The core team is two people, and we're lucky to have new contributors come with specific knowledge in different areas. So, ideally, we could wait for someone with domain expertise to come along. Failing that when have time we pick off the next most important-seeming thing and add it.

Thanks for the write-up. I thought we would be protected because calculations are done using decimal places and then the final return is prepared using rounded integers.

But we have heard this a few times, so I think it would be good to make it explicit somewhere that it's done this way, or switch to bignumber. Do you think if all our calculations are done using decimal places, and then numbers are rounded to integer dollars on the final PDFs, that we'll still have errors?

Created an issue based on your feedback. Thank you! https://github.com/ustaxes/UsTaxes/issues/457