An agent-assisted accounting and data analysis method

CN122989337APending Publication Date: 2026-10-27JIANGSU GUOXIN DIGITAL INTELLIGENCE SERVICE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611452186.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-09-18
Publication Date
2026-10-27

AI Technical Summary

Technical Problem

[0003]现有财务辅助核算与数据分析技术存在局限,首先辅助维度与会计科目的关联固化,多数仅支持预设的固定维度关联,无法根据动态业务需求灵活调整关联规则,适配性差;其次业务标记赋予缺乏智能性,要么依赖人工手动标注,要么仅通过简单字段匹配,未结合业务实体的财务属性进行深度匹配,易出现标记错误,且缺乏对标记准确性的异常判断机制;而且数据处理与分析滞后,核算数据的汇总和分析多在事后批量进行,无法实时将新增核算数据纳入分析体系,难以满足业务对实时财务数据支持的需求

Benefits of technology

[0037]与现有技术相比,本申请的有益效果是:通过接收用户配置的业务标记维度与标记值,建立业务标记维度与会计科目的关联规则,并基于财务属性的相似度建立业务实体与标记值的映射规则,形成业务标记规则;使业务标记规则可随业务变化灵活调整,提升财务核算对业务场景的适配性;通过自然语言处理解析原始业务单据,自动识别业务实体与财务属性,无需人工逐单处理,同时与业务标记规则进行匹配,为财务分录自动赋予业务标记并计算标记置信度,不仅提升标记效率,还提前识别标记异常,降低财务数据分类错误的风险。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122989337A_ABST
    Figure CN122989337A_ABST
Patent Text Reader

Abstract

The application relates to the technical field of data processing, and provides an agent-assisted accounting and data analysis method, which comprises the following steps: receiving a business marking dimension and a marking value configured by a user, establishing a correlation rule and a mapping rule to form a business marking rule; analyzing original business documents through natural language processing, automatically identifying business entities and financial attributes, and matching the business marking rule to automatically assign business marks to financial entries and calculate marking confidence, thereby reducing the risk of financial data classification errors; generating accounting vouchers and voucher identifiers through parallel processing, associating accounting data and voucher identifiers to construct business fact records; capturing newly added business fact records through flow processing, injecting data cubes in real time based on incremental aggregation rules, supporting drilling analysis based on any combination of business marking dimensions, and outputting analysis results containing abnormal marks to provide timely and reliable data support for management decisions.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an agent-assisted accounting and data analysis method. Background Technology

[0002] Early financial accounting relied on manual annotation of accounting items, which was inefficient and prone to errors. Later, tools such as ERP and financial software emerged, enabling the correlation between accounting items and fixed dimensions, which improved efficiency to some extent. In recent years, some companies have introduced data analysis tools to try to summarize and analyze accounting data, but this has mostly remained at the level of batch processing after accounting is completed, and the integration with business scenarios is low.

[0003] Existing financial auxiliary accounting and data analysis technologies have limitations. First, the association between auxiliary dimensions and accounting subjects is fixed, and most only support preset fixed dimension associations, making it impossible to flexibly adjust association rules according to dynamic business needs, resulting in poor adaptability. Second, the assignment of business tags lacks intelligence, either relying on manual annotation or simply using simple field matching without combining the financial attributes of business entities for in-depth matching, which easily leads to tagging errors and lacks anomaly judgment mechanisms for tagging accuracy. Moreover, data processing and analysis are lagging behind, with the aggregation and analysis of accounting data mostly carried out in batches after the fact, making it impossible to incorporate newly added accounting data into the analysis system in real time, which is insufficient to meet the business's need for real-time financial data support.

[0004] Given the shortcomings of the existing technology, the technical problem to be solved in this application is how to break through the rigidity of accounting dimensions in order to achieve a close connection and real-time processing of financial auxiliary accounting and data analysis. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides an intelligent agent-assisted accounting and data analysis method. The method includes: receiving a user-configured business tag dimension and corresponding tag value; establishing association rules between the business tag dimension and accounting subjects; and establishing mapping rules between business entities and tag values ​​based on the similarity of financial attributes to form business tag rules.

[0006] Receive original business documents, parse the text in the original business documents through natural language processing to identify business entities and financial attributes, match them with business tagging rules, automatically assign business tags to financial entries, calculate tag confidence and compare them with preset thresholds to judge abnormal tags, and output accounting data after confirmation.

[0007] Parallel processing of accounting data generates accounting vouchers and voucher identifiers. After associating accounting data with voucher identifiers, business fact records are constructed. New business fact records are captured through stream processing. Based on incremental aggregation rules, the new records are processed and injected into the data cube in real time.

[0008] Responding to user query requests for data cubes, it performs drill-down analysis based on any combination of business tag dimensions and outputs analysis results with anomaly tags. Responding to source tracing instructions for specific data points, it traces back accounting vouchers and business entities based on associated voucher identifiers.

[0009] As an optional implementation, the business tagging rules include:

[0010] Extract the financial attributes of business entities, assign priority weights to the financial attributes according to accounting standards and business rules, and set attribute similarity thresholds for different types of business entities;

[0011] The similarity threshold is automatically calibrated based on historical matching accuracy. The similarity between the financial attributes of the business entity and the financial attributes corresponding to the tag value is calculated. After being weighted and summed based on priority weights, it is compared with the calibrated similarity threshold to form a mapping rule between the business entity and the tag value.

[0012] By calculating the rule matching rate and anomaly identification rate through historical financial accounting records, the associated rules and mapping rules are validated. Rules that fail the validation are triggered for manual review, and the risk adaptation weight or attribute similarity threshold is automatically optimized based on the review results to form automatically iterative business marking rules.

[0013] As an optional implementation, establishing the association rules includes:

[0014] Receive the business tag dimensions and corresponding tag values ​​configured by the user, and divide the business tag dimensions into basic accounting dimensions and dynamic business dimensions according to accounting requirements;

[0015] Extract accounting attributes from accounting subjects, including accounting scope and risk level; establish fixed association rules between basic accounting dimensions and accounting subjects within the accounting scope; and set modification constraints for the fixed association rules according to the risk level.

[0016] By combining the validity period and business stage of dynamic business dimensions with the business lifecycle, the number of dynamic business dimensions to be bound is determined according to the risk level. After matching the business stage, conditional association rules between dynamic business dimensions and accounting subjects are established, and risk adaptation weights are configured for each conditional association rule.

[0017] As an optional implementation, the output accounting data includes:

[0018] Based on the automatically assigned basic business tags and dynamic business tags, the confidence scores of matching accuracy, rule validity, and business compliance are calculated respectively, and then weighted and summed to obtain the tag confidence score.

[0019] Based on the risk level, a preset threshold is set, and the confidence level of the label is compared with the preset threshold to determine whether it is a normal label, a low-risk anomaly, or a high-risk anomaly. When the dynamic business dimension expires, it is determined to be a high-risk anomaly.

[0020] When a low-risk anomaly occurs, it is automatically confirmed by comparing the markings of similar historical documents. If the comparison is consistent, it is calibrated to a normal marking. When a high-risk anomaly occurs, the business marking assignment process is traced back and the original business documents are checked and confirmed.

[0021] If the exception flag fails to pass the confirmation, return to the business flag assignment process, generate a verification flag for the confirmed business flag, bind it with the financial entry, and output the accounting data with the verification flag.

[0022] As an optional implementation, automatically assigning the service tag includes:

[0023] Receive original business documents, parse the text in the original business documents through natural language processing, identify business entities and financial attributes, match the accounting scope of accounting subjects based on the identified financial attributes, and call the business marking rules within the accounting scope.

[0024] Match the financial attributes with the financial attributes corresponding to the tag values ​​of the basic accounting dimensions. If they match, assign a basic business tag. If they do not match, trigger an error message about the basic accounting dimension matching.

[0025] Based on risk-adaptive weights, the financial attributes corresponding to the labeled values ​​of financial attributes and dynamic business dimensions are summed with similarity weights. When the summation result is not less than the result threshold, a dynamic business label is assigned.

[0026] Associate the basic business tags and dynamic business tags with the auxiliary accounting fields of the financial entries respectively, and generate and output the financial entries with auxiliary accounting tags.

[0027] As an optional implementation, the real-time injected data cube includes:

[0028] Initialize the stream processing channel, identify new business fact records based on voucher identifiers, and configure a capture trigger mechanism in conjunction with the accounting cycle to capture new business fact records;

[0029] The newly captured records are checked for integrity. If they are incomplete, they are recaptured. If they are complete, the dimension codes and verification levels in the new records are parsed. The target level is assigned based on the hierarchical structure of the data cube adapted to the dimension codes.

[0030] The incremental aggregation rules are invoked based on the validity period of the verification level and dynamic business dimension to process new records, generating incremental aggregation results and enhanced aggregation results with voucher identifiers;

[0031] Partitions are created in the data cube based on the target level. Incremental aggregation results are injected into fixed-dimensional partitions, and enhanced aggregation results are injected into variable-dimensional partitions. During the injection process, the consistency between the dimension encoding and the target level is checked. If there is a discrepancy, the injection is paused and the adaptation relationship of the target level is updated.

[0032] Generate a version identifier for the injected aggregation result, associate it with the partition of the data cube, and record the credential identifier of the corresponding business fact record.

[0033] As an optional implementation, the construction of the business fact record includes:

[0034] Receive accounting data with verification marks, generate accounting vouchers including voucher identifiers based on the accounting attributes of accounting subjects and accounting standards, and simultaneously parse the dimension code of business marks and the verification level of verification marks in the accounting data;

[0035] Using the voucher identifier as the link, the dimension code and verification level are embedded into the additional information of the accounting voucher, and the verification mark in the accounting data and the document number of the original business document are linked to verify the consistency between the dimension code and the accounting scope. If they are inconsistent, they are re-linked.

[0036] Integrate accounting vouchers, voucher identifiers, associated dimension codes, verification levels, verification marks, and original business document document numbers to construct a business fact record.

[0037] Compared with existing technologies, the beneficial effects of this application are as follows: by receiving the business tag dimensions and tag values ​​configured by the user, association rules between business tag dimensions and accounting subjects are established, and mapping rules between business entities and tag values ​​are established based on the similarity of financial attributes, thus forming business tag rules; the business tag rules can be flexibly adjusted according to business changes, improving the adaptability of financial accounting to business scenarios; by parsing the original business documents through natural language processing, business entities and financial attributes are automatically identified without manual processing of each document, and at the same time, they are matched with the business tag rules to automatically assign business tags to financial entries and calculate tag confidence, which not only improves tagging efficiency but also identifies tagging anomalies in advance, reducing the risk of financial data classification errors.

[0038] By generating accounting vouchers and voucher identifiers through parallel processing, and linking accounting data and voucher identifiers to construct business fact records, subsequent reverse tracing can be performed based on voucher identifiers and version identifiers, tracing back from the analysis results of the data cube to accounting vouchers, original business documents, and the business marking rules at the time. This meets the data traceability requirements of auditing and compliance verification, ensuring the authenticity and compliance of financial data. Newly added business fact records are captured through stream processing and injected into the data cube in real time based on incremental aggregation rules. It also supports drill-down analysis based on any combination of business marking dimensions, and can quickly output analysis results with anomaly markers. This makes the process of financial data from accounting to analysis real-time, and can meet the business's needs for multi-dimensional and precise financial analysis, providing timely and reliable data support for management decisions. Attached Figure Description

[0039] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0040] Figure 1 This is a flowchart of an agent-assisted accounting and data analysis method provided in an embodiment of this application;

[0041] Figure 2 The flowchart illustrates the automatic assignment of business tags in an agent-assisted accounting and data analysis method provided in this application embodiment.

[0042] Figure 3 The flowchart illustrates the real-time injection of a data cube in an agent-assisted accounting and data analysis method provided in this application embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0044] like Figure 1 The diagram shown is a flowchart of an agent-assisted accounting and data analysis method provided in this application embodiment. The method includes:

[0045] S1. Receive the business tag dimensions and corresponding tag values ​​configured by the user, establish the association rules between the business tag dimensions and accounting subjects, and establish the mapping rules between business entities and tag values ​​based on the similarity of financial attributes, thus forming business tag rules.

[0046] Furthermore, establishing association rules includes:

[0047] Receive the business tag dimensions and corresponding tag values ​​configured by the user, and divide the business tag dimensions into basic accounting dimensions and dynamic business dimensions according to accounting requirements;

[0048] Extract accounting attributes from accounting subjects, including accounting scope and risk level; establish fixed association rules between basic accounting dimensions and accounting subjects within the accounting scope; and set modification constraints for the fixed association rules according to the risk level.

[0049] By combining the validity period and business stage of dynamic business dimensions with the business lifecycle, the number of dynamic business dimensions to be bound is determined according to the risk level. After matching the business stage, conditional association rules between dynamic business dimensions and accounting subjects are established, and risk adaptation weights are configured for each conditional association rule.

[0050] In financial accounting, some dimensions are fixed elements mandated by accounting standards, including the accounting entity and expense type, which need to remain stable over the long term to ensure consistent accounting standards. Other dimensions change dynamically with business scenarios, including R&D project stages and supplier cooperation levels, and need to be adjusted according to the business lifecycle to adapt to actual needs. Failure to differentiate between dimension types can lead to inaccuracies in fixed dimensions due to frequent modifications, or inflexible management of dynamic dimensions that fail to respond to business changes. This system receives user-configured business tag dimensions and corresponding tag values. Based on the mandatory provisions of existing enterprise accounting standards regarding auxiliary accounting, it derives accounting requirements and calculates the recent additions, deletions, and modifications of business tag dimensions (historical change frequency). According to accounting requirements, business tag dimensions are divided into basic accounting dimensions and dynamic business dimensions, which can be combined with historical change frequency. If classified as basic accounting dimensions, the permissions for deleting dimensions and modifying tag values ​​are automatically locked, and only the super administrator can apply to unlock them.

[0051] If categorized as a dynamic business dimension, permissions for adding and deactivating tag values ​​are granted, and the business lifecycle is automatically associated for subsequent expiration labeling. After the business tag dimension is categorized, a report is generated that includes the classification criteria for each business tag dimension. Once the user confirms that everything is correct, the business tag dimension type and permission configuration are synchronized to subsequent association rules. The classification logic based on guidelines and change frequency ensures that the business tag dimension type categorization is compliant and meets actual management needs. Permission locking prevents the basic accounting dimensions from being mistakenly modified, provides a clear type identifier for the subsequent establishment of association rules, and allows subsequent processing to automatically read the type of the business tag dimension, avoiding mismatches between association rule configuration and dimension attributes.

[0052] The basic accounting dimension directly determines the accounting direction of accounting subjects. Incorrect association can lead to distorted financial data classification. If the dimension association rules of high-risk subjects are arbitrarily modified, it can trigger risks such as misappropriation of funds and accounting fraud. Strict constraints are needed to ensure the seriousness of the association rules. The system automatically reads the metadata of accounting subjects, including subject codes, accounting scope, and risk levels. The risk level is automatically marked according to the scale of funds involved in the accounting subject and regulatory requirements. Users can adjust it according to the actual situation of the enterprise and submit an adjustment explanation. After the user selects the basic accounting dimension, the system automatically loads all the tag values ​​of that dimension and the list of accounting subjects that match the accounting scope of the dimension to establish fixed association rules. The user selects the associated accounting subjects for each tag value and sets mandatory / optional attributes. When the fixed association rule is saved, a unique rule code is automatically generated, and the dimension code, tag value, subject code, and mandatory attributes are stored in the association rule.

[0053] Modification constraints for fixed association rules are set according to different risk levels. Modifications to fixed association rules for low-risk accounts require approval from the finance manager; modifications to fixed association rules for medium-risk accounts require approval from both the finance manager and finance director; and modifications to fixed association rules for high-risk accounts require approval from four levels: finance manager, finance director, finance director, and internal control specialist. All modifications are logged in the rule change log, recording the modifier, time, previous and subsequent content, and approval node comments. The log cannot be deleted or modified and is synchronously backed up to the enterprise's private cloud storage. The extraction of accounting attributes ensures the compliance of the association between accounts and dimensions. The construction of fixed association rules achieves precise binding between basic dimensions and accounts. The hierarchical modification constraints reduce the risk of changes to fixed association rules for high-risk accounts through multi-node approval and tamper-proof logs. It also defines the basic boundaries for conditional association rules for dynamic business dimensions, meaning that conditional association rules cannot exceed the account association scope of fixed association rules. At the same time, it provides the basis for the association between accounting accounts and business tag dimensions when matching tag values ​​for subsequent business entities.

[0054] The validity of dynamic business dimensions changes with the business lifecycle. For example, the testing period in a research and development project only becomes effective after the project is completed. If an expiration date is not marked, expired dimensions will still be used for accounting purposes, such as expenses still being recorded as R&D expenditures after project completion. The accounting treatment differs for different business stages. For example, procurement costs for suppliers with strategic-level cooperation can enjoy discounts and amortization. Applicable scenarios need to be distinguished through conditional rules. Dimension matching for high-risk businesses needs to be more stringent, and the impact of key dimensions needs to be strengthened through weight adjustments. The system integrates with business systems such as enterprise project management systems and supply chain management systems to automatically synchronize business data and mark the attributes of dynamic business dimensions. Taking the R&D project stage as an example, project nodes are obtained from the project management system, including project approval, R&D initiation, testing completion, and project completion. The system automatically marks each project node with the corresponding business stage name and validity period. The validity period can be adjusted by the user based on the actual business situation and submitted to the business department for explanation. At the same time, a validity period warning is set. When there are only 15 days left before the expiration of a business stage, a message warning is sent to the business manager and the finance manager to remind them to update or deactivate the dimension.

[0055] The number of dynamic business dimensions that can be bound is determined based on the risk level. High-risk subjects are allowed to be bound to 3 dynamic business dimensions, medium-risk subjects are allowed to be bound to 2, and low-risk subjects are allowed to be bound to 1. Users can adjust the number of bound dimensions according to the complexity of their business and submit an adjustment application explaining the reasons. After the adjustment, the upper limit of the number of dynamic business dimensions bound to a subject will be automatically updated. After selecting the dynamic business dimension and associated subject, the user sets the rule trigger conditions. The user can select fields such as business stage, validity period, and business status to construct the condition expression. For example, R&D project stage = R&D period AND project status = normal execution. After the conditions are set, other dynamic business dimensions that can be associated are automatically loaded. The user selects the allowed tag values ​​for each dynamic business dimension. When the rule is saved, a unique code is generated and the condition expression is stored in the condition association rule.

[0056] This feature displays all dynamic business dimensions associated with the current conditional association rule. Users assign risk adaptation weights based on the impact of these dynamic business dimensions on account calculations, and the system verifies in real time whether the total risk adaptation weights equal 1. If not, it prompts for adjustment and automatically distributes the remaining weights evenly. Once the risk adaptation weights are configured, they are associated with the conditional association rule code for synchronized updates as the rule is adjusted. Business lifecycle annotations prevent expired dynamic business dimensions from interfering with accounting, and the number of bound dimensions is controlled to prevent excessive dimensions from complicating accounting. Conditional association rules achieve precise matching of business scenarios, accounts, and dimensions, and differentiated risk adaptation weight settings ensure that high-impact dimensions play a dominant role in the matching process.

[0057] Specifically, the rules for forming business tags include:

[0058] Extract the financial attributes of business entities, assign priority weights to the financial attributes according to accounting standards and business rules, and set attribute similarity thresholds for different types of business entities;

[0059] The similarity threshold is automatically calibrated based on historical matching accuracy. The similarity between the financial attributes of the business entity and the financial attributes corresponding to the tag value is calculated. After being weighted and summed based on priority weights, it is compared with the calibrated similarity threshold to form a mapping rule between the business entity and the tag value.

[0060] By calculating the rule matching rate and anomaly identification rate through historical financial accounting records, the associated rules and mapping rules are validated. Rules that fail the validation are triggered for manual review, and the risk adaptation weight or attribute similarity threshold is automatically optimized based on the review results to form business marking rules that can be automatically iterated.

[0061] The importance of financial attributes of business entities to tag value matching varies. For example, a supplier's credit rating directly affects cooperation risk, while the registered address only affects tax jurisdiction. If priorities are not distinguished, key attributes will be diluted by secondary attributes. For example, a high-quality supplier may be misjudged due to a mismatch in registered address. Different types of entities have different management objectives, requiring differentiated setting of attribute similarity thresholds to adapt to the objectives. Extracting the financial attributes of business entities involves two aspects. First, it involves connecting to the databases of ERP systems, supplier management systems, and customer management systems to read structured fields such as registered capital, credit rating, and payment cycle, and automatically establishing a mapping relationship between business entities and financial attribute values. Second, it involves extracting text content from unstructured documents such as audit reports and cooperation agreements using OCR technology, then using natural language processing to parse keywords, including good financial health and no default records, and converting keywords into financial attributes.

[0062] Priority weights are assigned to financial attributes based on accounting standards and business rules. The emphasis on customer credit risk in accounting standards prioritizes customer payment records over other auxiliary attributes. Conversely, the emphasis on budget compliance in R&D projects prioritizes project-scale-related attributes over those related to project size, reflecting the actual business focus. Attribute similarity thresholds are set for different types of business entities. For supplier types, a stricter threshold is recommended by default, as suppliers require strict risk control. For customer types, a more lenient threshold is recommended by default, as customers need to balance expansion and risk. Users can adjust the threshold based on their enterprise risk tolerance. The similarity threshold for attributes is adjusted based on capabilities and business strategies, and then associated with the entity type. Financial attribute extraction uses a combination of structured and unstructured methods to ensure comprehensive attributes and avoid matching errors caused by chaotic attribute formats. The allocation of priority weights ensures that key financial attributes play a leading role in matching, making the labeling rules more in line with actual business needs. Differentiated attribute similarity threshold settings are adapted to the management objectives of different entities, avoiding matching deviations caused by a one-size-fits-all approach. This provides a weighted basis for calculating the similarity between business entities and label values, ensuring that the calculation results are consistent with business priorities. For example, even if other financial attributes match, suppliers with poor credit ratings may still find it difficult to reach the attribute similarity threshold.

[0063] The initial threshold is set based on industry experience and may deviate from actual business scenarios. For example, if the supplier attribute similarity threshold is too high, many qualified suppliers may not be able to match the tag value. It is necessary to dynamically calibrate through historical data to improve adaptability. It is also necessary to clarify the relationship between business entities and tag values ​​through similarity comparison to form reusable mapping rules and avoid recalculation for each match. Retrieve the enterprise's past business entity tagging records and filter out records whose actual business performance after tagging can be verified to exclude records that have no subsequent cooperation after tagging. Then, compare the tag value with the actual business performance to determine whether the tag is accurate and calculate the historical matching accuracy rate. If the accuracy rate does not reach the preset target, the attribute similarity threshold is automatically lowered. The adjustment range is determined based on the difference between the accuracy rate and the preset target. After adjustment, the historical records are extracted and the accuracy rate is recalculated until the target is reached. If the accuracy rate is greater than the preset target, the attribute similarity threshold is appropriately lowered after user confirmation to expand the matching range. After calibration, the attribute similarity threshold covers the original attribute similarity threshold, and the calibration time and basis are recorded.

[0064] For new business entities, their financial attributes are first extracted and compared one by one with the standard attributes of the target tag value to determine the degree of matching of each financial attribute, i.e., the similarity between the two. Then, based on the priority weight of the business entity, a weighted score is calculated for each matching attribute and summed to obtain the total similarity. If the total similarity reaches the calibrated attribute similarity threshold, a mapping relationship between the business entity and the tag value is automatically established, and a unique rule code is generated. Information such as the business entity, tag value, similarity score, and attribute similarity threshold is stored in the mapping rule. If the total similarity does not meet the standard, the business entity is marked as awaiting manual review and pushed to the business manager for confirmation. The attribute similarity threshold calibration is verified through historical data to ensure that it is suitable for the actual enterprise scenario. The weighted summation of similarity achieves a comprehensive evaluation of multiple attributes. The mapping rule formation avoids repeated calculations and improves the efficiency of subsequent matching.

[0065] Financial attributes include enumeration, descriptive, and duration types. Enumeration attributes use a perfect match criterion, with a perfect match scored as 1, a partial match as 0.8, and no match as 0.3. Descriptive attributes are calculated based on the cosine similarity of the vectorized text. The original text is vectorized using TF-IDF, and the cosine similarity is calculated, then mapped to a preset range of similarity scores: greater than 0.8 is mapped to 1, 0.5 to 0.8 to 0.6, and less than 0.5 to 0.2. Duration attributes are mapped proportionally: the actual value reaching or exceeding the target value is scored as 1, reaching 50% to less than 100% of the target value is scored as 0.7, and less than 50% of the target value is scored as 0.3. The total similarity S = Σ(w i ×s i ) / Σw i In the formula w i Let s be the priority weight of the i-th financial attribute. i Let Σw be the similarity score of the i-th financial attribute. i This is the sum of the priority weights of all financial attributes involved in the calculation.

[0066] Newly formed mapping rules may have incomplete scenario coverage or logical conflicts. For example, the same entity may match multiple contradictory tag values, requiring verification of validity through historical records. Machine verification may struggle to identify special business scenarios, such as temporary suppliers for emergency procurement, necessitating manual intervention for supplementary judgment. Furthermore, association rules and mapping rules need continuous optimization as business changes occur, otherwise they will gradually become ineffective. First, retrieve the company's historical financial accounting records from the past three years and filter out complete records including business entities, tag values, actual business performance, and rule codes. Next, calculate the rule matching rate and anomaly detection rate. The rule matching rate refers to the proportion of records that conform to the association and mapping rules out of the total number of records, while the anomaly detection rate refers to the proportion of records identified as abnormal by the association and mapping rules out of the actual number of abnormal records. If both the rule matching rate and the anomaly detection rate meet the company's preset targets, the rule is marked as valid. If either the rule matching rate or the anomaly detection rate fails to meet the target, the rule is marked as needing optimization and triggers manual review.

[0067] The association rules and mapping rules to be optimized, along with associated anomaly cases, are pushed to the reviewers. Anomaly cases include suppliers whose credit ratings are substandard but are marked as strategic, subsequently defaulting. Based on the entity attributes, rule matching process, and actual business performance of the anomaly cases, the reasons for non-compliance are analyzed, such as excessively low risk adaptation weights for default frequency or overly lenient attribute similarity thresholds. Optimization suggestions for risk adaptation weights and attribute similarity thresholds are provided. Then, historical records are retrieved to recalculate the adjusted rule matching rate and anomaly identification rate, generating an optimization effect comparison of the two indicators before and after parameter changes. If the optimized indicators meet the standards, the association rules and mapping rules are re-marked as valid; if they still do not meet the standards, rule reconstruction is triggered. A quarterly automatic rule verification and optimization process is initiated to ensure that association rules and mapping rules continuously adapt to business changes, forming automatically iterative business labeling rules. Rule verification ensures rule validity through data validation, while manual review compensates for the machine's cognitive limitations in special scenarios. Automatic optimization achieves full lifecycle adaptation of association rules and mapping rules, avoiding rule rigidity due to changes in the business environment.

[0068] S2. Receive the original business documents, parse the text in the original business documents through natural language processing to identify business entities and financial attributes, match them with business tagging rules, automatically assign business tags to financial entries, calculate the tag confidence level and compare it with a preset threshold to judge abnormal tags, and output accounting data with verification tags after confirmation.

[0069] Furthermore, such as Figure 2 As shown, automatically assigning business tags includes:

[0070] Receive original business documents, parse the text in the original business documents through natural language processing, identify business entities and financial attributes, match the accounting scope of accounting subjects based on the identified financial attributes, and call the business marking rules within the accounting scope.

[0071] Match the financial attributes with the financial attributes corresponding to the tag values ​​of the basic accounting dimensions. If they match, assign a basic business tag. If they do not match, trigger an error message about the basic accounting dimension matching.

[0072] Based on risk-adaptive weights, the financial attributes corresponding to the labeled values ​​of financial attributes and dynamic business dimensions are summed with similarity weights. When the summation result is not less than the result threshold, a dynamic business label is assigned.

[0073] Associate the basic business tags and dynamic business tags with the auxiliary accounting fields of the financial entries respectively, and generate and output the financial entries with auxiliary accounting tags.

[0074] Original business documents contain core information about the business transactions, but this information is mostly in unstructured text form, including contract terms and handwritten notes. If not converted into structured data, it cannot be matched with business marking rules. Different accounting subjects have clear accounting boundaries, and business marking rules need to be bound to specific subjects. If rules are called across subjects, it will lead to a disconnect between marking and accounting scenarios. The system receives original business documents pushed by various business systems or uploaded by users. For non-text formats such as scanned documents and images, optical character recognition technology is used to convert them into processable text. For electronic documents, the text content is directly extracted. Then, natural language processing is used to parse the text in the original business documents to identify business entities and financial attributes. For example, from a purchase contract, it can identify equipment supplier A and production line expansion project B, where the business entities are supplier and project, respectively. At the same time, it can identify the nature of expenses as travel expenses and the related department as marketing department from expense reports, and identify the cooperation mode as annual framework agreement and payment terms as settlement after acceptance from contracts.

[0075] After parsing, the business entity and financial attributes are organized into structured information. For example, if the business entity is equipment supplier A, the financial attributes are: expense nature = equipment purchase and cooperation mode = annual framework agreement. Then, the accounting scope of the accounting subject is matched according to the identified financial attributes. For example, if the expense nature is equipment purchase, it needs to match the fixed asset subject; if the expense nature is travel expenses, it needs to match the sales expense subject. After a successful match, the business marking rules bound to the accounting subject are called. For example, the accounting scope associated with the fixed asset subject includes business marking rules such as asset category, purchase source, and current effective period. This is recorded as a rule list. The rule list includes the dimension code, mark value, and risk adaptation weight corresponding to the business marking rule, ensuring that the called rules are completely matched with the accounting requirements of the subject. The structured parsing of unstructured text enables automatic extraction of business information, reducing manual input costs. The accounting scope is matched based on financial attributes and the business marking rules are called, ensuring that the business marking rules are adapted to the business scenario and accounting subject, and avoiding the misuse of business marking rules.

[0076] The basic accounting dimension forms the underlying framework of financial accounting. Its business labeling rules are fixed associations; for example, marketing department expenses must be labeled with the department name "Marketing Department." This directly affects the accuracy of data classification. Incorrect labeling of the basic accounting dimension will lead to confusion in the underlying logic of subsequent data aggregation and analysis. The basic accounting dimension rules, including departments and accounting entities, are filtered from the invoked business labeling rules. The financial attributes corresponding to the label values ​​in the rules are extracted. For example, the financial attributes corresponding to the marketing department are "Marketing Department" and "Marketing Promotion." The financial attributes of the parsed business entities are compared item by item with the financial attributes corresponding to the label values. If they are completely consistent, then... The system automatically assigns a basic business tag to the Marketing Department for financial entries. If the parsed financial attributes show a department name of Marketing Department and a business scope of Product Development, which is inconsistent with the financial attributes of Marketing Promotion in the tag value, a basic accounting dimension matching anomaly warning is triggered, displaying a mismatch between the department business scope attributes and pausing the basic accounting dimension tag assignment process until manual verification or correction of the attribute information is achieved. Strict matching of basic accounting dimensions ensures the stability of the underlying financial accounting framework, avoids chain problems caused by incorrect basic information, and the anomaly warning can promptly intercept attribute deviations, preventing incorrect tags from entering subsequent accounting stages and ensuring the reliability of the data foundation.

[0077] Dynamic business dimensions change with the business lifecycle, and their business labeling rules need to reflect flexibility. For example, the same project should correspond to different labels at different stages, and the matching strictness should be adjusted in combination with risk factors. If a fixed matching method is used, it cannot adapt to dynamic changes in business. It is necessary to calculate similarity through risk adaptation weights and flexibly determine whether to assign a label. Dynamic business dimension rules, including supplier level and project stage, are selected from the business labeling rules. The risk adaptation weights and result thresholds in the rules are extracted. For example, in the supplier level rule, the risk adaptation weight of credit status is greater than that of cooperation duration, and the risk adaptation weight of credit status is increased in high-risk procurement business. The result threshold of high-risk business is higher than that of ordinary business.

[0078] Taking a strategic supplier rating as an example, the supplier's financial attributes are categorized by type and compared with the financial attributes corresponding to the tag value. For enumerated attributes, such as a credit status tag value with financial attributes of "good" or "excellent," if the supplier's financial attribute is "excellent," completely matching the tag value's financial attributes, the similarity score is 1; if the supplier's financial attribute is "good," partially matching the tag value's financial attributes, the similarity score is 0.8; if the supplier's financial attribute is "average," inconsistent with the tag value's financial attributes, the similarity score is 0.3. For descriptive attributes, such as a cooperation stability tag value with financial attributes of "no cooperation interruption record," if the supplier's financial attribute is described as "no interruptions in the past two years,"... If the financial attributes of a supplier match the marked value, the similarity score is 1. If the supplier's financial attributes are described as having one short-term interruption in the past two years, which partially matches the marked value's financial attributes, the similarity score is 0.6. If the supplier's financial attributes are described as having multiple interruptions in the past two years, which does not match the marked value's financial attributes, the similarity score is 0.2. For duration-based attributes, such as the financial attributes of the marked value being greater than or equal to one year, if the supplier's cooperation duration is two years, which meets the marked value's financial attributes, the similarity score is 1. If the supplier's cooperation duration is eight months, which is close to the marked value's financial attributes, the similarity score is 0.7. If the supplier's cooperation duration is three months, which is far less than the marked value's financial attributes, the similarity score is 0.3.

[0079] Then, the similarity is weighted and summed according to the risk adaptation weights. The summation result is the comprehensive similarity. When the comprehensive similarity is not less than the result threshold, the financial entry is automatically assigned a dynamic business tag of strategic supplier level and written into the dynamic auxiliary accounting field of the financial entry. If the comprehensive similarity is less than the result threshold, the tag status of the dynamic business dimension is set to pending confirmation and marked as requiring manual review. The similarity calculation based on risk adaptation weights enables the dynamic business dimension tag to adapt to the dynamic changes of the business and adjust the matching strictness according to the risk level. It controls risks while ensuring flexibility. The comprehensive judgment of multiple attributes avoids misjudgment caused by the bias of a single attribute and improves the rationality of the tag.

[0080] Business tags must be embedded in the auxiliary accounting fields of financial entries to become part of the accounting data for subsequent verification, analysis, and traceability. If business tags are separated from financial entries, the tags will lose their actual accounting meaning and cannot support subsequent data processing. When generating financial entries, basic business tags are written into the fixed auxiliary accounting fields of the financial entries, including department and accounting entity fields, while dynamic business tags are written into the expandable auxiliary accounting fields of the financial entries. The association between business tags and original financial attributes is recorded. For example, if the supplier level is strategic supplier, the associated financial attributes are excellent credit status and a cooperation duration of 3 years. The output is a financial entry with auxiliary accounting tags, containing debit and credit accounts, amounts, basic business tags, dynamic business tags, and the original financial attributes associated with the tags. This is synchronously stored in the accounting data to provide complete data for subsequent tag confidence calculation and anomaly judgment. The association between business tags and financial entries allows business information to be directly integrated into the accounting data, avoiding the disconnect between business tags and financial entries. The structured output format ensures that business tags can be called by subsequent processing, providing a foundation for full-process data processing.

[0081] The following is an end-to-end numerical example from original document input to marked confidence level output:

[0082] The original business document is a reimbursement form for the purchase of equipment. After NLP parsing, the business entity is identified as equipment supplier A. The financial attributes are: expense nature = equipment purchase, credit status = excellent, cooperation stability = no interruption records in the past 2 years, and cooperation duration = 2 years. The matching accounting subject is fixed assets, and the supplier level business tagging rules bound to this subject are called. Basic business tag matching: In the financial attributes, the expense nature = equipment purchase is consistent with the accounting scope of the fixed asset subject, so the basic business tag is automatically assigned as expense type = equipment purchase, and the matching precision is counted as 1.

[0083] Dynamic business tag matching: In the supplier level business tagging rules, credit status priority weight is 0.4, cooperation stability weight is 0.35, and cooperation duration weight is 0.25. The similarity of each attribute is as follows: credit status = 1 (excellent perfect match), cooperation stability = 1 (uninterrupted perfect match), and cooperation duration = 1 (2 years meets the requirement of greater than or equal to 1 year). The weighted summation S = (0.4×1 + 0.35×1 + 0.25×1) / (0.4 + 0.35 + 0.25) = 1. This procurement business is a medium-risk business, and the result threshold is 0.7. The dynamic business tag is automatically assigned as supplier level = strategic supplier.

[0084] Tag confidence calculation: Matching accuracy is taken as the similarity of dynamic business tags, 1 (weight 0.5); rule validity is taken as the historical matching accuracy of the rule, 0.92 (weight 0.3); completion of all business compliance verification and approval nodes is counted as 1 (weight 0.2); tag confidence = 0.5×1 + 0.3×0.92 + 0.2×1 = 0.976; this item is of medium risk, the preset threshold is 0.75, 0.976≥0.75, it is judged as a normal tag, the verification tag is automatically generated and passed, and the accounting data with the verification tag is output.

[0085] Specifically, the output accounting data with verification marks includes:

[0086] Based on the automatically assigned basic business tags and dynamic business tags, the confidence scores of matching accuracy, rule validity, and business compliance are calculated respectively, and then weighted and summed to obtain the tag confidence score.

[0087] Based on the risk level, a preset threshold is set, and the confidence level of the label is compared with the preset threshold to determine whether it is a normal label, a low-risk anomaly, or a high-risk anomaly. When the dynamic business dimension expires, it is determined to be a high-risk anomaly.

[0088] When a low-risk anomaly occurs, it is automatically confirmed by comparing the markings of similar historical documents. If the comparison is consistent, it is calibrated to a normal marking. When a high-risk anomaly occurs, the business marking assignment process is traced back and the original business documents are checked and confirmed.

[0089] If the exception flag fails to pass the confirmation, return to the business flag assignment process, generate a verification flag for the confirmed business flag, bind it with the financial entry, and output the accounting data with the verification flag.

[0090] Business tags may exhibit recognition bias and rule adaptation bias. Recognition bias includes attribute deviations caused by text parsing errors, while rule adaptation bias includes situations where specific business scenarios are not covered by the rules. The reliability of the tags needs to be quantified using confidence metrics. Confidence metrics must comprehensively consider matching accuracy, rule validity, and business compliance to fully assess tag quality and avoid misjudgments based on a single dimension. Based on automatically assigned basic business tags and dynamic business tags, confidence scores for matching accuracy, rule validity, and business compliance are calculated separately. Matching accuracy refers to the degree of fit between the business tag and financial attributes, directly using the weighted sum of similarity results from the dynamic business dimension. Since dynamic business tags require comprehensive evaluation across multiple attributes, their similarity results reflect the degree of fit between the business tag and financial attributes. Basic business tags are scored as 1 if automatically matched and without anomalies, and as 0.9 if manually confirmed and corrected, ensuring the stability of basic business tags does not negatively impact matching accuracy.

[0091] Rule validity refers to the reliability of the business tagging rule itself. It involves retrieving the historical matching accuracy rate of the corresponding business tagging rule, i.e., the ratio of recent correct matches to total matches. This ratio is directly used as the rule validity. If the business tagging rule is newly enabled and has no historical data, the average accuracy rate of similar business tagging rules is used as the initial rule validity. Business compliance refers to the completeness of the business process corresponding to the business tag. It verifies the completeness of the approval process associated with the business entity. If all approval nodes are completed, business compliance is scored as 1; if there are incomplete approval nodes, business compliance is scored as 0.6. Then, based on the company's financial control requirements, fixed weights are assigned to the three dimensions, with the weight for matching accuracy set to 0. The weighting of rule validity is 0.3, and the weighting of business compliance is 0.2. The sum of the three weights is 1. The weighting allocation reflects the dominant role of matching accuracy in confidence. Those skilled in the art can adjust the weights according to the enterprise's control requirements and sum the values ​​of each dimension to obtain the final label confidence score, i.e., label confidence score = 0.5 × matching accuracy + 0.3 × rule validity + 0.2 × business compliance. The confidence score result is bound to the unique identifier of the rule. The three dimensions respectively cover the fit between business labels and financial attributes, rule reliability, and business process integrity, ensuring that the confidence score assessment is comprehensive, the weighting allocation is in line with the priority of financial control, avoids secondary factors from affecting the overall judgment, and avoids subjective judgment bias.

[0092] Different risk levels of accounting items have different tolerances for labeling errors. For example, labeling errors in high-risk items can lead to asset accounting deviations, requiring strict thresholds. Labeling errors in low-risk items have a smaller impact on overall accounting, allowing for a more relaxed threshold. Furthermore, dynamic business dimensions have a clear expiration date; exceeding this expiration date will cause business labeling to become disconnected from actual business operations. Even if the confidence level meets the standard, it must still be classified as high-risk to avoid accounting distortion. Preset thresholds are set based on the current risk level of the accounting items, with a preset threshold of 0.85 for high-risk items and 0.75 for medium-risk items. The preset threshold for low-risk items is set at 0.65. The preset threshold configuration is linked to the risk level of the accounting item to ensure that the control intensity matches the risk of the item. If the confidence level of the label is greater than or equal to the preset threshold, it is judged as a normal label. If the confidence level of the label is less than the preset threshold, but the difference between the confidence level of the label and the preset threshold is within 0.1, it is judged as a low-risk anomaly. If the confidence level of the label is less than the preset threshold and the difference exceeds 0.1, it is judged as a high-risk anomaly. The above preset threshold is determined based on the statistical distribution of the confidence level of the label. Those skilled in the art can adjust the preset threshold accordingly in actual process.

[0093] The system reads the expiration date of the current dynamic business tag and compares it with the occurrence date of the original business document. If the occurrence date is later than the expiration date, regardless of the tag's confidence level, it is forcibly classified as a high-risk anomaly and marked as expired in the dynamic business dimension. Simultaneously, it associates the expiration date configuration record for review. Based on the risk level, it associates preset thresholds to achieve differentiated control, avoiding a one-size-fits-all approach. The forced high-risk classification of expired dynamic business tags ensures that the dynamic business tag is synchronized with the business lifecycle, preventing expired tags from affecting accounting, providing a classification basis for subsequent processing, and improving anomaly handling efficiency.

[0094] Low-risk anomalies are mostly minor deviations, and manual handling of all of them would increase workload. High-risk anomalies are mostly core deviations, such as attribute recognition errors and rule adaptation errors, requiring in-depth tracing of the entire marking process to pinpoint the root cause of the problem. Manual review and record-keeping are also necessary to ensure accountability. Low-risk anomalies are handled with automated confirmation and manual calibration. Historical marking records for similar documents are automatically retrieved. If the current anomaly's marking combination matches a historical marking record, and the confidence difference between historical and similar documents is consistent with the current one, the current marking is automatically calibrated to a normal marking, and the calibration basis is recorded as matching historical similar documents. If no historical similar records exist or the records are inconsistent, the historical similar documents are added to the low-risk anomaly pending confirmation list and pushed to the initial financial auditor to unlock the anomaly by providing supplementary supporting materials or confirming special scenarios.

[0095] High-risk anomalies are handled through a full-process retrospective and tiered review process. Key information at each stage is displayed chronologically, including the parsing results of original business documents, business tagging rule calls, tag matching, and tag confidence calculations to assist reviewers in locating problems. Review authority is tiered according to the severity of the anomaly: ordinary high-risk anomalies are reviewed by the finance manager, while anomalies involving significant amounts or high-risk items are reviewed by the CFO. Reviewers must fill in their review comments, such as attribute identification errors requiring correction and recalculation, or rule adaptation deviations requiring rule updates. After archiving, the anomaly status is updated according to the review results, i.e., confirmed as normal or returned for correction. Low-risk anomalies are automatically confirmed to reduce manual workload, while high-risk anomalies are traced through a full-process retrospective to ensure the root cause of the problem can be found. Tiered review and comment archiving strengthen accountability and prevent high-risk anomalies from being handled arbitrarily.

[0096] Confirmed business tags must be accompanied by a verification status to ensure data reliability in subsequent stages. The output accounting data must include a complete association between financial entries, business tags, and verification tags to support traceability requirements after data cube injection and prevent traceability interruptions due to missing verification information. Based on the confirmation method and result of the business tags, corresponding verification tags are generated. Normal tags correspond to automatic tags in the verification pass process, low-risk anomalies calibrated to normal tags correspond to historical comparisons in the verification pass process, high-risk anomalies manually confirmed to be normal correspond to manual review in the verification pass process, and anomalies corrected to normal correspond to attribute corrections in the verification pass process. Verification tags are bound to unique rule identifiers. For anomaly tags that fail confirmation, such as tags that cannot be corrected by manual review, they are added to the anomaly reprocessing queue and periodically returned to the document parsing stage where business tags are automatically assigned to re-execute entity recognition. If multiple processing attempts still fail, maintenance personnel are notified to investigate the problem, such as missing templates of the original business documents.

[0097] The final output integrates financial entries and verification flags to generate structured accounting data. This data is then partitioned and stored according to the risk level of each accounting subject. The data is pushed to the subsequent business fact record construction via an interface. Before pushing, field non-empty checks and correlation identifier consistency checks are performed to ensure data integrity. After pushing, a successful receipt is received for subsequent processing, and the data status is updated to "output" to prevent duplicate pushes. Verification flags clearly indicate the source of data reliability, facilitating rapid data quality assessment in subsequent stages. Partitioned storage and integrity checks ensure orderly data management and reliable transmission. Reprocessing prevents the backlog of abnormal data.

[0098] S3. Parallel processing of accounting data to generate accounting vouchers and voucher identifiers, and association of accounting data with voucher identifiers to construct business fact records. New business fact records are captured through stream processing, and the new records are processed and injected into the data cube in real time based on incremental aggregation rules.

[0099] Furthermore, constructing a business fact record includes:

[0100] Receive accounting data with verification marks, generate accounting vouchers including voucher identifiers based on the accounting attributes of accounting subjects and accounting standards, and simultaneously parse the dimension code of business marks and the verification level of verification marks in the accounting data;

[0101] Using the voucher identifier as the link, the dimension code and verification level are embedded into the additional information of the accounting voucher, and the verification mark in the accounting data and the document number of the original business document are linked to verify the consistency between the dimension code and the accounting scope. If they are inconsistent, they are re-linked.

[0102] Integrate accounting vouchers, voucher identifiers, associated dimension codes, verification levels, verification marks, and original business document document numbers to construct a business fact record.

[0103] The aforementioned output accounting data with verification marks is essentially a combination of financial entries and verification marks. It needs to be converted into standardized accounting vouchers that comply with accounting standards before it can be incorporated into the formal financial accounting system. At the same time, the dimension coding of the business marks and the verification level of the verification marks are key indexes for subsequent association and traceability. If they are not parsed and extracted, it will lead to a break in the information chain for subsequent traceability. After receiving the aforementioned pushed accounting data, accounting vouchers including voucher identifiers are generated based on the accounting attributes of accounting subjects and accounting standards. For example, for the R&D expenditure subject, the accounting attributes of expensed and capitalized expenditures need to be distinguished according to the relevant accounting standards for the expensed nature of research stage expenditures. The financial entries are refined into "Debit: R&D expenditure - expensed expenditure - travel expenses, Credit: bank deposit". In the relevant entries for raw material procurement, combined with the inventory valuation requirements in accounting standards, the accounting vouchers clearly specify the accounting explanation of procurement costs including freight and miscellaneous charges. The debits and credits must be equal, and a unique voucher identifier is generated for each accounting voucher, including the year, month, and serial number.

[0104] The business tag dimension codes are extracted from the auxiliary accounting fields of the accounting data. Basic accounting dimensions correspond to fixed codes, such as the exclusive codes for departments, while dynamic business dimensions correspond to dynamic codes, such as "supplier level - execution period - core supplier". Then, the verification level is identified from the verification tags and divided according to the confirmation method and risk level. For example, the verification level corresponding to automatic confirmation in low-risk anomalies is 1, while the verification level corresponding to manual review in high-risk anomalies is 2. The verification level is then associated with the voucher identifier. The accounting vouchers are automatically generated to ensure compliance with accounting standards and enterprise subject specifications, avoiding manual input errors. The structured parsing of dimension codes and verification levels provides a standardized index for subsequent multi-element association, ensuring the integrity of the information chain and ensuring that business fact records can integrate accounting, tagging, and verification information.

[0105] Financial data needs to form a complete link between original business documents, accounting data, accounting vouchers, business tags, and verification results to meet audit and traceability requirements. For example, when querying a voucher, it is necessary to quickly locate the corresponding original expense report, business tag rules, and verification records. At the same time, the dimension code must strictly match the accounting scope of the accounting subject. If the mismatch occurs, it will lead to a disconnect between the auxiliary accounting dimension and the subject attribute, affecting the accuracy of data analysis. Using the voucher identifier as the core association key, a multi-element association link is constructed. The document number of the original business document is extracted from the accounting data output in the previous steps, and the original business document corresponding to the document number is queried, including scanned copies and electronic forms. The document storage path is associated with the voucher identifier, and the dimension code and verification level matching the voucher identifier are retrieved. The additional information of the accounting voucher is embedded. The additional information does not affect the structure of the accounting voucher and is only used for auxiliary information storage. The aforementioned verification tag is bound to the voucher identifier to form an association relationship between the voucher identifier, verification tag, and dimension code.

[0106] After the association is completed, the dimension code of the current accounting voucher is checked to see if it is within the accounting scope of the accounting subject. If it is not within the accounting scope, the re-association process is automatically triggered, that is, backtracking to the aforementioned business tag assignment process, checking the rule call record when the dimension code was assigned. If it is a business tag rule mismatch, the accounting scope of the accounting subject is updated. If it is a financial attribute parsing error, the aforementioned text parsing is re-triggered to re-identify the business entity, and the association is re-assigned after correction. The end-to-end association ensures the traceability of financial data. The original business documents and verification records can be directly located from the accounting voucher. Consistency verification avoids mismatch between dimension codes and accounting subjects, ensures the accuracy of auxiliary accounting dimensions, and provides a reliable foundation for subsequent data analysis.

[0107] If scattered accounting vouchers, dimension codes, original business documents, and verification records are not integrated, subsequent stream processing will require querying multiple scattered data points, reducing processing efficiency. Furthermore, data analysis and traceability require a structured, one-stop data carrier; business fact records must contain full-link information to support rapid querying and correlation analysis. The above data is integrated according to a pre-defined structured template, which includes an identification area, accounting information area, marked dimension area, and verification information area. The identification area stores voucher identifiers, document numbers, and record generation times for stream processing sorting. The accounting information area stores account codes, account names, debit / credit directions, amounts, and voucher summaries. The marked dimension area includes basic dimension areas and dynamic dimension areas, storing the dimension codes and names of basic accounting dimensions and dynamic business dimensions, respectively. The verification information area stores verification levels, verification tags, reviewers, and review times.

[0108] After integration, each business fact record undergoes a field non-empty check to ensure that no fields in the identification area and accounting information area are missing. After the check passes, the data is stored in the database and partitioned according to the record generation date and accounting subject type. Within each partition, data is sorted by voucher identifier to facilitate sequential reading by stream processing. The structured integration forms a cohesive whole from scattered data, avoiding cross-database queries. Partitioned storage and sorting improve the reading efficiency of stream processing, laying an efficient data foundation for real-time injection of the data cube and ensuring low latency for real-time injection.

[0109] Specifically, such as Figure 3 As shown, the real-time injected data cube includes:

[0110] Initialize the stream processing channel, identify new business fact records based on voucher identifiers, and configure a capture trigger mechanism in conjunction with the accounting cycle to capture new business fact records;

[0111] The newly captured records are checked for integrity. If they are incomplete, they are recaptured. If they are complete, the dimension codes and verification levels in the new records are parsed. The target level is assigned based on the hierarchical structure of the data cube adapted to the dimension codes.

[0112] The incremental aggregation rules are invoked based on the validity period of the verification level and dynamic business dimension to process new records, generating incremental aggregation results and enhanced aggregation results with voucher identifiers;

[0113] Partitions are created in the data cube based on the target level. Incremental aggregation results are injected into fixed-dimensional partitions, and enhanced aggregation results are injected into variable-dimensional partitions. During the injection process, the consistency between the dimension encoding and the target level is checked. If there is a discrepancy, the injection is paused and the adaptation relationship of the target level is updated.

[0114] Generate a version identifier for the injected aggregation result, associate it with the partition of the data cube, and record the credential identifier of the corresponding business fact record.

[0115] Business fact records are dynamically generated as business occurs. If traditional batch processing is used, new records cannot be incorporated into the data cube in a timely manner, affecting the real-time nature of the analysis results. At the same time, the identification of new records depends on a unique benchmark; otherwise, duplicate captures or omissions are likely to occur. The uniqueness of voucher identifiers makes them naturally suitable as a benchmark. In addition, accounting has a fixed cycle, and the capture triggering mechanism must be adapted to it; otherwise, data incompleteness will result from the capture timing being out of sync with the accounting rhythm. First, the stream processing channel is initialized, and a stream processing framework based on a distributed message queue is deployed to create dedicated processing channels. For example, expense channels and procurement channels are set up according to business types. The channel configuration includes data source connection information, data format conversion rules, and fault tolerance mechanisms. Data source connection information refers to the read and write interface to the business fact record database. Conversion rules refer to converting the structured fields of the records into a key-value pair format that stream processing can recognize. The fault tolerance mechanism refers to automatically switching to a backup channel when a node fails to avoid data loss. At the same time, voucher identifiers are embedded in the channels as a reference benchmark for subsequent identification of new records.

[0116] New business fact records are identified based on voucher identifiers. When a new record is written to the database, the voucher identifier of the new record is pushed to the stream processing channel in real time via a database trigger. The pushed voucher identifier is compared with the historical identifier set. If the voucher identifier does not exist in the historical set, i.e., it has not been captured, it is determined to be a new record, triggering the capture process. If the voucher identifier already exists, i.e., it is a duplicate record caused by data retransmission, it is directly filtered to avoid duplicate processing. Finally, the capture trigger mechanism is configured in conjunction with the accounting cycle. For the daily closing cycle, a full verification capture is triggered 1 hour before the daily closing, scanning all voucher identifiers generated on that day, comparing them with the captured voucher identifier set, and supplementing any missing records that were not captured in real time. For real-time business needs, a real-time incremental trigger is configured. When a new record is written to the database, the channel capture process is triggered immediately to ensure that records of high-frequency business are captured within 5 minutes. For the monthly accounting cycle, a cycle summary capture is triggered 24 hours before the monthly closing, traversing the voucher identifiers of all business fact records for the month, fully verifying the completeness of the capture, and ensuring that no monthly data is missing.

[0117] The configuration parameters for the capture trigger mechanism are stored in the trigger rule configuration library, allowing financial personnel to adjust them according to the accounting rhythm. The configuration parameters include daily verification time and real-time trigger delay threshold. The stream processing channel is initialized to build a stable data transmission link to avoid record loss due to channel failure. It uses voucher identifiers as the basis for identification, leveraging their uniqueness to ensure accurate identification of new records and prevent duplication or omission. Combined with the trigger mechanism of the accounting cycle, it not only meets the real-time needs of business operations but also adapts to the cyclical requirements of financial accounting, enabling deep collaboration between the data capture rhythm and financial processes, and ensuring the timeliness and integrity of the data.

[0118] Newly captured business fact records may contain missing information due to transmission interruptions and data source anomalies. Directly using these records for subsequent processing would result in invalid or erroneous data in the data cube, affecting the reliability of the analysis results. Furthermore, the data cube employs a multi-level nested structure, such as hierarchical division by accounting subject, basic accounting dimension, and dynamic business dimension. Newly added records must be matched to the corresponding level based on their own dimension information; otherwise, hierarchical mismatches will occur, making it impossible to accurately locate data during queries. Therefore, the first step is to perform an integrity check on the captured newly captured business fact records. The checked records include voucher identifiers and at least one basic accounting... The system checks each record for the existence and non-emptiness of the following fields: dimension code, accounting subject, amount, verification mark, and document number of the original business document. If a record is missing, such as the dimension code of the basic accounting dimension or an empty amount field, it is considered an incomplete record. If all key fields are complete, it is considered a valid record. For incomplete records, the capture trigger mechanism is re-executed, and the system traces back to the business fact record database through the voucher identifier to retrieve the complete information of the record. If multiple re-capture attempts fail, an alarm message is generated and pushed to the administrator, prompting manual intervention to supplement the information.

[0119] For complete records that pass verification, the dimension codes for the basic accounting dimension and the dynamic business dimension are extracted from the record's marked dimension area, along with the verification level from the verification information area. Then, based on the parsed dimension codes, the hierarchical structure of the data cube is adapted. The data cube's hierarchical structure is pre-set as a nested pattern of accounting subjects, basic accounting dimensions, and dynamic business dimensions, such as R&D expenditure, department, project, and supplier level. First, based on the record's accounting subject, the first-level subject node of the data cube is located, such as R&D expenditure. Then, based on the dimension code of the basic accounting dimension, the corresponding second-level basic dimension node is matched from the first-level subject node, such as R&D expenditure. Out → Department: R&D Department; Finally, based on the dimension code of the dynamic business dimension, the corresponding third-level dynamic dimension node is matched from the second-level basic dimension node, for example, R&D expenditure → Department: R&D Department → Project: Product A testing, forming the target hierarchical path of the business fact record to complete the allocation; Integrity verification intercepts incomplete records through key field checks to prevent invalid data from entering subsequent processes and ensure the cleanliness of the data cube; Dimension code parsing and hierarchical adaptation achieve accurate matching based on preset mapping relationships to ensure that new records are placed in the correct hierarchical level of the data cube, avoiding query deviations caused by hierarchical mismatches, and providing an accurate position benchmark for subsequent incremental aggregation.

[0120] Business fact records with different verification levels exhibit varying data reliability. For instance, records that have passed rigorous manual review are more reliable than those that have passed automatic system calibration. During aggregation, high-reliability records should be prioritized to prevent low-reliability data from interfering with core analysis. Dynamic business dimensions change with the business lifecycle; if expired dimensions are included in the current result aggregation, the aggregation results will become disconnected from actual business operations. Furthermore, the data cube needs to distinguish between the aggregation results of basic accounting dimensions and the aggregation results of basic and dynamic dimensions. First, the verification level and the validity period of dynamic business dimensions are extracted from newly added business fact records. Incremental aggregation rules are then called according to the verification level, with rigorous manual review corresponding to high priority and automatic calibration corresponding to regular priority. High-priority records are prioritized in the aggregation queue and occupy computing resources first, ensuring that core reliable data is aggregated first. Regular priority records are processed sequentially according to the queue order. Dedicated incremental aggregation rules are matched for different verification levels; for example, high-priority records require additional association with the reviewer's information field for subsequent traceability, while regular priority records only require aggregation of basic fields.

[0121] Then, the aggregation scope is filtered based on the validity period of the dynamic business dimension. If the dynamic business dimension is within its validity period, a complete aggregation is performed based on the combination of the basic accounting dimension and the dynamic business dimension. If the dynamic business dimension has expired, it is automatically marked as a historical dimension, and only historical data partitions are included during aggregation. It is not mixed with the aggregation results within the current validity period. For example, the expenses of completed projects are summarized separately into the historical project expense category to avoid interfering with the current business analysis. Finally, two types of aggregation results are generated. The incremental aggregation result refers to the aggregation performed only based on the basic accounting dimension, which counts the core indicators under the basic accounting dimension. The incremental aggregation result is associated with the voucher identifier set of all records participating in the aggregation, which is convenient for subsequent tracing to specific records. The enhanced aggregation result refers to the aggregation performed on the basis of the incremental aggregation, which is superimposed with the dynamic business dimension, which counts the detailed indicators under the combination of the basic accounting dimension and the dynamic business dimension. For example, the expenses of a project in a certain period of a certain department are associated with the corresponding voucher identifier set, which is also associated with the corresponding voucher identifier set to ensure that both results can be traced back to the original records.

[0122] The aggregation process records aggregation results in real time, including the name of the business tag rule called, the number of records participating in the aggregation, and the validity period filtering results, which facilitates subsequent anomaly investigation. Aggregation priorities are divided according to the verification level to ensure that high-reliability data is processed first, thereby improving the credibility of core analysis results. Dynamic validity period filtering of business dimensions avoids expired data from interfering with the current aggregation, ensuring that the results are consistent with the actual business. Incremental and enhanced aggregation results are provided to accurately adapt to fixed-dimensional or variable-dimensional partitions of the data cube without the need for subsequent format adjustments. This directly supports injection operations and improves overall processing efficiency.

[0123] Data cubes need to be partitioned and stored according to a hierarchical structure. If dedicated partitions are not created according to the target level, data from different levels will be mixed, requiring a full scan during subsequent queries, which will significantly reduce efficiency. Incremental aggregation results and enhanced aggregation results correspond to different dimensional complexities, and fixed-dimensional partitions and variable-dimensional partitions need to be injected separately. Otherwise, the consistency of the dimensional structure of the partitions will be destroyed. At the same time, the initial allocation of the target level may be deviated due to the update of the mapping relationship between dimension encoding and level. For example, if the newly added dimension encoding is not updated in time, direct injection without verification will cause data to be placed in the wrong level, affecting the accuracy of the analysis results.

[0124] Data cube partitions are created based on the target hierarchy. According to the previous target hierarchy path, corresponding partitions are generated in the data cube. For target hierarchies containing only basic accounting dimensions, fixed-dimensional partitions are created. The partition names reflect the accounting subject, basic accounting dimension, and dimension value, and are used to store incremental aggregation results. For target hierarchies containing both basic accounting dimensions and dynamic business dimensions, variable-dimensional partitions are created. The names reflect the accounting subject, basic accounting dimension, dynamic business dimension, and dimension value, and are used to store enhanced aggregation results. After the partitions are created, the correspondence between the partitions and the hierarchy is automatically recorded and stored in the index library of the data cube partitions.

[0125] The process involves injecting aggregation results, retrieving incremental and enhanced aggregation results, and injecting them according to the corresponding rules of partition type and result type. Incremental aggregation results containing only basic accounting dimensions are injected into fixed-dimensional partitions, while enhanced aggregation results containing both basic accounting dimensions and dynamic business dimensions are injected into variable-dimensional partitions. The injection process uses a streaming write method, writing data to partition fields according to the target level's field structure to ensure data format and partition structure compatibility. Simultaneously, consistency checks are initiated, extracting dimension codes from the injected aggregation results and comparing them with the dimension code range corresponding to the target level. If inconsistencies are found, such as a mismatch between the injected result's project code "B Product Development" and the target level's project code "A Product Testing," the injection process for that partition is immediately paused. The process is then traced back to the mapping between dimension codes and levels to check whether the adaptation deviation is due to outdated mapping relationships, such as newly added "B Product Development" codes not being associated with the corresponding level.

[0126] If a mapping is indeed missing, the mapping relationship between dimension codes and levels is automatically updated. The correspondence between the dimension codes of product B R&D and the level "R&D Expenditure → Department: R&D Department → Project: Product B R&D" is supplemented. After the update, the injection and verification of the result are re-executed until the dimension codes are consistent with the target level. A dedicated partition is created according to the target level to make the storage structure of the data cube consistent with the hierarchical logic of business analysis. Subsequent queries can directly locate the target partition, avoiding full scans and greatly improving query efficiency. Typed injection ensures that the incremental aggregation results / enhanced aggregation results are adapted to the dimension structure of fixed dimension partitions / variable dimension partitions without destroying the integrity of partition data. Real-time consistency verification promptly intercepts mismatches between dimension codes and the levels of the data cube. Deviations are corrected by dynamically updating the mapping relationship, rather than directly discarding data, which ensures data quality and avoids the loss of effective data.

[0127] The aggregation results in the data cube are continuously updated with newly added business fact records. Version identifiers are needed to distinguish the aggregation status at different points in time, facilitating user queries of historical aggregation data. Simultaneously, the version identifier must be associated with the voucher identifier of the original business fact record to ensure that the specific accounting voucher can be located from the aggregation result during tracing. A unique version identifier is generated for the aggregation result of each partition, using a format of partition code and aggregation time. The version identifier is bound to the partition and stored in the version table of the data cube. The version table records the version generation time, the number of records included in the aggregation result, and the generation status. At the same time, all voucher identifiers associated with the current version of the aggregation result are extracted, generating a relationship between the version identifier and the voucher identifier to ensure bidirectional tracing. The version identifier enables time-dimensional management of the aggregation results, supports historical data queries and comparative analysis, and the association between the version and the voucher ensures traceability from the aggregation result to the original accounting voucher, meeting the core requirements of traceability and verifiability of financial audit data.

[0128] S4. Respond to user query requests for the data cube, perform drill-down analysis based on any combination of business tag dimensions, and output analysis results with anomaly tags. Respond to source tracing instructions for specific data points and trace back accounting vouchers and business entities based on associated voucher identifiers.

[0129] Furthermore, the analysis results output with anomaly markers include:

[0130] Receive user query requests for data cubes, parse the combination of business tag dimensions in the query request, extract the judgment criteria for anomaly tags in the query request, and form a query parameter set;

[0131] Based on the query parameter set, locate the partitions of the data cube, match fixed-dimensional partitions according to the basic accounting dimension, match variable-dimensional partitions according to the dynamic business dimension, and filter the aggregation results within the partitions that include anomaly markers.

[0132] Aggregate analysis is performed in a hierarchical order prioritizing basic accounting dimensions and followed by dynamic business dimensions. If only basic accounting dimensions are included, the first aggregation analysis is performed based on the incremental aggregation results of fixed dimension partitions.

[0133] For each dynamic business dimension overlaid, the enhanced aggregation result of the corresponding variable dimension partition is matched, and a second aggregation is performed with the first aggregation result. The second aggregation result is then integrated to output the analysis result.

[0134] User query requirements for data cubes are often presented in unstructured form, such as textual descriptions of filter conditions and dimension combination requirements. Simply extracting dimension combinations can easily lead to missing key dimensions or including irrelevant data in the query results due to misunderstandings of the requirements. At the same time, business-marked dimensions have hierarchical relationships between basic accounting dimensions and dynamic business dimensions. For example, the project dimension needs to be attached to the department dimension to clarify the filter scope. If this relationship is not sorted out, invalid queries will be generated. In addition, the filtering of anomaly markers requires clear judgment criteria. If they are not extracted and standardized, the filtering criteria will be vague, affecting the accuracy of the results. First, the query request receiving operation is executed. The user's query requirements are obtained through preset request receiving methods, such as standardized query text input and structured parameter list submission. The query requirements include the filtering requirements of business-marked dimensions, the filtering intent of anomaly markers, and time range constraints.

[0135] Next, the combination of business tag dimensions is analyzed. All business tag dimensions are extracted from the received query requirements, and the hierarchical relationships between dimensions are sorted out. The basic accounting dimension is determined as a first-level dimension, and the dynamic business dimension is determined as a second-level dimension. Because the project needs to belong to a specific department, the expense type in the basic accounting dimension is determined as a first-level filtering dimension parallel to the department, excluding irrelevant dimensions not mentioned in the query requirements. At the same time, the specific filtering values ​​of each dimension are clarified to form an orderly dimension combination logic. Then, the judgment criteria for anomaly tags are extracted, that is, the abnormal characteristics mentioned in the user's query requirements are identified, such as failing automatic calibration but being manually confirmed. These abnormal characteristics are mapped to preset anomaly judgment rules. For example, failing automatic calibration corresponds to an initial tagging status of low-risk anomaly, while manual confirmation corresponds to a final verification result of confirmed validity. If the user does not explicitly mention the anomaly type, that is, only requires the inclusion of anomaly records, then the general anomaly judgment criteria are associated by default, such as the verification level not being the usual automatic pass, to ensure that anomaly screening has clear standards.

[0136] Finally, the combination of parsed business tag dimensions, the criteria for anomaly tagging, and time range constraints are integrated into a structured query parameter set. All parameters in this set use a unified description format. For example, the combination of business tag dimensions is described as "First-level dimension: [Dimension name = Filter value] → Second-level dimension: [Dimension name = Filter value]", and the criteria for anomaly tagging are described as "Anomaly feature → Mapping rule". This ensures that subsequent query operations can be directly executed based on this parameter set. The parsing of business tag dimension combinations clarifies the hierarchical relationships between dimensions, avoiding the generation of invalid queries. The extraction and standardization of anomaly tagging criteria eliminates ambiguity in filtering standards, ensuring accurate anomaly data filtering. The formation of this structured query parameter set provides a unified basis for subsequent data cube partitioning and filtering aggregation results, reducing query errors caused by misunderstandings of requirements and improving query efficiency.

[0137] The data cube is partitioned logically by matching fixed-dimensional partitions with basic accounting dimensions and variable-dimensional partitions with dynamic business dimensions. Failure to match partitions by dimension type would result in locating irrelevant partitions, increasing the amount of invalid data processed. Furthermore, user queries explicitly include anomaly filtering; simply locating partitions without filtering for anomalies would return a large amount of irrelevant normal data, failing to meet the core user requirement. First, fixed-dimensional partitions are located based on the basic accounting dimensions in the query parameter set. Basic accounting dimensions are extracted from the query parameter set and matched against the data cube's fixed-dimensional partitioning rules. Fixed-dimensional partitions are named according to the basic accounting dimension and accounting subject. If there are multiple basic accounting dimensions in the query parameter set, they are located layer by layer in the order of accounting subject → primary basic dimension → secondary basic dimension. That is, first, the R&D expenditure subject partition is matched; then, under the subject partition, the department is matched as R&D department; and finally, the expense type is matched as travel expenses, ensuring that the located fixed-dimensional partitions completely cover the basic accounting dimensions.

[0138] Then, the variable dimension partitions are located by combining the dynamic business dimensions in the query parameter set. The dynamic business dimensions are extracted from the query parameter set, and the variable dimension partitioning rules are compared. Under the fixed dimension partitions that have been located, the variable dimension partitions containing the target dynamic dimension are further matched. The variable dimension partitions are based on the fixed dimension partitions with the dynamic business dimension superimposed on them. The naming format is the fixed dimension partition name and the dynamic business dimension. If there is no dynamic business dimension to filter in the query parameter set, that is, only the basic accounting dimensions are searched, then only the fixed dimension partitions that have been located are retained, and there is no need to match the variable dimension partitions. Finally, the aggregation results with anomaly markers are filtered in the located partitions. The judgment criteria for the anomaly markers are extracted from the query parameter set. All aggregation results in the located partitions are traversed, and the verification marker information associated with each result is checked, such as the verification level and anomaly status fields recorded in the aggregation results.

[0139] If the verification flag information of the aggregation result completely matches the judgment criteria of the anomaly flag, the aggregation result is retained; otherwise, it is excluded. After filtering, all aggregation results that meet the conditions are collected, temporarily stored in the target result cache area, and the partition path to which each result belongs is recorded to facilitate subsequent tracing of the partition source. Partitions are located hierarchically by dimension type to avoid partition deviation caused by cross-type matching. At the same time, the partition scanning range is reduced by hierarchical positioning, improving positioning efficiency. Anomaly flags are accurately filtered within the partition, and irrelevant normal data is directly excluded to ensure that the output results fully meet the user's query needs for anomaly data, reduce the redundancy of subsequent data processing, and improve the overall query response speed.

[0140] The basic accounting dimensions form the underlying framework for financial data classification. Aggregating based on these dimensions first ensures the stability and compliance of the data summary. Dynamic business dimensions provide a more detailed supplement to the basic data. Overlaying dynamic business dimensions allows for drill-down analysis from summary to detail, aligning with user query habits. Reversing the hierarchical order can lead to chaotic data classification logic. For example, summarizing by project first and then splitting by department can result in mixed cross-departmental project data. If dynamic dimension results are still called even when only basic accounting dimensions are included, it will waste resources and be meaningless. Therefore, it is crucial to first clarify the combination of business marker dimensions in the query parameter set, determine whether it includes only basic accounting dimensions or both basic accounting dimensions and dynamic business dimensions, and then perform aggregation analysis according to the corresponding scenario.

[0141] If only the basic accounting dimension is included, then all incremental aggregation results matching the basic accounting dimension are extracted from the already located fixed dimension partitions. The incremental aggregation results themselves are summary data generated solely based on the basic accounting dimension, such as the monthly summary of R&D department travel expenses and the summary of various expense types in the R&D department. The first aggregation analysis is performed according to the hierarchical relationship of the basic accounting dimension. First, the department is taken as the first-level dimension, and all basic data under that department that meets the expense type of travel expenses are summarized to form the summary result of the total amount of R&D department travel expenses. Then, the expense type is taken as the second-level dimension, and the amounts of sub-types such as transportation, accommodation and subsidies in the R&D department travel expenses are broken down on the basis of the total amount to form multi-level summary results under the basic accounting dimension. During the aggregation process, the scope of voucher identifiers associated with each level of results is retained, such as the voucher identifiers of all travel expense documents associated with the total amount of R&D department travel expenses, to ensure subsequent traceability.

[0142] If both basic accounting dimensions and dynamic business dimensions are included, an initial aggregation analysis is performed first. Referring to the aggregation analysis results of the basic accounting dimensions, a basic summary result is generated for the total travel expenses of the R&D department and the amounts of each sub-item of expense, laying the foundation for the underlying framework of the analysis. Then, subsequent aggregations are performed by overlaying the dynamic business dimensions. Enhanced aggregation results matching the dynamic business dimensions are extracted from the identified variable dimension partitions. These enhanced aggregation results are a combination of data from the basic accounting dimensions and dynamic business dimensions, such as the travel expense summary for Project A in the R&D department. The enhanced aggregation results are then correlated and overlaid with the basic summary result of the initial aggregation. Using the sub-item expense types in the basic summary result as a benchmark, the expense types under each expense type are broken down into categories A. The corresponding amount for each project forms a hierarchical aggregation result from basic accounting dimensions to dynamic business dimensions. During the overlay process, it is ensured that the basic dimension data and dynamic dimension data are consistent in scope to avoid data deviation. The aggregation order prioritizing basic data conforms to the underlying logic of financial accounting, ensuring the stability and compliance of data aggregation and avoiding classification confusion. The subsequent overlay analysis of dynamic data enables drill-down from summary to details, meeting users' needs for data refinement. In basic dimension scenarios, the incremental results of fixed dimension partitions can be directly reused without additional processing of dynamic dimension data, significantly reducing the amount of calculation and improving aggregation efficiency. At the same time, the voucher identification association is retained to provide a basis for subsequent traceability, balancing the depth of analysis and data traceability.

[0143] Dynamic business dimensions represent multi-level refinements of basic accounting data. User queries often require a gradual progression from basic dimensions to dynamic dimensions, such as first viewing the department's total expenses, then the expenses of each project under that department, and finally the expenses of each supplier within those projects. Overlaying all dynamic business dimensions at once would result in a chaotic hierarchy of results, making it difficult for users to understand the relationships between the data. However, performing a secondary aggregation for each additional dynamic business dimension allows for a tiered analysis, from basic summarization to first-level refinement of dynamic business dimensions and then to second-level further refinement of dynamic business dimensions. This aligns with the user's cognitive logic of moving from overview to detail. Furthermore, secondary aggregation must be based on enhanced aggregation results from corresponding variable dimension partitions to ensure the accuracy of the refined analysis and avoid data mismatches.

[0144] Taking a user query requesting the travel expenses of the R&D department, including the cost percentage of each project and the cost details of the core suppliers under each project, as an example, the process first determines the overlay order of dynamic business dimensions. Based on the relationship between businesses, the overlay order is determined to be from project to supplier level. Then, the first dynamic business dimension is overlaid to perform the first secondary aggregation. Based on the basic summary result of the first aggregation, the variable dimension partition is located, including the enhanced aggregation results of each project, such as the travel expense summary of project A and the travel expense summary of project B. Then, the enhanced aggregation results of all projects are extracted from this partition. The enhanced aggregation results include the project name, the corresponding travel expense amount, and the associated anomaly marker. Next, based on the total travel expense amount of the R&D department in the first aggregation, the cost percentage of each project is calculated, and the anomaly marker information of each project is associated to form a first-level refined result of total R&D department expenses → expenses and percentages of each project.

[0145] Then, a second round of aggregation is performed by overlaying the second dynamic business dimension. Based on the first-level refinement results from the previous step, variable dimension partitions are located, including enhanced aggregation results for each supplier level under the project, such as the summary of travel expenses for core suppliers and the summary of travel expenses for ordinary suppliers. Enhanced aggregation results for core suppliers are extracted from this partition, including supplier level, corresponding travel expense amount, and associated anomaly markers. Using the travel expense amount of Project A from the previous step as a benchmark, the proportion of core supplier expenses in the project is calculated, and its anomaly markers are associated to form a second-level refinement result of R&D department total expenses → Project A expenses → core supplier expenses and proportions. The aggregation results of each step are integrated into a structured analysis report in the hierarchical order of basic accounting dimension aggregation → first-level refinement of dynamic business dimensions → further refinement of dynamic business dimensions.

[0146] The analysis report comprises a basic layer, a first-level dynamic business dimension, and a second-level dynamic business dimension. The basic layer includes the total travel expenses and total abnormal expenses of the R&D department. The first-level dynamic business dimension includes the expense amount, percentage, and project-level abnormal expenses for each project. The second-level dynamic business dimension includes the expense amount, percentage, and supplier-level abnormal expenses for core suppliers under Project A. The output retains the scope of the voucher identifier associated with each level of results for easy traceability. Dynamic business dimensions are sequentially overlaid and aggregated step-by-step, resulting in a clear hierarchical relationship in the analysis results. This aligns with users' query habits from overview to detail, reducing comprehension costs. Each aggregation matches the enhanced results of the corresponding variable dimension partitions, ensuring the correlation and accuracy between refined data and upper-level basic data, avoiding cross-dimensional mismatches. The integrated hierarchical output includes both summary information and detailed breakdowns and abnormal markers, meeting users' needs for data depth and completeness.

[0147] Specifically, the reverse tracing of accounting vouchers and business entities includes:

[0148] Receive user instructions to trace the source of specific data points, extract the voucher identifier associated with the specific data point and the version identifier of the aggregation result, query the data cube based on the version identifier and locate the range of voucher identifiers associated with the version identifier, and filter out business fact records that match the voucher identifier.

[0149] Extract accounting vouchers and document numbers from the matched business fact records, and verify the consistency between the voucher identifier in the business fact records and the voucher identifier in the accounting vouchers. If they are inconsistent, trigger a re-association verification.

[0150] Based on the document number, the corresponding original business document is traced back to extract the corresponding business entity and the matching business tag rules at that time. The similarity between the business entity and the tag value is recalculated by calling the business tag rules to verify the matching and adaptability of the business tags.

[0151] The specific data points that users focus on in the analysis results are the result of multi-level aggregation, which are associated with multiple original business fact records. If they are not accurately located using voucher identifiers and version identifiers, the original business fact records may be traced back to incorrect ones due to version updates of the aggregation results. At the same time, a single data point may be associated with multiple original business fact records. The original record range corresponding to the data point needs to be determined by the version identifier; otherwise, some sources will be missed. For example, take the user's tracing instruction for the specific data point of low-risk abnormal travel expenses of Company B, the core supplier of Project A in the R&D Department, as an example. First, the tracing instruction is received and key identifiers are extracted. The tracing request triggered by the user after selecting the data point is used to receive the tracing instruction. The voucher identifier and the version identifier of the aggregation result are extracted from the metadata of the data point. The voucher identifier is the unique identifier of the specific business document associated with the data point, corresponding to the original business document of a certain abnormal travel expense. The version identifier of the aggregation result records the generation version of the aggregation result to which the data point belongs. Since the aggregation result will be updated when new records are added later, the version identifier is used to lock the original record range when the data point was generated.

[0152] Based on the extracted version identifier, the version records of the data cube are queried, which records the range of business fact records corresponding to each version's aggregation result. This locates the range of voucher identifiers associated with that version, which is the set of voucher identifiers for all business fact records included when the corresponding version's aggregation result was generated. This ensures that the traceability is of the business fact record at the time the data point was generated, not a subsequently updated record. From the located voucher identifier range, business fact records that completely match the extracted voucher identifiers are selected. These records contain complete information, including accounting vouchers, associated basic accounting tags or dynamic business tags, verification tags, and the document number of the original business document. Thus, by extracting voucher identifiers and version identifiers, the range of original records corresponding to a specific data point is accurately located, avoiding tracing errors caused by version updates of the aggregation result. By filtering matching records based on the range, the link from the data point to the business fact record is unique and complete, providing a reliable intermediate node for subsequent tracing to accounting vouchers and business entities, ensuring the accuracy and auditability of data tracing.

[0153] Business fact records serve as the intermediate nodes connecting aggregation results with accounting vouchers and original business documents. The voucher identifier in these records is the core basis for associating accounting vouchers. If the voucher identifier in the business fact record is inconsistent with the identifier of the accounting voucher itself, it will lead to a break in the traceability chain or association with incorrect accounting vouchers. For example, associating a voucher from business A with a record from business B directly affects the accuracy of data traceability and audit reliability. Taking the business fact record matched when tracing low-risk abnormal travel expenses of B company, the core supplier of project A in the R&D department, as an example, the accounting voucher and document number are first extracted from the matched business fact record. The accounting voucher refers to the complete voucher content contained in the accounting information area of ​​the record, and the document number refers to the document number associated with the core identifier area of ​​the record, corresponding to B company's travel expense reimbursement form.

[0154] The voucher identifier of the business fact record is extracted from its core identifier area, and its own voucher identifier is extracted from the accounting voucher. The two identifiers are directly compared. If they are completely consistent, the association is deemed valid and the current association relationship is retained. If they are inconsistent, a re-association verification process is immediately triggered. In the case of inconsistency, the process first traces back to the generation log of the business fact record to check the voucher identifier association process when the record was created, such as whether the identifier entry deviation was caused by data transmission errors. If the log shows that the association process is correct, the process further checks whether the identifier of the accounting voucher has been updated. For example, if the voucher was renumbered due to subsequent adjustments, the process confirms whether it is the historical identifier of the voucher by calling the historical version record of the accounting voucher. If the inconsistency is indeed caused by an identifier update, the voucher identifier of the business fact record is updated to the current valid identifier, and the update log is recorded. If the original association is incorrect, the correct accounting voucher is re-matched, the association relationship in the business fact record is corrected, and the consistency verification is performed again until the two are consistent.

[0155] By extracting accounting vouchers and document numbers, the objects to be traced are clearly identified. Consistency checks directly intercept voucher identification association errors, avoiding traceability failures or mismatches caused by inconsistent identifications. Re-association checks correct deviations by backtracking logs and checking historical versions, rather than simply discarding data. This ensures the accuracy of the association relationship and prevents the loss of effective data, providing a reliable association foundation for subsequent full-chain traceability.

[0156] Original business documents are the original carriers of business transactions, recording the true attributes of business entities and the business scenario at the time. Only by tracing back to the original business documents can the actual basis for assigning business tags be accurately restored. At the same time, business tagging rules will iterate over time. If the current business tagging rules are used to verify historical tags, it will lead to judgment bias. It is necessary to retrieve the historical rules that were matched at that time, recalculate the similarity and verify the adaptability. This is to confirm whether the historical business tags conform to the rule logic at that time, and to check whether the tagging bias is caused by omissions in attribute extraction and errors in rule application, so as to ensure that the traceability of business tags is verifiable and the results are trustworthy.

[0157] Taking the low-risk abnormal travel expenses of Company B, a core supplier of Project A in the R&D Department, as an example, the process is as follows: First, the original document is traced back using the document number. This connects to the company's internal business document management system. The storage path of the original business document is located based on the document number, and the corresponding original business document is retrieved. During the tracing process, sensitive information in the document, including supplier bank accounts and personal reimbursement details, is filtered according to the user's business permissions, retaining only the core content related to business tag verification. Then, the corresponding business entity and its financial attributes at that time are extracted from the traced original reimbursement form. For example, the reimbursement form indicates "2 years of cooperation with Company B, no overdue payment records in the past year, and this service is exclusive to Project A." At the same time, the business tag rules that matched the business entity at that time are retrieved. Through the rule identifier associated with the business fact record, the effective core supplier business tag rules are located. These business tag rules clearly define the core supplier's judgment attributes, attribute priorities, and attribute similarity thresholds. For example, cooperation years greater than or equal to 1 year, no overdue records, and association with key projects are core judgment attributes. Attribute priorities are sorted by cooperation stability over project relevance.

[0158] According to the business tagging rules at the time, the similarity between the business entity and the core supplier tag values ​​is recalculated. The recalculated similarity result is compared with the business tag assigned at the time. If the recalculated similarity meets the threshold of the rules at the time and is consistent with the historical business tag, the verification conclusion is that the business tag matches and is suitable, and the tagging basis at the time is sufficient. If the recalculated similarity does not reach the threshold, the conclusion is that the suitability of the business tag is questionable, and the deviation is due to the incomplete extraction of financial attributes at the time. The reason for the deviation is recorded for reference in subsequent business tagging rule optimization or financial attribute extraction correction.

[0159] By retrospectively analyzing original business documents, the actual business scenarios and attribute bases at the time of business tag assignment are fully restored, avoiding information deviations caused by relying on subsequent records. Business tag rules are retrieved to ensure the objectivity of similarity calculation and verification, eliminating judgment interference caused by rule iteration, and recalculating and verifying. This not only confirms the rationality of historical business tags but also accurately locates the causes of tag deviations, providing a practical basis for subsequent optimization of business tag rules or extraction of financial attributes, forming a closed-loop process of tracing, verification, and optimization. At the same time, the verification results can be directly used for iterative optimization of business tag rules or correction of historical business tags, improving the accuracy of business tags in financial auxiliary accounting and ensuring the reliability of subsequent accounting data and analysis results.

Claims

1. A method for agent-assisted accounting and data analysis, characterized in that, include: Receive the business tag dimensions and corresponding tag values ​​configured by the user, establish the association rules between the business tag dimensions and accounting subjects, and establish the mapping rules between business entities and tag values ​​based on the similarity of financial attributes to form business tag rules; Receive original business documents, parse the text in the original business documents through natural language processing to identify business entities and financial attributes, match them with business tagging rules, automatically assign business tags to financial entries, calculate tag confidence and compare them with preset thresholds to judge abnormal tags, and output accounting data after confirmation. Parallel processing of accounting data generates accounting vouchers and voucher identifiers. After associating accounting data with voucher identifiers, business fact records are constructed. New business fact records are captured through stream processing. Based on incremental aggregation rules, the new records are processed and injected into the data cube in real time. Responding to user query requests for data cubes, it performs drill-down analysis based on any combination of business tag dimensions and outputs analysis results with anomaly tags. Responding to source tracing instructions for specific data points, it traces back accounting vouchers and business entities based on associated voucher identifiers.

2. The agent-assisted accounting and data analysis method as described in claim 1, characterized in that, The rules for forming business tags include: Extract the financial attributes of business entities, assign priority weights to the financial attributes according to accounting standards and business rules, and set attribute similarity thresholds for different types of business entities; The similarity threshold is automatically calibrated based on historical matching accuracy. The similarity between the financial attributes of the business entity and the financial attributes corresponding to the tag value is calculated. After being weighted and summed based on priority weights, it is compared with the calibrated similarity threshold to form a mapping rule between the business entity and the tag value. By calculating the rule matching rate and anomaly identification rate through historical financial accounting records, the associated rules and mapping rules are validated. Rules that fail the validation are triggered for manual review, and the risk adaptation weight or attribute similarity threshold is automatically optimized based on the review results to form automatically iterative business marking rules.

3. The agent-assisted accounting and data analysis method as described in claim 2, characterized in that, Establishing the association rules includes: Receive the business tag dimensions and corresponding tag values ​​configured by the user, and divide the business tag dimensions into basic accounting dimensions and dynamic business dimensions according to accounting requirements; Extract accounting attributes from accounting subjects, including accounting scope and risk level; establish fixed association rules between basic accounting dimensions and accounting subjects within the accounting scope; and set modification constraints for the fixed association rules according to the risk level. By combining the validity period and business stage of dynamic business dimensions with the business lifecycle, the number of dynamic business dimensions to be bound is determined according to the risk level. After matching the business stage, conditional association rules between dynamic business dimensions and accounting subjects are established, and risk adaptation weights are configured for each conditional association rule.

4. The agent-assisted accounting and data analysis method as described in claim 1, characterized in that, The output accounting data includes: Based on the automatically assigned basic business tags and dynamic business tags, the confidence scores of matching accuracy, rule validity, and business compliance are calculated respectively, and then weighted and summed to obtain the tag confidence score. Based on the risk level, a preset threshold is set, and the confidence level of the label is compared with the preset threshold to determine whether it is a normal label, a low-risk anomaly, or a high-risk anomaly. When the dynamic business dimension expires, it is determined to be a high-risk anomaly. When a low-risk anomaly occurs, it is automatically confirmed by comparing the markings of similar historical documents. If the comparison is consistent, it is calibrated to a normal marking. When a high-risk anomaly occurs, the business marking assignment process is traced back and the original business documents are checked and confirmed. If the exception flag fails to pass the confirmation, return to the business flag assignment process, generate a verification flag for the confirmed business flag, bind it with the financial entry, and output the accounting data with the verification flag.

5. The agent-assisted accounting and data analysis method as described in claim 4, characterized in that, Automatically assigning the service tag includes: Receive original business documents, parse the text in the original business documents through natural language processing, identify business entities and financial attributes, match the accounting scope of accounting subjects based on the identified financial attributes, and call the business marking rules within the accounting scope. Match the financial attributes with the financial attributes corresponding to the tag values ​​of the basic accounting dimensions. If they match, assign a basic business tag. If they do not match, trigger an error message about the basic accounting dimension matching. Based on risk-adaptive weights, the financial attributes corresponding to the labeled values ​​of financial attributes and dynamic business dimensions are summed with similarity weights. When the summation result is not less than the result threshold, a dynamic business label is assigned. Associate the basic business tags and dynamic business tags with the auxiliary accounting fields of the financial entries respectively, and generate and output the financial entries with auxiliary accounting tags.

6. The agent-assisted accounting and data analysis method as described in claim 1, characterized in that, The real-time injected data cube includes: Initialize the stream processing channel, identify new business fact records based on voucher identifiers, and configure a capture trigger mechanism in conjunction with the accounting cycle to capture new business fact records; The newly captured records are checked for integrity. If they are incomplete, they are recaptured. If they are complete, the dimension codes and verification levels in the new records are parsed. The target level is assigned based on the hierarchical structure of the data cube adapted to the dimension codes. The incremental aggregation rules are invoked based on the validity period of the verification level and dynamic business dimension to process new records, generating incremental aggregation results and enhanced aggregation results with voucher identifiers; Partitions are created in the data cube based on the target level. Incremental aggregation results are injected into fixed-dimensional partitions, and enhanced aggregation results are injected into variable-dimensional partitions. During the injection process, the consistency between the dimension encoding and the target level is checked. If there is a discrepancy, the injection is paused and the adaptation relationship of the target level is updated. Generate a version identifier for the injected aggregation result, associate it with the partition of the data cube, and record the credential identifier of the corresponding business fact record.

7. The agent-assisted accounting and data analysis method as described in claim 6, characterized in that, The constructed business fact record includes: Receive accounting data with verification marks, generate accounting vouchers including voucher identifiers based on the accounting attributes of accounting subjects and accounting standards, and simultaneously parse the dimension code of business marks and the verification level of verification marks in the accounting data; Using the voucher identifier as the link, the dimension code and verification level are embedded into the additional information of the accounting voucher, and the verification mark in the accounting data and the document number of the original business document are linked to verify the consistency between the dimension code and the accounting scope. If they are inconsistent, they are re-linked. Integrate accounting vouchers, voucher identifiers, associated dimension codes, verification levels, verification marks, and original business document document numbers to construct a business fact record.

8. The agent-assisted accounting and data analysis method as described in claim 1, characterized in that, The reverse traceability accounting vouchers and business entities include: Receive user instructions to trace the source of specific data points, extract the voucher identifier associated with the specific data point and the version identifier of the aggregation result, query the data cube based on the version identifier and locate the range of voucher identifiers associated with the version identifier, and filter out business fact records that match the voucher identifier. Extract accounting vouchers and document numbers from the matched business fact records, and verify the consistency between the voucher identifier in the business fact records and the voucher identifier in the accounting vouchers. If they are inconsistent, trigger a re-association verification. Based on the document number, the corresponding original business document is traced back to extract the corresponding business entity and the matching business tagging rule at that time. The similarity between the business entity and the tag value is recalculated by calling the business tagging rule to verify the matching and adaptability of the business tag.

9. The agent-assisted accounting and data analysis method as described in claim 8, characterized in that, The analysis results with anomaly markers in the output include: Receive user query requests for data cubes, parse the combination of business tag dimensions in the query request, extract the judgment criteria for anomaly tags in the query request, and form a query parameter set; Based on the query parameter set, locate the partitions of the data cube, match fixed-dimensional partitions according to the basic accounting dimension, match variable-dimensional partitions according to the dynamic business dimension, and filter the aggregation results within the partitions that include anomaly markers. Aggregate analysis is performed in a hierarchical order prioritizing basic accounting dimensions and followed by dynamic business dimensions. If only basic accounting dimensions are included, the first aggregation analysis is performed based on the incremental aggregation results of fixed dimension partitions. For each dynamic business dimension overlaid, the enhanced aggregation result of the corresponding variable dimension partition is matched, and a second aggregation is performed with the first aggregation result. The second aggregation result is then integrated to output the analysis result.

10. The agent-assisted accounting and data analysis method as described in claim 2, characterized in that, Financial attributes include enumeration type, descriptive type, and duration type.