A system and method for processing data for the cancellation of a voucher based on a flow map

Abstract

The application discloses a voucher cancellation data processing system and method based on a flow conversion graph, and belongs to the technical field of voucher data processing. The method specifically comprises the following steps: obtaining voucher data of an enterprise, and generating a voucher flow conversion graph according to the flow conversion path, processing time sequence and account relationship of the voucher in the enterprise; generating a cancellation strategy for each voucher based on the voucher flow conversion graph; and canceling each voucher, performing account distribution trial calculation on the canceled vouchers in a virtual account book unit, automatically optimizing the account distribution according to the multi-dimensional account book consistency, budget constraints and project cost distribution requirements, and automatically deducing the abnormal root cause according to the voucher flow conversion graph simulation causal path in the cancellation or account distribution process. The application greatly improves the efficiency and accuracy of cancellation and account distribution, reduces manual intervention, and significantly enhances the refinement and reliability of enterprise financial management.

Description

Technical Field

[0001] This invention belongs to the field of voucher data processing technology, specifically a voucher verification data processing system and method based on flow graphs. Background Technology

[0002] As businesses grow rapidly, the number and complexity of vouchers increase exponentially. Traditional voucher reconciliation and accounting methods mainly rely on manual operations or automated tools based on fixed rules. Traditional rules usually rely on static rules or fixed matching logic, which are difficult to cope with cross-system, multi-business-line and complex accounting scenarios, and lack flexibility and adaptability.

[0003] Existing voucher reconciliation processes often rely on matching voucher amounts, corresponding accounts, or simple chronological order, neglecting the dynamic flow of vouchers among departments, projects, and cost centers within the enterprise, as well as the impact of historical reconciliation patterns on reconciliation strategies. Furthermore, separate accounting is typically executed directly in the actual ledgers, lacking virtual trial calculations and multi-dimensional consistency verification, which can easily lead to incorrect allocations or conflicts, increasing the workload of financial review and adjustments. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes a voucher reconciliation data processing system and method based on a flow graph. This system can combine voucher flow paths, historical flow patterns, real-time ledger status, and multi-dimensional constraints to achieve automated reconciliation, virtual ledger trial calculations, and a closed loop for anomaly handling, thereby improving the accuracy, efficiency, and intelligence of financial accounting management.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] The data processing method for voucher reconciliation based on flow graphs includes:

[0007] The system acquires the voucher data of the enterprise and generates a voucher flow graph based on the voucher's internal flow path, processing time sequence, and account relationships. The graph is used to describe the dynamic transmission and dependency relationships of each voucher between different ledgers, departments, and projects.

[0008] Based on the voucher flow graph, a reconciliation strategy is generated for each voucher, and each voucher is reconciled. The reconciliation strategy is dynamically adjusted according to the real-time ledger status and historical flow pattern, including reconciliation order, reconciliation amount allocation, and matching priority.

[0009] After the vouchers are reconciled, a trial calculation is performed in the virtual ledger unit. The calculation is automatically optimized based on the consistency of the multi-dimensional ledgers after the calculation, budget constraints, and project cost allocation requirements. When the trial calculation results meet the constraints, the calculation results are synchronized to the real ledger.

[0010] For abnormal vouchers generated during the reconciliation or accounting process, the cause-and-effect path is simulated based on the voucher flow diagram to automatically deduce the root cause of the abnormality.

[0011] Specifically, the process of acquiring the enterprise's voucher data and generating a voucher flow graph based on the voucher's internal circulation path, processing time sequence, and account relationships includes:

[0012] Obtain voucher records from within the enterprise and mark the transaction entity, transaction amount, transaction time, and account identifier for each voucher;

[0013] Based on the processing logs and account interaction information of vouchers within the enterprise, the complete flow of vouchers from creation, approval, accounting to settlement is tracked layer by layer, and the time sequence and account relationship of each flow node are recorded.

[0014] Each flow node is mapped to its associated department, project, and contract terms to generate a multi-dimensional relationship between flow nodes, and a topological logical connection is established for the order and interaction frequency of flow nodes.

[0015] The processing time sequence of the voucher circulation nodes is mapped into operable sequential logic, and dynamic node links are generated based on the sequential relationship between nodes and the parallel processing status.

[0016] Based on the flow nodes, relationships, and time series links, a voucher flow graph is constructed.

[0017] Specifically, the construction of a voucher flow graph based on flow nodes, relationships, and time-series links includes:

[0018] The identified voucher flow nodes are integrated sequentially, and a node sequence is established according to the flow order of vouchers between different ledgers, departments and projects. The associated account, transaction amount and contract terms information are recorded in each node.

[0019] Cross-mapping is performed on the department, project, and account relationships between nodes in the node sequence to generate a multi-dimensional logical association matrix between nodes, and the multi-dimensional logical relationships between nodes are marked, including sequential dependencies and parallel processing paths;

[0020] Based on the node sequence and multidimensional association matrix, node links are dynamically generated according to the time sequence and interaction frequency of voucher circulation, so that each link reflects the possible multi-path circulation status of vouchers and node dependencies.

[0021] Based on node sequences, multidimensional logical association matrices, and node links, a voucher flow graph covering vouchers across various ledgers, departments, and projects within the enterprise is formed.

[0022] Specifically, based on the voucher flow graph, a reconciliation strategy is generated for each voucher, and each voucher is reconciled, including:

[0023] Based on the voucher flow map, identify the write-off target for each voucher, including ledger, department, project and related transaction amount, and establish a mapping relationship between the write-off target and the historical flow pattern;

[0024] Based on the node sequence and multi-dimensional logical relationship of the voucher in the voucher flow graph, multiple reimbursement path candidates for the voucher are generated. Each path includes the reimbursement order, reimbursement amount allocation and potential matching priority, and the dependencies and conflict possibilities between paths are marked.

[0025] For each write-off path candidate, obtain the real-time ledger status, dynamically compare the path candidate with the real-time ledger status, and identify the set of executable paths. The real-time ledger status includes available balance, write-off records, and budget constraints.

[0026] The optimal path is selected from the set of executable paths, and a reconciliation strategy for each voucher is automatically generated. At the same time, the strategy is dynamically adjusted according to the historical flow pattern to adapt to changes in the ledger status. The reconciliation strategy includes specific reconciliation order, amount allocation and matching priority.

[0027] The reconciliation operation is executed sequentially according to the generated reconciliation strategy. The reconciliation results are fed back to the flow graph and ledger status for subsequent voucher path generation and strategy adjustment, realizing the closed-loop logic of the reconciliation operation.

[0028] Specifically, for each reimbursement path candidate, the real-time ledger status is obtained, and the path candidate is dynamically compared with the real-time ledger status to identify the set of executable paths, including:

[0029] The nodes in each candidate reimbursement path are mapped sequentially to the corresponding ledger, and the account, transaction amount and time information associated with the node are extracted to form a path node mapping set;

[0030] The real-time ledger status of each account is obtained sequentially, including available balance, written-off records and budget constraints, and associated with the path node mapping set to form a ledger status mapping table;

[0031] The system performs a logical comparison between the candidate write-off paths and the ledger status mapping table for each node. It identifies the executability of nodes based on the matching of node amount with available balance, node order with write-off records and budget constraints, and marks the node sequence affected by constraints in the path.

[0032] Based on the node executability label, all complete paths that meet the ledger status constraints are selected from the reversal path candidates to form an executable path set.

[0033] Specifically, the process involves selecting the optimal path from the set of executable paths and automatically generating a reconciliation strategy for each voucher, including the specific reconciliation order, amount allocation, and matching priority. Simultaneously, the strategy is dynamically adjusted based on historical processing patterns, including:

[0034] Priority scores are generated based on the node order, node amount distribution, and historical flow patterns of each path in the executable path set. The frequent node matching patterns are combined with the path order to form a comprehensive scoring system.

[0035] Based on priority scoring, the path with the highest score is selected as the basis for reimbursement execution, and the execution order and candidate value for amount allocation for each node in the path are marked.

[0036] By combining historical voucher circulation patterns and current ledger status, the reconciliation order, amount allocation, and matching priority of the selected path are adjusted node by node to generate a reconciliation strategy that can be executed directly, while retaining the flexibility of the strategy to adapt to changes in the ledger.

[0037] The dynamically adjusted path information is transformed into specific reimbursement strategies, including the reimbursement order, reimbursement amount allocation, and matching priority for each voucher, and the strategies are associated with the voucher flow graph and the set of executable paths.

[0038] Specifically, the process of performing a trial calculation of the reconciled vouchers in a virtual ledger unit, automatically optimizing the calculation based on the consistency of the multi-dimensional ledgers after the calculation, budget constraints, and project cost allocation requirements, and synchronizing the calculation results to the real ledger when the constraints are met, includes:

[0039] The reconciled vouchers are mapped to the corresponding virtual ledger units, and the department, project and related cost center information of the voucher are recorded in each virtual unit;

[0040] Based on the voucher flow diagram and the information recorded in the virtual ledger unit, multiple accounting scheme candidates are generated. Each scheme includes the preliminary allocation ratio and sequence of voucher amounts in different departments, projects and cost centers.

[0041] For each candidate revenue sharing scheme, the consistency of the multidimensional ledger, budget constraints, and project cost allocation requirements in the virtual ledger are compared node by node. Nodes that do not meet the constraints and their revenue sharing ratios are marked to form a set of constraint markers.

[0042] Based on the constraint tag set and the virtual ledger status, the accounting ratio and node order are dynamically adjusted to generate a set of optimized accounting schemes that meet the requirements of multidimensional ledger consistency and budget constraints.

[0043] The results of optimizing the revenue sharing scheme and satisfying all constraints will be synchronized to the actual ledger, and the ledger status and voucher flow graph will be updated.

[0044] Specifically, based on the voucher flow diagram and the information recorded in the virtual ledger unit, multiple candidate accounting schemes are generated, including:

[0045] The amount of the written-off vouchers is initially broken down according to the department, project and cost center association information recorded in the voucher flow diagram to form a set of amount breakdown units;

[0046] Based on the flow order of nodes in the virtual ledger unit and the dependencies between nodes, generate the allocation order link for each split unit, and mark the parallel allocation path and node priority;

[0047] By combining the amount splitting unit with the allocation sequence link, multiple preliminary accounting scheme candidates are generated. Each scheme reflects the allocation ratio and node sequence possibilities of different departments, projects and cost centers.

[0048] Establish a mapping relationship between each candidate revenue sharing scheme and the node information in the voucher flow graph and virtual ledger unit.

[0049] Specifically, the step of dynamically adjusting the accounting allocation ratio and node order based on the constraint tag set and the virtual ledger state to generate an optimized accounting allocation scheme set that satisfies multidimensional ledger consistency and budget constraints includes:

[0050] The information in the constraint tag set is parsed one by one, and the tags are associated with the virtual ledger nodes and the amount splitting units in the splitting scheme to identify the splitting nodes affected by the constraints and their allocation ratio range.

[0051] Based on the parsed constraint information, the revenue sharing ratio of each node is adjusted sequentially according to node priority and ledger status to generate multiple revenue sharing scheme candidates.

[0052] By combining the dependencies between nodes and the possibility of parallel processing, the order of nodes in each revenue sharing scheme is dynamically adjusted to form an optimized sequential link that satisfies the constraint information.

[0053] The revenue sharing schemes, which have been adjusted in proportion and optimized in node order, are integrated to generate a final optimized revenue sharing scheme set, which satisfies the requirements of multidimensional ledger consistency, budget constraints, and project cost allocation.

[0054] The voucher reconciliation data processing system based on flow graph is used to implement the voucher reconciliation data processing method based on flow graph, including: a graph generation module, a reconciliation module, an accounting processing module, and an anomaly tracing module.

[0055] The graph generation module is used to acquire the voucher data of the enterprise and generate a voucher flow graph based on the voucher's internal flow path, processing time sequence and account relationship. The graph is used to describe the dynamic transmission and dependency relationship of each voucher between different ledgers, departments and projects.

[0056] The reconciliation module is used to generate a reconciliation strategy for each voucher based on the voucher flow graph, and to reconcile each voucher. The reconciliation strategy is dynamically adjusted according to the real-time ledger status and historical flow pattern, including reconciliation order, reconciliation amount allocation and matching priority.

[0057] The accounting module is used to perform accounting trial calculations on the reconciled vouchers in the virtual ledger unit, automatically optimize the accounting based on the consistency of the multi-dimensional ledger after accounting, budget constraints and project cost allocation requirements, and synchronize the accounting results to the real ledger when the trial calculation results meet the constraints.

[0058] The anomaly tracing module is used to simulate causal paths based on the voucher flow graph and automatically deduce the root cause of anomalies in abnormal vouchers generated during the reconciliation or accounting process.

[0059] Compared with the prior art, the beneficial effects of the present invention are:

[0060] This invention proposes a voucher reconciliation data processing system and method based on a voucher flow graph. It constructs an enterprise voucher flow graph, combines multi-scheme accounting trials of vouchers in virtual ledger units, sequentially generates dynamic reconciliation strategies and executes reconciliation, and simultaneously performs multi-path causal deduction and intelligent collaborative processing for abnormal vouchers. This achieves closed-loop automated operation of vouchers from acquisition and reconciliation to accounting and anomaly handling. This method can significantly improve the efficiency and accuracy of reconciliation and accounting while ensuring consistency of multi-dimensional ledgers, budget constraints, and project cost allocation requirements. It reduces manual intervention and achieves intelligent, traceable, and continuously optimized financial processing, thereby significantly enhancing the refinement and reliability of enterprise financial management. Attached Figure Description

[0061] Figure 1 A flowchart of the voucher reconciliation data processing method based on flow graph provided by the present invention;

[0062] Figure 2 This is a schematic diagram of the voucher flow chart provided by the present invention;

[0063] Figure 3 A schematic diagram illustrating the reconciliation strategy provided by this invention;

[0064] Figure 4 This is a diagram illustrating the architecture of a voucher verification data processing system based on flow graphs, provided by the present invention. Detailed Implementation

[0065] The present application will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0067] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," and "third" used in this application do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0068] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0069] Example 1

[0070] Please see Figure 1 The present invention provides an embodiment of a voucher reconciliation data processing method based on a flow graph, comprising the following specific steps:

[0071] Step S1: Obtain the voucher data of the enterprise, and generate a voucher flow graph based on the voucher's internal flow path, processing time sequence and account relationship. The graph is used to describe the dynamic transmission and dependency relationship of each voucher between different ledgers, departments and projects.

[0072] The specific steps of step S1 are as follows:

[0073] Step S101: Obtain voucher records from within the enterprise and mark the transaction subject, transaction amount, transaction time, and account identifier for each voucher.

[0074] In this embodiment, voucher records within the enterprise are acquired through multi-source data acquisition channels, specifically including the enterprise's intranet financial system, financial accounting system, and cloud accounting system. After acquiring the voucher records, structured marking processing is performed on each voucher. Specifically, the payer's name, payee's name, and unified social credit code are extracted from the voucher text. The transaction amount is marked by matching all numeric fields in the voucher using regular expressions, and the amount type (such as tax-inclusive amount, tax-exclusive amount, and handling fee) is determined based on the context semantics. The total transaction amount is automatically extracted and converted into integer data stored in cents. The transaction time is marked by extracting the invoice date, payment date, and accounting date fields from the voucher, converting them to UTC time format, and automatically adjusting them to the local time according to the enterprise's time zone. The account identifier is marked by extracting information such as bank account number, internal department code, and project number from the voucher. The bank account number is anonymized by retaining the first 6 digits and the last 4 digits and replacing the middle part with asterisks. At the same time, a mapping relationship between the account identifier and the enterprise's internal chart of accounts is established, ultimately generating a structured voucher dataset containing a unique code of the transaction entity, an integer transaction amount, transaction time, and account identifier.

[0075] Step S102: Based on the processing logs and account interaction information of the voucher within the enterprise, trace the complete flow nodes of the voucher from creation, approval, accounting to settlement layer by layer, and record the time sequence and account relationship of each flow node.

[0076] In this embodiment, the distributed log collection framework Flume is first used to connect to the log data sources of all business systems within the enterprise. Specifically, structured log data containing voucher number, voucher ID, process instance ID, operator ID, operation type, operation time, account number, and transaction serial number is collected in real time from application server logs, operation audit logs, process engine logs, message consumption logs, and transaction interaction logs. After log collection is completed, a multi-source log association index is constructed using the unique voucher code in the structured voucher data generated in step S101 as the primary key. Specifically, the unique voucher code is first compared with the voucher number field in the log. For logs that are precisely matched, a successful match is directly associated with the corresponding voucher. For logs that fail to match, a fuzzy matching algorithm based on a sliding time window is used, with the time window size set to 10 minutes. The similarity of the transaction amount, the name of the transaction entity, and the account identifier is weighted and calculated. In the comprehensive calculation, the transaction amount has the highest weight, followed by the name of the transaction entity, and the account identifier has a relatively lower weight. Specifically, the weight can be set to 40-45% for the transaction amount, 30-35% for the name of the transaction entity, and 20-30% for the account identifier. When the weighted similarity is greater than or equal to 90%, the log is associated with the corresponding voucher and marked as a fuzzy association record.

[0077] After completing the log association, the complete flow nodes of the voucher are tracked layer by layer. Specifically, starting from the voucher creation node, all associated process logs are recursively traversed through the process instance ID to identify the document submission node, the first-level department approval node, the second-level financial review node, the third-level general manager approval node, the financial document preparation node, the voucher review node, the accounting entry node, and the bank settlement node in sequence. For nodes that flow across systems, they are associated with the bank's front-end logs through the transaction serial number to complete the settlement processing nodes on the bank side. During the tracking process, the time series data of each flow node is recorded synchronously. The start time, end time, and time consumed by each node are extracted and uniformly converted into the standard UTC time format with millisecond accuracy. At the same time, all account information involved in each node is recorded, including the internal account of the applying department, the financial accounting account, the bank's corporate account, and the counterparty's transaction account. A directed graph of account relationships is constructed, where nodes represent accounts, directed edges represent the flow of funds and the corresponding flow nodes, and the weight of the edge is the transaction amount of that node.

[0078] Step S103: Map each flow node to its associated departments, projects and contract terms to generate multi-dimensional relationships between flow nodes, and establish topological logical connections for the order and interaction frequency of flow nodes.

[0079] In this embodiment, based on the voucher circulation tracking dataset generated in step S102, the following steps are taken: First, department master data containing department code, department level, employee's department and job permissions is obtained; project master data containing project number, project name, project status, project leader and budget item information is obtained; and structured contract data containing contract number, contract validity period, transaction entity, payment node terms, settlement method and amount splitting rules are obtained. Then, the mapping operation between circulation nodes and related entities is performed. Specifically, department mapping is performed using the unique identifier of the employee master data recorded by the circulation node; project mapping is performed by precise matching using the project number associated with the voucher; and contract term mapping is performed by precise matching using the voucher number and the associated voucher number field. After completing the single-dimensional mapping, a multi-dimensional association relationship based on an attribute graph is constructed. Each circulation node is used as a core vertex, and the department, project, and contract term are used as attribute vertices. The directed edges between vertices represent the association relationship. The edge attributes include the association method (exact matching / fuzzy matching), association confidence, and association timestamp. At the same time, three types of multi-dimensional association subgraphs are generated: circulation node-department-project, circulation node-contract-payment terms, and circulation node-account-accounting item.

[0080] Based on this, a topological logical connection is established, the legality of the node link is verified based on the time series data of each node, and a weighted adjacency matrix is ​​constructed, where the matrix element value is the standardized interaction frequency between nodes. For shared nodes across systems and processes (such as the unified approval node of the CFO), their full historical interaction data is statistically analyzed and updated to the topology matrix.

[0081] Step S104: Map the processing time sequence of the voucher transfer nodes into operable sequential logic, and generate dynamic node links based on the sequential relationship between nodes and the parallel processing status.

[0082] In this embodiment, the processing time of each voucher flow node is abstracted as a closed interval [T_start, T_end]. By calculating the intersection, union, and inclusion relationship of the time intervals of any two nodes, four core business logic relationships among the 13 basic time relationships are accurately identified: strict precedence, start at, end at, and overlap. The strict precedence relationship is defined as node A's T_end being earlier than node B's T_start with a time interval greater than or equal to 1 second. The overlap relationship is defined as the length of the intersection of the time intervals of two nodes being greater than 30% of the total length of their respective intervals. Based on this, for multi-branch nodes defined by the parallel gateway in the process definition, regardless of whether their actual execution time overlaps, they are all marked as valid parallel nodes. For nodes with a strict precedence relationship in the process definition but overlapping execution times, they are marked as abnormal parallel nodes and the degree of abnormality is recorded.

[0083] Then, a dynamic node link is generated. Specifically, the voucher creation node is used as the starting vertex and the bank settlement node is used as the ending vertex. An adjacency list is constructed according to the sequential logical relationship obtained by mapping. Vertices with an in-degree of 0 are removed and added to the link sequence in turn. For parallel node groups, they are encapsulated as composite nodes and the parallel relationship of each node in the group is retained. At the same time, nodes that are not triggered are automatically pruned according to the actual execution condition branches. For example, for daily expense vouchers with a transaction amount of less than 50,000 yuan, the general manager approval node in the process definition is automatically omitted. For vouchers involving fixed asset procurement, asset acceptance node and warehousing registration node are automatically added. During the link generation process, the time interval of each edge, the percentage of node processing time, and the completion order of parallel nodes are calculated synchronously. For vouchers with multiple optional paths, a unique dynamic link identifier is generated based on the actual executed node sequence. At the same time, the deviation rate between the link and the standard process template is recorded. The deviation rate is calculated by dividing the number of node differences between the actual link and the standard process by the total number of nodes in the standard process. Finally, the link integrity is verified. For links that are missing key nodes (such as financial document preparation nodes and accounting entry nodes), they are automatically marked as incomplete links, and the location and type of the missing nodes are generated, ultimately generating dynamic node links.

[0084] Step S105: Construct a voucher flow graph based on flow nodes, relationships, and time series links.

[0085] In this embodiment, based on the dynamic node link of the voucher generated in step S104 and the flow nodes, multi-dimensional associations, and time series data obtained in the previous steps, a voucher flow graph is constructed in four steps. Specifically, the first step is to integrate the flow nodes and establish a node sequence. First, all identified flow nodes are temporarily stored using Redis caching technology. Using the unique voucher code as the grouping key, all flow nodes corresponding to each voucher are extracted. Combined with the standardized time series of each node, the nodes are arranged in an orderly manner according to the actual flow order of the voucher in different ledgers such as general ledger, subsidiary ledger, and auxiliary ledger, different departments such as finance department, business department, and purchasing department, and between various projects, forming a unique node sequence. At the same time, the account information marked in step S101, transaction amount data, and contract terms information mapped in step S103 are queried by SQL association. The account anonymization identifier, transaction amount (integer in cents), unique code of contract terms, and core terms (such as payment deadline and amount ratio) are embedded into the attribute fields of each node to ensure the integrity of the node information.

[0086] The second step generates a multidimensional logical association matrix between nodes. A two-dimensional matrix is ​​constructed with the nodes in the node sequence as rows and columns. Based on the multidimensional association relationship in step S103, the department, project, and account relationships between nodes are cross-mapped. The cosine similarity algorithm is used to calculate the association degree between any two nodes in terms of department affiliation, project association, and account interaction. The association metric is quantified into a value between 0 and 1 and filled into the corresponding position in the matrix. At the same time, the multidimensional logical relationship between nodes is marked by binary labeling, where 10 represents a strict sequential dependency relationship, 01 represents a parallel processing path, and 11 represents a relationship with both sequential dependency and partial parallel interaction. The labeling results are stored as additional attributes of the matrix.

[0087] The third step dynamically generates node links. Based on the node sequence, combined with the multidimensional logical association matrix and the interaction frequency data from step S104, the existing LSTM prediction model is used to predict the circulation path of vouchers in different scenarios. For node combinations with an interaction frequency higher than a preset threshold (e.g., ≥50 interactions per month), their link weights are automatically strengthened. For abnormal node combinations with extremely low interaction frequencies (e.g., <3 interactions per quarter), they are marked as potential abnormal links and their frequency of occurrence is recorded. At the same time, the legal parallel paths and abnormal parallel paths identified in step S104 are retained, so that each link can reflect the multi-path circulation status of vouchers and the dependency constraints between nodes.

[0088] It should be noted that the training of the LSTM prediction model is explained as follows:

[0089] Training data: Complete historical voucher circulation data for 36 months, including node sequences, department / project / account associations, transaction amounts, and time series; Input features: Node encoding (one-hot encoding), department / project association vectors, time interval features (node ​​time consumption), and historical reconciliation success rate; Model structure: 2-layer LSTM network, 128 hidden units per layer, Dropout 0.2; Output layer Softmax, predicting the probability distribution of the next node; Training parameters: Learning rate 0.001, batch size 64, 50 training epochs, loss function is cross-entropy; Prediction strategy: Node paths with predicted probability > threshold 0.5 are considered high-probability links, while low-probability paths are recorded for anomaly analysis.

[0090] The fourth step is to form a complete voucher flow graph. The nodes in the node sequence are used as vertices of the graph, and the multi-dimensional logical relationships between nodes are used as directed edges between vertices. The weight of the edge is determined by the degree of association in the association matrix and the frequency of node interaction. A triplet structure of node-association relationship-node is constructed. At the same time, the flow trajectory of vouchers between various ledgers, departments and projects is integrated, and additional attributes of ledger switching nodes, department handover nodes and project association nodes are added. Finally, a voucher flow graph covering the entire process and multiple dimensions of vouchers between various ledgers, departments and projects within the enterprise is formed.

[0091] exist Figure 2 In this context, N1 represents budget control: controlling budget usage; N2 represents departmental approval: departmental review process; N4 represents project account P1: the project account corresponding to the voucher; N5 represents project account P2: another project account; N3 represents fund pool A: fund pool allocation; N6 represents supplier transactions: related to supplier payments; and N7 represents expense aggregation: summarizing voucher expenses. The path candidate set includes: P1: source → N1 → N3 → N6 → destination; P2: source → N1 → N4 → N6 → destination; P3: source → N2 → N5 → N7 → destination; and P4: source → N2 → N6 → N7 → destination.

[0092] Step S2: Based on the voucher flow graph, generate a reconciliation strategy for each voucher and reconcile each voucher. The reconciliation strategy is dynamically adjusted according to the real-time ledger status and historical flow pattern, including reconciliation order, reconciliation amount allocation and matching priority.

[0093] like Figure 3 As shown, the specific steps of step S2 are as follows:

[0094] Step S201: Based on the voucher flow map, identify the reconciliation target of each voucher, including ledger, department, project and related transaction amount, and establish a mapping relationship between the reconciliation target and the historical flow pattern.

[0095] In this embodiment, the ledger write-off target determines the scope of ledgers to be written off and the corresponding page numbers by extracting the ledger type identifiers (such as general ledger, subsidiary ledger, and auxiliary ledger) and corresponding accounting subject codes associated with nodes in the graph, combined with the accounting entry records in the node attributes; the department write-off target identifies the initiating department, approving department, executing department, and write-off responsibility department involved in the voucher by using the department codes associated with nodes and cross-departmental transfer records; the project write-off target determines the project sub-items corresponding to the voucher and the project budget amount to be written off based on the project number mapped by the node and combined with the project budget data; the transaction amount write-off target splits the total transaction amount in the node attributes, and according to the sharing ratio and project budget allocation rules agreed in the contract terms, uses a weighted proportional sharing algorithm to split the total amount to each corresponding ledger, department, and project, retaining the split accuracy to the cent, and recording the split basis and split ratio.

[0096] After identifying the reconciliation target, historical voucher circulation data and corresponding reconciliation records for nearly 36 months are obtained. The circulation patterns related to historical reconciliation are classified, and the core features of each pattern are extracted (including node sequence features, department / project association features, amount splitting features, and circulation duration features). A historical circulation pattern feature library is constructed and a unique pattern identifier is established. Subsequently, the cosine similarity algorithm is used to calculate the similarity between the feature vector of the current voucher reconciliation target and the feature vectors of each pattern in the historical pattern feature library. The similarity threshold is set to 88%. When the similarity is higher than the threshold, a mapping relationship is established between the current reconciliation target and the corresponding historical pattern. The pattern identifier, similarity value, and historical reconciliation success rate are recorded. When the similarity is lower than the threshold, it is marked as a new reconciliation pattern, its unique features are extracted, and it is added to the feature library.

[0097] Step S202: Based on the node sequence and multi-dimensional logical relationship of the voucher in the voucher flow graph, generate multiple candidate reimbursement paths for the voucher. Each path includes the reimbursement order, reimbursement amount allocation, and potential matching priority, and marks the dependencies and conflict possibilities between paths.

[0098] In this embodiment, from the starting node (voucher creation node) to the ending node (settlement and reconciliation node) of the voucher flow graph, all valid paths that meet the reconciliation target are traversed, generating 3-5 candidate differentiated reconciliation paths. Specifically, the generation of the reconciliation order combines the sequential dependencies of nodes in the graph and historical flow patterns, prioritizing the generation of reconciliation orders consistent with patterns that have a historical reconciliation success rate ≥90%, while supplementing 2-3 differentiated orders (such as department reconciliation → project reconciliation → ledger reconciliation, ledger reconciliation → department reconciliation → project reconciliation, project reconciliation → department reconciliation → ledger reconciliation). The reconciliation amount allocation is based on the corresponding amounts of each ledger, department, and project split in step S201, using a weighted allocation algorithm based on entropy weighting. Based on the historical write-off amount allocation deviation rate (controlled within ±5%), the write-off amount at each stage is dynamically adjusted to ensure that the allocated amount is consistent with the write-off target. The potential matching priority is evaluated using the Analytic Hierarchy Process (AHP), which selects four core indicators: historical write-off success rate, path execution complexity (number of nodes, number of cross-system operations), amount matching accuracy, and department / project response efficiency. The weights of each indicator are set to 40%, 25%, 20%, and 15%, respectively. The indicator weights used for path priority scoring are not arbitrarily set, but are jointly determined based on the statistical results of the company's historical write-off data and the expert judgment of financial and business personnel. The priority score (0-10 points) of each path is quantitatively calculated, with higher scores indicating higher priority.

[0099] The dependencies between paths are analyzed by parsing the multidimensional logical association matrix of nodes in the graph and using directed edge annotation to clearly indicate that path A must complete departmental reconciliation before path B can perform project reconciliation. The probability of conflict is analyzed by a conflict detection algorithm based on resource competition to determine whether there is overlap in the reconciliation amount allocation of different paths for the same reconciliation object (same department, project, ledger) and the same time period. The conflict probability (0-100%) is calculated. When the total reconciliation amount of two paths for the same reconciliation object exceeds the corresponding split amount, it is marked as high conflict (probability ≥ 70%). When there is a contradiction in the reconciliation order but no overlap in the amount, it is marked as medium conflict (30% ≤ probability < 70%). No conflict is marked as low conflict (probability < 30%).

[0100] Step S203: For each reconciliation path candidate, obtain the real-time ledger status, dynamically compare the path candidate with the real-time ledger status, and identify the set of executable paths. The real-time ledger status includes available balance, reconciled records, and budget constraints.

[0101] In this embodiment, for each candidate reconciliation path generated in step S202, each node in the path is sequentially mapped to the corresponding ledger (general ledger, subsidiary ledger, auxiliary ledger). Combining the account desensitization identifier marked in step S101, the transaction amount (integer in cents), and the standardized time information (ISO8601 UTC format) in step S104, a path node mapping set containing node identifier, corresponding ledger code, account information, reconciliation amount, and execution time window is constructed through SQL relational query.

[0102] Subsequently, real-time ledger status data for each account is retrieved, while real-time changes in ledger status (such as balance changes and addition of write-off records) are captured. The extracted real-time status includes the account's available balance (accurate to the cent), write-off records for the past 90 days (including write-off amount, write-off time, and write-off object), and project / department budget constraints (including total budget, used amount, and remaining amount). After data cleaning to remove invalid data (such as negative balances and expired records), the data is precisely associated with the path node mapping set through account identifiers. A two-dimensional data table structure is used to generate a ledger status mapping table, which clearly defines the corresponding node ID, account identifier, ledger code, available balance, write-off amount, and remaining budget amount.

[0103] Next, the logical comparison between the candidate write-off path and the ledger status mapping table is performed node by node. Boolean logic is used to determine the executability of the node: if the write-off amount associated with the node is less than or equal to the available balance of the corresponding account, the execution order of the node does not conflict with the time of the already written-off record (i.e., there is no duplicate write-off), and the write-off amount is less than or equal to the remaining budget of the corresponding project / department, then the node is marked as executable; if any one of these conditions is not met, it is marked as unexecutable, and the specific type of constraint (insufficient balance, duplicate write-off, budget overspending) and the corresponding node sequence are marked. At the same time, the deviation between the constraint threshold and the actual value is recorded.

[0104] Finally, based on the node executability labeling results, an executable path set is selected from the reconciliation path candidates. The selection criteria are that all core nodes (amount reconciliation nodes and ledger confirmation nodes) in the path are executable. Non-core nodes (log recording nodes) that are not executable can be automatically replaced with candidate nodes. After the selection is completed, each executable path is labeled with constraint satisfaction, execution priority (using the priority score of S202) and potential execution risks (such as the balance approaching the threshold or the budget remaining less than 10%), and finally an executable path set is generated.

[0105] Step S204: Select the optimal path from the set of executable paths and automatically generate a reconciliation strategy for each voucher. At the same time, dynamically adjust the strategy according to the historical flow pattern to adapt to changes in the ledger status. The reconciliation strategy includes specific reconciliation order, amount allocation and matching priority.

[0106] In this embodiment, a comprehensive priority scoring system is first constructed. Specifically, the Analytic Hierarchy Process (AHP) is used to determine the weights of the scoring indicators. Four core indicators are selected: the fit between the node order and the historical circulation pattern, the rationality of the node amount distribution, the historical reimbursement success rate, and the path execution efficiency. The weights are set to 30%, 20%, 40%, and 10%, respectively. The node order fit is calculated by using the edit distance algorithm to determine the similarity between the path node sequence and the historical high-frequency circulation pattern sequence. The rationality of the amount distribution is verified by using analysis of variance to verify the consistency between the allocation ratio and the contract agreement and budget rules. The path execution efficiency is quantified by the average processing time of the nodes and the number of cross-system interactions. The random forest algorithm is used to perform weighted calculations on each indicator to generate a comprehensive priority score (0-100 points) for each executable path.

[0107] Subsequently, the path with the highest comprehensive score was selected as the basis for reconciliation execution. All node information for this path was extracted via SQL query, clearly marking the execution order of each node (sorted by time sequence and assigned execution sequence number), and the candidate values ​​for reconciliation amount allocation (with a floating range set based on the historical reconciliation deviation rate of ±3%). Simultaneously, the corresponding account, ledger, and responsible department were recorded. Then, based on historical voucher flow pattern data from the past 36 months and the real-time ledger status obtained in step S203, the selected path was dynamically adjusted node by node. Specifically, if the average execution time of a certain type of node in the historical pattern (such as the project reconciliation node) is lower than the current... If the previous path setting value is used, the execution order of the node will be advanced by 1-2 positions. If the real-time available balance of an account deviates from the path allocation amount by more than 5%, the reimbursement amount of the corresponding node will be fine-tuned using linear interpolation to ensure that the amount allocation matches the balance. If the remaining budget is close to the threshold (remaining ≤10%), the matching priority will be adjusted to prioritize matching projects / departments with sufficient budget. During the adjustment process, the strategy flexibility will be maintained by setting dynamic thresholds (such as changes in ledger balance ≥5% or budget changes ≥8%) to trigger a real-time reassessment mechanism. Finally, the adjusted path information will be converted into a reimbursement strategy that can be executed directly.

[0108] exist Figure 3The process lists candidate paths E1, E2, E3, etc., clearly marking the source node, the voucher transfer nodes (e.g., N1, N3, N6, etc.) along each path, and the final destination node. Each candidate path is then scored for priority, with scoring dimensions including node sequence completeness, amount distribution rationality, and historical transfer pattern matching. A comprehensive evaluation value is generated to compare the merits of different paths. Based on the comprehensive score, the optimal path (path E1 in this example) is selected, and the reimbursement strategy is output, including the execution order of each node (source → N1 → N3 → N6 → destination) and candidate amount allocation values ​​(e.g., source 100,000 yuan, N1 60,000 yuan, N3 30,000 yuan, N6 10,000 yuan, destination 0 yuan), ensuring that the reimbursement operation can be executed directly.

[0109] Step S205: Execute the reconciliation operation for each voucher in sequence according to the generated reconciliation strategy, and feed back the reconciliation results to the flow graph and ledger status for subsequent voucher path generation and strategy adjustment, so as to realize the closed-loop logic of the reconciliation operation.

[0110] In this embodiment, based on the standardized reconciliation strategy for each voucher generated in step S204, hierarchical reconciliation operations are initiated node by node, sequentially completing the entire process of departmental ledger reconciliation, project budget offsetting, accounting book entry, and bank statement matching and reconciliation. When each reconciliation node is executed, the built-in voucher generation engine of the financial system is called to automatically match the corresponding accounting subject and generate a reconciliation accounting voucher with a unique transaction number, which is simultaneously written to the designated page entries of the corresponding general ledger, subsidiary ledger, and auxiliary ledger. After the reconciliation operation is completed, the reconciliation result type is divided according to the actual execution status, specifically into four states: full reconciliation successful, reconciliation temporarily suspended due to insufficient amount, budget rule constraint rejection, and process node approval rejection. At the same time, the actual reconciliation path of this voucher, the deviation value between the strategy and the actual execution amount, and the flow time characteristics of each node are included in the historical flow pattern sample library, providing training sample support for the generation of candidate reconciliation paths for subsequent new vouchers, priority comprehensive scoring, and dynamic fine-tuning of strategies.

[0111] Step S3: Perform a trial calculation of the reconciled vouchers in the virtual ledger unit, automatically optimize based on the consistency of the multi-dimensional ledger after the division, budget constraints and project cost allocation requirements, and synchronize the division results to the real ledger when the trial calculation results meet the constraints.

[0112] The specific steps of step S3 are as follows:

[0113] Step S301: Map the reconciled vouchers to the corresponding virtual ledger units, and record the department, project and related cost center information of the voucher in each virtual unit.

[0114] In this embodiment, firstly, all voucher data completed in step S205 is extracted, including the voucher's unique code, cancellation status, transaction amount, associated department code, project number, and transaction type. Then, a virtual ledger unit is constructed according to the three-dimensional dimensions of department-project-cost center. This virtual ledger unit is a lightweight simulation ledger container built on an in-memory database, with the same structure, accounts, and permissions as the real ledger. It is uniquely identified by [department code + project number + cost center code] and includes four major data structures: account dimension, amount dimension, status dimension, and constraint dimension. The hierarchy of the virtual unit is consistent with the enterprise's organizational structure and project hierarchy. Next, the mapping operation between the cancelled vouchers and the virtual ledger unit is performed. Specifically, the department master data is associated with the voucher's associated department code to obtain complete information such as department name, department level, and affiliated business unit, as well as detailed information such as project name, project stage, and budget allocation. The system accurately allocates vouchers to their corresponding cost centers based on transaction type (such as procurement expenditures, management expenses, and fixed asset investments) and the enterprise's cost center allocation rules (based on Activity-Based Costing, ABC). For example, procurement vouchers are allocated to the procurement cost center, administrative office expense vouchers are allocated to the administrative cost center, and project construction expenditures are allocated to the project's dedicated cost center. During the allocation process, a cosine similarity algorithm is used to process the correspondence between transaction types and cost centers. Transactions with a matching degree below 90% are marked as requiring manual confirmation. The allocation basis and matching confidence level are also recorded. After the mapping is completed, the core information of the vouchers is recorded in a structured manner in each virtual ledger unit, including the voucher's unique code, the amount reimbursed (accurate to the cent), the department (code + name + level), the project (number + name + stage), the cost center (code + type + responsible entity), and the reimbursement completion time (ISO8601 UTC format).

[0115] Step S302: Based on the voucher flow diagram and the information recorded in the virtual ledger unit, generate multiple accounting scheme candidates. Each scheme includes the preliminary allocation ratio and sequence of voucher amounts in different departments, projects and cost centers.

[0116] In this embodiment, the total transaction amount of the vouchers after verification is first extracted. Combining the department, project, cost center identifiers and corresponding weights associated with the nodes in the voucher flow graph, the amount is split based on the activity-based costing (ABC) method. According to the sharing ratio agreed in the contract, the project budget allocation rules and the cost center's responsibility scope, the total amount is initially split into multiple independent amount splitting units. Each unit is labeled with the corresponding department code, project number, cost center code and split amount (accurate to the cent), forming a structured set of amount splitting units.

[0117] Subsequently, the flow order of nodes in the virtual ledger unit and the multidimensional dependencies between nodes are analyzed to generate the allocation order link of each split unit. The allocation paths that can be executed in parallel in the link are clearly marked (the accounting of different departments at the same level can be done in parallel) and the priority of each node (set based on historical accounting efficiency and cost center response speed). The priority is marked in a 1-5 level hierarchy, with level 1 being the highest priority.

[0118] Next, the Cartesian product combination method is used to combine the set of amount splitting units and the allocation order link in a variety of ways to generate 3-5 preliminary differentiated accounting scheme candidates. Each scheme clearly defines the accounting ratio, specific amount and node execution order corresponding to different departments, projects and cost centers, while taking into account the accounting efficiency and cost collection accuracy. For example, some schemes focus on allocation according to project priority, while others focus on allocation according to department responsibility weight.

[0119] Finally, a one-to-one mapping is established between each candidate revenue sharing scheme and the node identifiers, multi-dimensional relationships in the voucher flow graph, as well as the node attributes and mapping information in the virtual ledger unit. The mapping basis (such as node relationships and amount splitting rules), matching confidence, and mapping timestamp are recorded.

[0120] Step S303: For each candidate revenue sharing scheme, compare the consistency of the multidimensional ledger, budget constraints, and project cost allocation requirements in the virtual ledger node by node, mark the nodes and revenue sharing ratios that do not meet the constraints, and form a set of constraint markers.

[0121] In this embodiment, the consistency of the multidimensional ledger, budget constraints, and project cost allocation requirements in the virtual ledger are compared sequentially. Specifically, the multidimensional ledger consistency comparison uses the MD5 hash verification method to compare the consistency of the accounting amount, accounting subject code, and department / project / cost center identifier of each node in the candidate accounting scheme with the corresponding fields in the virtual ledger through the corresponding node data of the general ledger, subsidiary ledger, and auxiliary ledger in the virtual ledger. At the same time, the reconciliation relationship between the accounting amount and the ledger entry amount is verified through field-level comparison. If the hash value does not match or the reconciliation relationship is abnormal, the node is marked. Points indicating discrepancies in ledger consistency are recorded, along with the deviation field and specific difference value. Budget constraint comparison uses the real-time remaining budget, budget execution progress, and budget control thresholds of each department, project, and cost center to determine whether the revenue sharing amount in the revenue sharing scheme exceeds the corresponding remaining budget and whether it meets the budget execution progress requirements (e.g., when the project execution progress is less than 30%, the revenue sharing ratio shall not exceed 40% of the total budget). If the budget is exceeded or the progress requirements are not met, the node is marked as budget constraint non-compliance, and the remaining budget, revenue sharing amount, and overspending ratio are recorded.

[0122] The project cost allocation requirements are compared based on the company's pre-set activity-based costing (ABC) allocation rules and project cost collection standards. The cosine similarity algorithm is used to calculate the similarity between the revenue sharing ratio in the revenue sharing scheme and the project cost allocation standards, with a similarity threshold of 92%. At the same time, it is verified whether the revenue sharing amount meets the collection requirements for direct and indirect costs. If the similarity is lower than the threshold or the cost collection does not meet the standards, the node is marked as a cost allocation mismatch, and the revenue sharing ratio, standard ratio, and reason for the deviation are recorded. During the node-by-node comparison process, the node identifier, revenue sharing ratio, constraint type (ledger consistency, budget constraint, cost allocation), and specific anomaly description are simultaneously marked. All marked information is grouped according to the revenue sharing scheme candidates and a constraint mark set is formed in the form of a structured data table.

[0123] Step S304: Based on the constraint tag set and the virtual ledger status, dynamically adjust the accounting ratio and node order to generate an optimized accounting scheme set that satisfies multidimensional ledger consistency and budget constraints.

[0124] In this embodiment, each constraint record in the constraint mark set formed in step S303 is parsed one by one. The constraint mark is matched to the corresponding virtual ledger node and the amount splitting unit within the revenue sharing scheme through a multi-table association query. The revenue sharing node constrained due to multi-dimensional ledger reconciliation deviation, budget limit exceeding the limit, or project cost collection rule non-compliance is identified. At the same time, based on the real-time balance of the virtual ledger, the remaining budget of the project, and the cost center's approved allocation limit, the legal and valid revenue sharing ratio fluctuation range of each constrained node is delineated in reverse, and the maximum, minimum and compliance benchmark values ​​of the ratio are clarified.

[0125] Based on the constraint boundary information obtained from the analysis, the original allocation ratio of each constrained node is fine-tuned dimension by dimension. For nodes exceeding the budget limit, the allocation ratio is reduced by the remaining budget amount. For nodes with mismatched ledgers, the allocation ratio is corrected according to the accounting entry standards. For nodes whose cost allocation deviates from the standard, the allocation ratio is reallocated according to the activity cost collection rules. When the allocation ratio does not meet the project cost allocation requirements, the system prioritizes the correction based on the project allocation ratio agreed in the contract terms. If the contract terms do not specify the allocation ratio, the average allocation ratio of similar historical vouchers is referenced. If the number of historical samples is insufficient, the initial allocation ratio is determined according to the budget ratio of each project. During the ratio adjustment process, the ratio of other nodes in the same unit is kept in sync and multiple versions of the reconstructed allocation scheme candidate are generated simultaneously.

[0126] Based on this, relying on the sequential dependency logic and parallel adaptation attributes between nodes in the voucher flow graph, the execution order of nodes in each version of the accounting scheme is dynamically reconstructed. The flow order of accounting nodes with strong sequential dependencies is fixed, the parallel processing link is opened for nodes without business association and that meet the conditions for parallel accounting, and the sequential order of nodes that cause constraint conflicts due to ratio adjustments is rearranged to avoid conflicts in the timing of ledger recording and budget deduction, thereby forming an optimized sequential link that adapts to the constraints.

[0127] Finally, the various revenue-sharing schemes that have completed the restructuring of revenue-sharing ratios and dynamic adjustment of node order are summarized and integrated. Multi-dimensional compliance reviews are carried out on each scheme, verifying the consistency of virtual ledger debit and credit, compliance of departmental and project budget execution, and matching degree of cost center expense collection. Invalid schemes with constraint conflicts and logical flaws are eliminated, and all valid schemes that meet the requirements of multi-dimensional ledger consistency, budget not exceeding the limit, and compliance of project cost allocation rules are retained. The optimized revenue-sharing scheme set is then compiled and constructed.

[0128] Step S305: Synchronize the results of the optimized accounting scheme that meet all constraints to the real ledger, and update the ledger status and voucher flow diagram.

[0129] In this embodiment, when synchronizing the results of the optimized accounting scheme that meet all constraints to the real ledger, the voucher amount is first mapped to the corresponding real ledger account, department, project, and cost center according to the accounting ratio and sequence link of each node in the virtual ledger. Then, the ledger status is updated one by one, including available balance, written-off records, and budget occupancy information, to ensure that the data of each node in the ledger is consistent with the virtual trial calculation results. At the same time, the nodes involved in the voucher flow graph are marked and updated, and the amount and node sequence status of the accounting are recorded so that they can be directly called in subsequent write-off and accounting operations, ensuring the consistency of the multi-dimensional ledger and the continuous tracking of budget constraints.

[0130] During implementation, the batch ledger update interface provided by the existing enterprise resource planning (ERP) system or financial management software can be used for automatic writing. Combined with transaction control mechanisms or distributed lock technology, the atomicity of the operation and the consistency of ledger data can be guaranteed, and the synchronization of the optimized ledger scheme to the real ledger and the updating of ledger status and voucher flow map can be completed.

[0131] Step S4: For abnormal vouchers generated during the reconciliation or accounting process, simulate the cause-and-effect path based on the voucher flow diagram and automatically deduce the root cause of the abnormality.

[0132] In this embodiment, for abnormal vouchers identified during the reconciliation or accounting process, the complete flow path and related node information of the voucher in the voucher flow graph can be extracted first, including the departments, projects, cost centers, transaction amounts and time series involved. Then, by constructing a node dependency network, the mutual influence between the abnormal voucher and the ledger status, budget occupancy and historical accounting patterns of the preceding and subsequent nodes can be analyzed in sequence. On this basis, multiple possible causal paths can be simulated, and the possible amount conflicts, sequence conflicts or budget overruns caused by abnormal vouchers can be cross-validated with the corresponding relationships of each node, thereby deducing the most likely root cause of the abnormality.

[0133] During implementation, existing database queries, transaction log analysis, and graph traversal algorithms or topological sorting methods can be used to complete node dependency analysis and causal path simulation. The simulation results can be fed back to the voucher flow graph to mark abnormal nodes and their root causes, and abnormalities can be manually processed or automatically repaired.

[0134] Example 2

[0135] Please see Figure 4 Another embodiment of the present invention provides a voucher reconciliation data processing system based on flow graph, comprising: a graph generation module, a reconciliation module, an accounting processing module, and an anomaly tracing module;

[0136] The graph generation module is used to acquire the voucher data of the enterprise and generate a voucher flow graph based on the voucher's internal flow path, processing time sequence and account relationship. The graph is used to describe the dynamic transmission and dependency relationship of each voucher between different ledgers, departments and projects.

[0137] The reconciliation module is used to generate a reconciliation strategy for each voucher based on the voucher flow graph, and to reconcile each voucher. The reconciliation strategy is dynamically adjusted according to the real-time ledger status and historical flow pattern, including reconciliation order, reconciliation amount allocation and matching priority.

[0138] The accounting module is used to perform accounting trial calculations on the reconciled vouchers in the virtual ledger unit, automatically optimize the accounting based on the consistency of the multi-dimensional ledger after accounting, budget constraints and project cost allocation requirements, and synchronize the accounting results to the real ledger when the trial calculation results meet the constraints.

[0139] The anomaly tracing module is used to simulate causal paths based on the voucher flow graph and automatically deduce the root cause of anomalies in abnormal vouchers generated during the reconciliation or accounting process.

[0140] In addition, the parts of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of the corresponding technical solutions in the prior art have not been described in detail, so as to avoid excessive elaboration.

[0141] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for processing voucher reconciliation data based on flow graphs, characterized in that, include: The system acquires the voucher data of the enterprise and generates a voucher flow graph based on the voucher's internal flow path, processing time sequence, and account relationships. The graph is used to describe the dynamic transmission and dependency relationships of each voucher between different ledgers, departments, and projects. Based on the voucher flow graph, a reconciliation strategy is generated for each voucher, and each voucher is reconciled. The reconciliation strategy is dynamically adjusted according to the real-time ledger status and historical flow pattern, including reconciliation order, reconciliation amount allocation, and matching priority. After the vouchers are reconciled, a trial calculation is performed in the virtual ledger unit. The calculation is automatically optimized based on the consistency of the multi-dimensional ledgers after the calculation, budget constraints, and project cost allocation requirements. When the trial calculation results meet the constraints, the calculation results are synchronized to the real ledger. For abnormal vouchers generated during the reconciliation or accounting process, the cause-and-effect path is simulated based on the voucher flow diagram to automatically deduce the root cause of the abnormality.

2. The voucher verification data processing method based on flow graph as described in claim 1, characterized in that, The process of acquiring the enterprise's voucher data and generating a voucher flow graph based on the voucher's internal circulation path, processing time sequence, and account relationships includes: Obtain voucher records from within the enterprise and mark the transaction entity, transaction amount, transaction time, and account identifier for each voucher; Based on the processing logs and account interaction information of vouchers within the enterprise, the complete flow of vouchers from creation, approval, accounting to settlement is tracked layer by layer, and the time sequence and account relationship of each flow node are recorded. Each flow node is mapped to its associated department, project, and contract terms to generate a multi-dimensional relationship between flow nodes, and a topological logical connection is established for the order and interaction frequency of flow nodes. The processing time sequence of the voucher circulation nodes is mapped into operable sequential logic, and dynamic node links are generated based on the sequential relationship between nodes and the parallel processing status. Based on the flow nodes, relationships, and time series links, a voucher flow graph is constructed.

3. The voucher verification data processing method based on flow graph as described in claim 2, characterized in that, The construction of a voucher flow graph based on flow nodes, relationships, and time series links includes: The identified voucher flow nodes are integrated sequentially, and a node sequence is established according to the flow order of vouchers between different ledgers, departments and projects. The associated account, transaction amount and contract terms information are recorded in each node. Cross-mapping is performed on the department, project, and account relationships between nodes in the node sequence to generate a multi-dimensional logical association matrix between nodes, and the multi-dimensional logical relationships between nodes are marked, including sequential dependencies and parallel processing paths; Based on the node sequence and multidimensional association matrix, node links are dynamically generated according to the time sequence and interaction frequency of voucher circulation, so that each link reflects the possible multi-path circulation status of vouchers and node dependencies. Based on node sequences, multidimensional logical association matrices, and node links, a voucher flow graph covering vouchers across various ledgers, departments, and projects within the enterprise is formed.

4. The voucher verification data processing method based on flow graph as described in claim 1, characterized in that, Based on the voucher flow graph, a reconciliation strategy is generated for each voucher, and each voucher is reconciled, including: Based on the voucher flow map, identify the write-off target for each voucher, including ledger, department, project and related transaction amount, and establish a mapping relationship between the write-off target and the historical flow pattern; Based on the node sequence and multi-dimensional logical relationship of the voucher in the voucher flow graph, multiple reimbursement path candidates for the voucher are generated. Each path includes the reimbursement order, reimbursement amount allocation and potential matching priority, and the dependencies and conflict possibilities between paths are marked. For each candidate write-off path, obtain the real-time ledger status, dynamically compare the candidate path with the real-time ledger status, and identify the set of executable paths. The real-time ledger status includes available balance, write-off records, and budget constraints. The optimal path is selected from the set of executable paths, and a reconciliation strategy for each voucher is automatically generated. At the same time, the strategy is dynamically adjusted according to the historical flow pattern. The reconciliation strategy includes the specific reconciliation order, amount allocation and matching priority. The reconciliation operation for each voucher is executed sequentially according to the generated reconciliation strategy, and the reconciliation results are fed back to the flow chart and ledger status.

5. The voucher verification data processing method based on flow graph as described in claim 4, characterized in that, For each candidate write-off path, the real-time ledger status is obtained, and the candidate path is dynamically compared with the real-time ledger status to identify a set of executable paths, including: The nodes in each candidate reimbursement path are mapped sequentially to the corresponding ledger, and the account, transaction amount and time information associated with the node are extracted to form a path node mapping set; The real-time ledger status of each account is obtained sequentially, including available balance, written-off records and budget constraints, and associated with the path node mapping set to form a ledger status mapping table; The system performs a logical comparison between the candidate write-off paths and the ledger status mapping table for each node. It identifies the executability of nodes based on the matching of node amount with available balance, node order with write-off records and budget constraints, and marks the node sequence affected by constraints in the path. Based on the node executability label, all complete paths that meet the ledger status constraints are selected from the reversal path candidates to form an executable path set.

6. The voucher verification data processing method based on flow graph as described in claim 5, characterized in that, The process involves selecting the optimal path from the set of executable paths and automatically generating a reconciliation strategy for each voucher, including the specific reconciliation order, amount allocation, and matching priority. Simultaneously, the strategy is dynamically adjusted based on historical processing patterns, including: A priority score is generated based on the node order, node amount distribution, and historical transfer pattern of each path in the executable path set; Based on priority scoring, the path with the highest score is selected as the basis for reimbursement execution, and the execution order and candidate value for amount allocation for each node in the path are marked. By combining historical voucher circulation patterns and current ledger status, the reconciliation order, amount allocation, and matching priority of the selected path are adjusted node by node to generate a reconciliation strategy that can be executed directly, while retaining the flexibility of the strategy to adapt to changes in the ledger. The dynamically adjusted path information is transformed into specific reimbursement strategies, including the reimbursement order, reimbursement amount allocation, and matching priority for each voucher, and the strategies are associated with the voucher flow graph and the set of executable paths.

7. The voucher verification data processing method based on flow graph as described in claim 1, characterized in that, The process of performing a trial calculation of the reconciled vouchers in a virtual ledger unit, automatically optimizing the calculation based on the consistency of the multi-dimensional ledgers after the calculation, budget constraints, and project cost allocation requirements, and synchronizing the calculation results to the real ledger when the constraints are met, includes: The reconciled vouchers are mapped to the corresponding virtual ledger units, and the department, project and related cost center information of the voucher are recorded in each virtual unit; Based on the voucher flow diagram and the information recorded in the virtual ledger unit, multiple accounting scheme candidates are generated. Each scheme includes the preliminary allocation ratio and sequence of voucher amounts in different departments, projects and cost centers. For each candidate revenue sharing scheme, the consistency of the multidimensional ledger, budget constraints, and project cost allocation requirements in the virtual ledger are compared node by node. Nodes that do not meet the constraints and their revenue sharing ratios are marked to form a set of constraint markers. Based on the constraint tag set and the virtual ledger status, the accounting ratio and node order are dynamically adjusted to generate a set of optimized accounting schemes that meet the requirements of multidimensional ledger consistency and budget constraints. The results of optimizing the revenue sharing scheme and satisfying all constraints will be synchronized to the actual ledger, and the ledger status and voucher flow graph will be updated.

8. The voucher verification data processing method based on flow graph as described in claim 7, characterized in that, Based on the voucher flow diagram and the information recorded in the virtual ledger unit, multiple candidate accounting schemes are generated, including: The amount of the vouchers after verification is initially broken down according to the department, project and cost center association information recorded in the voucher flow diagram to form a set of amount breakdown units; Based on the flow order of nodes in the virtual ledger unit and the dependencies between nodes, generate the allocation order link for each split unit, and mark the parallel allocation path and node priority; By combining the amount splitting unit with the allocation sequence link, multiple preliminary accounting scheme candidates are generated. Each scheme reflects the allocation ratio and node sequence possibilities of different departments, projects and cost centers. Establish a mapping relationship between each candidate revenue sharing scheme and the node information in the voucher flow graph and virtual ledger unit.

9. The voucher verification data processing method based on flow graph as described in claim 8, characterized in that, The process of dynamically adjusting the accounting allocation ratio and node order based on the constraint tag set and the virtual ledger state to generate a set of optimized accounting allocation schemes that satisfy multidimensional ledger consistency and budget constraints includes: The information in the constraint tag set is parsed one by one, and the tags are associated with the virtual ledger nodes and the amount splitting units in the splitting scheme to identify the splitting nodes affected by the constraints and their allocation ratio range. Based on the parsed constraint information, the revenue sharing ratio of each node is adjusted sequentially according to node priority and ledger status to generate multiple revenue sharing scheme candidates. By combining the dependencies between nodes and the possibility of parallel processing, the order of nodes in each revenue sharing scheme is dynamically adjusted to form an optimized sequential link that satisfies the constraint information. The revenue sharing schemes, which have been adjusted in proportion and optimized in node order, are integrated to generate the final optimized revenue sharing scheme set.

10. A voucher reconciliation data processing system based on a flow graph, used to implement the voucher reconciliation data processing method based on a flow graph as described in any one of claims 1-9, characterized in that, include: The system includes a graph generation module, a reconciliation module, a revenue sharing module, and an anomaly tracking module. The graph generation module is used to acquire the voucher data of the enterprise and generate a voucher flow graph based on the voucher's internal flow path, processing time sequence and account relationship. The graph is used to describe the dynamic transmission and dependency relationship of each voucher between different ledgers, departments and projects. The reconciliation module is used to generate a reconciliation strategy for each voucher based on the voucher flow graph, and to reconcile each voucher. The reconciliation strategy is dynamically adjusted according to the real-time ledger status and historical flow pattern, including reconciliation order, reconciliation amount allocation and matching priority. The accounting module is used to perform accounting trial calculations on the reconciled vouchers in the virtual ledger unit, automatically optimize the accounting based on the consistency of the multi-dimensional ledger after accounting, budget constraints and project cost allocation requirements, and synchronize the accounting results to the real ledger when the trial calculation results meet the constraints. The anomaly tracing module is used to simulate causal paths based on the voucher flow graph and automatically deduce the root cause of anomalies in abnormal vouchers generated during the reconciliation or accounting process.

Images