This seems to me to fall into the " wishful thinking" category; they may intend well, but actually providing comprehensive coverage of the tax law that governments are "not ungenerous in imposing", for free, seems rather unlikely.
A system-in-planning to compute tax returns for the US and possibly other countries.
See also at SourceForge at Canadian Taxes in Prolog , as well as canadiantaxes at Google Code , where there is a Subversion repository that I think I'll probably have become authoritative for 2008 and later years... (Entertainingly, my repository, at home, uses Git rather than Subversion.)
It primarily manages the forms that I use, and therefore care about, and is still something of a Work In Progress.
It offers, by virtue of a
in the vital rules, the capability to have the facts about an
arbitrary number of taxpayers in the environment at the same time.
Nothing prevents them from tightly interlinking, as is particularly
typical when dealing with a family situation involving numerous
dependents of different sorts. Spousal income is, for instance, an
important variable, and many tax packages have some way to switch
between spouses when working on the returns. But it is also the case
that students at college may have credits to add in to their parents'
returns; this calculator will be able to cope with that
trivially, in effect calculating all of the
A free program for calculating Tax Form entries and tax-owed or refund-due, such as Federal or State personal income taxes.
You enter data for amounts associated with tax form line numbers into the text file used as input.
The presentation of motivations is an interesting presentation of why the software is designed as it is. It is not "user friendly" in the manner that applications like TurboTax or QuickTax; it is, instead, "friendly" in the Unix Philosophy manner.
A number of people have produced spreadsheets to assist in estimating taxes in one jurisdiction or another. These won't help you " e-File", are not likely usable to help you print " pretty " tax returns, but they can help you manage your tax information.
A spreadsheet (largely compatible with Gnumeric ) for residents of Ontario, Canada for the 2002 tax year.
They're presently working on the XML schema.
Color me skeptical that this will succeed, but the architecture seems reasonably sound so far. Unfortunately, the last activity appears to have been in January 2000.
I have had some " gentle thoughts" of my own. Several projects have started by trying to hack together some of the base forms; I think the process should do a lot more up-front design, perhaps something like the following:
Create some sort of "language" to describe tax forms, calculations, and their interdependencies.
Then build, based on that, a GUI to display forms and accept input;
There needs to be a " data persistence" layer so that entered data will persist;
A back end evaluates the contents of forms, attaching values to other GUIed forms;
A back end generates printed forms, and perhaps files to be submitted to tax authorities.
People tend to start the project by assuming that they can hardcode some GUI code to build a 1040 form; this approach will not scale to the production of the hundreds of forms commonly associated with tax returns.
What should happen is for the tax return to be represented as a sort of "schema," with sets of:
Forms, some of which can be repeated, with properties that include the title, the technical name, and whether or not there are supposed to be a bunch of them or not;
Cells, which are what contain values, which have properties that include descriptive labels, data types, an ID (often a "line number"), the form that they occur on, perhaps a reference to what legislation/regulation they tie to, and an indication of where they get their data, which might be via user input, via pulling a value from another cell, via pulling the sum of a set of cells, or via a calculation requiring calling a specially defined function in some programming language.
NOT AT ALL incidentally, there should be enough "calculation" options built in that it should be exceedingly rare to need to call a "custom-coded" function.
There probably needs to be a way to group cells together to make nice looking sections within forms.
You'd have a "table" of forms, cells, and whatever other abstractions turned out to be necessary.
Adding in a simple form like a "variant on a W4" where you have a dozen fields that get added up, summarized, and added into Net Income should merely require adding in a "form" entry, which is just data, and a list of the cells, with /no custom coding/ being required.
This will make auditing the calculations a whopping lot easier as they won't require looking at a lot of specific code, but if you threw the "database" into PostgreSQL, you might get some good milage for analysis out of some select form, field, calctype, formula from cells queries.
The approach may introduce some complexity up front, but the usual approach that conglomerates program logic, GUI logic, and tax law into a common "jumble" of code, is not going to be maintainable when things move from 5 forms to 50.
Using these sorts of abstractions where there's a hierarchy of "cells", "forms", and such is the only way you'll get 220 forms written and working and audited.
This sort of project is likely to have a few other properties:
The project needs to start, in earnest, a goodly year before the tax year that it intends to first support.
The project would require a combination of programmers and tax lawyers in order that the legalities may be accurately observed.
The software should prefer software components that work well on both Unix and Microsoft Windows platforms, in order that the project can harness resources from both sorts of communities.
The project might combine some use of free software for the underlying infrastructure with not-so-free software expressing the country-specific legalities.
This represents a sort of " proof of concept" that this sort of thing is feasible; this software (which actually runs on just about anything resembling Unix ) demonstrates that it is feasible to build a system involving a "form language" that can generate tax returns.
In addition to the software that comprises the basic "engine" of the program (written in C), for each tax form there is a source file written in a kludgy language that is a combination of ROFF and C. With these form source files, programmers can modify the source files or create new ones, to use the program year after year. The blank forms that tax data is written onto are generated from forms downloaded from the IRS.
|Other Personal Finance Packages for Linux||Up||Proprietary Business Finance Software For Linux|