Methods systems and articles of manufacture for efficiently calculating a tax return in a tax return preparation application

Abstract

Methods, systems and articles of manufacture for efficiently calculating an electronic tax return, such as within a tax return preparation system. A computerized tax return preparation system accesses taxpayer-specific tax data from a shared data store. The system executes a tax calculation engine configured to perform a plurality of tax calculations based on a tax calculation graph and the taxpayer-specific tax data from the shared data store. The system is configured to perform only the calculations in the tax calculation graph which are changed by new taxpayer-specific tax data received since the preceding tax calculation executed by the tax calculation engine. The system may also determine whether the new taxpayer-specific tax data does, or does not change the calculated tax return and the reason why.

Description

SUMMARY

Embodiments of the present invention are directed to methods, systems and articles of manufacture for efficiently calculating a tax return in a tax return preparation application operable to prepare an electronic tax return.

The embodiments of the present invention may be implemented on and/or within a tax return preparation system comprising a tax preparation software application executing on a computing device. The tax return preparation system may operate on a new construct in which tax rules and the calculations based thereon are established in declarative data-structures, namely, completeness graph(s) and tax calculation graph(s). Use of these data-structures permits the user interface to be loosely connected or even divorced from the tax calculation engine and the data used in the tax calculations. Tax calculations are dynamically calculated based on tax-related data that is input from a user, derived from sourced data, or estimated. A smart tax logic agent running on a set of rules can review current run time data and evaluate missing tax data necessary to prepare and complete a tax return. The tax logic agent proposes suggested questions to be asked to a user to fill in missing blanks. This process can be continued until completeness of all tax topics has occurred. A completed tax return (e.g., a printed tax return or an electronic tax return) can then be prepared and filed with respect to the relevant taxing jurisdictions.

In another aspect of the tax return preparation system, a computer-implemented method of calculating tax liability includes the operations of a computing device establishing a connection to a shared data store configured to store user-specific tax data therein. The computing device executes a tax calculation engine configured to read and write tax calculation data to and from the shared data store, the tax calculation engine using one or more of the calculation graphs specific to particular tax topics. The computing device executes a tax logic agent, the tax logic agent reading from the shared data store and a plurality of decision tables collectively representing a completion graph for computing tax liability or a portion thereof, the tax logic agent outputting one or more suggestions for missing tax data based on an entry in one of the plurality of decision tables. The computing device executes a user interface manager configured to receive the one or more suggestions and present to a user one or more questions based on the one or more suggestions via a user interface, wherein a user response to the one or more questions is input to the shared data store. The user interface manager which receives the suggestion(s) selects one or more suggested questions to be presented to a user. Alternatively, the user interface manager may ignore the suggestion(s) and present a different question or prompt to the user.

In the event that all tax topics are covered, the tax logic agent, instead of outputting one or more suggestions for missing tax data may output a “done” instruction to the user interface manager. The computing device may then prepare a tax return based on the data in the shared data store. The tax return may be a conventional paper-based return or, alternatively, the tax return may be an electronic tax return which can then be e-filed.

The one or more suggestions may be questions, declarative statements, or confirmations that are output by the tax logic agent. The one or more suggestions may include a ranked listing of suggestions. The ranking may be weighted in order of importance, relevancy, confidence level, or the like. Statistical data may be incorporated by the tax logic agent to be used as part of the ranking.

In another aspect of the tax return preparation system, the tax return preparation software running on the computing device imports tax data into the shared data store. The importation of tax data may come from one or more third party data sources. The imported tax data may also come from one or more prior year tax returns. In another aspect of the invention, the shared data store may be input with one or more estimates.

In still another feature, the tax return preparation system comprises a computer-implemented system for calculating tax liability. The system includes a computing device operably coupled to the shared data store which is configured to store user-specific tax data therein. The computing device executes a tax calculation engine. The tax calculation engine accesses taxpayer-specific tax data from the shared data store, and is configured to read and to read and write data to and from the shared data store. The tax calculation engine performs the tax calculations based on one or more tax calculation graphs. The tax calculation graph may be a single overall calculation graph for all of the tax calculations required to calculate a tax return, or it may comprise a plurality of tax topic calculation graphs specific to particular tax topics which may be compiled to form the overall tax calculation graph. The computing device executes a tax logic agent, the tax logic agent reading from the shared data store and a plurality of decision tables collectively representing a completion graph for computing tax liability or a portion thereof, the tax logic agent outputting one or more suggestions for missing tax data based on one of the plurality of decision tables. The computing device executes a user interface manager configured to receive the one or more suggestions and present to a user with one or more questions based on the one or more suggestions via a user interface, wherein a user response to the one or more questions is input to the shared data store.

One embodiment of the present invention is directed to methods for efficiently calculating a tax return while preparing an electronic tax return with the tax return preparation system. The tax return preparation system accesses the taxpayer-specific tax data from the shared data store, as described above. Upon receiving a certain amount of user-specific tax data, the tax return preparation system will typically perform a preliminary (i.e. not final) tax calculation. The system may be configured to perform preliminary tax calculations at various stages of the tax return preparation process, for example, in order to give the user an indication of their final tax liability, tax refund and/or taxes owed. Accordingly, the tax return preparation system executes the tax calculation engine to perform a first tax calculation based on the taxpayer-specific tax data read from the shared data store, which results in a first calculated tax data. As explained above, the tax calculation engine performs a plurality of tax calculations based on the tax calculation graph. The first calculated tax data may include the calculated values for the complete tax calculation graph for which data is available (including estimated tax data as described herein), or any subset of the tax calculation graph. Thus, the first calculated tax data may include the calculated values for an overall tax liability, a tax refund (if any), a tax owed (if any), and/or any intermediate calculations used to determine any of the foregoing.

As described above, the system then receives additional taxpayer-specific tax data (referred to as “new taxpayer-specific tax data”) which was not utilized in the first tax calculation, such as responses received in response to the questions presented to the user by the user interface manager which questions are based on the suggestions output by the tax logic agent. After receiving some amount of new taxpayer-specific tax data, the tax return preparation system executes the tax calculation engine to perform a second tax calculation. For instance, the system can perform the second tax calculation after receiving each response or additional tax-payer specific data, or after receiving complete information for a tax topic, or after a certain elapsed time period during preparation of the tax return, or other suitable point in the process of preparing a tax return.

In the second tax calculation, the tax calculation engine ONLY performs those calculation in the tax calculation graph which are changed by the new taxpayer-specific tax data. In other words, if a calculation in the tax calculation graph is not changed by the new taxpayer-specific tax data, the calculation is not performed, because it does need to be performed since it will have no effect on the tax calculations. For instance, if the new taxpayer-specific tax data is related to a particular tax topic, then the calculations in only that tax topic part of the tax calculation graph may need to be calculated, as well as any other parts of the calculation graph changed by a change in that tax topic part of the tax calculation graph. And if the second calculation of the tax topic part of the tax calculation graph does not result in a change in any value(s) utilized by other parts of the calculation graph, then no other part of the tax calculation graph needs to be calculated during the second tax calculation. The second calculation results in a second calculated tax data, which may include the same types of calculated data a described above for the first calculated tax data.

In this way, the system very efficiently performs the tax calculations because it avoids doing calculations which are not affected by the new taxpayer-specific tax data.

In another aspect of the present invention, the tax return preparation system may determine whether there is a difference between the first tax calculation data and the second tax calculation data, and also identify a reason why there is, or is not a difference between the first and second tax calculation data. The system may also present the reason why there is, or is not, a difference between the first and second tax calculation data to the user. For example, if there is no difference in the tax refund between the first and second tax calculation data, a user may be interested to know the reason why the new taxpayer-specific tax data did not affect the taxpayer's tax refund. Conversely, if there is a difference in the tax refund between first and second tax calculation data, the user may also be interested to know the reason for the difference. As an example, the new taxpayer-specific tax data may have qualified the taxpayer for an additional tax deduction, which the user may find of interest.

In still another aspect, the tax calculation graph may comprise a plurality of calculation paths connecting a plurality of nodes. Each of the nodes represents at least one of a tax data input, a tax concept, a function or a tax calculation. For instance, a node may be the number of dependents of the taxpayer, the qualifying data for a dependent, a decision function for determining eligibility as a dependent, etc. The calculation paths define data dependencies between the nodes, in which case a node has a data dependency on another node if a determination at such node depends on a value of the other node. A node has a direct dependency on another node if it is directly dependent on the other node without any intervening nodes. A node has an indirect dependency on another node if it is dependent on a node which is directly dependent on the other node or an intervening node. Then, to perform the second tax calculation, the tax return preparation system executes the tax calculation engine by only performing those calculations at nodes in the tax calculation graph having a direct or indirect data dependency on a node utilizing the new taxpayer-specific tax data and which value of the node from which it depends is changed from its value obtained by the first tax calculation. Thus, the second tax calculation only performs those calculations which are changed by the new taxpayer-specific tax data.

In yet another aspect, at least one of the nodes is interconnected to another node, or represents, a “gist” function, and the tax return preparation system uses the gist function to determine the reason why there is, or is not, a difference between the first and second tax calculation data. A “gist” function is a well-defined function to capture domain specific patterns and semantic abstractions used in tax calculations. Gists can be de-coupled from a specific narrow definition and instead be associated with one or more explanation. Examples of common “gists” found in tax legislation/rules include the concepts of “caps” or “exceptions” that are found in various portions of the tax code.

Another embodiment of the present invention is directed to a system for efficiently calculating a tax return using one or more of the described methods. The system includes or comprises a tax return preparation system comprising a computing device (i.e. a computer) having a computer processor, and a tax return preparation software application executable on the computing device. The computing device is operably coupled to a shared data store configured to store user-specific tax data for one or more taxpayers. The tax return preparation software application includes a tax calculation engine configured to read user-specific tax data from a shared data store and write calculated tax data to the shared data store. The tax calculation engine is configured to perform a plurality of tax calculations based on a tax calculation graph. The system may also include servers, data storage devices, and one or more displays. The tax return preparation system is configured and programmed to perform a process according to any of the method embodiments of the present invention. For instance, the system may be configured for: accessing taxpayer-specific tax data from the shared data store; executing the tax calculation engine to perform a first tax calculation based on taxpayer-specific tax data read from the shared data store and determining a first calculated tax data; receiving new taxpayer-specific tax data, the new taxpayer-specific tax data not utilized in the first tax calculation; and executing the tax calculation engine to perform a second tax calculation, the tax calculation engine only performing those calculations in the tax calculation graph affected by the new taxpayer-specific tax data and determining a second calculated tax data.

In addition, the tax return preparation system may be implemented on a computing system operated by the user or an online application operating on a web server and accessible using a computing device via a communications network such as the internet.

In additional aspects, the tax return preparation system may be further configured according to the additional aspects described above for the method of calculating an electronic tax return.

Another embodiment of the present invention is directed to an article of manufacture comprising a non-transitory computer readable medium embodying instructions executable by a computer to execute a process according to any of the method embodiments of the present invention for calculating an electronic tax return. For instance, the non-transitory computer readable medium embodying instructions executable by a computer may be configured to execute a process comprising: accessing taxpayer-specific tax data from the shared data store; executing the tax calculation engine to perform a first tax calculation based on taxpayer-specific tax data read from the shared data store and determining a first calculated tax data; receiving new taxpayer-specific tax data, the new taxpayer-specific tax data not utilized in the first tax calculation; and executing the tax calculation engine to perform a second tax calculation, the tax calculation engine only performing those calculations in the tax calculation graph affected by the new taxpayer-specific tax data and determining a second calculated tax data.

It is understood that the steps of the methods and processes of the present invention are not required to be performed in the order as shown in the figures or as described, but can be performed in any order that accomplishes the intended purpose of the methods and processes.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 schematically illustrates how tax legislation/tax rules is parsed and represented by a completeness graph and a tax calculation graph.

FIG. 2 illustrates an example of a simplified version of a completeness graph related to a qualifying child for purposes of determining deductions for federal income tax purposes.

FIG. 3 illustrates another illustration of a completeness graph.

FIG. 4 illustrates a decision table based on or derived from the completeness graph of FIG. 3.

FIG. 5 illustrates another embodiment of a decision table that incorporates statistical data.

FIG. 6 illustrates an example of a calculation graph according to one embodiment.

FIG. 7 schematically illustrates a system for calculating taxes using rules and calculations based on declarative data structures.

FIG. 8 schematically illustrates another system for calculating taxes using rules and calculations based on a declarative data structures.

FIG. 9 illustrates components of a computing device that may be utilized to execute software method of tagging tax-related events.

FIG. 10 illustrates a computing device with an illustrative user interface presentation that incorporates the attribute rules to arrive a confidence level for tax calculations.

FIG. 11 illustrates a computing device with another illustrative user interface presentation that incorporates the attribute rules to arrive a confidence level for tax calculations.

FIG. 12 illustrates a flowchart of operations used in connection with a method of calculating tax liability according to one embodiment.

FIG. 13 illustrates the implementation of tax preparation software on various computing devices.

FIG. 14 schematically illustrates a process whereby a combination of user inputs, sourced data, and estimates are used in connection with a tax calculation.

FIG. 15 illustrates generally the components of a computing device that may be utilized to execute the software for automatically calculating or determining tax liability and preparing a tax return based thereon.

FIG. 16 illustrates a flowchart of operations used in connection with a method of calculating an electronic tax return according to one embodiment.

DETAILED DESCRIPTION OF ILLUSTRATED EMBODIMENTS

Embodiments of the present invention are directed to methods, systems and articles of manufacture for efficiently calculating an electronic tax return, such as within a tax return preparation system. In general, a computerized tax return preparation system accesses taxpayer-specific tax data from a shared data store configured to store therein taxpayer-specific tax data for a taxpayer. The system then executes a tax calculation engine configured to read the taxpayer-specific tax data and write calculated tax data to the shared data store, and also configured to perform a plurality of tax calculations based on a tax calculation graph. As explained below in more detail, the tax calculation graph semantically represents the tax legislation/tax rules for the tax return and the data structures that capture the conditions necessary to complete the computations that are required to calculate an electronic tax return. The complete tax calculation graph may have hundreds or even thousands of calculations depending on the complexity of the tax code for the tax return and the tax situation of the taxpayer. In addition, the tax preparation applications typically perform the tax calculations periodically, such as when new taxpayer-specific tax data has been received, or after receiving complete information for a tax topic, or after a certain time period has elapsed during preparation of the tax return, or other suitable point in the process of preparing a tax return. Accordingly, in order to efficiently perform the tax calculations, which also efficiently utilizes the computing power of the system, the system is configured to perform only the calculations which are changed by the new taxpayer-specific tax data received since the previous tax calculation executed by the tax calculation engine. Thus, if a calculation in the tax calculation graph is not changed by the new taxpayer-specific tax data received since the previous tax calculation. The system may also determine whether the new taxpayer-specific tax data does, or does not change the calculated tax return and the reason why. This information may be of interest to a user for various reasons, such as tax planning, error checking and/or other reasons.

Tax preparation is a time-consuming and laborious process. It is estimated that individuals and businesses spend around 6.1 billion hours per year complying with the filing requirements of the Internal Revenue Code. Tax return preparation software has been commercially available to assist taxpayers in preparing their tax returns. Tax return preparation software is typically run on a computing device such as a computer, laptop, tablet, or mobile computing device such as a Smartphone. Traditionally, a user has walked through a set of rigidly defined user interface interview screens that selectively ask questions that are relevant to a particular tax topic or data field needed to calculate a taxpayer's tax liability.

In contrast to the rigidly defined user interface screens used in prior iterations of tax preparation software, the current invention provides tax preparation software 100 that may run on computing devices 102 that operate on a new construct in which tax rules and the calculations based thereon are established in declarative data-structures, namely, completeness graph(s) and tax calculation graph(s). Use of these data-structures permits the user interface to be loosely connected or even divorced from the tax calculation engine and the data used in the tax calculations. Tax calculations are dynamically calculated based on tax data derived from sourced data, estimates, or user input. A smart tax logic agent running on a set of rules can review current run time data and evaluate missing data fields and propose suggested questions to be asked to a user to fill in missing blanks. This process can be continued until completeness of all tax topics has occurred. An electronic return can then be prepared and filed with respect to the relevant taxing jurisdictions.

FIG. 1 illustrates graphically how tax legislation/tax rules 10 are broken down into a completeness graph 12 and a tax calculation graph 14. In one aspect of the invention, tax legislation or rules 10 are parsed or broken into various topics. For example, there may be nearly one hundred topics that need to be covered for completing a federal tax return. When one considers both federal and state tax returns, there can be well over one hundred tax topics that need to be covered. When tax legislation or tax rules 10 are broken into various topics or sub-topics, in one embodiment of the invention, each particular topic (e.g., topics A, B) may each have their own dedicated completeness graph 12A, 12B and tax calculation graph 14A, 14B as seen in FIG. 1.

Note that in FIG. 1, the completeness graph 12 and the tax calculation graph 14 are interdependent as illustrated by dashed line 16. That is to say, some elements contained within the completeness graph 12 are needed to perform actual tax calculations using the tax calculation graph 14. Likewise, aspects within the tax calculation graph 14 may be needed as part of the completion graph 12. Taken collectively, the completeness graph 12 and the tax calculation graph 14 represent data structures that capture all the conditions necessary to complete the computations that are required to complete a tax return that can be filed. Individual combinations of completeness graphs 12 and tax calculation graphs 14 that relate to one or more topics can be used complete the computations required for some sub-calculation. In the context of a tax setting, for example, a sub-selection of topical completeness graphs 12 and tax calculation graphs 14 can be used for intermediate tax results such as Adjusted Gross Income (AGI) or Taxable Income (TI).

The completeness graph 12 and the tax calculation graph 14 represent data structures that can be constructed in the form of tree. FIG. 2 illustrates a completeness graph 12 in the form of a tree with nodes 20 and arcs 22 representing a basic or general version of a completeness graph 12 for the topic of determining whether a child qualifies as a dependent for federal income tax purposes. A more complete flow chart-based representation of questions related to determining a “qualified child” may be found in U.S. patent application Ser. No. 14/097,057, which is incorporated by reference herein. Each node 20 contains a condition that in this example is expressed as a Boolean expression that can be answered in the affirmative or negative. The arcs 22 that connect each node 20 illustrate the dependencies between nodes 20. The combination of arcs 22 in the completeness graph 12 illustrates the various pathways to completion. A single arc 22 or combination of arcs 22 that result in a determination of “Done” represent a pathway to completion. As seen in FIG. 2, there are several pathways to completion. For example, one pathway to completion is where an affirmative (True) answer is given to the question of whether you or a spouse can be claimed on someone else's tax return. If such a condition is true, your child is not a qualifying dependent because under IRS rules you cannot claim any dependents if someone else can claim you as a dependent. In another example, if you had a child and that child did not live with you for more than 6 months of the year, then your child is not a qualifying dependent. Again, this is a separate IRS requirement for a qualified dependent.

As one can imagine given the complexities and nuances of the tax code, many tax topics may contain completeness graphs 12 that have many nodes with a large number of pathways to completion. However, by many branches or lines within the completeness graph 12 can be ignored, for example, when certain questions internal to the completeness graph 12 are answered that eliminate other nodes 20 and arcs 22 within the completeness graph 12. The dependent logic expressed by the completeness graph 12 allows one to minimize subsequent questions based on answers given to prior questions. This allows a minimum question set that can be generated that can be presented to a user as explained herein.

FIG. 3 illustrates another example of a completeness graph 12 that includes a beginning node 20a (Node A), intermediate nodes 20b-g (Nodes B-G) and a termination node 20y (Node “Yes” or “Done”). Each of the beginning node 20a and intermediate nodes 20a-g represents a question. Inter-node connections or arcs 22 represent response options. In the illustrated embodiment, each inter-node connection 22 represents an answer or response option in binary form (Y/N), for instance, a response to a Boolean expression. It will be understood, however, that embodiments are not so limited, and that a binary response form is provided as a non-limiting example. In the illustrated example, certain nodes, such as nodes A, B and E, have two response options 22, whereas other nodes, such as nodes D, G and F, have one response option 22.

As explained herein, the directed graph or completion graph 12 that is illustrated in FIG. 3 can be traversed through all possible paths from the start node 20a to the termination node 20y. By navigating various paths through the completion graph 12 in a recursive manner can determine each path from the beginning node 20a to the termination node 20y. The completion graph 12 along with the pathways to completion through the graph can be converted into a different data structure or format. In the illustrated embodiment shown in FIG. 4, this different data structure or format is in the form of a decision table 30. In the illustrated example, the decision table 30 includes rows 32 (five rows 32a-e are illustrated) based on the paths through the completion graph 12. In the illustrated embodiment, the columns 34a-g of the completion graph represent expressions for each of the questions (represented as nodes A-G in FIG. 3) and answers derived from completion paths through the completion graph 12 and column 34h indicates a conclusion, determination, result or goal 34h concerning a tax topic or situation, e.g., “Yes—your child is a qualifying child” or “No—your child is not a qualifying child.”

Referring to FIG. 4, each row 32 of the decision table 30 represents a tax rule. The decision table 30, for example, may be associated with a federal tax rule or a state tax rule. In some instances, for example, a state tax rule may include the same decision table 30 as the federal tax rule. The decision table 30 can be used, as explained herein, to drive a personalized interview process for the user of tax preparation software 100. In particular, the decision table 30 is used to select a question or questions to present to a user during an interview process. In this particular example, in the context of the completion graph from FIG. 3 converted into the decision table 30 of FIG. 4, if the first question presented to the user during an interview process is question “A” and the user answers “Yes” rows 32c-e may be eliminated from consideration given that no pathway to completion is possible. The tax rule associated with these columns cannot be satisfied given the input of “Yes” in question “A.” Note that those cell entries denoted by “?” represent those answers to a particular question in a node that is irrelevant to the particular pathway to completion. Thus, for example, referring to row 34a, when an answer to Q_A is “Y” and a path is completed through the completion graph 12 by answering Question C as “N” then answers to the other questions in Nodes B and D-F are “?” since they are not needed to be answered given that particular path.

After an initial question has been presented and rows are eliminated as a result of the selection, next, a collection of candidate questions from the remaining available rows 32a and 32b is determined. From this universe of candidate questions from the remaining rows, a candidate question is selected. In this case, the candidate questions are questions Q_C and Q_G in columns 34c, 34g, respectively. One of these questions is selected and the process repeats until either the goal 34h is reached or there is an empty candidate list.

FIG. 5 illustrates another embodiment of a decision table 30. In this embodiment, the decision table 30 includes additional statistical data 36 associated with each rule (e.g., rules R₁-R₆). For example, the statistical data 36 may represent a percentage or the like in which a particular demographic or category of user(s) satisfies this particular path to completion. The statistical data 36 may be mined from existing or current year tax filings. The statistical data 36 may be obtained from a proprietary source of data such as tax filing data owned by Intuit, Inc. The statistical data 36 may be third party data that can be purchased or leased for use. For example, the statistical data 36 may be obtained from a government taxing authority or the like (e.g., IRS). In one aspect, the statistical data 36 does not necessarily relate specifically to the individual or individuals preparing the particular tax return. For example, the statistical data 36 may be obtained based on a number of tax filers which is then classified one or more classifications. For example, statistical data 36 can be organized with respect to age, type of tax filing (e.g., joint, separate, married filing separately), income range (gross, AGI, or TI), deduction type, geographic location, and the like).

FIG. 5 illustrates two such columns 38a, 38b in the decision table 30 that contain statistical data 36 in the form of percentages. For example, column 38a (STAT1) may contain a percentage value that indicates taxpayers under the age of thirty-five where Rule₁ is satisfied. Column 38b (STAT2) may contain a percentage value that indicates taxpayers over the age of thirty-five where Rule₁ is satisfied. Any number of additional columns 38 could be added to the decision table 30 and the statistics do not have to relate to an age threshold or grouping. The statistical data 36 may be used, as explained in more detail below, by the tax preparation software 100 to determine which of the candidate questions (Q_A-Q_G) should be asked to a taxpayer. The statistical data 36 may be compared to one or more known taxpayer data fields (e.g., age, income level, tax filing status, geographic location, or the like) such that the question that is presented to the user is most likely to lead to a path to completion. Candidate questions may also be excluded or grouped together and then presented to the user to efficiently minimize tax interview questions during the data acquisition process. For example, questions that are likely to be answered in the negative can be grouped together and presented to the user in a grouping and asked in the negative—for example, “we think these question do not apply to you, please confirm that this is correct.” This enables the elimination of many pathways to completion that can optimize additional data requests of the taxpayer.

FIG. 6 illustrates an example of a tax calculation graph 14. The tax calculation graph semantically describes the tax legislation/tax rules 10. In FIG. 6, various nodes 24 are leaf or input nodes. Examples of leaf nodes 24 in this particular example include data obtained from W-2 forms, data obtained from 1099-INT forms, data obtained from other investment income, filing status, and number of dependents. Typically, though not exclusively, leaf nodes 24 are populated with user inputs. That is to say the user taxpayer will enter this information from a user interface. In other embodiments, however, the leaf nodes 24 may be populated with information that is automatically obtained by the tax preparation software 100. For example, in some embodiments, tax documents may be imaged or scanned with relevant data being automatically extracted using Object Character Recognition (OCR) techniques. In other embodiments, prior tax returns may be used by the tax preparation software 100 to extract information (e.g., name, potential dependents, address, and social security number) which can then be used to populate the leaf nodes 24. Online resources such as financial services websites or other user-specific websites can be crawled and scanned to scrap or otherwise download tax related information that can be automatically populated into leaf nodes 24. Additional third party information sources such as credit bureaus, government databases, and the like can also be used by the tax preparation software 100 to obtain information that can then be populated in to respective leaf nodes 24. In still other embodiments, values for leaf nodes 24 may be derived or otherwise calculated. For example, while the number of dependents may be manually entered by a taxpayer, those dependents may not all be “qualifying” dependents for tax purposes. In such instances, the actual number of “qualified” dependents may be derived or calculated by the tax preparation software 100. In still other embodiments, values for leaf nodes 24 may be estimated as described herein.

Still other internal nodes 26 semantically represent a tax concept and may be calculated using a function node 28. Some or all of these internal nodes 26 may be labeled as “tax concepts.” Interconnected nodes 26 containing tax concepts may be connected via “gist” functions that can be tagged and later be used or called upon to explain to the user the reasoning behind why a particular result was calculated or determined by the tax preparation software 100 program as explained in more detail below. Gists are well-defined functions to capture domain specific patterns and semantic abstractions used in tax calculations. Gists can be de-coupled from a specific narrow definition and instead be associated with one or more explanation. Examples of common “gists” found in tax legislation/rules include the concepts of “caps” or “exceptions” that are found in various portions of the tax code. The function node 28 may include any number of mathematical or other operations. Examples of functions 28 include summation, subtraction, multiplication, division, and look-ups of tables or values from a database 30 or library as is illustrated in FIG. 6. It should be understood that nodes within completion graph 12 and the tax calculation graph 14 may be shared in some instances. For example, AGI is a re-occurring tax concept that occurs in many places in the tax code. AGI is used not only for the mathematical computation of taxes is also used, for example, to determine eligibility of certain tax deductions and credits. Thus, the AGI node is common to both the completion graph 12 and the tax calculation graph 14.

The calculation graph 14 also has a plurality of calculation paths connecting the nodes 24, 26 and 28, which define data dependencies between the nodes. A second node is considered to be dependent on a first node if a calculation (calculation includes any determination within the calculation graph, such as function, decisions, etc.) at the second node depends on a value of the first node. A second node has a direct dependency on the first node if it is directly dependent on the first node without any intervening nodes. A second node has an indirect dependency on the first node if it is dependent on a node which is directly dependent on the first node or an intervening node along a calculation path to the first node. Although there are many more calculation paths in the calculation graph 14 of FIG. 6, FIG. 6 shows two exemplary calculation paths 27a and 27b, which interconnect nodes having data dependencies. Some or all of the data dependencies may be gists, as described above. The two calculation paths 27a and 27b intersect at the “accumulator” 28a, and are thereafter coincident as calculation path 27c.

FIG. 7 schematically illustrates a tax return preparation system 40 for calculating taxes using rules and calculations based on declarative data structures according to one embodiment. The system 40 include a shared data store 42 that contains therein a schema 44 or canonical model representative to the data fields utilized or otherwise required to complete a tax return. The shared data store 42 may be a repository, file, or database that is used to contain the tax-related data fields. The shared data store 42 is accessible by a computing device 102, 103 as described herein. The shared data store 42 may be located on the computing device 102, 103 running the tax preparation software 100 or it may be located remotely, for example, in cloud environment on another, remotely located computer. The schema 44 may include, for example, a schema based on the Modernized e-File (MeF) system developed by the Internal Revenue Service. The MeF is a web-based system that allows electronic filing of tax returns through the Internet. MeF uses extensible markup language (XML) format that is used when identifying, storing, and transmitting data. For example, each line or data element on a tax return is given an XML name tag as well as every instance of supporting data. Tax preparation software 100 uses XML schemas and business rules to electronically prepare and transmit tax returns to tax reporting agencies. Transmitters use the Internet to transmit electronic tax return data to the IRS MeF system. The IRS validates the transmitted files against the XML schemas and Business Rules in the MeF schema 44.

The schema 44 may be a modified version of the MeF schema used by the IRS. For example, the schema 44 may be an extended or expanded version (designated MeF++) of the MeF model established by government authorities. While the particular MeF schema 44 is discussed herein the invention is not so limited. There may be many different schemas 44 depending on the different tax jurisdiction. For example, Country A may have a tax schema 44 that varies from Country B. Different regions or states within a single country may even have different schemas 44. The systems and methods described herein are not limited to a particular schema 44 implementation. The schema 44 may contain all the data fields required to prepare and file a tax return with a government taxing authority. This may include, for example, all fields required for any tax forms, schedules, and the like. Data may include text, numbers, and a response to a Boolean expression (e.g., True/False or Yes/No). As explained in more detail, the shared data store 42 may, at any one time, have a particular instance 46 of the MeF schema 44 (for MeF++ schema) stored therein at any particular time. For example, FIG. 7 illustrates several instances 46 of the MeF schema 44 (labeled as MeF₁, MeF₂, MeF_N). These instances 46 may be updated as additional data is input into the shared data store 42.

As seen in FIG. 7, the shared data store 42 may import data from one or more data sources 48. A number of data sources 48 may be used to import or otherwise transfer tax related data to the shared data store 42. The tax related data may include personal identification data such as a name, address, or taxpayer ID. Tax data may also relate to, for example, details regarding a taxpayer's employer(s) during a preceding tax year. This may include, employer name, employer federal ID, dates of employment, and the like. Tax related day may include residential history data (e.g., location of residence(s) in tax reporting period (state, county, city, etc.) as well as type of housing (e.g., rental unit or purchased home). Tax related information may also include dependent-related information such as the number of family members in a household including children. Tax related information may pertain to sources of income, including both earned and unearned income as well. Tax related information also include information that pertains to tax deductions or tax credits.

For example, user input 48a is one type of data source 48. User input 48a may take a number of different forms. For example, user input 48a may be generated by a user using, for example, a input device such as keyboard, mouse, touchscreen display, voice input (e.g., voice to text feature) or the like to enter information manually into the tax preparation software 100. For example, as illustrated in FIG. 7, user interface manager 82 contains an import module 89 that may be used to select what data sources 48 are automatically searched for tax related data. Import module 89 may be used as a permission manager that includes, for example, user account numbers and related passwords. The UI control 80 enables what sources 48 of data are searched or otherwise analyzed for tax related data. For example, a user may select prior year tax returns 48b to be searched but not online resources 48c. The tax data may flow through the UI control 80 directly as illustrated in FIG. 7 or, alternatively, the tax data may be routed directly to the shared data store 42. The import module 89 may also present prompts or questions to the user via a user interface presentation 84 generated by the user interface manager 82. For example, a question may ask the user to confirm the accuracy of the data. The user may also be given the option of whether or not to import the data from the data sources 48.

User input 48a may also include some form of automatic data gathering. For example, a user may scan or take a photographic image of a tax document (e.g., W-2 or 1099) that is then processed by the tax preparation software 100 to extract relevant data fields that are then automatically transferred and stored within the data store 42. OCR techniques along with pre-stored templates of tax reporting forms may be called upon to extract relevant data from the scanned or photographic images whereupon the data is then transferred to the shared data store 42.

Another example of a data source 48 is a prior year tax return 48b. A prior year tax return 48b that is stored electronically can be searched and data is copied and transferred to the shared data store 42. The prior year tax return 48b may be in a proprietary format (e.g., .txf, .pdf) or an open source format. The prior year tax return 48b may also be in a paper or hardcopy format that can be scanned or imaged whereby data is extracted and transferred to the shared data store 42. In another embodiment, a prior year tax return 48b may be obtained by accessing a government database (e.g., IRS records).

An additional example of a data source 48 is an online resource 48c. An online resource 48c may include, for example, websites for the taxpayer(s) that contain tax-related information. For example, financial service providers such as banks, credit unions, brokerages, investment advisors typically provide online access for their customers to view holdings, balances, transactions. Financial service providers also typically provide year-end tax documents to their customers such as, for instance, 1099-INT (interest income), 1099-DIV (dividend income), 1099-B (brokerage proceeds), 1098 (mortgage interest) forms. The data contained on these tax forms may be captured and transferred electronically to the shared data store 42.

Of course, there are additional examples of online resources 48c beyond financial service providers. For example, many taxpayers may have social media or similar accounts. These include, by way of illustration and not limitation, Facebook, Linked-In, Twitter, and the like. User's may post or store personal information on these properties that may have tax implications. For example, a user's Linked-In account may indicate that a person changed jobs during a tax year. Likewise, a posting on Facebook about a new home may suggest that a person has purchased a home, moved to a new location, changed jobs; all of which may have possible tax ramifications. This information is then acquired and transferred to the shared data store 42, which can be used to drive or shape the interview process described herein. For instance, using the example above, a person may be asked a question whether or not she changed jobs during the year (e.g., “It looks like you changed jobs during the past year, is this correct?”. Additional follow-up questions can then be presented to the user.

Still referring to FIG. 7, another data source 48 includes sources of third party information 48d that may be accessed and retrieved. For example, credit reporting bureaus contain a rich source of data that may implicate one or more tax items. For example, credit reporting bureaus may show that a taxpayer has taken out a student loan or home mortgage loan that may be the source of possible tax deductions for the taxpayer. Other examples of sources of third party information 48d include government databases. For example, the state department of motor vehicles may contain information relevant to tax portion of vehicle registration fees which can be deductible in some instances. Other government databases that may be accessed include the IRS (e.g., IRS tax return transcripts), and state taxing authorities.

Still referring to FIG. 7, the tax return preparation software 100 executed by the computing device 102, 103 includes a tax calculation engine 50 that computes one or more tax calculations based on the tax calculation graph(s) 14 and the available data at any given instance within the schema 44 in the shared data store 42. The tax calculation engine 50 may calculate a final tax due amount, a final refund amount, or one or more intermediary calculations (e.g., taxable income, AGI, earned income, un-earned income, total deductions, total credits, alternative minimum tax (AMT) and the like). The tax calculation engine 50 utilizes the one or more calculation graphs 14 as described previously in the context of FIGS. 1 and 6. In one embodiment, a series of different calculation graphs 14 are used for respective tax topics. These different calculation graphs 14 may be coupled together or otherwise compiled as a composite calculation graph 14 to obtain an amount of taxes due or a refund amount based on the information contained in the shared data store 42. The tax calculation engine 50 reads the most current or up to date information contained within the shared data store 42 and then performs tax calculations. Updated tax calculation values are then written back to the shared data store 42. As the updated tax calculation values are written back, new instances 46 of the canonical model 46 are created. The tax calculations performed by the tax calculation engine 50 may include the calculation of an overall tax liability or refund due. The tax calculations may also include intermediate calculations used to determine an overall tax liability or refund due (e.g., AGI calculation).

Referring now to FIG. 16, a method 1210 for efficiently performing the tax calculations using the tax calculation engine 50 and the tax calculation graph(s) 14 is shown. At step 1212, the tax return preparation system 40 accesses the taxpayer-specific tax data from the shared data store, as described above. Upon receiving a certain amount of user-specific tax data, at step 1214, the tax return preparation system performs a preliminary (i.e. not final) tax calculation, which may be referred to as a first tax calculation. The system is configured to perform one or more preliminary tax calculations at various stages of the tax return preparation process. For example, a preliminary tax calculation may be performed in order to give the user an estimate or preliminary indication of their final tax liability, tax refund and/or taxes owed. Accordingly, the system executes the tax calculation engine 50 to perform the first tax calculation based on the tax calculation graph(s) 14 and the taxpayer-specific tax data read from the shared data store. As explained above, executing the tax calculation engine 50 based on the tax calculation graph(s) 14 results in calculated tax data, referred to as “first calculated tax data,” which may include the calculated values for the complete tax calculation graph for which data is available (including estimated tax data as described herein), or any subset of the tax calculation graph. Thus, the first calculated tax data may include an overall tax liability, a tax refund (if any), a tax owed (if any), final tax due amount, a final refund amount, or one or more intermediary calculations used to determine any of the foregoing (e.g., taxable income, AGI, earned income, un-earned income, total deductions, total credits, alternative minimum tax (AMT) and the like).

As an example using the sample calculation graph 14 of FIG. 6, let's say the user has input W2 information for the nodes 24 labeled W2, but has not yet input data for 1099 INT for the nodes 24 labeled 1099 INT or Investment Income data for the nodes 24 labeled Inv. Then, the first calculation would perform all of the calculations in the calculation graph 14, or a subset of the calculation graph, for example, at least those calculations needed to obtain a desired amount of calculated tax data (e.g. an overall tax liability, a tax refund (if any), a tax owed (if any), final tax due amount, a final refund amount). Alternatively, the first calculation may only include those calculations for which the shared data store has taxpayer-specific tax data (and estimated tax data as explained below) which includes the calculation paths 27a and 27c, (i.e. the nodes including the f=Accumulator below the nodes 24 labeled W2 (i.e. each of the nodes having a direct or indirect data dependency on the nodes 24 labeled W2). The first calculation may not include any calculations along calculation paths for which there is no taxpayer-specific tax data in the shared data store (and for which there is no estimated tax data, as described below). For instance, in this example, there is no taxpayer-specific tax data in the shared data store for the nodes 24 labeled 1099INT or Inv. and therefore those calculation paths, including calculation path 27b, may not be calculated during the first tax calculation.

At step 1216, the system 40 then receives additional taxpayer-specific tax data (referred to as “new taxpayer-specific tax data”) which was not utilized in the first tax calculation, by any of the processes described herein, such as responses received in response to the questions presented to the user by the user interface manager which questions are based on the suggestions output by the tax logic agent.

After receiving some amount of new taxpayer-specific tax data, at step 1218, the tax return preparation system executes the tax calculation engine to perform a second tax calculation only for these calculations in the tax calculation graph(s) 14 which are changed by the new taxpayer-specific tax data. For instance, the system can perform the second tax calculation after receiving each response or additional tax-payer specific data, or after receiving complete information for a tax topic, or after a certain elapsed time period during preparation of the tax return, or other suitable point in the process of preparing a tax return.

In the second tax calculation, the tax calculation engine ONLY performs those calculations in the tax calculation graph(s) 14 which are changed by the new taxpayer-specific tax data from the calculation performed in the first tax calculation. Thus, this includes only those calculations at nodes along calculation paths 27 which have a direct or indirect data dependency on a node utilizing the new taxpayer-specific tax data and which the value of the node from which it depends is changed from its value obtained by the first tax calculation. Accordingly, if a calculation at a node in the tax calculation graph 40 is not changed by the new taxpayer-specific tax data, the calculation is not performed, because it does need to be performed since it will have no effect on the tax calculations. For instance, if the new taxpayer-specific tax data is related to a particular tax topic, then the calculations in only that tax topic part of the tax calculation graph may need to be calculated, as well as any other parts of the calculation graph changed by a change in that tax topic part of the tax calculation graph. Moreover, if the second calculation of the tax topic part of the tax calculation graph does not result in a change in any value(s) utilized by other parts of the calculation graph, then no other part of the tax calculation graph 14 needs to be calculated during the second tax calculation. The second calculation results in a second calculated tax data, which may include the same types of calculated data as described above for the first calculated tax data.

Describing the second calculation in terms of the calculation paths 27 and nodes 24, 26 and 28, the tax calculation engine 50 only performs those calculation at nodes in the tax calculation graph having a direct or indirect data dependency on a node utilizing the new taxpayer-specific tax data, and which value of the node from which it directly depends is changed from its value obtained by the first tax calculation. Continuing the example using FIG. 6 started above, let's say the new taxpayer-specific tax data includes 1099 INT information for one or more of the nodes 24 labeled 1099 INT. The second tax calculation will then include the calculations at nodes along the calculation path 27b, because the nodes 24 labeled 1099 INT utilize the new taxpayer-specific tax data, and the calculations at nodes along the calculation path 27b below the nodes 24 labeled 1099 INT are directly or indirectly dependent on the nodes 24 labeled 1099 INT. The second tax calculation will NOT include the calculations at nodes along the calculation path 27a because none of the nodes along the calculation path 27a are directly or indirectly dependent on the nodes 24 labeled 1099 INT. In addition, if a value of a node along the calculation path 27b is not changed by the second tax calculation from its value from the first tax calculation, then the calculations along the calculation path stop, because there will be no change in any nodes after that point. Similarly, if the value of the node at the end of the calculation path 27b (the node 26 labeled totalInterest) is not changed from its value from the first tax calculation, then the tax calculation engine 50 does not execute any calculations for calculation paths depending from the node at the end of the calculation path 27b, in this case, calculation path 27c. On the other hand, if the value of the node at the end of the calculation path 27b is changed from its value from the first tax calculation, then the tax calculation engine 50 continues and executes the calculation paths depending from such node, including calculation path 27c beginning with node 28a.

At step 1220 of method 1210, the tax return preparation system 40 determines whether there is a difference between the first tax calculation data and the second tax calculation data. This can also be considered as a determination whether the new taxpayer-specific tax data causes a change in a result of the tax return, such as the total tax liability, tax return or tax owed. For instance, the first tax calculation data and second tax calculation data may include only the final tax result, such as the an overall tax liability, and a tax refund or tax owed. It may be of interest to the user to know whether the new taxpayer-specific tax data changed the final tax result.

At step 1222, the tax return preparation system 40 identifies a reason why there is, or is not a difference between the first and second tax calculation data, as determined at step 1220. This identification is equivalent to identifying a reason why the new taxpayer-specific tax data causes, or does not cause, a change in the tax return. The system 40 may make this determination by any suitable method, such as by identifying and analyzing the node(s) and/or gist(s) at which there is a change or no change in the value between the first tax calculation and the second tax calculation. Each of these node(s) or gist(s) are referred to as “reason node” or “reason gist”, respectively. As explained above, a node may be interconnected to another node by a “gist” function. The tax return preparation system may use the reason node or reason gist to determine the reason why there is, or is not, a difference between the first and second tax calculation data. For instance, in the example started above, assume there is a gist function interconnecting the node labeled totalInterest to the node 28a in which the gist function requires the totalInterest to be more than a minimum value in order to be included in the taxpayer's AGI (adjusted gross income) (note that this example is hypothetical). Thus, if the totalInterest is less the minimum value, then the new taxpayer-specific tax data comprising 1099 INT data will not be included in the AGI, and there will effectively be no change in the second calculated tax data comprising the total tax liability and tax refund or tax owed, as the case may be. In this case, the system 40 will identify that the reason there was no change in the second calculated data is because the 1009 INT is less than the minimum taxable 1099 INT amount. Conversely, if the totalInterest from the new 1099 INT data exceeds the minimum value, then there will most likely be a change in the second calculated tax data for the total tax liability and the tax refund or tax owed, because the AGI will increase. In this case, the system 40 will identify that the reason for the change in the second calculated tax data is because the 1099 INT exceeds the minimum taxable 1099 INT amount.

At step 1224, the tax return preparation system 40 presents the reason why there is, or is not, a difference between the first and second tax calculation data to the user. Referring again to the example started above, if the new 1099 INT data changes the overall tax liability, this information may be utilized for tax planning purposes, such as the taxpayer investing less in investments producing 1099 INT income and investing in more tax efficient investments. Conversely, if the new 1099 INT data did not change the overall tax liability, the taxpayer may want to invest more in investments earning 1099 INT income, such that the 1099 INT income is expected be at or near the minimum taxable amount.

Referring back to FIG. 7, the system 40 includes a tax logic agent (TLA) 60. The TLA 60 operates in conjunction with the shared data store 42 whereby updated tax data represented by instances 46 are read to the TLA 60. The TLA 60 contains run time data 62 that is read from the shared data store 42. The run time data 62 represents the instantiated representation of the canonical tax schema 44 at runtime. The TLA 60 may contain therein a rule engine 64 that utilizes a fact cache to generate either non-binding suggestions 66 for additional question(s) to present to a user or “Done” instructions 68 which indicate that completeness has occurred and additional input is not needed. The rule engine 64 may operate in the form a Drools expert engine. Other declarative rules engines 64 may be utilized and a Drools expert rule engine 64 is provided as one example of how embodiments may be implemented. The TLA 60 may be implemented as a dedicated module contained within the tax preparation software 100.

As seen in FIG. 7, The TLA 60 uses the decision tables 30 to analyze the run time data 62 and determine whether a tax return is complete. Each decision table 30 created for each topic or sub-topic is scanned or otherwise analyzed to determine completeness for each particular topic or sub-topic. In the event that completeness has been determined with respect to each decision table 30, then the rule engine 64 outputs a “done” instruction 68 to the UI control 80. If the rule engine 64 does not output a “done” instruction 68 that means there are one or more topics or sub-topics that are not complete, in which case, as explained in more detail below, the UI control 80 presents interview questions to a user for answer. The TLA 60 identifies a decision table 30 corresponding to one of the non-complete topics or sub-topics and, using the rule engine 64, identifies one or more non-binding suggestions 66 to present to the UI control 80. The non-binding suggestions 66 may include a listing or compilation of one or more questions (e.g., Q₁-Q₅ as seen in FIG. 7) from the decision table 30. In some instances, the listing or compilation of questions may be ranked in order by rank. The ranking or listing may be weighted in order of importance, relevancy, confidence level, or the like. For example, a top ranked question may be a question that, based on the remaining rows (e.g., R₁-R₅) in a decision will most likely lead to a path to completion. As part of this ranking process, statistical information such as the STAT1, STAT2 percentages as illustrated in FIG. 5 may be used to augment or aid this ranking process. Questions may also be presented that are most likely to increase the confidence level of the calculated tax liability or refund amount. In this regard, for example, those questions that resolve data fields associated with low confidence values may, in some embodiments, be ranked higher.

The following pseudo code generally expresses how a rule engine 64 functions utilizing a fact cache based on the runtime canonical data 62 or the instantiated representation of the canonical tax schema 46 at runtime and generating non-binding suggestions 66 provided as an input a UI control 80. As described in U.S. application Ser. No. 14/097,057 previously incorporated herein by reference, data such as required inputs can be stored to a fact cache so that the needed inputs can be recalled at a later time, and to determine what is already known about variables, factors or requirements of various rules:

Rule engine (64)/Tax Logic Agent (TLA) (60)

• • // initialization process
  • Load_Tax_Knowledge_Base;
  • Create_Fact_Cache; While (new_data_from_application)
    • Insert_data_into_fact_cache;
    • collection=Execute_Tax_Rules; // collection is all the fired rules and corresponding conditions
    • suggestions=Generate_suggestions (collection);
    • send_to_application(suggestions);

The TLA 60 may also receive or otherwise incorporate information from a statistical/life knowledge module 70. The statistical/life knowledge module 70 contains statistical or probabilistic data related to the taxpayer. For example, statistical/life knowledge module 70 may indicate that taxpayers residing within a particular zip code are more likely to be homeowners than renters. The TLA 60 may use this knowledge to weight particular topics or questions related to these topics. For example, in the example given above, questions about home mortgage interest may be promoted or otherwise given a higher weight. The statistical knowledge may apply in other ways as well. For example, tax forms often require a taxpayer to list his or her profession. These professions may be associated with transactions that may affect tax liability. For instance, a taxpayer may list his or her occupation as “teacher.” The statistic/life knowledge module 70 may contain data that shows that a large percentage of teachers have retirement accounts and in particular 403(b) retirement accounts. This information may then be used by the TLA 60 when generating its suggestions 66. For example, rather than asking generically about retirement accounts, the suggestion 66 can be tailored directly to a question about 403(b) retirement accounts.

The data that is contained within the statistic/life knowledge module 70 may be obtained by analyzing aggregate tax data of a large body of taxpayers. For example, entities having access to tax filings may be able to mine their own proprietary data to establish connections and links between various taxpayer characteristics and tax topics. This information may be contained in a database or other repository that is accessed by the statistic/life knowledge module 70. This information may be periodically refreshed or updated to reflect the most up-to-date relationships. Generally, the data contained in the statistic/life knowledge module 70 is not specific to a particular tax payer but is rather generalized to characteristics shared across a number of tax payers although in other embodiments, the data may be more specific to an individual taxpayer.

Still referring to FIG. 7, the UI controller 80 encompasses a user interface manager 82 and a user interface presentation or user interface 84. The user interface presentation 84 is controlled by the interface manager 82 may manifest itself, typically, on a visual screen or display 104 that is presented on a computing device 102 (seen, for example, in FIG. 13). The computing device 102 may include the display of a computer, laptop, tablet, mobile phone (e.g., Smartphone), or the like. Different user interface presentations 84 may be invoked using a UI generator 85 depending, for example, on the type of display or screen 104 that is utilized by the computing device. For example, an interview screen with many questions or a significant amount of text may be appropriate for a computer, laptop, or tablet screen but such as presentation may be inappropriate for a mobile computing device such as a mobile phone or Smartphone. In this regard, different interface presentations 84 may be prepared for different types of computing devices 102. The nature of the interface presentation 84 may not only be tied to a particular computing device 102 but different users may be given different interface presentations 84. For example, a taxpayer that is over the age of 60 may be presented with an interview screen that has larger text or different visual cues than a younger user.

The user interface manager 82, as explained previously, receives non-binding suggestions from the TLA 60. The non-binding suggestions may include a single question or multiple questions that are suggested to be displayed to the taxpayer via the user interface presentation 84. The user interface manager 82, in one aspect of the invention, contains a suggestion resolution element 88, which is responsible for resolving how to respond to the incoming non-binding suggestions 66. For this purpose, the suggestion resolution element 88 may be programmed or configured internally. Alternatively, the suggestion resolution element 88 may access external interaction configuration files. Additional details regarding configuration files and their use may be found in U.S. patent application Ser. No. 14/206,834, which is incorporated by reference herein.

Configuration files specify whether, when and/or how non-binding suggestions are processed. For example, a configuration file may specify a particular priority or sequence of processing non-binding suggestions 66 such as now or immediate, in the current user interface presentation 84 (e.g., interview screen), in the next user interface presentation 84, in a subsequent user interface presentation 84, in a random sequence (e.g., as determined by a random number or sequence generator). As another example, this may involve classifying non-binding suggestions as being ignored. A configuration file may also specify content (e.g., text) of the user interface presentation 84 that is to be generated based at least in part upon a non-binding suggestion 66.

A user interface presentation 84 may be pre-programmed interview screens that can be selected and provided to the generator element 85 for providing the resulting user interface presentation 84 or content or sequence of user interface presentations 84 to the user. User interface presentations 84 may also include interview screen templates, which are blank or partially completed interview screens that can be utilized by the generation element 85 to construct a final user interface presentation 84 on the fly during runtime.

As seen in FIG. 7, the UI controller 80 interfaces with the shared data store 42 such that data that is entered by a user in response to the user interface presentation 84 can then be transferred or copied to the shared data store 42. The new or updated data is then reflected in the updated instantiated representation of the schema 44. Typically, although not exclusively, in response to a user interface presentation 84 that is generated (e.g., interview screen), a user inputs data to the tax preparation software 100 using an input device that is associated with the computing device. For example, a taxpayer may use a mouse, finger tap, keyboard, stylus, voice entry, or the like to respond to questions. The taxpayer may also be asked not only to respond to questions but also to include dollar amounts, check or un-check boxes, select one or more options from a pull down menu, select radio buttons, or the like. Free form text entry may also be requested of the taxpayer. For example, with regard to donated goods, the taxpayer may be prompted to explain what the donated goods are and describe the same in sufficient detail to satisfy requirements set by a particular taxing authority.

Still referring to FIG. 7, the TLA 60 is operatively coupled to a services engine 90 that is configured to perform a number of tasks or services for the taxpayer. For example, the services engine 90 can include a printing option 92. The printing option 92 may be used to print a copy of a tax return, tax return data, summaries of tax data, reports, tax forms and schedules, and the like. The services engine 90 may also electronically file 94 or e-file a tax return with a tax authority (e.g., federal or state tax authority). Whether a paper or electronic return is filed, data from the shared data store 42 required for particular tax forms, schedules, and the like is transferred over into the desired format. With respect to e-filed tax returns, the tax return may be filed using the MeF web-based system that allows electronic filing of tax returns through the Internet. Of course, other e-filing systems may also be used other than those that rely on the MeF standard. The services engine 90 may also make one or more recommendations 96 based on the run-time data 62 contained in the TLA 60. For instance, the services engine 90 may identify that a taxpayer has incurred penalties for underpayment of estimates taxes and may recommend to the taxpayer to increase his or her withholdings or estimated tax payments for the following tax year. As another example, the services engine 90 may find that a person did not contribute to a retirement plan and may recommend 96 that a taxpayer open an Individual Retirement Account (IRA) or look into contributions in an employer-sponsored retirement plan. The services engine 90 may also include a calculator 98 that can be used to calculate various intermediate calculations used as part of the overall tax calculation algorithm. For example, the calculator 98 can isolate earned income, investment income, deductions, credits, and the like. The calculator 98 can also be used to estimate tax liability based on certain changed assumptions (e.g., how would my taxes change if I was married and filed a joint return?). The calculator 98 may also be used to compare analyze differences between tax years.

FIG. 8 illustrates another schematic illustration of a system 40′ for calculating taxes using rules and calculations based on declarative data structures. Those elements equivalent to the embodiment of FIG. 7 are labeled with the same element numbers. In this alternative embodiment, the system 40′ includes an estimation module 110 that writes to the shared data store 42 with estimates 112 or guesses of one or more data fields contained within the shared data store 42. The estimates 112 or guesses may pertain to any number of tax topics and may include alphanumeric characters, a response to a Boolean operation, text, and the like. In this particular embodiment, the estimate module 110 assigns an estimated value to one or more data fields of the schema 44 contained in the shared data store 42. The estimated value may be obtained in a number of ways. In one aspect, user input 114 is used to generate the estimated value. For example, the user may be prompted by UI control 80 with a prompt 84 to enter a guess or estimate on a particular data field. In another aspect, a prior tax return or multiple tax returns 116 can be used to generate an estimated value. For example, taxpayer A may have a history of the past three years of tax return data (e.g., stored as proprietary or standardized files) stored or otherwise made available to tax preparation software 100 that shows yearly dividend income of $1,200, $1,350, and $1,400. The estimation module 110 may generate an average of $1,317 to be used as an estimate for a current year return. Alternatively, the estimation module 110 may employ more robust analytics than merely computing an average or mean value. In the context of this example, the estimation module 100 seeing that dividends appear to be increasing in value each year may attempt to find a function (e.g., linear or non-linear function) that fits the observable data and can be used to better estimate current year tax data. For example, in the above example, a curve fitting function may estimate current year dividend at $1,525 rather than the average value of $1,317.

Online resources 118 may also be used by the estimation module 110 to provide estimated values. Online resources 118 include, for example, financial services accounts for a taxpayer that can be accessed to estimate certain values. For example, a taxpayer may have one or more accounts at a bank, credit union, or stock brokerage. These online resources 118 can be accessed by the tax preparation software 100 to scrape, copy, or otherwise obtain tax relevant data. For example, online resources 118 may be accessed to estimate the value of interest income earned. A user's linked accounts may be accessed to find all of the interest income transactions that have occurred in the past year. This information may be used as the basis to estimate total interest income for the taxpayer. In another example, online resources 118 may be accessed to estimate the amount of mortgage interest that has been paid by a taxpayer. Instead of waiting for a Form 1098 from the mortgage service provider.

Still referring to FIG. 8, third party information 120 may be used by the estimation module 110 to arrive at an estimated value for one or more data fields. Third party information 120 may include credit bureaus, government databases, and the like. For example, credit bureaus may include information on student loans taken out by a taxpayer. This information may be used by the estimation module 110 to determine the amount of interest paid on such loans which may be qualified student loan interest.

It should also be understood that the estimation module 110 may rely on one or more inputs to arrive at an estimated value. For example, the estimation module 110 may rely on a combination of prior tax return data 116 in addition to online resources 118 to estimate a value. This may result in more accurate estimations by relying on multiple, independent sources of information. The UI control 80 may be used in conjunction with the estimation module 110 to select those sources of data to be used by the estimation module 110. For example, user input 114 will require input by the user of data using a user interface presentation 84. The UI control 80 may also be used to identify and select prior tax returns 116. Likewise, user names and passwords may be needed for online resources 118 and third party information 120 in which case UI control 80 will be needed to obtain this information from the user.

In one embodiment of the invention, the estimated values or other estimated data provided by the estimation module 110 may be associated with one or more attributes 122 as illustrated in FIG. 9. The attributes 122 may indicate a label such as a source 124 or provenance of the estimated value (e.g., user input 114, prior tax return 116, etc.). In the example of FIG. 9, a source ID 124 indicates the particular source of the data that is used for the field. For example, source ID 01 may correspond to user input 114. Source ID 03 may correspond to a prior year tax return 116. Source ID 05 may correspond to online resources 118 while source ID 06 corresponds to third party information 120.

The attributes 122 may also include a confidence level 126 associated with each estimated field. The confidence level 126 is indicative of the level of trustworthiness of the estimated user-specific tax data and may be expressed in a number of different ways. For example, confidence level 126 may be broken down to intervals (e.g., low, medium, high) with each estimated value given an associated label (e.g., L—low, M—medium, H, high). Alternatively, confidence levels 126 may be described along a continuum without specific ranges (e.g., range from 0.0 to 1.0 with 0.0 being no confidence and 1.0 with 100% confidence). The confidence level 126 may be assigned based on the source of the estimated user-specific tax data (e.g., source #1 is nearly always correct so estimated data obtained from this source will be automatically assigned a high confidence level).

In some embodiments, the estimation module 110 may acquire a plurality of estimates from different sources (e.g., user input 1145, prior year tax returns 116, online resources 118, third party information 120) and only write the “best” estimate to the shared data store 42 (e.g., the source with the highest confidence level 126). Alternatively, the estimation module 110 may be configured to ignore data (e.g., sources) that have confidence levels 126 below a pre-determined threshold. For example, all “low” level data from a source may be ignored. Alternatively, all the data may be stored in the shared data store 42 including, for example, the attribute 122 of the confidence level 126 with each entry. The tax calculation engine 50 may ignore data entries having a confidence level below a pre-determined threshold. The estimation module 110 may generate a number of different estimates from a variety of different sources and then writes a composite estimate based on all the information from all the different sources. For example, sources having higher confidence levels 126 may be weighted more than other sources having lower confidence levels 126.

Still referring to FIG. 9, another attribute 122 may include a confirmation flag 128 that indicates that a taxpayer or user of the tax preparation software 100 has confirmed a particular entry. For example, confirmed entries may be given an automatic “high” confidence value as these are finalized by the taxpayer. Another attribute 122 may include a range of values 130 that expresses a normal or expected range of values for the particular data field. The range of values 130 may be used to identify erroneous estimates or data entry that appear to be incorrect because they fall outside an intended range of expected values. Some estimates, such as responses to Boolean expressions, do not have a range of values 130. In this example, for example, if the number of estimates dependents is more than five (5), the tax logic agent 60 may incorporate into the rules engine 64 attribute range information that can be used to provide non-binding suggestions to the UI control 80 recommending a question to ask the taxpayer about the high number of dependents (prompting user with “are you sure you have 7 dependents”). Statistical data may also be used instead of specific value ranges to identify suspect data. For example, standard deviation may be used instead of a specific range. When a data field exhibits statistical deviation beyond a threshold level, the rules engine 64 may suggest a prompt or suggestion 66 to determine whether the entry is a legitimate or not. Additional details regarding methods and systems that are used to identify suspect electronic tax data may be found in U.S. Pat. No. 8,346,635 which is incorporated by reference herein.

Referring back to FIG. 8, in this embodiment, the tax logic agent 64 includes within or as part of the rules engine 64 attribute rules 130 that are incorporated and used to generate the non-binding suggestion. For example, as explained above, when an estimated value is input or otherwise transferred to the shared data structure 42, this estimated value may fall outside a generally accepted range of values. This may prompt the TLA 60 to suggest a confirmatory question to the UI control 80 to confirm the accuracy of the estimated value that has been obtained. Likewise, various data fields may be associated with a low level of confidence as seen in FIG. 9. Questions relating to tax topics that incorporate these low confidence fields may be promoted or otherwise ranked higher so that accurate values may be obtained from the taxpayer. Conversely, if a particular estimated tax field is associated with a high level of confidence, questions concerning this field may be demoted to a lower importance using the attribute rules 130. For example, multiple fields with a high level of confidence could be presented to the user in a single interview screen to confirm the accuracy of this information without the need to walk through individual questions.

In some embodiments, each estimated value produced by the estimation module 110 will need to be confirmed by the user using the UI control 80. For example, the user interface manager 82 may present estimated data fields to the user for confirmation or verification using a user interface presentation 84. In other embodiments, however, the user may override data using the user interface presentation 84. Some estimated data, for example, data having a high confidence level 126 may not need to be confirmed but can be assumed as accurate.

FIG. 10 illustrates an illustrative user interface presentation 84 on a computing device 102 that incorporates the attribute rules 130 to arrive at a confidence level for tax calculations. The user interface presentation 84 appears on a screen 104 of the computing device 102. As seen in FIG. 10, the dollar amount of the calculated federal refund in listed along with the refund amount of the calculated state refund. The user interface presentation 84 includes a confidence level indicator 132. The confidence level indicator 132 indicates the overall or aggregate confidence level in the tax calculation. The tax calculation could include a refund amount as illustrated in FIG. 10 but it may also include a taxes due amount. In the example given in FIG. 10, the confidence level indicator 132 is expressed as a bar 134 in a bar meter type implementation.

The confidence level indicator 132 may take a number of different forms, however. For example, the confidence level indicator 132 may be in the form of a gauge or the like that such as that illustrated in FIG. 11. In the example, of FIG. 11, the confidence level indicator 132 is indicated as being “low.” Of course, the confidence level indicator 132 may also appear as a percentage (e.g., 0% being low confidence, 100% being high confidence) or as a text response (e.g., “low,” “medium,” and “high” or the like). Other graphic indicia may also be used for the confidence level indicator 132. For example, the color of a graphic may change or the size of the graphic may change as a function of level of confidence. Referring to FIG. 11, in this instance, the user interface presentation 84 may also include hyperlinked tax topics 136 that are the primary sources for the low confidence in the resulting tax calculation. For example, the reason that the low confidence is given is that there is low confidence in the amount listed on the taxpayer's W-2 form that has been automatically imported into the shared data store 42. This is indicated by the “LOW” designation that is associated with the “earned income” tax topic. In addition, in this example, there is low confidence in the amount of itemized deductions being claimed by a taxpayer. This is seen with the “LOW” designation next to the “deductions” tax topic. Hyperlinks 136 are provided on the screen so that the user can quickly be taken to and address the key drivers in the uncertainty in the calculated tax liability.

FIG. 12 illustrates the operations of one illustrative method for calculating tax liability according to an embodiment of the invention. In operation 1000, a user initiates the tax preparation software 100 on a computing device 102 as seen, for example, in FIG. 13. The tax preparation software 100 may reside on the actual computing device 102 that the user interfaces with or, alternatively, the tax preparation software 100 may reside on a remote computing device 103 such as a server or the like as illustrated. In such an instances, the computing device 102 that is utilized by the user or tax payer communicates via the remote computing device 103 using an application 105 contained on the computing device 102. The tax preparation software 100 may also be run using conventional Internet browser software. Communication between the computing device 102 and the remote computing device 103 may occur over a wide area network such as the Internet. Communication may also occur over a private communication network (e.g., mobile phone network).

Referring back to FIG. 12, after initiating the tax preparation software 100, the tax preparation software 100, in operation 1100, gathers or imports tax related data from the one or more data sources 48 as illustrated in FIGS. 7 and 8. Note that the gathering of tax related data from the one or more data sources 48 may occur at the time the tax preparation software 100 is run. Alternatively, the gathering of tax related data from the one or more data sources 48 may occur over a period of time. For example, data sources 48 may be periodically queried over time (e.g., during a tax reporting year) whereby updated information is stored in a database (not shown) or the like that is then accessed by the tax preparation software 100. This option may improve the efficiency and speed of tax return preparation as the information is already available.

In one embodiment, the gathering or importation of data sources such as prior tax returns 48b, online resources 48c, and third party information 48d is optional. For example, a taxpayer may want to start the process from scratch without pulling information from other sources. However, in order to streamline and more efficiently complete a tax return other users may desire to obtain tax related information automatically. This would reduce the number of interview or prompt screens that are presented to the user if such information were obtained automatically by the tax preparation software 100. A user may be given the opportunity to select which data sources 48 they want accessed and searched for relevant tax related data that will be imported into the shared data store 42. A user may be asked to submit his or her account and password information for some data sources 48 using the UI control 80. Other data sources 48 such as some third party data sources 48d may be accessed without such information.

Next, as seen in operation 1200, after the schema 44 is populated with the various imported or entered data fields from the data sources 48, the tax calculation engine 50, using the calculation graphs 14, reads data from the shared data store 42, performs tax calculations, and writes back data to the shared data store 42. The schema 44 may also be populated with estimates or educated guesses as explained herein using the estimation module 110 as described in the context of the embodiment of FIG. 8. Operation 1200 may utilize the method 1210, as described above, to efficiently perform the tax calculations using the tax calculation engine 50 and the calculation graph(s) 14.

In operation 1300, the tax logic agent 60 reads the run time data 62 which represents the instantiated representation of the canonical tax schema 44 at runtime. The tax logic agent 60 then utilizes the decision tables 30 to generate and send non-binding suggestions 66 to the UI control 80 as seen in operation 1400. Alternatively, the tax logic agent 60 may determine that completeness has been achieved across the tax topics in which case a done instruction may be delivered to the UI control as seen in operation 1500. If not done, the process continues whereby the user interface manager 82 will then process the suggestion(s) 66 using the suggestion resolution element 88 for resolving of how to respond to the incoming non-binding suggestions 66 as seen in operation 1600. The user interface manager 82 then generates a user interface presentation 84 to the user as seen in operation 1700 whereby the user is presented with one or more prompts. The prompts may include questions, affirmations, confirmations, declaratory statements, and the like. The prompts are displayed on a screen 104 of the computing device 102 whereby the user can then respond to the same by using one or more input devices associated with the computing device 102 (e.g., keyboard, mouse, finger, stylus, voice recognition, etc.).

Still referring to FIG. 12, as seen in operation 1800, the response or responses that are given by the user of the tax preparation software 100 are then written back to the shared data store 42 to thereby update all appropriate fields of the schema 44. The process then continues with operation 1200 and proceeds as explained above until a completeness state has been reached and a done instruction is sent to the UI control 80.

FIG. 14 illustrates a schematic representation of one preferred embodiment of the invention in which user input via the user interface presentation 84 is minimized. As seen in FIG. 14, tax calculations 2000 are performed based on a number of inputs including user inputs 2100 that are input using the user interface presentation 84 that appears on the computing device 102. It should be noted that tax calculations 2000 can be made even though there may be some missing data entry that is not incorporated into the tax calculation 2000. While the tax return may not be in a condition to be filed, the tax liability or a sub-component thereof (e.g., total itemized deductions, or gross income) can be calculated. These user inputs 2100 are combined with data sources 2200 as well as estimates 2300. Data sources 2200 are obtained, for example, as described previously with respect to data sources 48. Estimates 2300 are obtained, as explained previously, using the estimation module 110. In one aspect of the invention, a large portion of data needed for the calculation and preparation of taxes is obtained either by data sources 2200, estimates 2300 or both. The user input 2100 aspect may be minimized by first populating relevant fields using data sources 2200 and/or estimates 2300. The user input 2100 may be used to input missing data that was not otherwise obtained using data sources 2200 or estimates 2300. User input 2100, however, may also be used to verify estimates or verify sourced data. For example, prior to being incorporated into tax calculations (e.g., stored within the shared data store 42), the user may be prompted to accept, reject, or alter the values of sourced data 2200 or estimates 2300. User input 2100 may also be used to resolve conflicts. For example, soured data 2200 and estimates 2300 may conflict with one another and user input 2100 may be required to resolve the conflict. User input 2100 may also be used to accept or reject sourced data 2200 or estimates 2300. For example, a user may know that a particular estimate 2300 is incorrect and plans to input this particular value manually. The user may be given the option to override the importation and utilization of sourced data 2200 and estimates 2300.

FIG. 15 generally illustrates components of a computing device 102, 103 that may be utilized to execute the software for automatically calculating or determining tax liability and preparing an electronic or paper return based thereon. The components of the computing device 102 include a memory 300, program instructions 302, a processor or controller 304 to execute program instructions 302, a network or communications interface 306, e.g., for communications with a network or interconnect 308 between such components. The computing device 102, 103 may include a server, a personal computer, laptop, tablet, mobile phone, or other portable electronic device. The memory 300 may be or include one or more of cache, RAM, ROM, SRAM, DRAM, RDRAM, EEPROM and other types of volatile or non-volatile memory capable of storing data. The processor unit 304 may be or include multiple processors, a single threaded processor, a multi-threaded processor, a multi-core processor, or other type of processor capable of processing data. Depending on the particular system component (e.g., whether the component is a computer or a hand held mobile communications device), the interconnect 308 may include a system bus, LDT, PCI, ISA, or other types of buses, and the communications or network interface may, for example, be an Ethernet interface, a Frame Relay interface, or other interface. The interface 306 may be configured to enable a system component to communicate with other system components across a network which may be a wireless or various other networks. It should be noted that one or more components of the computing device 102, 103 may be located remotely and accessed via a network. Accordingly, the system configuration illustrated in FIG. 15 is provided to generally illustrate how embodiments may be configured and implemented.

Method embodiments may also be embodied in, or readable from, a computer-readable medium or carrier, e.g., one or more of the fixed and/or removable data storage data devices and/or data communications devices connected to a computer. Carriers may be, for example, magnetic storage medium, optical storage medium and magneto-optical storage medium. Examples of carriers include, but are not limited to, a floppy diskette, a memory stick or a flash drive, CD-R, CD-RW, CD-ROM, DVD-R, DVD-RW, or other carrier now known or later developed capable of storing data. The processor 304 performs steps or executes program instructions 302 within memory 300 and/or embodied on the carrier to implement method embodiments.

Embodiments, however, are not so limited and implementation of embodiments may vary depending on the platform utilized. Accordingly, embodiments are intended to exemplify alternatives, modifications, and equivalents that may fall within the scope of the claims.

Claims

1. A method implemented by a server computing device that automatically calculates a tax return with a computerized tax return preparation system during preparation of an electronic tax return for a preparer operating a computer in communication with the server over a network, the server including a memory and a processor, the computerized tax return preparation system comprising a shared data store, a calculation engine, a rule-based logic agent and a user interface controller, the computerized tax return preparation system being stored as computer-executable instructions in the memory of the server, the method comprising: by executing the calculation engine of the computerized tax return preparation system stored in the server, reading first stored taxpayer-specific data stored in the shared data store of the computerized tax preparation system, determining first calculated data based at least in part upon calculations performed using the first stored taxpayer-specific data and a calculation graph, the calculation graph representing a calculation graph data structure and comprising a plurality of nodes, each node representing a tax data input, a tax concept, a function or a tax calculation, where at least one node of the calculation graph is interconnected to another node of the calculation graph by a tax gist function, and a plurality of calculation paths connecting respective nodes, respective calculation paths defining respective data dependencies between respective nodes, a first node having a data dependency on another node based on a determination at the first node depends on a value of the another node, writing the first calculated data to the shared data store resulting in second stored taxpayer-specific data comprising the first calculated data;by executing the rule-based logic agent of the computerized tax preparation system stored in the server, reading, from the shared data store, the second stored taxpayer-specific data, determining at least one question of at least one topic of the electronic tax return that remains unanswered based at least in part upon the second stored taxpayer-specific data and a decision table derived from a completeness graph comprising a plurality of rows defining respective rules and a plurality of columns defining respective topic questions, generating at least one non-binding suggestion including the at least one unanswered question that is presented to a display of the computer operated by the preparer of the electronic tax return providing the at least one non-binding suggestion to the user interface controller of the computerized tax preparation system stored in the server;by executing the user interface controller, presenting, through the display of the computer to the preparer of the electronic tax return, a computer generated interview screen involving the unanswered question of the non-binding suggestion, receiving, through the generated interview screen, a response from the computer to the unanswered question, and writing the response to the shared data store that updates the second stored taxpayer-specific data resulting in third stored taxpayer-specific data, where a portion of the third stored taxpayer-specific data is new taxpayer-specific data that was not previously utilized to determine the first calculated data; andby executing the calculation engine, reading, from the shared data store, at least the new taxpayer-specific data of the third stored taxpayer-specific data, determining the second calculated data by only performing those calculations at nodes in the calculation graph having a direct or indirect data dependency on a node that changed as a result of the new taxpayer-specific data, writing the second calculated data to the shared data store resulting in fourth stored taxpayer-specific data; using the tax gist function to determine a reason why there is, or is not, a difference between the first calculated data and the second calculated data; and presenting, through the display of the computer, the reason why there is, or is not, a difference to the preparer.

2. The method of claim 1, where the first calculated data and the second calculated data are one of an overall tax liability, an overall tax refund, and an overall tax owed.

3. The method of claim 1, where the first calculated data and the second calculated data are one of an overall tax liability, an overall tax refund, and an overall tax owed and data of intermediate calculations that determines the overall tax liability, the overall tax refund, or the overall tax owed.

4. The method of claim 1, where the calculation graph comprises a plurality of topic calculation graphs, each topic calculation graph representing a different tax topic, and where the tax topic calculation graphs are compiled to form the calculation graph.

5. The method of claim 1, further comprising: by executing the rule-based logic agent, generating a plurality of non-binding suggestions, and, by executing the user interface controller, processing one or more configuration files that determines which non-binding suggestion to process.

6. The method of claim 5, where the user interface controller is further executed by the processor to process at least one configuration file that determines whether and when to process the at least one non-binding suggestion provided by the tax logic agent, the at least configuration file specifying a particular priority or sequence of processing the at least one non-binding suggestion, the at least configuration file specifying contents of the user interface presentation that is generated based at least in part upon the at least one non-binding suggestion.

7. The method of claim 1, where the plurality of the nodes comprise: input nodes comprising the taxpayer-specific data, where the input nodes are populated with respective first stored taxpayer-specific data read from the shared data store;function nodes associated with respective functions, where respective input nodes are associated with respective function nodes, and inputs to a function include the taxpayer-specific data of respective associated input nodes; andfunctional nodes associated with respective functions nodes, a functional node comprising an output generated by function associated with a function node.

8. A computing system, the computing system comprising a server including a memory and a processor, the server being in communication with a computer operated by a preparer over a network, the processor being configured to execute a computerized tax return preparation system, the computerized tax return preparation system comprising: a calculation engine executable by the processor;a calculation graph executable by the calculation engine, the calculation graph representing a calculation graph data structure and comprising a plurality of nodes, each node representing a tax data input, a tax concept, a function or a tax calculation, where at least one node of the calculation graph is interconnected to another node of the calculation graph by a tax gist function, and a plurality of calculation paths connecting respective nodes, respective calculation paths defining respective data dependencies between respective nodes, a first node having a data dependency on another node based on a determination at the first node depends on a value of the another node;a shared data store in communication with the calculation engine;a user interface controller executable by the processor and being in communication with the shared data store;a rule-based logic agent executable by the processor and being in communication with the shared data store and the user interface controller;a decision table derived from a completeness graph, the decision table comprising a plurality of rows defining respective rules and a plurality of columns defining respective topic questions, the computerized tax return preparation system being stored as computer-executable instructions in the memory of the server, the instructions being executed by the processor that:by executing the calculation engine being configured or programmed according to the computer-executable instructions that:read first stored taxpayer-specific data stored in the shared data store, determine first calculated data based at least in part upon calculations performed using the first stored taxpayer-specific data and the calculation graph, and write the first calculated data to the shared data store resulting in second stored taxpayer-specific data comprising the first calculated data;by executing the rule-based logic agent being configured or programmed according to computer-executable instructions that:read the second stored taxpayer-specific data from the shared data store, determine at least one question of at least one topic of an electronic tax return that remains unanswered based at least in part upon the second stored taxpayer-specific data and which rules and associated questions of the decision table remain after rule and question elimination based at least in part upon the second stored taxpayer-specific data, generate at least one non-binding suggestion including the at least one unanswered question that is presented to a display of the computer operated by the preparer of the electronic tax return based at least in part on the determining the at least one unanswered question, provide the at least one non-binding suggestion to a user interface controller, by executing the user interface controller being configured or programmed according to computer-executable instructions that:present through the display of a computer generated interview screen involving the determined unanswered question of the at least one non-binding suggestion, receive through the generated interview screen a response from the computer to the determined unanswered question, and write the response to the shared data store that updates the second stored taxpayer-specific data resulting in third stored taxpayer-specific data, where a portion of the third stored taxpayer-specific data is new taxpayer-specific data that was not previously utilized to determine the first calculated data; andby executing the calculation engine being further configured or programmed according to the computer-executable instructions that:read at least the new taxpayer-specific data of the third stored taxpayer-specific data from the shared data store, determining the second calculated data by only performing those calculations at nodes in the calculation graph having a direct or indirect data dependency on a node that changed as a result of the new taxpayer-specific data, writing the second calculated data to the shared data store resulting in fourth stored taxpayer-specific data; using the tax gist function to determine a reason why there is, or is not, a difference between the first calculated data and the second calculated data; and presenting, through the display of the computer, the reason why there is, or is not, a difference to the preparer.

9. The computing system of claim 8, where the plurality of the nodes comprise: input nodes comprising the taxpayer-specific data, where the input nodes are populated with respective first stored taxpayer-specific data read from the shared data store;function nodes associated with respective functions, where respective input nodes are associated with respective function nodes, and inputs to a function include the taxpayer-specific data of respective associated input nodes; andfunctional nodes associated with respective functions nodes, a functional node comprising an output generated by function associated with a function node.

10. The computing system of claim 8, where the instructions are further executed by the processor to cause the server to perform: by executing the rule-based logic agent, generating a plurality of non-binding suggestions including the at least one non-binding suggestion, and by executing the user interface controller, executing at least one configuration file that determines whether and when to process the at least one non-binding suggestion provided by the tax logic agent, the at least configuration file specifying a particular priority or sequence of processing the at least one non-binding suggestion, the at least configuration file specifying contents of the user interface presentation that is generated based at least in part upon the at least one non-binding suggestion.

11. An article of manufacture comprising a non-transitory computer program carrier readable by a server and embodying executable instructions of a computerized tax return preparation system being stored in a memory of the server, the server being in communication with a computer operated by a preparer over a network, the instructions being executed by a processor of the server that performs a process of preparing an electronic tax return, the process comprising: by executing a calculation engine of the computerized tax return preparation system reading first stored taxpayer-specific data stored in a shared data store, determining first calculated data based at least in part upon calculations performed using the first stored taxpayer-specific data and a calculation graph, the calculation graph representing a calculation graph data structure and comprising a plurality of nodes, each node representing a tax data input, a tax concept, a function or a tax calculation, where at least one node of the calculation graph is interconnected to another node of the calculation graph by a tax gist function, and a plurality of calculation paths connecting respective nodes, respective calculation paths defining respective data dependencies between respective nodes, a first node having a data dependency on another node based on a determination at the first node depends on a value of the another node, writing, by the calculation engine, the first calculated data to the shared data store resulting in second stored taxpayer-specific data comprising the first calculated data;by executing a rule-based logic agent of the computerized tax return preparation system reading from the shared data store, the second stored taxpayer-specific data, determining at least one question of at least one topic of the electronic tax return that remains unanswered based at least in part upon the second stored taxpayer-specific data and a decision table derived from a completeness graph comprising a plurality of rows defining respective rules and a plurality of columns defining respective topic questions, generating at least one non-binding suggestion including the at least one unanswered that is presented to a display of the computer operated by the preparer of the electronic tax return, providing, by the rule-based logic agent, the at least one non-binding suggestion to a user interface controller;by executing the user interface controller, presenting through the display of the computer to the preparer of the electronic tax return, a computer generated interview screen involving the unanswered question of the at least one non-binding suggestion, receiving through the generated interview screen, a response to the unanswered question from the computer, and writing the response to the shared data store that updates the second stored taxpayer-specific data resulting in third stored taxpayer-specific data, where a portion of the third stored taxpayer-specific data is new taxpayer-specific data that was not previously utilized to determine the first calculated data; andby executing the calculation engine, reading from the shared data store, at least the new taxpayer-specific data of the third stored taxpayer-specific data, determining the second calculated data by only performing those calculations at nodes in the calculation graph having a direct or indirect data dependency on a node that changed as a result of the new taxpayer-specific data, writing the second calculated data to the shared data store resulting in fourth stored taxpayer-specific data; using the tax gist function to determine a reason why there is, or is not, a difference between the first calculated data and the second calculated data; and presenting, through the display of the computer, the reason why there is, or is not, a difference to the preparer.

12. The article of manufacture of claim 11, where the plurality of the nodes comprise: input nodes comprising the taxpayer-specific data, where the input nodes are populated with respective first stored taxpayer-specific data read from the shared data store;function nodes associated with respective functions, where respective input nodes are associated with respective function nodes, and inputs to a function include the taxpayer-specific data of respective associated input nodes; andfunctional nodes associated with respective functions nodes, a functional node comprising an output generated by function associated with a function node.

13. The article of manufacture of claim 11, where the instructions are further executed by the processor to cause the server to perform: by executing the rule-based logic agent, generating a plurality of non-binding suggestions including the at least one non-binding suggestion, and by executing the user interface controller, executing at least one configuration file that determines whether and when to process the at least one non-binding suggestion provided by the tax logic agent, the at least configuration file specifying a particular priority or sequence of processing the at least one non-binding suggestion, the at least configuration file specifying contents of the user interface presentation that is generated based at least in part upon the at least one non-binding suggestion.