Patent Publication Number: US-11386505-B1

Title: System and method for generating explanations for tax calculations

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 14/530,159 filed Oct. 31, 2014, now U.S. Pat. No. 10,169,826 entitled “System and Method for Generating Explanations for Tax Calculations”, the contents and disclosure of which are incorporated herein in their entirety. 
    
    
     SUMMARY 
     In one embodiment, a computer-implemented method for generating explanations for a tax calculation or tax operation is performed by tax preparation software. The method includes a computing device executing a tax calculation engine located or contained in connection with the tax preparation software, the tax calculation engine operating on a tax calculation graph to perform a tax calculation, the tax calculation graph semantically describing data dependent tax operations comprising functional nodes connected to input nodes by one of a plurality of functions, wherein each tax operation is associated with one or more explanations. The computing device executes an explanation engine in connection with the tax preparation software to generate a narrative explanation from the one or more explanations associated with one of the tax operations and the computing device presents the narrative explanation to the user on a computing device. 
     In another aspect of the invention, a user may be able to drill down to find even more detailed explanations or answers to a tax topic or the reasoning or rationale behind a particular tax computation or process. The computing device executes the explanation engine to generate narrative explanations from one or more predecessor tax operations in response to a user request or automatically as a user advances through the tax preparation software. The predecessor tax operations are found further upstream within the tax calculation graph. 
     In some embodiments, the level of detail visible to a user may be tied to a particular product type (e.g., SKU code or the like). In still another alternative, the level of detail visible to a user may be tied to a particular user type. For example, a more basic user may be shown a bare-bones or summary explanation. A more skilled user may be shown more detailed explanations or may be offered additional level of detail that is otherwise unavailable to other users. In still another embodiment, a user may be able to upgrade or purchase additional explanations. 
     In one aspect of the invention, the tax calculation graph semantically describes data dependent tax operations comprising functional nodes connected to input nodes by one of a plurality of functions. The functions that are used to generate explanations may be found in a common data store and library and are used throughout the tax calculation graphs. Certain functions may be more common than others and shared in various nodes of the tax calculation graph. This sharing of functions aids in programming and creating of tax calculation graphs that are utilized as part of the tax preparation software. 
     The computing device may automatically generate a narrative explanation that is displayed to a user or the narrative may be generated in response to a user request. In one aspect of the invention, the narrative explanation that is presented to the user is a natural language expression that is generated by an explanation engine that is executed as part of the tax preparation software. 
     In another embodiment, a computer-implemented system is provided for generating explanations for a tax calculation or tax operation performed by tax preparation software. The system includes a computing device executing a tax calculation engine in connection with the tax preparation software, the tax calculation engine operating on a tax calculation graph to perform a tax calculation, the tax calculation graph semantically describing data dependent tax operations comprising functional nodes connected to input nodes by one of a plurality of functions, wherein each tax operation is associated with one or more explanations. The system includes a data store operatively coupled to the computing device and containing the one or more explanations. The computing device executes an explanation engine in connection with the tax preparation software to generate a narrative explanation from the one or more explanations associated with one of the tax operations. A display operatively connected to the computing device is provided for displaying the narrative explanation to the user. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  schematically illustrates according to one embodiment how tax legislation and tax rules are 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 according to one embodiment related to a qualifying child for purposes of determining deductions for federal income tax purposes. 
         FIG. 3  illustrates another illustration of a completeness graph according to one embodiment. 
         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. 6A  illustrates an example of a calculation graph according to one embodiment. 
         FIG. 6B  illustrates an example of a calculation graph that relates to the determination and calculation of a shared responsibility penalty under the Affordable Care Act according to one embodiment. 
         FIG. 7  schematically illustrates a system for calculating taxes using rules and calculations based on a declarative data structures according to one embodiment. 
         FIG. 8A  illustrates a display of a computing device illustrating a narrative explanation according to one embodiment. 
         FIG. 8B  illustrates a display of a computing device illustrating a narrative explanation according to another embodiment. 
         FIG. 8C  illustrates a display of a computing device illustrating a narrative explanation according to another embodiment. 
         FIG. 9  illustrates an explanation engine that is part of the system for calculating taxes according to one embodiment. The explanation engine generates narrative explanations that can be displayed or otherwise presented to users to explain one or more tax calculations or operations that are performed by the tax preparation software. 
         FIGS. 10A and 10B  illustrate a display of a computing device along with a narrative explanation that was generated by the explanation engine according to one embodiment. The narrative explanation contains multiple phrases that are linked that can be selected to provide additional detailed explanations. 
         FIGS. 11A and 11B  illustrate a display of a computing device along with a narrative explanation that was generated by the explanation engine according to one embodiment. The narrative explanation contains multiple phrases that are linked that can be selected to provide additional detailed explanations. 
         FIGS. 12A and 12B  illustrate a display of a computing device along with a narrative explanation that was generated by the explanation engine according to one embodiment. The narrative explanation contains multiple phrases that are linked that can be selected to provide additional detailed explanations. 
         FIG. 13  illustrates the implementation of tax preparation software on various computing devices according to one embodiment. 
         FIG. 14  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 according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION OF ILLUSTRATED EMBODIMENTS 
     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 preparation software has been commercially available to assist taxpayers in preparing their tax returns. Tax preparation software is typically run on a computing device such as a computer, laptop, tablet, mobile computing device such as a Smartphone, or remotely on another computer and accessed via a network. 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&#39;s tax liability. 
     In contrast to the rigidly defined user interface screens used in prior iterations of tax preparation software, more recent iterations provide tax preparation software  100  that runs on computing devices  102 ,  103  (as seen in  FIG. 13 ) that operates on a new construct in which tax rules and the calculations based thereon are established in declarative data-structures, namely, one or more completeness graphs  12  and one or more tax calculation graphs  14 . Completeness graphs  12  and tax calculation graphs  14  are data structures in the form of trees having nodes and interconnecting arcs in which arcs are directed from one node to another. Completion graphs  12  identify when all conditions have been satisfied to complete a particular tax topic or, collectively, produce a fileable tax return. The tax calculation graph  14  semantically describes data depending tax operations that perform a tax calculation or operation in accordance with tax code or tax rules. Examples of these data structures may be found in U.S. patent application Ser. Nos. 14/097,057 and 14/448,886, both of which are incorporated by reference as if set forth fully herein. Use of these data-structures permits the user experience 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, user input, or even intermediate tax calculations that are then utilized for additional tax calculations. 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. 
     According to one aspect of the invention, a computer-implemented method is provided that generates explanations for tax calculations or tax operations performed by tax preparation software. The explanations that are generated by the computer may be automatically generated as data is input or otherwise loaded into the tax preparation software. Explanations may also be generated or presented after a request by a user. The explanations are in easy to understand and may be presented in a narrative form. The explanations may be generated with varying levels of complexity depending on the user type, product type, or user credentials. The explanations are generated based on explanations associated with tax operations contained in the tax calculation graphs. 
       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  12 A,  12 B and tax calculation graph  14 A,  14 B 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. The completeness graph  12 , for example, determines when all conditions have been satisfied such that a “fileable” tax return can be prepared with the existing data. The completeness graph  12  is used to determine, for example, that no additional data input is needed to prepare and ultimately print or file a tax return. The completeness graph  12  is used to determine when a particular schema contains sufficient information such a tax return can be prepared and 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), Taxable Income (TI), itemized deductions, tax credits, and the like. 
     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, for example, 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&#39;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 six 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  20   a  (Node A), intermediate nodes  20   b - g  (Nodes B-G) and a termination node  20   y  (Node “Yes” or “Done”). Each of the beginning node  20   a  and intermediate nodes  20   a - 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  20   a  to the termination node  20   y . By navigating various paths through the completion graph  12  in a recursive manner one can determine each path from the beginning node  20   a  to the termination node  20   y . 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  32   a - e  are illustrated) based on the paths through the completion graph  12 . In the illustrated embodiment, the columns  34   a - 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  34   h  indicates a conclusion, determination, result or goal  34   h  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  32   c - 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  34   a , when an answer to QA 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 in 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  32   a  and  32   b  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 QC and QG in columns  34   c ,  34   g , respectively. One of these questions is selected and the process repeats until either the goal  34   h  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 1 -R 6 ). 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  38   a ,  38   b  in the decision table  30  that contain statistical data  36  in the form of percentages. For example, column  38   a  (STAT1) may contain a percentage value that indicates taxpayers under the age of thirty-five where Rule1 is satisfied. Column  38   b  (STAT2) may contain a percentage value that indicates taxpayers over the age of thirty-five where Rule1 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 (QA-QG) 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. Predictive models based on the statistical data  36  may be used to determine candidate questions. 
       FIG. 6A  illustrates one example of a tax calculation graph  14 . The tax calculation graph  14  semantically describes data dependent tax operations that used perform a tax calculation in accordance with the tax code or tax rules  10 . The tax calculation graph  14  in  FIG. 6A  is a simplified view of data dependent tax operations that are used to determine the taxes Due (taxDue) based on various sources of income, deductions, exemptions, and credits. The tax calculation graph  14  is a type of directed graph and, in most situations relevant to tax calculations, is a directed acyclic graph that encodes the data dependencies amongst tax concepts or topics. 
     In  FIG. 6A , 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 (INV), 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 as described herein. 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 scrape 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 dependent 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 referred to as functional nodes  26  semantically represent a tax concept and may be calculated or otherwise determined using a function  28 . The functional node  26  and the associated function  28  define a particular tax operation  29 . For example, as seen in  FIG. 6A , operation  29  refers to total wage income and is the result of the accumulator function  28  summing all W-2 income from leaf nodes  24 . The functional node  26  may include a number in some instances. In other instances, the functional node  26  may include a response to a Boolean expression such as “true” or “false.” The functional nodes  26  may also be constant values in some instances. Some or all of these functional nodes  26  may be labelled as “tax concepts” or “tax topics.” The combination of a functional node  26  and its associated function  28  relate to a specific tax operation as part of the tax topic. 
     Interconnected function nodes  26  containing data dependent tax concepts or topics are associated with a discrete set of functions  28  that are used to capture domain specific patterns and semantic abstractions used in the tax calculation. The discrete set of functions  28  that are associated with any particular function node  26  are commonly reoccurring operations for functions that are used throughout the process of calculating tax liability. For example, examples of such commonly reoccurring functions  28  include copy, capping, thresholding (e.g., above or below a fixed amount), accumulation or adding, look-up operations (e.g., look-up tax tables), percentage of calculation, phase out calculations, comparison calculations, exemptions, exclusions, and the like. 
     In one embodiment, the entire set of functions  28  that is used to compute or calculate a tax liability is stored within a data store  30  which in some instances may be a database. The various functions  28  that are used to semantically describe data connections between function nodes  26  can be called upon by the tax preparation software  100  for performing tax calculations. Utilizing these common functions  28  greatly improves the efficiency of the tax preparation software  100  can be used by programmer to more easily track and follow the complex nature of the ever-evolving tax code. The common functions  28  also enables easier updating of the tax preparation software  100  because as tax laws and regulations change, fewer changes need to be made to the software code as compared to prior hard-wired approaches. 
     Importantly, the tax calculation graph  14  and the associated function nodes  26  and functions  28  can be tagged and later be used or called upon to intelligently 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. The functions  28  can be de-coupled from a specific narrow definition and instead be associated with one or more explanations. Examples of common functions  28  found in tax legislation and tax rules include the concepts of “caps” or “exemptions” that are found in various portions of the tax code. One example of a “cap” is the portion of the U.S. tax code that limits the ability of a joint filer to deduct more than $3,000 of net capital losses in any single tax year. There are many other instances of such caps. An example of an “exemption” is one that relates to early distributions from retirement plants. For most retirement plans, early distributions from qualified retirement plans prior to reaching the age of fifty nine and one-half (59½) require a 10% penalty. This penalty can be avoided, however, if an exemption applies such as the total and permanent disability of the participant. Other exemptions also apply. Such exemptions are found throughout various aspects of the tax code and tax regulations. 
     In some embodiments, the function  28  may also include any number of mathematical or other operations. Examples of functions  28  include summation, subtraction, multiplication, division, and comparisons, greater of, lesser of, at least one of, calling of look-ups of tables or values from a database  30  or library as is illustrated in  FIG. 6A . It should be understood that the function nodes  26  in the tax calculation graph  14  may be shared in some instances. For example, AGI is a reoccurring 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. The AGI function node  26  may be found in multiple locations within the tax calculation graph  14 . Taxable income is another example of such a function node  26 . 
       FIG. 6B  illustrates an example of a tax calculation graph  14  that is used to calculate the amount of penalty under the Affordable Care Act (ACA). Under the ACA, taxpayers are required to have minimum essential health coverage for each month of the year, qualify for an exemption, or make a shared responsibility penalty payment when filing his or her federal tax return.  FIG. 6B  illustrates a flowchart illustration of a process used to calculate a taxpayer&#39;s shared responsibility payment under the ACA (referred to herein as an ACA penalty).  FIG. 6B  illustrates, for example, various leaf nodes  24   a - 24   j  used as part of this calculation to determine the ACA penalty. Leaf nodes  24   a - 24   f  are used to calculate the modified adjusted gross income (ACA MAGI) as well as the applicable ACA poverty level. One can see how the accumulator function  28   a  is used to generate the ACA MAGI in this example by adding foreign income  14   a , AGI  24   b , and tax exempt interest  24   c . Likewise, a look-up function  28   b  can be used to determine the applicable ACA poverty level based on the taxpayer&#39;s zip code  24   d , filing status  24   e , and number of dependents  24   f . The ACA MAGI and the ACA poverty level are then subject to a thresholding function  28   c  to determine whether the ACA poverty level exemption applies. Under the ACA, if a taxpayer cannot afford basic coverage because the minimum amount one must pay for the premiums exceeds a percentage of household income (i.e., 8%), one is exempt from obtaining minimum essential coverage. 
     Still referring to  FIG. 6B , a taxpayer may be exempt from the requirement to obtain minimum essential coverage by obtaining a different statutory exemption. These exemptions include: religious conscience, health care sharing ministry, a member of Indian tribe, short coverage gap (less than 3 consecutive months), hardship, affordability (already mentioned above), incarceration, and not lawfully present. A true/false Boolean function  28   d  may be used to determine whether an Exemption Certificate Number (ECN) has been obtained from the taxpayer certifying that one of the statutory exemptions has been satisfied. Another threshold function  28   e  is applied to determine whether one of the statutory exemptions is satisfied (e.g., affordability or others). If at least one of these statutory conditions is met then the taxpayer is exempt from the ACA shared responsibility payment penalty. 
     As seen in  FIG. 6B , if a taxpayer has obtained minimal essential coverage during the year, there is still the possibility that a penalty may be owed because under the ACA, if there is a gap in coverage for a covered member of the family of more than three (3) months, at least some penalty amount is owed. Function  28   f  (at least one condition true) is used to determine if there was minimum essential coverage during the year for any period. Function  28   g  (gap&gt;3 months) is used to determine the gap in coverage in order to gaps in coverage that exceed the 3 month statutory requirement. The gap in coverage penalty, however, may be pro-rated based on the length of the gap in coverage as indicated in  FIG. 6B . 
     In the event there is a penalty, the ACA requires that the penalty be the greater of a percentage of income, net of specified deductions, or a specified penalty that is applied per individual or family. For example, for the 2015 year, the percentage is 2.0 percent and increases to 2.5 percent in subsequent years.  FIG. 6B  illustrates the use of a subtraction function  28   g  that utilizes the AGI node  24   b  to arrive at a taxable income value. A look-up function  28   h  is used to obtain the applicable tax rate (e.g., 2.0% for 2015) and is used to calculate the income-based ACA penalty. 
     In order to determine the non-income or “fixed” penalty, an accumulator function  28   i  is used to determine the penalty. In this example, the calculation pertains to a family wherein the penalty includes a fixed amount for a child ($162.50 per child in 2015) and a fixed amount per adult ($325.00 per adult). Under the ACA, there is a maximum cap of this fixed penalty. For example, in 2015, the maximum family penalty is $975. As seen in  FIG. 6B , a cap function  28   j  is used to determine the minimum cap. Another function  28   k  that is referred to as “at least minimum cap” is used to determine the greater of the fixed penalty or the income-based penalty. If the income-based penalty is higher than the fixed amount then that value is used, otherwise the fixed penalty amount is used. Still referring to  FIG. 6B , another cap function  28   l  is used to determine whether the penalty has exceeded another cap that is part of the ACA law. Under the ACA, the overall penalty is capped at the national average premium for a bronze level insurance plan. The cap function  28   l  is used to ensure that the calculated penalty (i.e., the income based penalty) does not exceed this amount. After application of the cap function  28   l , the ACA penalty amount is determined. 
     As seen in  FIG. 6B , there are a variety of different functions  28  that are employed as part of the process used to calculate any applicable penalty under the ACA. In some instances, a common function (e.g., cap functions  28   j  and  28   l ) is found in multiple locations within the tax calculation graph  14 . It should be understood that the functions  28  illustrated in  FIG. 6B  are illustrative as other functions may be used beyond those specifically illustrated in the drawings. 
       FIG. 7  schematically illustrates a system  40  for calculating taxes using rules and calculations based on a 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 (e.g.,  FIG. 13 ). 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 of the MeF model established by government authorities that utilizes additional fields. 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  stored therein at any particular time. For example,  FIG. 7  illustrates several instances  46  of the MeF schema  44  (labeled as MeF1, MeF2, MeFN). 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 . This may occur through a user interface control  80  as described herein or, alternatively, data importation may occur directly to the shared data store  42  (not illustrated in  FIG. 7 ). 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&#39;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. Tax related information may also pertain to medical insurance information. For example, under the new ACA many taxpayers may obtain health insurance through a state or federal marketplace. Such a marketplace may have information stored or accessible that is used in connection with preparing a tax return. Tax information related to premiums paid, coverage information, subsidy amounts (if any), and enrolled individuals can be automatically imported into the shared data store  42 . 
     User input  48   a  is also one type of data source  48 . User input  48   a  may take a number of different forms. For example, user input  48   a  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), photograph or image, 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  48   b  to be searched but not online resources  48   c . 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 or prompt may ask the user to confirm the accuracy of the data. For instance, the user may be asked to click a button, graphic, icon, box or the like to confirm the accuracy of the data prior to or after the data being directed to the shared data store  42 . Conversely, the interface manager  82  may assume the accuracy of the data and ask the user to click a button, graphic, icon, box or the like for data that is not accurate. The user may also be given the option of whether or not to import the data from the data sources  48 . 
     User input  48   a  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  48   b . A prior year tax return  48   b  that is stored electronically can be searched and data is copied and transferred to the shared data store  42 . The prior year tax return  48   b  may be in a proprietary format (e.g., .txf, .pdf) or an open source format. The prior year tax return  48   b  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  48   b  may be obtained by accessing a government database (e.g., IRS records). 
     An additional example of a data source  48  is an online resource  48   c . An online resource  48   c  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  48   c  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&#39;s may post or store personal information on these properties that may have tax implications. For example, a user&#39;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  48   d  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  48   d  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. Third party resources  48   d  may also include one of the state-based health insurance exchanges or the federal health insurance exchange (e.g., www.healthcare.gov). 
     Referring briefly to  FIG. 13 , the tax preparation software  100  including the system  40  of  FIG. 7  is executed by the computing device  102 ,  103 . Referring back to  FIG. 7 , the tax preparation software  100  includes a tax calculation engine  50  that performs one or more tax calculations or tax operations based on 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, 6A, and 6B . In one embodiment, a series of different calculation graphs  14  are used for respective tax topics. These different calculation graphs  14  may be glued 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). Tax calculations include, for example, the ACA penalty that is described in  FIG. 6B  as one illustrative example. 
     Still referring 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 or executed in connection with 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, which, as explained in more detail below 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 of compilation of one or more questions (e.g., Q 1 -Q 5  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 1 -R 5 ) 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. Predictive modeling based on statistical data  36  using any suitable data such as previously filed tax returns, demographic information, financial information and the like may be used as part of this ranking process. 
     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 ,  103  (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  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 , is responsible for resolving of 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  102 ,  103 . 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 request of the taxpayer. For example, with regard to donated goods, the taxpayer may be prompted to explain what the donated good are and describe the same in sufficient detail to satisfy requirements set by a particular taxing authority. 
     Still referring to  FIG. 7 , in one aspect, the TLA  60  outputs a current tax result  65  which can be reflected on a display  104  of a computing device  102 ,  103 . For example, the current tax result  65  may illustrate a tax due amount or a refund amount. The current tax results  65  may also illustrate various other intermediate calculations or operations used to calculate tax liability. For example, AGI or TI may be illustrated. Deductions (either itemized or standard) may be listed along with personal exemptions. Penalty or tax credits may also be displayed on the computing device  102 ,  103 . This information may be displayed contemporaneously with other information, such as user input information, or user interview questions or prompts or even narrative explanations  116  as explained herein. 
     The TLA  60  also outputs a tax data that is used to generate the actual tax return (either electronic return or paper return). The return itself can be prepared by the TLA  60  or at the direction of the TLA  60  using, for example, the services engine  60  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. 
     By using calculation graphs  14  to drive tax calculations and tax operations, the year-over-year calculation graphs  14  can be used to readily identify differences and report the same to a user. Differences can be found using commonly used graph isomorphism algorithms over the two respective calculation graphs  14 . 
     Still referring to  FIG. 7 , the system includes an explanation engine  110  that operates in connection with the tax preparation software  100  to generate a narrative explanation from the one or more explanations associated with a particular tax operation  29  (illustrated in  FIGS. 6A and 6B ). To generate the narrative explanation for a particular tax operation  29 , the explanation engine  110  extracts the stored function  28  that is associated with the particular functional node  26 . The stored function  28  is one function of a defined set and may be associated with a brief explanation. For example, a “cap” function may be associated with an explanation of “value exceeds cap.” This brief explanation can be combined with a stored explanation or narrative that is associated with the particular functional node  26  within the calculation graph  14 . For example, the functional node  26  paired with the stored “cap” function  28  gives a contextual tax explanation in that is more than merely “value exceeds cap.” For instance, a pre-stored narrative associated with the particular functional node  26  having to do with the child tax credit within the calculation graph  14  may be a complete statement or sentence such as “You cannot claim a child tax credit because your income is too high.” In other embodiments, the pre-stored narrative may be only a few words or a sentence fragment. In the above example, the pre-stored narrative may be “credit subject to income phase out” or “AGI too high.” A particular functional node  26  and associated function  28  may have multiple pre-stored narratives. The particular narrative(s) that is/are associated with a particular functional node  26  and associated function  28  may be stored in entries  112  in a data store or database such as data store  42  of  FIG. 7 . For example, with reference to  FIG. 7 , data store  42  contains the pre-stored narratives that may be mapped or otherwise tagged to particular functional nodes  26  and associated functions  28  contained within the calculation graph(s)  14 . The locations or addresses of the various functional nodes  26  and the associated functions  28  can be obtained using the calculation graphs  14 . 
     These stored entries  112  can be recalled or extracted by the explanation engine  110  and then displayed to a user on a display  104  of a computing device  102 ,  103 . For example, explanation engine  110  may interface with the UI control  80  in two-way communication such that a user may be ask the tax preparation software  100  why a particular tax calculation, operation, or decision has been made by the system  40 . For instance, the user may be presented with an on-screen link ( FIGS. 10A, 10B, 11A, 11B, 12A, and 12B  illustrate a hyperlink  120 ), button, or the like that can be selected by the user to explain to the user why a particular tax calculation, operation, or decision was made by the tax preparation software  100 . For example, in the context of  FIG. 6B  described herein, a user may see an ACA penalty of $1,210.00 listed on the screen of the computing device  102 ,  103  while he or she is preparing the tax return for a prior year.  FIGS. 8A-8C  illustrate an example of such a screen shot. The taxpayer may be interested in why there such a penalty. As one example, the initial explanation provided to the user may be “you have an ACA penalty because you, your spouse, and your two child dependents did not have coverage during the 2014 calendar year and the penalty is based on your income.” This explanation may be associated with, for example, function node  26  and function  28  pair B in  FIG. 6B . In some instances, a user is able to further “drill down” with additional questions to gain additional explanatory detail. This additional level of detailed explanations is possible by retracing the calculation graph(s)  14  to identify a predecessor or upstream function node  26  and function  28 . In the context of the example listed above, a user may not be satisfied and may want additional explanation. In this instance, for example, the word “income” may be highlighted or linked with a hyperlink. A user clicking on this would then be provided with additional explanation on the detail regarding the ACA penalty. In this example, the user may be provided with “Under the ACA your penalty is the greater of 1% of your taxable income or a fixed dollar amount based on your family circumstances. In your situation, the 1% of taxable income exceeded the fixed dollar amount.” This particular explanation may be associated with the predecessor function node  26  and function  28  pair A in  FIG. 6B . Additional details may be provided by further retracing, in a backwards fashion, the calculation graph  14 . 
     With reference to  FIG. 7 , the explanation engine  110  may also automatically generate explanations that are then communicated to the user interface manager  80 . The automatically generated explanations may be displayed on a display associated with the computing devices  102 ,  103 . In some embodiments, the explanations may be contemporaneously displayed alongside other tax data and/or calculations. For example, as a user inputs his or her information into the tax preparation software  100  and calculations are automatically updated, explanations maybe automatically displayed to the user. These explanations maybe displayed in a side bar, window, panel, pop-up (e.g., mouse over), or the like that can be followed by the user. The explanations may also be fully or partially hidden from the user which can be selectively turned on or off as requested by the user. 
     In one aspect of the invention, the choice of what particular explanation will be displayed to a user may vary. For example, different explanations associated with the same function node  26  and function  28  pair may be selected by the explanation engine  110  for display to a user based on the user&#39;s experience level. A basic user may be given a general or summary explanation while a user with more sophistication may be given a more detailed explanation. A professional user such as a CPA or other tax specialist may be given even more detailed explanations.  FIGS. 8A-8C  illustrates three different explanations ( 116 basic,  116 intermediate,  116 detailed) that are displayed to different users that have various degrees of explanation.  FIG. 8A  illustrates a basic explanation  116 basic. In this example, an explanation is provided by the taxpayer owes an ACA penalty of $1,210.  FIG. 8B  illustrates a more detailed explanation  116 intermediate of this same penalty. In the  FIG. 8B  example, the taxpayer is told additional reasons behind the penalty (i.e., required health insurance was not obtained for the entire tax year). In  FIG. 8C , an even more detailed explanation  116 detailed is given which more closely tracks the actual function node  26  and function  28  that makes up the calculation graph  14 . Note that in  FIG. 8C  various terms such as “minimum essential health insurance” which has a specific definition under U.S. tax code and regulations is linked so that the user can drill into even more detail. Likewise, taxable income is linked in this example, letting the user potentially drill even further into the calculation of the ACA penalty. While three such explanations  116  are illustrated in the context of  FIGS. 8A-8C , additional levels of simplicity/complexity for the explanation can be used. 
     In some embodiments, the different levels of explanation may be tied to product types or codes. These may be associated with, for example, SKU product codes. For example, a free edition of the tax preparation software  100  may little or no explanations. In a more advanced edition (e.g., “Deluxe edition”), additional explanation is provided. Still more explanation may be provided in the more advanced editions of the tax preparation software  100  (e.g., “Premier edition”). Version of the tax preparation software  100  that are developed for accountants and CPAs may provide even more explanation. 
     In still other embodiments a user may be able to “unlock” additional or more detailed explanations by upgrading to a higher edition of tax preparation software  100 . Alternatively, a user may unlock additional or more detailed explanations in an a la carte manner for payment of an additional fee. Such a fee can be paid through the tax preparation software  100  itself using known methods of payment. 
       FIG. 9  illustrates additional details of the explanation engine  110  according to an embodiment of the invention. In this embodiment, the explanation engine  110  includes a natural language generator  114  that converts fragments, expressions or partial declaratory statements into natural language expressions that are better understood by users. The natural language expressions may or may not be complete sentences but they provide additional contextual language to the more formulaic, raw explanations that may be tied directly to the explanation associated with a function node  26  and associated function  28 . In the example of  FIG. 9 , a brief explanation  115 A extracted by the explanation engine  110  which indicates that the child credit tax is zero due to phase out from income level is then subject to post-processing to convert the same into a more understandable sentence that can be presented to the user. In this example, the user is provided with a natural language explanation  115 B that is more readily understood by users. 
     In one aspect of the invention, the natural language generator  114  may rely on artificial intelligence or machine learning such that results may be improved. For example, the explanation engine  110  may be triggered in response to a query that a user has typed into a free-form search box within the tax preparation software  100 . The search that has been input within the search box can then be processed by the explanation engine  110  to determine what tax operation the user is inquiring about and then generate an explanatory response  115 B. 
       FIGS. 10A, 10B, 11A, 11B, 12A, and 12B  illustrate various embodiments of how a narrative explanation  116  may be displayed to a user on a display  104  that is associated with a computing device  102 ,  103 .  FIGS. 10A and 10B  illustrate an exemplary screen shot of a display  104  that contains a narrative explanation  116  of a tax operation. In this particular example, the tax operation pertains to the ACA shared responsibility penalty. As seen in the screen shot on display  104 , the narrative explanation  116  may be presented along with additional tax data  118  that generally relates to the specific tax operation. In this example, a separate window  119  contains tax data  118  that relates to the tax operation or topic that is germane to the narrative explanation  116  that is being displayed. In this example, the taxpayer&#39;s zip code, AGI, tax exempt interest amount, exemption status, and insurance coverage status are illustrated. It should be understood, however, that the specific tax data  118  that is displayed may vary and many include more or less information. In addition, the tax data  118  may be hidden from view in other embodiments. Likewise, the tax data  118  does not have to be displayed in a separate window  119  or other area on the display  104 . For example, the tax data  118  could be on a ribbon or pop-up window. 
     As seen in  FIG. 10A , the narrative explanation  116  includes a plurality of words wherein several words or phrases are hyperlinked  120 . In this regard, the narrative explanation  116  is nested as one or more phrases can be further expanded as is illustrated below. In this example, the narrative explanation  116  tells the user why their shared responsibility penalty was $405. Specifically, the narrative explanation  116  explains that the shared responsibility penalty is $405 because there was a deficit in coverage that causes the ACA penalty to apply and there was not exemption. The narrative explanation  116  in this example includes three phrases or words (“deficit in coverage”; “ACA Penalty”; “exemption”) that are hyperlinked  120 . A user can select a hyperlink  120  associated with one of these phrases or words where an additional narrative explanation  116 ′ is given as illustrated in  FIG. 10B .  FIG. 10B  illustrates a view of the display  104  after a user has selected the “deficit in coverage” phrase in  FIG. 10A . As seen in  FIG. 10B , the user is presented with another narrative explanation  116 ′ explaining additional details on why there was a deficit in coverage for the taxpayer. Here, the user is told that a deficit in coverage was present because the taxpayer did not enroll in a qualified insurance plan during the year. As seen in  FIG. 10B , the hyperlink  120  for “deficit in coverage” may change appearances upon being selected. For example, the hyperlink  120  may go from a solid line to a dashed line to indicate that it has been selected. Of course, other changes in appearance such as size, shape, highlighting can be used. Alternatively, the word or phrase of the hyperlink  120  may change appearances after being selected. For example, the word or phrase may change color, font size, or be highlighted to illustrate that the additional explanation  116 ′ pertains to that specific word or phrase. 
       FIGS. 11A and 11B  illustrate how the initial narrative explanation  116  can be expanded further a plurality of times. In this example, the initial narrative explanation  116  includes the phrase “ACA Penalty.” A user may select the hyperlink  120  associated with this phrase that brings up another narrative explanation  116   a  that provides additional explanatory detail on the ACA penalty. In this example, the additional narrative explanation  116   a  itself includes several words or phrases with hyperlinks  120 . In this example, “calculated ACA penalty,” “minimum penalty,” and “maximum penalty” are phrases that contain respective hyperlinks  120  where even additional explanation can be found. As seen in  FIG. 11B , for example, a user that selects the hyperlink  120  that is associated with “calculated ACA penalty” returns another narrative explanation  116   b  that explains how the amount of the calculated ACA penalty was derived. In this example, the penalty was calculated as 1% of taxable income. 
       FIGS. 12A and 12B  illustrate the same initial narrative explanation  116  as found in  FIGS. 10A and 11A  but with the hyperlinks  120  associated with the word “exemption” being selected. As seen in  FIG. 12A , in narrative explanation  116   d , the user is given an explanation that no exemption applies because the taxpayer did not quality for any specified exemptions including the affordability exemption because the lowest cost plan, itself a defined phrase that has a hyperlink), is less than 8% of household income.  FIG. 12B  illustrates the same display  104  after a user has selected the hyperlink  120  that is associated with “lowest cost plan” which then displays that the lowest cost plan offered by the State in which the taxpayer resides is $250/month. 
     The narrative explanations  116  and their associated sub-explanations (e.g.,  116 ′,  116   a ,  116   b ,  116   d ,  116   e ) are constructed as an explanation tree with the root of the tree representing a particular tax topic or tax operation. In the example of  FIGS. 10A, 10B, 11A, 11B, 12A, and 12B , the tax topic pertains to the ACA penalty. The explanation trees are readily constructed based on the function nodes  26  and associated functions  28  contained within the calculation graph  14 . For example, one is able to “drill down” into more detailed explanations by walking up the directed graph that forms the calculation graph  14 . For example, the initial explanation  116  that is displayed on the screen may be associated with node D of the calculation graph  14  of  FIG. 6B . By selecting the ACA penalty hyperlink  120  as seen in  FIGS. 11A and 11B , a predecessor node (e.g., node C) is used to generate the narrative explanation  116   a . Yet another predecessor node (node A) is used to generate the narrative explanation of the calculated ACA penalty. In this manner, explanations can be presented to the user in a recursive manner by reversely traversing the calculation graph  14 . Conversely, walking progressively down the calculation graph  14  shows how one node  26  affects other downstream nodes  26 . 
     By encapsulating the tax code and regulations within calculation graphs  14  results in much improved testability and maintainability of the tax preparation software  100 . Software bugs can be identified more easily when the calculation graphs  14  are used because such bugs can be traced more easily. In addition, updates to the calculation graphs  14  can be readily performed when tax code or regulations change with less effort. 
     Further, the degree of granularity in the narrative explanations  116  that are presented to the user can be controlled. As explained in the context of  FIGS. 8A-8C  different levels of details can be presented to the user. This can be used to tailor the tax preparation software  100  to provide scalable and personalized tax explanations to the user. The narrative explanations  116  can be quickly altered and updated as needed as well given that they are associated with the calculation graphs and are not hard coded throughout the underlying software code for the tax preparation software  100 . 
     Note that one can traverse the calculation graph  14  in any topologically sorted order. This includes starting at a leaf or other input node and working forward through the calculation graph  14 . Alternatively, one can start at the final or terminal node and work backwards. One can also start at in intermediate node and traverse through the directed graph in any order. By capturing the tax code and tax regulations in the calculation graph, targeted calculations can be done on various tax topics or sub-topics. For example,  FIG. 6B  demonstrates a very isolated example of this where a calculation graph  14  is used to determine the amount, if any, of the ACA shared responsibility penalty. Of course, there are many such calculation graphs  14  for the various topics or sub-topics that makeup the tax code. This has the added benefit that various tax topics can be isolated and examined separately in detail and can be used to explain intermediate operations and calculations that are used to generate a final tax liability or refund amount. 
     A user initiates the tax preparation software  100  on a computing device  102 ,  103  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). 
     A user initiating the tax preparation software  100 , as explained herein may import tax related information form one or more data sources  48 . Tax data may also be input manually with user input  48   a . The tax calculation engine  50  computes one or more tax calculations dynamically based on the then available data at any given instance within the schema  44  in the shared data store  42 . In some instances, estimates or educated guesses may be made for missing data. Details regarding how such estimates or educated guesses are done maybe found in U.S. patent application Ser. No. 14/448,986 which is incorporated by reference as if set forth fully herein. As the tax preparation software  100  is calculating or otherwise performing tax operations, the explanation engine  110  is executing or made available to execute and provide to the user one or more narrative explanations regarding calculations or operations being performed as referenced by particular functional nodes  26  and functions  28  contained within the calculation graph  14 . As noted herein, in some instances, the narrative explanations are provided automatically to the UI control  80 . In other instances, explanations are provided by the explanation engine  110  upon request of a user. For example, a user may request explanations on an as-needed basis by interfacing with the tax preparation software  100 . 
       FIG. 14  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. 14  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.