The application discloses a method for locating an abnormal source of an index platform based on a finance and tax field and an index platform

Abstract

This application relates to the field of data processing technology, and in particular to a method for locating the source of anomalies in an indicator platform based on the financial and tax field, and an indicator platform. The method includes: upon receiving a user's query instruction for a target indicator report, obtaining a pre-established full-link data lineage graph based on the target indicator report identifier in the query instruction, and obtaining the display results corresponding to the target indicator report based on the full-link data lineage graph; each lineage node in the full-link data lineage graph is used to represent the corresponding data calculation and processing step, and is associated with the operator rules for executing the data calculation and processing steps; the starting lineage node of the full-link data lineage graph is associated with pre-acquired raw data and corresponding type labels; the display results are the indicator calculation results corresponding to different dimensions obtained by executing each data calculation and processing step sequentially according to the data flow dependency relationship based on the raw data associated with the starting lineage node in the full-link data lineage graph.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and indicator platform for locating the source of anomalies in an indicator platform based on the financial and tax field. Background Technology

[0002] Against the backdrop of deepening financial and tax informatization, financial and tax SaaS platforms are gradually becoming core infrastructure for enterprises to manage invoices, file tax returns, and conduct financial accounting. Among these, indicator platforms process multi-source data, including VAT invoices, corporate income tax returns, financial ledgers, and business registration information, using rule-based processing to generate key indicator results such as tax burden rate, tax health, and credit rating, providing crucial support for enterprise business decisions and risk control. Typically, these indicator platforms use pre-defined calculation logic rules to chain multiple data processing steps into a calculation flow, which is then parsed and executed by a rule engine to ultimately output the indicator calculation results.

[0003] However, the mainstream implementation methods in existing technologies mostly adopt a "rule engine + scheduling execution" architecture. This involves defining indicator calculation rules through visual configuration, having the rule engine parse and generate an execution plan, and then having a scheduler trigger batch calculation tasks at preset times to obtain the final indicator results. While this approach can automate indicator calculation, it is essentially still an "input-output" processing mode. Users can only obtain the final calculation results and cannot intuitively understand the data flow path and intermediate calculation details during indicator formation. Clearly, in related technologies, the aforementioned indicator calculation scheme based on rule engine-encapsulated execution has significant shortcomings when facing complex financial and tax business scenarios. First, due to the dispersed sources of financial and tax data and the lack of a unified data modeling and correlation mechanism between different systems, it is difficult to form effective correlations between various types of invoice data, declaration data, and ledger data, resulting in a fragmented data chain and making it difficult to achieve unified tracking of cross-source data when conducting indicator analysis. Second, existing solutions generally encapsulate the calculation process within the rule engine, lacking explicit expression of intermediate calculation steps and variables, and failing to build a clear data dependency structure, making the indicator calculation process "black box." Once an anomaly occurs, it is impossible to quickly locate the specific error. Third, in the process of anomaly localization, it is usually necessary to gradually investigate through full recalculation or log backtracking, which is not only computationally expensive but also has a long localization cycle, making it difficult to meet the real-time and high-efficiency requirements of actual business. In addition, for large-scale invoice and financial data scenarios, it is impossible to locate the intermediate data entities or even the original data fragments step by step from the final indicator results, making it difficult to accurately pinpoint the source of the anomaly. For example, patent application publication number CN115495519A (classification number G06F) provides a method and apparatus for processing report data; patent application publication number CN120407554A (classification number G06F) provides a method for facilitating data lineage collection and analysis; and patent application publication number CN120561105A (classification number G06F) provides a method, apparatus, equipment, and medium for processing data lineage maps.

[0004] Furthermore, even when using data playback or sandbox mechanisms to recalculate historical data, existing technologies can only observe changes in the final result and cannot obtain the specific intermediate data entities involved in the calculation and their corresponding original data sources. They lack the ability to penetrate layer by layer from "indicator result—intermediate processing steps—original data." When users need to perform fine-grained analysis of a certain dimension's indicator result, existing technologies struggle to provide the corresponding data entities and their calculation basis, and are unable to trace further back to the original data fragments actually involved in the calculation. This severely impacts the accuracy and interpretability of anomaly localization. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides an anomaly source location method and indicator platform based on the indicator platform in the field of finance and taxation, which solves the technical problem in the prior art that it is difficult to accurately locate the source of anomalies because it is impossible to reverse the location from the indicator calculation results to the original data.

[0007] (II) Technical Solution

[0008] To achieve the above objectives, the main technical solutions adopted in this application include:

[0009] In a first aspect, embodiments of this application provide a method for locating the source of anomalies in an indicator platform based on the financial and tax field, comprising: upon receiving a user's query instruction for a target indicator report, obtaining a pre-established full-link data lineage graph corresponding to the target indicator report identifier carried in the query instruction, and obtaining the display result corresponding to the target indicator report based on the full-link data lineage graph; wherein, each data calculation and processing step in the preset calculation logic rules corresponding to the target indicator report is pre-mapped as a lineage node, and the data flow dependency relationship between each data calculation and processing step is mapped as a lineage edge, thereby constructing the full-link data lineage graph; the data flow dependency relationship is as follows: In the computational logic rules, there are sequential constraints between different data computation and processing steps based on data transfer. The calculation result of the previous data computation and processing step serves as the input data for the next data computation and processing step. Each lineage node in the full-link data lineage graph represents the corresponding data computation and processing step and is associated with the operator rules for executing that step. The starting lineage node of the full-link data lineage graph is associated with pre-acquired raw data and the type label corresponding to the raw data. The displayed result is the result of calculating indicators corresponding to different dimensions obtained by executing each data computation and processing step sequentially according to the data flow dependency relationship based on the raw data associated with the starting lineage node in the full-link data lineage graph.

[0010] Optionally, in some embodiments of this application, the method further includes: upon receiving a first penetration query instruction representing a first-level data penetration of the indicator calculation result of any dimension in the displayed results, obtaining the first-level penetration result of that dimension; wherein, the first-level penetration result includes a data entity and / or the storage index of the data entity obtained by executing the operator rule associated with the intermediate lineage node in the full-link data lineage graph corresponding to the indicator calculation result of the dimension, and the operator rule for calculating the data entity; the data type of the data entity includes tax return forms, invoice data or financial ledger data, and business registration data.

[0011] Optionally, in some embodiments of this application, the method further includes: upon receiving a second penetration query instruction characterizing a second-level data penetration of any data entity and / or the index of the data entity in the first-level penetration result, obtaining a second-level penetration result; wherein the second-level penetration result includes: original data fragments in the original data associated with the starting lineage node for calculating the full-link data lineage graph of the data entity, the original data fragments being the original data actually used in the process of calculating the data entity.

[0012] Optionally, in some embodiments of this application, the process of obtaining the first layer penetration result of the dimension includes: determining the corresponding bloodline node in the full-link data bloodline graph as the target bloodline node based on the index calculation result of the dimension; starting from the target bloodline node, traversing in reverse along the bloodline edge of the full-link data bloodline graph to obtain upstream bloodline nodes that have a data flow dependency relationship with the target bloodline node, until the starting bloodline node is reached;

[0013] During the traversal, for each bloodline node, the following are recorded: the computational input determined by the data flow dependency relationship between adjacent bloodline nodes in the full-link data bloodline graph; the computational output obtained by executing the operator rule corresponding to the bloodline node; the operator rule associated with the bloodline node; and the timestamp information of the execution based on the operator rule corresponding to the bloodline node. Each bloodline node obtained by traversal is divided into layers according to its bloodline layer distance from the target bloodline node. The computational output and its operator rule corresponding to the upper-layer bloodline node whose bloodline layer distance from the target bloodline node is the first layer are determined as the data entity and its operator rule in the first layer penetration result.

[0014] Optionally, in some embodiments of this application, the process of obtaining the second-layer penetration result includes: determining the lineage node corresponding to any data entity and / or the storage index of the data entity in the first-layer penetration result as the target intermediate lineage node; starting from the target intermediate lineage node, recursively tracing back along the lineage edge direction of the full-link data lineage graph to identify all upstream lineage nodes that directly or indirectly contribute to the calculation output of the target intermediate lineage node, until the starting lineage node is reached; determining the original data fragment in the process of calculating the target data entity according to the recursive back-tracing process along the lineage edge direction of the full-link data lineage graph, wherein the original data fragment is the original data in the original data associated with the starting lineage node of the full-link data lineage graph that participated in the generation of the data entity, and using the original data fragment as the second-layer penetration result; the original data includes tax returns, invoice data or financial ledger data, and industrial and commercial data.

[0015] Optionally, in some embodiments of this application, the method further includes: receiving a user's modification instruction for any data entity or original data fragment; based on the modification instruction, taking the lineage node corresponding to the modified data entity or original data fragment as the modification lineage node, and identifying the affected sub-lineage graph from the modification lineage node along the downstream lineage edge direction of the full-link data lineage graph; performing local recalculation on the lineage nodes in the affected sub-lineage graph to generate modified indicator calculation results; comparing the indicator calculation results before and after modification to generate a risk impact assessment report, the risk impact assessment report including numerical differences in indicator calculation results and compliance warning prompts; the numerical differences include the difference and change ratio between the target indicator values ​​before and after modification; the compliance warning prompts are prompt information generated after threshold judgment of the numerical differences or matching according to preset financial and tax risk control rules; wherein, the financial and tax risk control rules include at least one of the consistency verification rules between tax return forms and invoice data and the logical reconciliation rules between financial ledgers and declaration data.

[0016] Optionally, in some embodiments of this application, the affected sub-lineage map is: a sub-lineage map composed of all lineage nodes reachable along the downstream lineage edge direction starting from the modified lineage node; or, a map constructed based on the full-link data lineage map using a preset impact analysis strategy; wherein, the process of constructing the affected sub-lineage map based on the full-link data lineage map using a preset impact analysis strategy includes: determining the lineage node in the full-link data lineage map corresponding to the user-modified data entity or original data fragment as the modified lineage node; adding the modified lineage node to the affected lineage node set, and using the modified lineage node as the initial affected lineage node; starting from the modified lineage node, Downstream relatives with data flow dependencies on the modified relatives are identified layer by layer along the downstream edge direction of the full-link data lineage graph. During the identification process, for each downstream relative, the sensitivity coefficient of the downstream relative to the output of the preceding relative is obtained, and the subsequent relative is determined based on the sensitivity coefficient to determine whether the subsequent relative meets the influence condition. Downstream relative nodes that meet the influence condition are added to the affected relative node set, and the identification and determination process continues along the downstream edge direction until there are no more downstream relative nodes that meet the influence condition. All relatives in the affected relative node set and their connection relationships in the full-link data lineage graph are preserved to construct the affected sub-lineage graph.

[0017] Optionally, in some embodiments of this application, obtaining the sensitivity coefficient of the downstream kinship node to the computational output of the preceding kinship node, and determining whether the subsequent kinship node meets the influence condition based on the sensitivity coefficient, includes: obtaining the current computational input and current computational output corresponding to the downstream kinship node executing its association operator rule, wherein the current computational input at least includes the computational output from the preceding kinship node that has a data flow dependency relationship with the downstream kinship node; applying a preset perturbation amount based on the computational output of the preceding kinship node corresponding to the current computational input to obtain the perturbed preceding computational output; replacing the corresponding input item in the current computational input with the perturbed preceding computational output, and associating it based on the downstream kinship node. The operator rules are re-executed to obtain the perturbed computation output. Based on the degree of difference between the current computation output and the perturbed computation output, the sensitivity coefficient of the preceding lineage node to the downstream lineage node is determined. The degree of difference includes any one or more of the following: the relative rate of change between the current computation output and the perturbed computation output; the normalized difference ratio of the current computation output and the perturbed computation output on each computation result item; the distance metric between the current computation output and the perturbed computation output in the vector space. When the sensitivity coefficient is greater than or equal to a preset influence threshold, the downstream lineage node is determined to meet the influence condition and is included in the set of affected lineage nodes.

[0018] Optionally, in some embodiments of this application, the method further includes: after generating the modified indicator calculation result, performing compliance backtracking verification on the data calculation processing steps and their corresponding calculation logic rules of the modified indicator calculation result based on a pre-built and time-versioned snapshot of the tax policy clauses, in order to identify potential compliance risk lineage nodes; wherein, the snapshot of the tax policy clauses includes historical policy documents and their corresponding clauses; the compliance backtracking verification includes: obtaining the business occurrence time corresponding to the modified indicator calculation result, matching the target version policy rule corresponding to the business occurrence time from a preset tax policy rule knowledge base; semantically mapping and logically comparing the data processing logic associated with each lineage node in the affected sub-lineage graph with the target version policy rule; and, based on the comparison result, determining whether the execution of the data processing logic conflicts logically with the target version policy rule, and marking the lineage nodes with logical conflicts as potential compliance risk nodes.

[0019] On the other hand, this application embodiment also provides an indicator platform, including a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the above-mentioned method for locating the source of anomalies in an indicator platform based on the financial and tax field.

[0020] (III) Beneficial Effects

[0021] The method and platform for locating the source of anomalies in a financial and tax-related indicator platform provided in this application's embodiments map each data calculation and processing step in the preset calculation logic rules corresponding to the target indicator report as a lineage node, and maps the sequential constraints between each data calculation and processing step based on data transmission as lineage edges, thereby constructing a full-link data lineage graph. This allows the calculation process, originally scattered within the rule engine, to be uniformly expressed in a structured graph form. Compared to the encapsulation of the calculation process and the invisibility of paths in existing technologies, this application can explicitly depict the data flow dependencies between each data calculation and processing step, thereby achieving a complete expression and structured modeling of the indicator calculation process, and improving the interpretability and visualization capabilities of the calculation process.

[0022] Furthermore, by associating operator rules for executing corresponding data calculation and processing steps with each ancestry node in the full-link data lineage graph, each node not only represents the calculation steps but also carries specific calculation logic, thereby making the full-link data lineage graph executable. Based on this, by sequentially executing each data calculation and processing step according to the data flow dependency relationship based on the original data associated with the initial ancestry node, the complete indicator calculation process can be reconstructed. Thus, not only can indicator calculation results corresponding to different dimensions be obtained, but the calculation process can also be gradually restored, effectively avoiding the problem of relying on full recalculation or manual inspection in existing technologies, and improving the efficiency and accuracy of calculation process reproduction.

[0023] Furthermore, by associating pre-acquired raw data and its type labels with the starting lineage node of the full-link data lineage map, a clear correspondence is established between the indicator calculation results and the raw data, thus forming a complete link from the raw data to the intermediate calculation steps and finally to the indicator result. Based on this complete link, reverse tracing of the indicator calculation results can be achieved, providing a structured basis for anomaly source location. This solves the problem in existing technologies where indicator results are difficult to trace back to the raw data, significantly improving the accuracy and efficiency of anomaly location.

[0024] Meanwhile, this application obtains the display results corresponding to the target indicator report based on a unified end-to-end data lineage map, so that the indicator calculation results of different dimensions all come from the same data lineage structure. While ensuring the consistency of calculation, it avoids the result deviation problem caused by independent processing of multi-source data, thereby improving the reliability and consistency of indicator results and further realizing the structured expression and traceable analysis of the calculation process. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a method for locating the source of anomalies in an indicator platform based on the financial and tax field, according to an embodiment of this application.

[0026] Figure 2 This is a flowchart illustrating the process of obtaining a second-layer penetration result according to an embodiment of this application. Detailed Implementation

[0027] To better explain and facilitate understanding of this application, the following detailed description of the application is provided in conjunction with the accompanying drawings and specific embodiments.

[0028] In related technologies, the calculation of indicators and anomaly location for indicator platforms in the financial and tax field can be mainly summarized into the following implementation methods:

[0029] The first type is the indicator calculation scheme based on rule engines and batch processing scheduling. This type of scheme configures the calculation logic rules corresponding to the indicators, which are then parsed and generated by the rule engine. The scheduler then triggers batch calculation tasks to output the indicator calculation results of the target indicator report. However, this scheme usually only focuses on the generation process of the final indicator result and lacks a structured expression of each data calculation and processing step in the calculation logic rules. This makes the indicator calculation process appear as a black box, making it difficult to intuitively reflect the data flow dependencies between each data calculation and processing step. Consequently, it is difficult to effectively trace the results when anomalies occur.

[0030] The second type is anomaly localization based on log recording and manual analysis. This type of solution typically records intermediate calculation logs during each data calculation and processing step, reconstructs the indicator calculation process by retrieving log information, and gradually locates the source of abnormal data by combining this with human experience. Although this method can obtain some intermediate calculation results to a certain extent, its localization efficiency is low and it relies heavily on human experience, making it difficult to adapt to the large-scale data analysis needs in complex financial and tax scenarios.

[0031] The third type is the indicator verification scheme based on result playback or full recalculation. This type of scheme re-inputs the original data into the rule engine and recalculates the target indicator report to help determine the source of the anomaly by comparing the differences between the before and after results. However, this scheme can only obtain the final indicator calculation result during execution and cannot obtain the execution results of each intermediate data calculation and processing step and the original data on which they depend. Therefore, it is difficult to achieve step-by-step tracing from the indicator result to the original data, resulting in high computational overhead and low positioning accuracy.

[0032] To this end, the method for locating the source of anomalies in an indicator platform based on the financial and tax field provided in this application constructs a full-link data lineage graph by mapping each data calculation and processing step in the preset calculation logic rules corresponding to the target indicator report to lineage nodes and mapping the data flow dependencies between each data calculation and processing step to lineage edges. Furthermore, in the full-link data lineage graph, operator rules for executing the corresponding data calculation and processing steps are associated with each lineage node, and the original data and its type label are associated with the starting lineage node. This ensures that the full-link data lineage graph not only represents the complete data calculation and processing steps and their dependencies but also possesses executability. Based on this, by sequentially executing each data calculation and processing step according to the data flow dependencies, indicator calculation results corresponding to different dimensions can be obtained. A complete expression and traceability of the indicator calculation process can be achieved under a unified lineage structure. Therefore, when an indicator result is abnormal, layer-by-layer location from the result to the original data can be achieved based on the full-link data lineage graph, improving the efficiency and accuracy of anomaly source location while ensuring the transparency and consistency of the indicator calculation process.

[0033] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application can be understood more clearly and thoroughly, and that the scope of this application can be fully conveyed to those skilled in the art.

[0034] Figure 1 This is a flowchart illustrating a method for locating the source of anomalies in an indicator platform based on the financial and tax field, according to an embodiment of this application. Figure 1 As shown, this method for locating the source of anomalies in an indicator platform based on the financial and tax field includes:

[0035] Upon receiving a user's query instruction for a target indicator report, the system obtains a pre-established end-to-end data lineage map corresponding to the target indicator report identifier carried in the query instruction, and obtains the display results corresponding to the target indicator report based on the end-to-end data lineage map.

[0036] Specifically, the data calculation and processing steps in the preset calculation logic rules corresponding to the target indicator report are mapped to lineage nodes in advance, and the data flow dependency relationship between each data calculation and processing step is mapped to lineage edge, thereby constructing the full-link data lineage graph; the data flow dependency relationship is the sequential constraint relationship formed between different data calculation and processing steps based on data transmission in the calculation logic rules, wherein the calculation result of the previous data calculation and processing step is used as the input data of the next data calculation and processing step;

[0037] Each lineage node in the full-link data lineage graph is used to represent the corresponding data calculation and processing step, and is associated with the operator rule for executing the data calculation and processing step; the starting lineage node of the full-link data lineage graph is associated with the pre-acquired raw data and the type label corresponding to the raw data;

[0038] The displayed results are the result of the full-link data lineage map, which is based on the original data associated with the starting lineage node, and executes each data calculation and processing step in sequence according to the data flow dependency relationship to obtain the corresponding indicator calculation results of different dimensions.

[0039] In this embodiment, the dimensions are the corresponding accounting dimensions or their detailed dimensions set according to the calculation results of different indicators based on a preset accounting dimension system.

[0040] In this embodiment, the method for locating the source of anomalies in the indicator platform based on the financial and tax field is described in detail according to a specific business scenario. Furthermore, by introducing a preset accounting dimension system, the calculation results of indicators from different dimensions are displayed in a structured manner, as follows:

[0041] First, upon receiving a user's query instruction for a target indicator report, the system retrieves a pre-established end-to-end data lineage graph corresponding to the target indicator report identifier carried in the query instruction. For example, if a user queries "Enterprise 2024 Annual Tax Burden Rate Analysis Report," the system retrieves the corresponding end-to-end data lineage graph based on the report identifier. This end-to-end data lineage graph already includes a series of data calculation and processing steps, such as "Revenue Summary → Cost Collection → Profit Calculation → Tax Payable Calculation → Tax Burden Rate Calculation," and their dependencies.

[0042] Secondly, each data calculation and processing step in the calculation logic rules corresponding to the target indicator report is pre-mapped as a lineage node, and the sequential constraints between different data calculation and processing steps based on data transmission are mapped as lineage edges, thereby constructing a full-link data lineage graph. For example, in the process of "tax burden rate calculation", the "output tax calculation result" is used as the input data for the next step "tax payable calculation". In this case, a lineage edge is constructed in the lineage graph pointing from the "output tax calculation node" to the "tax payable calculation node", thus clearly expressing the data flow path.

[0043] Furthermore, each lineage node in the full-link data lineage graph represents the corresponding data calculation and processing step and is associated with the operator rule that executes that step. Simultaneously, the original data and its type label are associated in the starting lineage node. For example, the starting lineage node can be associated with "Value-added tax invoice data (type label: invoice)" or "General ledger data (type label: financial ledger)," ensuring that each subsequent calculation step clearly identifies its data source and data type.

[0044] Then, based on the original data associated with the initial lineage node, each data calculation and processing step is executed sequentially according to the data flow dependency relationship to obtain the indicator calculation results corresponding to different dimensions. Here, the dimension refers to the analytical caliber used to divide the indicator results according to a preset accounting dimension system. For example, after the tax burden rate indicator is calculated, it can be broken down according to "accounting period dimension (months in 2024)," "regional dimension (East China, South China, etc.)," ​​"subject dimension (main business revenue, other business revenue)," and "business type dimension (general taxpayer business, small-scale taxpayer business)" to form multi-dimensional indicator results, such as "tax burden rate in East China in March 2024" or "tax burden rate corresponding to main business revenue," etc.

[0045] In practical applications, if a user finds that "the tax burden rate in a certain region is abnormally high in a certain month", they can analyze the results along the lineage path of the corresponding dimension: first, locate the node for income and cost calculation under the dimension of this region; second, further locate the specific invoice data or ledger records involved in the calculation; and finally, trace back to the specific original invoice or voucher data to clarify the cause of the anomaly, such as a batch of invoices being counted twice or costs not being allocated correctly.

[0046] In this embodiment, since the calculation of indicators for each dimension is performed based on the same end-to-end data lineage map, the consistency of data sources and the uniformity of calculation logic between results of different dimensions are guaranteed, thereby avoiding data inconsistency problems caused by multi-caliber calculations. In addition, during the anomaly source location process, the investigation scope can be quickly narrowed down based on specific dimensions without the need for full analysis of the entire link, thereby significantly improving the location efficiency. At the same time, by associating lineage nodes with original data, it is possible to trace back layer by layer from the indicator calculation results to the original data, which enhances the interpretability and auditability of the indicator calculation results, and also improves the transparency of indicator calculation, thereby improving the accuracy and efficiency of anomaly location.

[0047] Optionally, in some embodiments of this application, see Figure 2 The method further includes: upon receiving a first penetration query instruction representing a first-level data penetration of the indicator calculation result of any dimension in the displayed results, obtaining the first-level penetration result of that dimension; wherein, the first-level penetration result includes a data entity and / or the storage index of the data entity obtained by executing the operator rule associated with the intermediate lineage node in the full-link data lineage graph corresponding to the indicator calculation result of the dimension, and the operator rule for calculating the data entity; the data type of the data entity includes tax return forms, invoice data or financial ledger data, and business registration data.

[0048] For example, in one specific embodiment, upon receiving a first penetration query instruction representing a first-level data penetration of the indicator calculation result for any dimension of the displayed results, the intermediate lineage nodes associated with that dimension are first located based on the full-link data lineage graph corresponding to the indicator calculation result. These intermediate lineage nodes represent intermediate calculation stages in the indicator calculation chain, and each intermediate lineage node is associated with a corresponding operator rule. This method ensures that the indicator calculation result no longer exists in isolation as a final value, but can be mapped to a resolvable link structure, thus providing a structured foundation for subsequent penetration analysis and solving the problems of untraceable indicator calculation processes and difficulty in locating the calculation source in existing technologies. For example, when receiving a first penetration query instruction for the "revenue growth rate dimension," the intermediate lineage nodes in the indicator calculation path are first located in the full-link data lineage graph. This implementation allows user queries to be directly anchored to specific calculation stage nodes, avoiding the problem of being unable to locate the calculation process in existing technologies, thereby improving indicator interpretation capabilities and positioning accuracy. Furthermore, after obtaining the intermediate lineage node, the operator rule associated with that lineage node is executed to obtain the corresponding data entity and / or its storage index. For example, for the associated operator rule "Σ taxable income field in each enterprise's tax return," executing this operator rule will yield the summarized tax return data entity, or the storage index information of that data entity in the database cluster. In this way, the intermediate lineage node can directly reconstruct the corresponding data entity through the operator rule, thereby achieving an integrated mapping between computational logic and data results, significantly improving the real-time performance and accuracy of data penetration, and reducing the cost of manual backtracking.

[0049] Furthermore, the data types of the data entities include, but are not limited to, tax returns, invoice data, financial ledger data, and business registration data. For example, in the scenario of financial ledger data, there may be operator rules for general ledger account aggregation, and the execution of these operator rules yields the ledger summary data entity for the corresponding accounting account. This technical feature enables standardized mapping and penetration of data from different sources and with different structures within a unified lineage framework, improving the consistency and fusion capabilities of cross-data domain analysis, thereby enhancing the applicability and accuracy of anomaly source localization in multi-source data scenarios.

[0050] Through the above methods, this embodiment achieves the step-by-step location of intermediate lineage nodes based on the full-link data lineage graph, starting from the indicator calculation results. It then directly reconstructs or locates the original and intermediate data entities and their storage indexes by executing node association operator rules, thereby achieving refined data penetration at the indicator dimension level. This makes the calculation chain of indicator results transparent, data sources traceable, and penetration analysis automated, effectively solving the technical problems of difficult anomaly location, fragmented data links, and low analysis efficiency in existing financial and tax indicator platforms.

[0051] Optionally, in this embodiment of the application, the process of obtaining the first layer penetration result of the dimension includes: determining the corresponding bloodline node in the full-link data bloodline map of the index calculation result of the dimension as the target bloodline node;

[0052] Starting from the target lineage node, traverse in reverse along the lineage edges of the full-link data lineage graph to obtain upstream lineage nodes that have data flow dependencies with the target lineage node, until the starting lineage node is reached.

[0053] During the traversal, for each bloodline node, the following are recorded: the computational input determined by the data flow dependency relationship between adjacent bloodline nodes in the full-link data bloodline graph; the computational output obtained by executing the operator rule corresponding to the bloodline node; the operator rule associated with the bloodline node; and the timestamp information of the execution based on the operator rule corresponding to the bloodline node. Each bloodline node obtained by traversal is divided into layers according to its bloodline layer distance from the target bloodline node. The computational output and its operator rule corresponding to the upper-layer bloodline node whose bloodline layer distance from the target bloodline node is the first layer are determined as the data entity and its operator rule in the first layer penetration result.

[0054] For example, in the scenario of obtaining the first-level penetration result of "corporate income tax revenue growth rate of a certain region", the first step is to determine the lineage node corresponding to the calculated result of this growth rate as the target lineage node. Then, starting from this target lineage node, the process traverses backwards along the lineage edges in the lineage graph. For instance, if the calculation of this growth rate depends on the execution result of the associated operator rule being "summary of taxable income for the current period" and the execution result of the associated operator rule being "summary of taxable income for the previous period", then the process will trace upstream to these two lineage nodes, and continue tracing upwards to nodes where the execution result of the associated operator rule is "summary of tax returns" or "collection of invoices", etc. During this process, each lineage node records its calculation input (such as detailed income declarations of each enterprise), calculation output (such as the summarized taxable income), corresponding operator rule (such as Σ summary rule, filtering rule), and execution timestamp, thus forming a complete calculation process log, making each step of the calculation auditable and reproducible. Furthermore, in the hierarchical division process, each lineage node is layered according to the distance relationship with the target lineage node. For example, the execution result of the associated operator rule directly connected to the target lineage node, which is the summary of taxable income for the current period, and the execution result of the associated operator rule, which is the summary of taxable income for the previous period, are classified as first-level upstream lineage nodes; higher-level lineage nodes belong to the second level and above. This hierarchical classification method structurally decomposes complex data lineage chains into layered dependencies, facilitating hierarchical penetration analysis of data at different granularities. Finally, the calculation output and its operator rule corresponding to the upper-level lineage node whose lineage level distance from the target lineage node is one level are determined as the first-level penetration result. In this way, users can directly penetrate from the indicator calculation results to the most critical upper-level calculation data without tracing the entire chain downwards, thus significantly improving data analysis efficiency.

[0055] This embodiment achieves full-link replayability and auditability of the indicator calculation process by reverse traversing the lineage edges and recording the calculation inputs, outputs, operator rules, and timestamp information, thus solving the problem of uninterpretable calculation processes in existing fiscal and tax indicator systems. Secondly, by performing structured layering based on lineage hierarchy distances, the complex calculation chain is decomposed into a clear hierarchical structure, thereby improving the granularity and controllability of data penetration. Thirdly, by directly outputting the first-layer upstream nodes as the penetration results, users can quickly obtain the most critical upstream calculation basis, avoiding redundant path analysis and improving the efficiency of anomaly location and problem tracing. Finally, because this method simultaneously retains the calculation inputs, outputs, and operator rule information, the dependencies between data at different levels can be fully reproduced, thereby significantly enhancing the stability, interpretability, and anomaly location capabilities of the fiscal and tax indicator platform in multi-source data environments.

[0056] Preferably, in some embodiments of this application, see Figure 2 The method further includes: upon receiving a second penetration query instruction characterizing a second-level data penetration of any data entity and / or the index of the data entity in the first-level penetration result, obtaining a second-level penetration result; wherein the second-level penetration result includes: original data fragments in the original data associated with the starting lineage node for calculating the full-link data lineage graph of the data entity, the original data fragments being the original data actually used in the process of calculating the data entity.

[0057] For example, in the scenario of analyzing the indicator "Corporate Income Tax Revenue Growth Rate in a Certain Region," after completing the first layer of penetration, the user has already obtained the data entity corresponding to "Summary of Taxable Income for the Current Period," such as the summary result of the taxable income of all enterprises in a certain region for the current period and its calculation rules. However, based on this, when the user further initiates a second penetration query command targeting this "Summary of Taxable Income Data Entity," the system will continue to trace down along the entire data lineage graph to the starting lineage node, directly locating the original data fragment actually referenced by this data entity during the calculation process. For example, for a lineage node whose execution result of an associated operator rule is a summary of taxable income, its data source may include tax return records from multiple companies. In this case, the second-level penetration result will return the original declaration fields of the specific company within a specific period, such as "Company A declared taxable income of 12 million yuan in Q1 2025" and "Company B declared income of 8.5 million yuan". These data fragments are all original data records that are actually called during the summary calculation process. In the case of invoice data, specific invoice details may be returned, such as the original field information of a VAT invoice, such as the invoice amount, tax amount, and invoice time.

[0058] Furthermore, the second-layer penetration result not only returns the original data itself, but also includes the initial lineage node association information used to calculate the data entity, thereby ensuring that the one-to-one correspondence between the original data fragment and the calculation link is clear and verifiable.

[0059] In detail, the process of obtaining the second layer penetration result in this embodiment includes: determining any data entity in the first layer penetration result and / or the lineage node corresponding to the storage index of the data entity as the target intermediate lineage node;

[0060] Starting from the target intermediate bloodline node, recursively trace back along the bloodline edge direction of the full-link data bloodline graph to identify all upstream bloodline nodes that directly or indirectly contribute to the calculation output of the target intermediate bloodline node, until the starting bloodline node is reached.

[0061] Based on the recursive reverse tracing process along the bloodline edges of the full-link data lineage graph, the original data fragments in the process of calculating the target data entity are determined. The original data fragments are the original data that participated in the generation of the data entity from the original data associated with the starting bloodline node of the full-link data lineage graph, and the original data fragments are used as the second layer penetration result. The original data includes tax returns, invoice data or financial ledger data, and business registration data.

[0062] The following is a detailed explanation using a specific example. After completing the first-level penetration query for "the growth rate of corporate income tax revenue in a certain region," the data entity corresponding to the target intermediate lineage node has been obtained, such as "summary result of taxable income for this period." This result may originate from the sum of tax return data from multiple companies. When a user initiates a second-level penetration query for this data entity, the lineage node whose execution result of the associated operator rule is the summary of taxable income is first identified as the target intermediate lineage node. Starting from this node, a recursive backward tracing is performed along the lineage edges in the lineage graph. During this recursive tracing process, not only is the direct upstream node traced back, but also the upstream starting lineage node associated with the original data is further traced. For example, for company A, its taxable income data may originate from the "taxable income field" in the original data (which is the tax return form). Furthermore, after completing the full-link backtracking, not all original data is output; only the original data fragments that "actually participated in the calculation" during the generation of the target data entity are extracted. For example, in tax return data scenarios, only the enterprise declaration records included in the summary calculation are extracted, such as "Enterprise A declared taxable income of 12 million yuan". By extracting only the "original data fragments actually involved in the calculation", redundant information interference caused by full data backtracking is avoided, improving the accuracy of data positioning and the efficiency of calculation reconstruction. Finally, since the original data fragments cover multiple heterogeneous data types such as tax returns, invoice data, financial ledger data, and business registration data, cross-data source consistency traceability can be achieved under a unified lineage framework, thereby significantly improving the completeness, credibility, and audit interpretability of locating the source of anomalies in financial and tax indicators.

[0063] Preferably, the method in this application embodiment further includes: receiving a user's modification instruction for any data entity or original data fragment; based on the modification instruction, taking the lineage node corresponding to the modified data entity or original data fragment as the modified lineage node; and identifying the affected sub-lineage graph from the modified lineage node along the downstream lineage edge direction of the full-link data lineage graph.

[0064] Local recalculation is performed on the bloodline nodes in the affected sub-bloodline map to generate modified index calculation results;

[0065] The calculation results of the indicators before and after the modification are compared to generate a risk impact assessment report, which includes the numerical differences in the indicator calculation results and compliance warning prompts.

[0066] The numerical differences include the difference and the percentage change between the target indicator values ​​before and after the modification;

[0067] The compliance warning is a prompt message generated based on preset financial and tax risk control rules, which are used to determine the threshold of the numerical differences or to match them according to preset rules. The financial and tax risk control rules include at least one of the consistency verification rules between tax return forms and invoice data and the logical reconciliation rules between financial ledgers and declaration data.

[0068] Specifically, during the penetration process of the "Corporate Income Tax Revenue Growth Rate in a Certain Region" indicator calculation, after the second layer of penetration, the user discovered an input error in the "Taxable Income Field" of a company's tax return, for example, "12 million yuan" was mistakenly entered as "1.2 million yuan". At this point, the user initiated a modification command for this original data fragment. First, the "starting lineage node corresponding to the original record of the tax return" was used as the modification lineage node, and an impact propagation analysis was performed along the downstream lineage edges of the full-link data lineage graph. For example, this data first affected lineage nodes associated with the summary of corporate taxable income, then affected lineage nodes associated with the current period's total taxable income, and finally affected the lineage node used to calculate the corporate income tax revenue growth rate, thus identifying the complete affected sub-lineage graph. After identifying the affected sub-graph, local recalculation was performed on each lineage node within that sub-graph. For example, only the summary of taxable income for the region where the company is located was recalculated, without requiring a full recalculation of other unrelated regions or historical data, thereby significantly improving computational efficiency and avoiding the resource waste caused by global recalculation. After the recalculation is completed, the revised indicator calculation results are generated. For example, the corporate income tax revenue growth rate is adjusted from the original "8.5%" to "9.2%", and then compared and analyzed with the results before the modification.

[0069] Furthermore, a risk impact assessment report will be automatically generated, including numerical difference analysis, such as "growth rate difference = 0.7 percentage points, change ratio approximately 8.2%". Simultaneously, compliance judgment will be made on this change based on preset financial and tax risk control rules. For example, according to the "consistency verification rules between tax return and invoice data", a significant deviation between the company's declared revenue and the corresponding invoice amount is detected; or according to the "logical reconciliation rules between financial ledgers and declared data", an anomaly is found in the matching relationship between the modified declared data and the ledger revenue, thereby triggering compliance warnings, such as "risk of inconsistency between declared data and invoice data" or "revenue recognition logic deviation exceeding threshold".

[0070] This embodiment utilizes a downstream impact propagation mechanism based on lineage graphs to automatically trigger the identification of the affected scope after data modification. This avoids the problem of traditional technologies that only modify parts and ignore the global impact, achieving end-to-end traceability of the impact of data changes. Secondly, by performing local recalculation on the sub-lineage graph, the computational resource consumption is significantly reduced compared to full recalculation, improving response efficiency and enhancing the real-time performance and scalability of the indicator platform. Thirdly, by comparing the differences in indicator results before and after modification, the impact of data changes is presented intuitively in a quantitative form, thereby improving the interpretability and decision support capabilities of data analysis. Finally, by introducing risk control rules based on the logical reconciliation of tax returns, invoice data, and financial ledgers, automatic compliance verification of data modification behavior is achieved. Potential financial and tax risks can be identified simultaneously during data adjustment, thereby significantly improving the security, reliability, and audit compliance capabilities of the financial and tax indicator platform.

[0071] In the practical application of the application embodiments, the affected sub-lineage map is: a sub-lineage map composed of all lineage nodes reachable along the downstream lineage edge direction starting from the modified lineage node; or, a map constructed based on the full-link data lineage map using a preset impact analysis strategy.

[0072] For example, in a directly accessible implementation, starting from the modified lineage node, all lineage nodes reachable along downstream lineage edges constitute the affected sub-lineage graph. For instance, in a scenario where "corporate income tax revenue growth rate" is manipulated, if a user modifies the "taxable income field" in a company's tax return, the starting lineage node corresponding to that tax return is the modified lineage node. The influence propagates forward sequentially along downstream dependencies in the lineage graph. For example, it first affects the lineage node whose execution result of the associated operator rule is the summary data of the company's taxable income, then affects the lineage node whose execution result of the associated operator rule is the summary data of regional taxable income, further affects the lineage node whose execution result of the associated operator rule is the total taxable income of the entire region, and finally affects the lineage node whose execution result of the associated operator rule is the corporate income tax revenue growth rate. In this process, all lineage nodes reachable from the modified data are included in the sub-lineage graph. This direct access method allows the determination of the scope of influence to rely entirely on the structured dependencies in the lineage graph. Propagation path identification can be completed without additional modeling or complex calculations, thereby significantly improving the real-time performance and determinism of influence analysis. It is especially suitable for scenarios involving the calculation of fiscal and tax indicators with clear lineage structures and stable dependencies.

[0073] In another implementation based on a preset impact analysis strategy, the affected sub-lineage map is a map constructed based on the full-link data lineage map using the preset impact analysis strategy. The process of constructing the affected sub-lineage map based on the full-link data lineage map using the preset impact analysis strategy includes:

[0074] The bloodline nodes in the full-link data bloodline graph corresponding to the data entity or original data fragment modified by the user are identified as the modified bloodline nodes;

[0075] Add the modified bloodline node to the set of affected bloodline nodes, and use the modified bloodline node as the initial affected bloodline node;

[0076] Starting from the modified lineage node, downstream lineage nodes with data flow dependencies on the modified lineage node are identified layer by layer along the downstream lineage edge direction of the full-link data lineage graph. During the identification process, for each downstream lineage node, the sensitivity coefficient of the downstream lineage node to the output of the preceding lineage node is obtained, and the subsequent lineage node is determined to meet the influence conditions based on the sensitivity coefficient.

[0077] Add downstream bloodline nodes that meet the impact conditions to the set of affected bloodline nodes, and continue to perform the identification and judgment process along the downstream bloodline edge until there are no more downstream bloodline nodes that meet the impact conditions.

[0078] All bloodline nodes in the affected bloodline node set and their connection relationships in the full-link data bloodline map are preserved to construct the affected sub-bloodline map.

[0079] The following is a detailed explanation using a specific example. For instance, in the scenario of analyzing the "corporate income tax revenue growth rate" indicator, if a user modifies the "taxable income field" in a company's tax return, the lineage node corresponding to this field is identified as the modified lineage node and added to the set of affected lineage nodes as the initial affected node.

[0080] Subsequently, the impact path is identified layer by layer along the downstream lineage edge. The first-layer downstream lineage node may be a lineage node whose execution result of the associated operator rule is the summary of the enterprise's taxable income. Its calculation output directly depends on the enterprise's declared data, so its sensitivity coefficient is high. For example, a sensitivity coefficient of 0.9 indicates that this lineage node is highly sensitive to changes in upstream input. Based on the preset impact condition (such as sensitivity coefficient ≥ 0.7), this lineage node is determined to meet the impact condition and is added to the set of affected lineage nodes. Continuing to propagate downstream, a lineage node whose execution result of the associated operator rule is the summary of regional taxable income is identified. This lineage node depends on multiple enterprise data inputs simultaneously, so the impact of changes in data from a single enterprise is diluted, and its sensitivity coefficient may be 0.4. Since the preset threshold condition is not met, this lineage node is not included in the affected set, thus terminating further propagation along this path. Similarly, at higher-level nodes such as the "Regional Taxable Income Summary Node" and the "Income Tax Growth Rate Calculation Node," a lower sensitivity coefficient, such as 0.2 or 0.1, is calculated based on the multi-source input and weight distribution and is also filtered out, thus preventing further expansion of the influence chain.

[0081] Through the above-mentioned layer-by-layer identification and sensitivity determination process, only the set of nodes that have a substantial impact on the modified data is retained, such as the "enterprise taxable income summary node" and its directly dependent nodes, while upper-level lineage nodes with weaker impact or diluted by multi-source data are filtered out, thereby constructing a simplified but semantically accurate affected sub-lineage map.

[0082] Furthermore, after construction, all nodes in the affected lineage node set and their connections in the full-link lineage graph are preserved to form a complete subgraph structure. For example, this subgraph may only contain the critical path of "tax declaration node → enterprise summary node" without globally irrelevant branches, thus forming a targeted impact sub-lineage graph. Because only nodes that meet the impact conditions and their relationship structures are retained, the final sub-lineage graph is more compact and semantically clear, which helps with subsequent local recalculation and risk assessment. Finally, this mechanism can effectively distinguish between "substantial impact nodes" and "weakly related nodes," thereby reducing misjudgments and redundant propagation paths.

[0083] Specifically, in some embodiments of this application, obtaining the sensitivity coefficient of the downstream lineage node to the calculation output of the preceding lineage node, and determining whether the subsequent lineage node meets the influence condition based on the sensitivity coefficient, includes: obtaining the current calculation input and current calculation output corresponding to the downstream lineage node executing its association operator rule, wherein the current calculation input includes at least the calculation output from the preceding lineage node that has a data flow dependency relationship with the downstream lineage node;

[0084] Based on the output of the preceding bloodline node corresponding to the current calculation input, a preset perturbation amount is applied to obtain the perturbed preceding calculation output;

[0085] The perturbed preceding calculation output replaces the corresponding input item in the current calculation input, and the calculation is re-executed based on the operator rules associated with the downstream bloodline node to obtain the perturbed calculation output;

[0086] Based on the degree of difference between the current calculation output and the perturbed calculation output, the sensitivity coefficient of the preceding bloodline node to the downstream bloodline node is determined.

[0087] The degree of difference includes any one or more of the following: the relative rate of change between the current calculation output and the perturbed calculation output; the normalized difference ratio between the current calculation output and the perturbed calculation output on each calculation result item; and the distance metric between the current calculation output and the perturbed calculation output in the vector space.

[0088] When the sensitivity coefficient is greater than or equal to the preset influence threshold, the downstream bloodline node is determined to meet the influence condition and is included in the set of affected bloodline nodes.

[0089] For example, in the calculation chain of "corporate income tax revenue growth rate", the preceding lineage node is the lineage node whose execution result of the associated operator rule is the summary of corporate taxable income, and its output is the total taxable income of enterprises in a certain region in the current period of 1 billion yuan; the downstream lineage node is the lineage node whose execution result of the associated operator rule is the summary of regional taxable income, and its calculation input includes the summary results of multiple enterprises, and further calculates the regional total value. In this embodiment, the current calculation input and output are first obtained. For example, the current output of the lineage node whose execution result of the associated operator rule is the summary of regional taxable income is 5 billion yuan. Then, a preset perturbation amount is applied to the output of the preceding node, for example, adjusting the taxable income of a single enterprise from 100 million yuan to 110 million yuan (perturbation amount is +10%). The perturbed preceding calculation output is replaced by the input item of the downstream node, and the "regional summary operator rule (Σ corporate taxable income)" is re-executed to obtain the perturbed calculation output, for example, 5.01 billion yuan. Next, a difference analysis is performed between the current calculated output of 5 billion yuan and the output after perturbation, which is 5.01 billion yuan. Under the relative change rate calculation method, the change rate is 0.2%; under the normalized difference method, this change represents only a very small proportion of the total; under the vector space distance metric (e.g., vectorizing the revenue of each enterprise), the Euclidean distance change caused by the perturbation is also small. Based on a comprehensive calculation using one or more of the above difference methods, a sensitivity coefficient, for example, 0.15, can be obtained. Further, this sensitivity coefficient is compared with a preset impact threshold (e.g., 0.3). Since 0.15 is less than 0.3, the execution result of the associated operator rule is determined to be that the lineage node of the regional taxable income summary is insensitive to the change of this preceding node, does not meet the impact condition, and is not included in the set of affected lineage nodes, thus terminating the propagation of the impact in this direction.

[0090] In another example, for instance, if the execution result of the associated operator rule is a bloodline node that summarizes the taxable income of an enterprise as a downstream node, since it only depends on the data input of a single enterprise, when the preceding input is disturbed by 10%, its output may change by nearly 10% synchronously. At this time, the sensitivity coefficient may be 0.92, which is significantly higher than the threshold, and thus it is judged as a highly sensitive node and included in the affected set.

[0091] In this embodiment, by introducing a sensitivity calculation mechanism of "perturbation-recalculation-difference measurement," the impact analysis is expanded from static dependency relationship to dynamic function response analysis, thereby accurately characterizing the true impact strength of data input changes on downstream indicators. Secondly, by adopting multi-dimensional difference measurement methods such as relative change rate, normalized difference ratio, and vector space distance, the sensitivity assessment results have stronger robustness and adaptability, avoiding evaluation bias caused by a single indicator. Thirdly, by setting a sensitivity threshold screening mechanism, low-impact propagation paths are effectively filtered out, preventing the disordered diffusion of impact analysis in complex lineage maps, thereby significantly reducing computational complexity.

[0092] In some other embodiments of this application, the method further includes: after generating the modified indicator calculation results, performing compliance backtracking verification on the data calculation and processing steps and their corresponding calculation logic rules of the modified indicator calculation results based on a pre-built and time-versioned snapshot of the tax policy clauses, in order to identify potential compliance risk lineage nodes; wherein, the tax policy clause version snapshot includes historical policy documents and their corresponding clauses; such as corporate income tax policies, value-added tax deduction rules, and R&D expense super-deduction ratio policies for different years, and is structured and stored according to time versions. For example, if a certain R&D expense super-deduction ratio was 75% in 2022 and adjusted to 100% in 2023, the policy rules at different time points are respectively formed into versioned snapshots.

[0093] The compliance backtracking verification includes: obtaining the business occurrence time corresponding to the modified indicator calculation result; matching the target version policy rule corresponding to the business occurrence time from a preset financial and tax policy rule knowledge base; semantically mapping and logically comparing the data processing logic associated with each lineage node in the affected sub-lineage graph with the target version policy rule; and, based on the comparison result, determining whether the execution of the data processing logic conflicts logically with the target version policy rule, and marking the lineage nodes with logical conflicts as potential compliance risk nodes.

[0094] Specifically, in actual implementation, the first step is to obtain the business occurrence time corresponding to the modified indicator calculation result. For example, in the scenario of "corporate income tax payable calculation," if the business occurrence time corresponding to the calculation result of a certain indicator is "2023," this time information can be determined based on the tax return period field or accounting period associated with the starting lineage node in the full-link data lineage graph. Subsequently, based on this business occurrence time, the corresponding target version of the policy rule is matched from the preset financial and tax policy rule knowledge base, such as matching the policy clause "the additional deduction ratio for R&D expenses in 2023 is 100%." ​​Through this step, the policy rule is strictly aligned with the business time, avoiding calculation deviations caused by misusing historical or future policies.

[0095] After matching the target version of the policy rules, the data processing logic associated with each lineage node in the affected sub-lineage graph is semantically mapped and logically compared with the target version of the policy rules. For example, in the affected sub-lineage graph, there is a "R&D expense deduction calculation node", whose corresponding operator rule is "deduction amount = R&D expense × 75%". Through semantic parsing technology, the "75%" in this operator rule is identified as a policy parameter and mapped and compared with "100%" in the target version of the policy rules, thereby identifying the difference in logical meaning between the two.

[0096] Furthermore, after completing the semantic mapping and logical comparison, the system determines whether the execution of the data processing logic conflicts logically with the target version of the policy rules based on the comparison results. For example, in the above scenario, since the lineage node still uses the historical rule of "75%" while the current applicable policy is "100%", the node is determined to have a logical conflict and is marked as a lineage node with potential compliance risks. Similarly, in the VAT scenario, if the operator rule corresponding to a lineage node is "input tax cannot be fully deducted", while the current policy has been adjusted to "qualified input tax can be fully deducted", the node will also be identified as having a policy conflict and marked.

[0097] Furthermore, in more complex scenarios, such as "intertemporal indicator calculation" or "multiple policy overlays," different time versions of policy rules can be matched for different lineage nodes. For example, when calculating the "revenue growth rate" indicator, which involves "2023 revenue" and "2022 revenue," the corresponding policy versions for 2023 and 2022 can be matched respectively, and the calculation logic for different time intervals can be verified for compliance, thereby achieving more refined policy adaptation. By constructing a snapshot of fiscal and tax policy clauses managed by time version, the indicator calculation can automatically match the policy rules corresponding to the time of business occurrence, ensuring the timeliness and legality of the calculation logic from the source. Secondly, by semantically mapping and logically comparing the operator rules of lineage nodes with policy clauses, automatic compliance review of the calculation logic can be achieved, which can not only determine whether the calculation is correct, but also whether the calculation is compliant. Thirdly, by accurately marking lineage nodes with logical conflicts, risks can be located to specific calculation steps and specific rule parameters, thereby significantly reducing the cost of manual investigation and improving the efficiency of problem location.

[0098] In one embodiment, the method of this application further includes: comparing the deviation between the calculated output of each lineage node and the expected value; when the deviation exceeds a preset threshold, marking the corresponding lineage node as an abnormal node, and outputting the abnormal node and its associated operator rules. In this way, anomaly detection is moved from the traditional "result anomaly judgment" to "calculation process node level judgment", thereby enabling early identification of anomaly sources in the indicator generation chain and improving the accuracy and efficiency of anomaly localization.

[0099] Specifically, in the end-to-end data lineage graph, each lineage node generates a corresponding calculation output after executing its associated operator rule. For example, a lineage node whose execution result of the associated operator rule is the summary of the company's taxable income, or a lineage node whose execution result of the associated operator rule is the summary of invoice amounts, all have clear calculation results. In this embodiment, corresponding expected values ​​are pre-built or dynamically generated for each lineage node. These expected values ​​can come from historical statistical models, rule derivation results, industry benchmark values, or cross-data source verification results. For example, in the "corporate income tax revenue growth rate" analysis scenario, for a lineage node whose execution result of the associated operator rule is the summary of the company's taxable income, an expected value can be generated based on historical data from the same period. For example, "the company's taxable income in 2022 was 10 million yuan, combined with the industry average growth rate of 10%", then the expected taxable income in 2023 is approximately 11 million yuan. When the actual calculated output is 16 million yuan, the calculation deviation ratio is approximately 45%. If the preset deviation threshold is 20%, the lineage node is determined to be abnormal, and the lineage node whose execution result of the associated operator rule is the summary of the enterprise's taxable income is marked as an abnormal node.

[0100] Furthermore, in more complex links, deviation detection can be performed level by level on multi-layered lineage nodes. For example, in lineage nodes where the execution result of the associated operator rule is a summary of regional income, if some of the lower-level lineage nodes have already been marked as anomalous, the anomalousness of the lineage node where the execution result of the associated operator rule is a summary of regional income can be further analyzed using weighted analysis to determine whether it originated from a local anomalous propagation, thereby assisting in determining the anomalous propagation path.

[0101] This embodiment introduces a "compare calculated output with expected value deviation" mechanism at the lineage node level, shifting anomaly detection from the final indicator result to the intermediate calculation stage. This allows for earlier identification of anomaly sources, preventing anomalies from being amplified or masked in multi-layered calculations. Secondly, by outputting corresponding operator rules for each lineage node, anomalies are not only "discoverable" but also "explainable," significantly improving interpretability and auditability. Thirdly, by combining multi-source data (such as tax returns, invoice data, and financial ledgers) for expected value construction and cross-validation, anomaly identification becomes more accurate and robust. Finally, this mechanism can work in conjunction with the full-link data lineage graph to achieve integrated analysis of "anomaly node location + computational logic tracing," significantly improving the efficiency and accuracy of locating the source of anomalies in financial and tax indicators and reducing manual investigation costs. Additionally, this embodiment also provides an indicator platform, including a memory and a processor. The memory and processor are communicatively connected. The memory stores computer instructions, and the processor executes these instructions to perform the anomaly source location method for the indicator platform based on the financial and tax field described in the above embodiment.

[0102] In summary, the method for locating the source of anomalies in a financial and tax-related indicator platform provided in this application obtains a pre-established full-link data lineage graph corresponding to the identifier of the target indicator report upon receiving a user's query instruction for the target indicator report. Based on the full-link data lineage graph, it obtains the indicator calculation results corresponding to different dimensions, maps each data calculation and processing step in the preset calculation logic rules corresponding to the target indicator report to lineage nodes, and maps the data flow dependencies between each data calculation and processing step to lineage edges. This constructs a structured and traceable full-link data lineage graph, enabling the explicit expression of the sequential constraints formed by data transmission between each data calculation and processing step. This effectively breaks the "black box" problem of the traditional indicator calculation process, realizes an interpretable association between the indicator results and the calculation process, and fundamentally improves the transparency and traceability of the indicator calculation process.

[0103] Based on this, upon receiving a first penetration query instruction for performing first-level data penetration on the indicator calculation results of any dimension in the displayed results, the corresponding first-level penetration result is obtained. By traversing the entire data lineage graph in reverse to locate intermediate lineage nodes, the data entity generated by the operator rules executed by the lineage node and its storage index are obtained, enabling users to quickly locate the intermediate calculation link and its data source from the indicator results. Furthermore, by receiving a second penetration query instruction, the system recursively traces back to the starting lineage node to obtain the original data fragments actually used in the calculation process, realizing layer-by-layer penetration from indicator results to original data. This constructs a full-link data traceability system of "indicator results - intermediate calculation nodes - original data fragments", significantly improving the precision and accuracy of anomaly source location. Meanwhile, by receiving user modification instructions for any data entity or original data fragment, the corresponding lineage node is used as the modification lineage node, and the affected sub-lineage graph is identified along the downstream lineage edge direction of the full-link data lineage graph. Local recalculation is performed on the lineage nodes in the affected sub-lineage graph to generate modified index calculation results. By comparing the index calculation results before and after the modification, a risk impact assessment report containing numerical differences and compliance warning prompts is generated. This enables data modification to trigger impact propagation analysis and risk assessment based on lineage relationships, thereby avoiding the performance bottleneck problem caused by traditional full recalculation and effectively improving computing efficiency and response capability. Furthermore, by limiting the affected sub-lineage map to the set of lineage nodes reachable along the downstream lineage edge, or the map constructed based on a preset influence analysis strategy, and introducing a sensitivity coefficient determination mechanism during the influence propagation process, the sensitivity coefficient is determined based on the degree of difference by perturbing the calculated output of the preceding lineage nodes and recalculating the output of the downstream nodes. This effectively suppresses the ineffective propagation of low-influence paths, reduces redundant calculations, and improves the accuracy and controllability of influence analysis by retaining only the lineage nodes that meet the influence conditions.

[0104] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make modifications, alterations, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for locating the source of anomalies in an indicator platform based on the financial and tax field, characterized in that, include: Upon receiving a user's query instruction for a target indicator report, the system obtains a pre-established end-to-end data lineage map corresponding to the target indicator report identifier carried in the query instruction, and obtains the display results corresponding to the target indicator report based on the end-to-end data lineage map. Specifically, the data calculation and processing steps in the preset calculation logic rules corresponding to the target indicator report are mapped to lineage nodes in advance, and the data flow dependency relationship between each data calculation and processing step is mapped to lineage edge, thereby constructing the full-link data lineage graph; the data flow dependency relationship is the sequential constraint relationship formed between different data calculation and processing steps based on data transmission in the calculation logic rules, wherein the calculation result of the previous data calculation and processing step is used as the input data of the next data calculation and processing step; Each lineage node in the full-link data lineage graph is used to represent the corresponding data calculation and processing step, and is associated with the operator rule for executing the data calculation and processing step; the starting lineage node of the full-link data lineage graph is associated with the pre-acquired raw data and the type label corresponding to the raw data; The displayed results are the result of the full-link data lineage map, which is based on the original data associated with the starting lineage node, and executes each data calculation and processing step in sequence according to the data flow dependency relationship to obtain the corresponding indicator calculation results of different dimensions.

2. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 1, characterized in that, The method further includes: Upon receiving a first penetration query instruction representing the first level of data penetration for the indicator calculation results of any dimension in the displayed results, the first level of penetration result for that dimension is obtained; The first layer penetration result includes the data entity and / or the storage index of the data entity obtained by executing the operator rule associated with the intermediate bloodline node in the full-link data bloodline graph corresponding to the index calculation result of the dimension, as well as the operator rule for calculating the data entity. The data entities mentioned include tax returns, invoice data or financial ledger data, and business registration data.

3. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 2, characterized in that, The method further includes: Upon receiving a second penetration query instruction representing a second-level data penetration of any data entity and / or the index of that data entity in the first-level penetration result, the second-level penetration result is obtained; The second layer penetration result includes: original data fragments in the original data associated with the starting lineage node for calculating the full-link data lineage map of the data entity, wherein the original data fragments are the original data actually used in the process of calculating the data entity.

4. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 3, characterized in that, The process of obtaining the first layer of penetration results for this dimension includes: The corresponding lineage node in the full-link data lineage map is determined as the target lineage node based on the index calculation results of the aforementioned dimension. Starting from the target lineage node, traverse in reverse along the lineage edges of the full-link data lineage graph to obtain upstream lineage nodes that have data flow dependencies with the target lineage node, until the starting lineage node is reached. During the traversal, for each lineage node, the following are recorded: the computational input determined by the data flow dependency relationship between adjacent lineage nodes in the full-link data lineage graph, the computational output obtained by executing the operator rule corresponding to the lineage node, the operator rule associated with the lineage node, and the timestamp information of the execution based on the operator rule corresponding to the lineage node. Each bloodline node obtained through traversal is divided into levels according to its bloodline level distance from the target bloodline node; The calculation output and its operator rules corresponding to the upper-level bloodline node whose bloodline level distance from the target bloodline node is the first layer are determined as the data entity and its operator rules in the first layer penetration result.

5. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 4, characterized in that, The process of obtaining the second-layer penetration result includes: The bloodline node corresponding to any data entity and / or the storage index of the data entity in the first layer penetration result is determined as the target intermediate bloodline node; Starting from the target intermediate bloodline node, recursively trace back along the bloodline edge direction of the full-link data bloodline graph to identify all upstream bloodline nodes that directly or indirectly contribute to the calculation output of the target intermediate bloodline node, until the starting bloodline node is reached. Based on the recursive reverse tracing process along the bloodline edges of the full-link data lineage graph, the original data fragments in the process of calculating the target data entity are determined. The original data fragments are the original data that participated in the generation of the data entity from the original data associated with the starting bloodline node of the full-link data lineage graph, and the original data fragments are used as the second layer penetration result. The original data includes tax returns, invoice data or financial ledger data, and business registration data.

6. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 5, characterized in that, The method further includes: Receive user's modification instruction for any data entity or original data fragment. Based on the modification instruction, take the lineage node corresponding to the modified data entity or original data fragment as the modified lineage node, and identify the affected sub-lineage graph from the modified lineage node along the downstream lineage edge direction of the full-link data lineage graph. Local recalculation is performed on the bloodline nodes in the affected sub-bloodline map to generate modified index calculation results; The calculation results of the indicators before and after the modification are compared to generate a risk impact assessment report, which includes the numerical differences in the indicator calculation results and compliance warning prompts. The numerical differences include the difference and the percentage change between the target indicator values ​​before and after the modification; The compliance warning is a prompt message generated based on preset financial and tax risk control rules, which are used to determine the threshold of the numerical differences or to match them according to preset rules. The financial and tax risk control rules include at least one of the consistency verification rules between tax return forms and invoice data and the logical reconciliation rules between financial ledgers and declaration data.

7. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 6, characterized in that, The affected sub-lineage map is: a sub-lineage map formed by all lineage nodes reachable along the downstream lineage edge starting from the modified lineage node; or, a map constructed based on the full-link data lineage map using a preset impact analysis strategy. The process of constructing the affected sub-lineage map based on the full-link data lineage map using a preset impact analysis strategy includes: The bloodline nodes in the full-link data bloodline graph corresponding to the data entity or original data fragment modified by the user are identified as the modified bloodline nodes; Add the modified bloodline node to the set of affected bloodline nodes, and use the modified bloodline node as the initial affected bloodline node; Starting from the modified lineage node, downstream lineage nodes with data flow dependencies on the modified lineage node are identified layer by layer along the downstream lineage edge direction of the full-link data lineage graph. During the identification process, for each downstream lineage node, the sensitivity coefficient of the downstream lineage node to the output of the preceding lineage node is obtained, and the subsequent lineage node is determined to meet the influence conditions based on the sensitivity coefficient. Add downstream bloodline nodes that meet the impact conditions to the set of affected bloodline nodes, and continue to perform the identification and judgment process along the downstream bloodline edge until there are no more downstream bloodline nodes that meet the impact conditions. All bloodline nodes in the affected bloodline node set and their connection relationships in the full-link data bloodline map are preserved to construct the affected sub-bloodline map.

8. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 7, characterized in that, Obtain the sensitivity coefficient of the downstream kinship node to the output of the preceding kinship node, and determine whether the subsequent kinship node meets the influence conditions based on the sensitivity coefficient, including: Obtain the current computational input and current computational output corresponding to the execution of the association operator rule of the downstream lineage node, wherein the current computational input includes at least the computational output from the preceding lineage node that has a data flow dependency relationship with the downstream lineage node; Based on the output of the preceding bloodline node corresponding to the current calculation input, a preset perturbation amount is applied to obtain the perturbed preceding calculation output; The perturbed preceding calculation output replaces the corresponding input item in the current calculation input, and the calculation is re-executed based on the operator rules associated with the downstream bloodline node to obtain the perturbed calculation output; Based on the degree of difference between the current calculation output and the perturbed calculation output, the sensitivity coefficient of the preceding bloodline node to the downstream bloodline node is determined. The degree of difference includes any one or more of the following: The relative rate of change between the current calculated output and the calculated output after the disturbance; The normalized difference ratio between the current calculation output and the perturbed calculation output in each calculation result item; The distance metric between the current calculation output and the perturbed calculation output in the vector space; When the sensitivity coefficient is greater than or equal to the preset influence threshold, the downstream bloodline node is determined to meet the influence condition and is included in the set of affected bloodline nodes.

9. The method for locating the source of anomalies in an indicator platform based on the financial and tax field according to claim 7, characterized in that, The method further includes: after generating the modified indicator calculation results, performing compliance backtracking verification on the data calculation and processing steps and their corresponding calculation logic rules of the modified indicator calculation results based on a pre-built and time-versioned snapshot of the fiscal and tax policy clauses, in order to identify potential compliance risk lineage nodes; wherein, the snapshot of the fiscal and tax policy clauses includes historical policy documents and their corresponding clauses; The compliance backtracking verification includes: obtaining the business occurrence time corresponding to the modified indicator calculation result, and matching the target version policy rule corresponding to the business occurrence time from the preset financial and tax policy rule knowledge base; The data processing logic associated with each bloodline node in the affected sub-bloodline graph is semantically mapped and logically compared with the target version policy rules; Based on the comparison results, it is determined whether the execution of the data processing logic conflicts with the target version policy rules, and the related nodes with logical conflicts are marked as potential compliance risk nodes.

10. An indicator platform, characterized in that, The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to perform the method for locating the source of anomalies in an indicator platform based on the financial and tax field, as described in any one of claims 1-9.

Images