A Distributed Anomaly Detection Method and System for Enterprise Financial Reconciliation

CN122571395APending Publication Date: 2026-08-14SHENYANG INSTITUTE OF CHEMICAL TECHNOLOGY
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-01
Publication Date
2026-08-14

AI Technical Summary

Technical Problem

[0006]本申请提供一种用于企业财务对账的分布式异常数据检测方法及系统,旨在解决现有技术中企业财务对账方案过于依赖批量规则核对或主键精确匹配、难以对海量未核销账务记录进行自动化核销与异常识别的技术问题,实现企业财务数据的高效分布式核对与异常定位的效果

Benefits of technology

本申请提供的一种用于企业财务对账的分布式异常数据检测方法及系统,通过统一账务事件标准化、分片分发、候选匹配图构建和匹配得分核销相结合,不再仅仅依赖静态业务规则或主键完全一致的核对方式,而是能够在海量账务数据中基于金额、时间与会计科目偏差实现可解释的近似核销,并通过最大处理窗口时间阈值对长期未核销记录进行异常判定,在保证分布式处理吞吐量的同时提升企业财务对账的自动化程度与可扩展性,既能适应多源异构数据特点,又能在分布式架构下执行自动化核销与异常判定,具有处理吞吐量高、可扩展性好的优点。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122571395A_ABST
    Figure CN122571395A_ABST
Patent Text Reader

Abstract

This application discloses a distributed anomaly data detection method and system for enterprise financial reconciliation, belonging to the field of enterprise financial data processing and distributed computing technology. The method includes: collecting and standardizing accounting data from multiple business systems to obtain a unified accounting event sequence; performing routing and sharding distribution processing on the unified accounting event sequence to distribute the unified accounting events to multiple sharding processing nodes; performing a first round of reconciliation and candidate matching construction processing on the unified accounting events in each sharding processing node to obtain a candidate matching graph; performing feature extraction and scoring calculation processing on the candidate matching edges in the candidate matching graph to obtain the matching score of the candidate matching edges; and performing threshold reconciliation and anomaly output processing based on the matching scores of the candidate matching edges. This application can adapt to the characteristics of multi-source heterogeneous data and can perform automated reconciliation and anomaly judgment under a distributed architecture, with advantages such as high processing throughput and good scalability.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of enterprise financial data processing and distributed computing technology, specifically involving a distributed abnormal data detection method and system for enterprise financial reconciliation, which is applicable to the automated reconciliation and abnormal identification of massive financial data in group enterprises, multi-legal entity enterprises or multi-system collaborative scenarios. Background Technology

[0002] Corporate financial reconciliation typically requires verifying the consistency of cash flow, voucher flow, and invoice flow across multiple business systems, including ERP systems, online banking systems, invoice management systems, expense approval systems, and general ledger systems. As business volume continues to increase, the number of accounting records to be processed daily is also growing. Traditional reconciliation methods relying on manual sampling, single-machine batch tasks, or static rules are no longer sufficient to simultaneously meet the requirements of processing timeliness and identification accuracy.

[0003] In existing technologies, one type of solution triggers distributed real-time reconciliation via message queues. While this improves the timeliness of accessing accounting records, it relies heavily on predefined fields and cross-checking logic, primarily addressing whether data has arrived and whether direct inconsistencies exist. Its ability to identify complex anomalies such as missing voucher numbers, inconsistent summary descriptions, reasonable drift in arrival times, and incomplete document chains is limited. Another type of solution predicts transaction anomalies in distributed systems by statistically analyzing processing time or historical proportions. Its focus is on system timeouts and processing congestion, rather than multi-source accounting consistency detection in enterprise financial reconciliation scenarios, making it difficult to directly use for identifying accounting reconciliation anomalies.

[0004] Another type of solution uses hash sharding and sorting matching to process large-scale accounting data, which significantly improves basic reconciliation throughput. However, its core lies in the efficient pairing of data with the same primary key. For abnormal scenarios such as approximate matching, differences in field expression across systems, missing documents, and process deviations, manual review or supplementation of static rules is still required. Another multi-source financial risk control monitoring solution applies technologies such as knowledge graphs and graph neural networks to risk identification, focusing more on real-time risk control and anomaly propagation analysis, rather than establishing a distributed reconciliation detection link around the reconciliation relationships in corporate financial reconciliation.

[0005] Therefore, current technologies lack a complete solution that can adapt to the multi-source heterogeneous data characteristics of enterprise financial reconciliation scenarios and perform automated reconciliation and anomaly detection under a distributed architecture. Especially in massive reconciliation scenarios, how to further calculate interpretable matching scores for residual candidate matching relationships after sharding processing to complete reconciliation and anomaly detection remains a technical problem that needs to be solved. Summary of the Invention

[0006] This application provides a distributed anomaly detection method and system for enterprise financial reconciliation, aiming to solve the technical problem that existing enterprise financial reconciliation schemes rely too heavily on batch rule verification or primary key exact matching, making it difficult to automatically reconcile and identify anomalies in massive amounts of unreconciled accounting records. The method achieves efficient distributed reconciliation and anomaly localization of enterprise financial data. The method includes: collecting and standardizing accounting data from multiple business systems to obtain a unified accounting event sequence; performing routing and sharding distribution processing on the unified accounting event sequence to distribute the unified accounting events to multiple sharding processing nodes; performing a first round of reconciliation and candidate matching construction processing on the unified accounting events in each sharding processing node to obtain a candidate matching graph; performing feature extraction and scoring calculation processing on the candidate matching edges in the candidate matching graph to obtain the matching score of the candidate matching edges; and performing threshold reconciliation and anomaly output processing based on the matching scores of the candidate matching edges.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application provides a distributed anomaly detection method and system for enterprise financial reconciliation. By combining standardized accounting events, fragmented distribution, candidate matching graph construction, and matching score verification, it no longer relies solely on static business rules or verification methods with completely identical primary keys. Instead, it can achieve interpretable approximate verification based on deviations in amount, time, and accounting subject in massive accounting data. It also uses the maximum processing window time threshold to determine anomalies in long-term unverified records. While ensuring distributed processing throughput, it improves the automation and scalability of enterprise financial reconciliation. It can adapt to the characteristics of multi-source heterogeneous data and perform automated verification and anomaly detection under a distributed architecture. It has the advantages of high processing throughput and good scalability. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0009] Figure 1 A schematic diagram of a distributed abnormal data detection method for enterprise financial reconciliation provided in this application embodiment; Figure 2 A schematic diagram of a distributed anomaly data detection system for enterprise financial reconciliation provided in this application embodiment; Figure labeling: 11. Standardization module, 12. Piece distribution module, 13. Candidate graph construction module, 14. Matching score calculation module, 15. Verification and anomaly detection module. Detailed Implementation

[0010] This application provides a distributed anomaly data detection method and system for enterprise financial reconciliation, which solves the technical problems in the prior art where enterprise financial reconciliation relies on batch rule verification or primary key exact matching, it is difficult to automatically identify anomalies in massive amounts of unreconciled accounting records, and the fixed anomaly threshold leads to high false alarm and false alarm rates under different accounting periods and different enterprise entities.

[0011] 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 a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0012] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, apparatus, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0013] Example 1, as Figure 1 As shown, this application provides a distributed anomaly data detection method for enterprise financial reconciliation, the method comprising: S100: Collect and standardize accounting data from multiple business systems to obtain a unified accounting event sequence; In corporate financial reconciliation scenarios, raw data typically originates from multiple different systems, such as ERP systems, online banking systems, invoice management systems, expense approval systems, general ledger systems, and cash management systems. Since different systems may differ in field naming conventions, time formats, currency representation methods, and invoice numbering rules, it is necessary to define a unified data structure for accounting events. This allows data from different systems to flow and be processed using the same structure. Specifically, a unified accounting event includes fields such as source system identifier, enterprise entity identifier, account set identifier, business time, posting time, transaction amount, currency identifier, counterparty identifier, voucher number, invoice number, summary text, accounting subject, debit / credit direction, document completeness marker, process path identifier, and reconciliation start time.

[0014] Furthermore, in order to collect and standardize the accounting data from multiple business systems, the following steps need to be performed: S101: Perform connection configuration and SQL definition for multiple business systems to obtain a unified set of accounting event collection rules; The system pre-configures database connection information and multiple SQL statements for data acquisition for different financial systems. Each SQL statement corresponds to a business type, and all attribute values ​​and incremental judgment conditions for querying unified accounting events are predefined in each SQL statement for data acquisition. This ensures that each execution only returns incremental change data since the last execution. Finally, the database connection information of different financial systems and the multiple SQL statements for data acquisition are combined into a unified accounting event collection rule set.

[0015] S102: Based on the unified accounting event collection rule set, perform fixed-frequency collection and text standardization processing to obtain a unified accounting event sequence; The system iterates through each collection rule in the unified accounting event collection rule set at a fixed frequency, executes the corresponding SQL statement according to the database connection information of each rule, reads the data added or updated since the previous collection cycle and constructs it into a unified accounting event. In order to avoid too many invalid differences in the text fields, after the data acquisition is completed, word segmentation, stop word filtering and keyword extraction are performed on the summary text attribute in the unified accounting event to form a standard summary text for subsequent summary text similarity calculation. For time-type fields, the date and time formats from different source systems are uniformly converted to the same time zone and the same format in each SQL statement used for data retrieval; For identification fields such as voucher number, invoice number, and counterparty name, each SQL statement used for data retrieval includes whitespace removal, case uniformity, special character removal, and alias mapping processing. Document completeness is marked as an unsigned integer, and the existence status of the material is represented by the lower 4 bits of the binary bitmask structure: the 1st bit indicates whether the voucher exists, the 2nd bit indicates whether the invoice exists, the 3rd bit indicates whether the approval form exists, and the 4th bit indicates whether the receipt exists; The write-off start time field is a time type and is assigned the current time to indicate the start time of abnormal data detection; After the above processing, the unified accounting events are written into the message buffer in the order of business time to form a unified accounting event sequence, waiting to enter the fragmentation and distribution stage.

[0016] S200: Performs routing and sharding distribution processing on the unified accounting event sequence, distributing the unified accounting events to multiple sharding processing nodes; In high-volume reconciliation scenarios, if all unified accounting events are processed by a single node, it can easily lead to throughput bottlenecks and latency accumulation. Therefore, it is necessary to distribute unified accounting events to different sharding processing nodes for parallel processing. At the same time, a routing key is constructed based on the core business attributes of the unified accounting events, and sharding is performed based on the routing key to distribute the unified accounting events to multiple sharding processing nodes, so as to ensure that records that should be associated in the business enter the same sharding processing node as much as possible.

[0017] S201: Based on the core business attributes of the unified accounting event, execute the routing key construction to obtain the unified accounting event routing key; Specifically, the enterprise entity identifier, account set identifier, currency identifier, and counterparty identifier contained in the unified accounting event are concatenated in sequence, with each attribute value separated by a delimiter. The concatenated result is then hashed using the MurmurHash3 algorithm to generate a routing key for the unified accounting event, which is a 32-bit unsigned integer. Based on the multiple routing keys contained in the unified accounting event sequence, the system uses a consistent hash ring based on sharding processing nodes for sharding mapping. Unified accounting events with the same routing key will be routed to the same sharding processing node, which is beneficial for building candidate matching relationships in the future.

[0018] S202: Based on the number of unified accounting events to be processed and the node CPU utilization, the number of shards is estimated to obtain the number of shards, and the container orchestration platform performs elastic scaling according to the number of shards to dynamically adjust the number of shard processing nodes; Furthermore, the number of sharding processing nodes is not fixed, but can be dynamically determined based on the current number of unified accounting events to be processed (i.e., the length of the unified accounting event sequence) and the node CPU utilization. It can be estimated using the following formula: in: Indicates the current number of shards; Indicates the preset maximum number of shards; This indicates the total number of unified accounting events currently pending processing; This represents the average processing capacity of a single sharding node per unit of time. This represents the target load factor.

[0019] This represents the average CPU utilization of the sharded processing nodes; This represents the weighting coefficient of the CPU utilization factor.

[0020] From the above estimation relationship, it can be seen that, with other parameters remaining constant, as or Increase the number of fragments Increase accordingly until the preset maximum number of fragments is reached. .

[0021] Accordingly, the sharding processing nodes need to be deployed in a containerized manner, and the container orchestration platform should determine the number of shards accordingly. Perform elastic scaling: when the estimated number of shards is obtained. When increasing size, automatically expand horizontally to add new sharding processing node container instances; when the estimated number of shards is obtained... When shrinking, redundant sharded processing node container instances are automatically reclaimed, thereby maintaining a dynamic balance between processing capacity and resource consumption under different loads.

[0022] S203: Generate and maintain a mapping table between the routing key and the sharding processing node to obtain the routing key-sharding processing node mapping table, and distribute the unified accounting event to multiple sharding processing nodes based on the mapping table; After obtaining the number of shards, the system manages the correspondence between routing keys and shard processing nodes by constructing a routing key-shard processing node mapping table based on the various routing keys contained in the unified accounting event sequence. Specifically, the routing key-shard processing node mapping table uses the routing key as the index and the list of shard processing node numbers as the mapping value. For a routing key that corresponds to only a single shard processing node, the unified accounting event is directly delivered to that node. For a routing key that corresponds to multiple shard processing nodes, the system selects the target shard processing node sequentially from the node list according to a preset time window order, so that the unified accounting events corresponding to the routing key within the same time window are assigned to the same shard processing node, and the unified accounting events corresponding to the routing key within different time windows are evenly distributed among multiple shard processing nodes. Finally, the system distributes the unified accounting events in the unified accounting event sequence to multiple shard processing nodes based on the above routing key-shard processing node mapping table.

[0023] Furthermore, the routing key-sharding processing node mapping table supports real-time updates. When the number of routing key types changes or the sharding processing nodes are expanded or scaled down, the system updates the mapping entries in the routing key-sharding processing node mapping table in real time.

[0024] S300: In each of the sharding processing nodes, the first round of reconciliation and candidate matching construction processing is performed on the unified accounting event to obtain a candidate matching graph; Prioritizing the completion of accounting reconciliation tasks that can be directly and accurately matched before proceeding with anomaly detection helps reduce the size of subsequent candidate matching graphs.

[0025] S301: Perform source-side and target-side segmentation processing on unified accounting events to obtain a source-side unified accounting event set and a target-side unified accounting event set; Unified accounting events are divided into source-side unified accounting events and target-side unified accounting events. First, a primary classification is performed based on the source system identifier: unified accounting events originating from ERP systems, invoice management systems, expense approval systems, or fund management systems are marked as candidate source-side unified accounting events; unified accounting events originating from online banking systems, general ledger systems, or clearing systems are marked as candidate target-side unified accounting events. Second, a secondary validation is performed based on business action keywords in the summary text. Events containing initiation actions such as "application," "submission," "invoice registration," and "expense submission" are classified into the source-side unified accounting event set; events containing result actions such as "account posting," "bank receipt," "clearing completion," and "receipt confirmation" are classified into the target-side unified accounting event set. If the primary classification and secondary validation results conflict, the conflict is resolved according to preset priority rules. Through these rules, unified accounting events can be stably divided into the source-side unified accounting event set and the target-side unified accounting event set.

[0026] Furthermore, the conflict resolution process according to preset priority rules includes: Priority 1: If the voucher number exists, search for categorized unified accounting events with the same voucher number within a preset historical time window, and categorize them according to the type with the higher classification ratio of the voucher number in historical unified accounting events; Priority 2: If the voucher number is missing or cannot be determined, search for categorized unified accounting events with the same bill number within a preset historical time window, and categorize them according to the type with the higher classification ratio of the bill number in historical unified accounting events; Priority 3: If neither the voucher number nor the bill number is sufficient for determination, search for categorized unified accounting events with the same lending direction, the same counterparty, the same currency, and the same amount within a preset historical time window, and categorize them according to the type with the higher classification ratio in historical unified accounting events; Priority 4: If the first three items still cannot determine the outcome, the business action keyword verification result in the summary text shall prevail. If the initiation rule is matched, the event is assigned to the source-side unified accounting event set; otherwise, it is assigned to the target-side unified accounting event set.

[0027] S302: Perform the first round of write-off judgment processing on the unified accounting events on the source side and the target side to obtain the set of unified accounting events that have not been written off on the source side and the set of unified accounting events that have not been written off on the target side; The unified accounting events in the source-side unified accounting event set and the unified accounting events in the target-side unified accounting event set are compared one by one. When the source-side unified accounting event and the target-side unified accounting event meet the following conditions: the voucher number is consistent, or the invoice number is consistent, or the amount and currency are consistent and the business time difference does not exceed the preset time tolerance threshold, the two are identified as unified accounting events that have been successfully reconciled in the first round. The source-side unified accounting event and the target-side unified accounting event are removed from the source-side unified accounting event set and the target-side unified accounting event set, and no longer participate in the subsequent processing. After the set traversal is completed, the remaining source-side unified accounting events in the source-side unified accounting event set constitute the source-side unreconciled unified accounting event set, and the remaining target-side unified accounting events in the target-side unified accounting event set constitute the target-side unreconciled unified accounting event set.

[0028] By using the above method, the system only retains unresolved unified accounting events for subsequent anomaly detection, thereby controlling the computational scale.

[0029] S303: Based on the source side's unreconciled unified accounting event set and the target side's unreconciled unified accounting event set, perform candidate matching edge construction processing to obtain a candidate matching graph; Let the set of unreconciled unified accounting events on the source side be . The target side's unreconciled unified accounting event set is ,by The source-side unified accounting events are used as the first vertex set, with Using the unified accounting events on the target side as the second vertex set, a candidate matching graph is constructed: in, This represents the set of candidate matching edges. A candidate matching edge is established between a source-side unified accounting event and a target-side unified accounting event only if both satisfy the following conditions: currency consistency, amount deviation rate not exceeding a preset amount tolerance threshold, and business time difference not exceeding a preset time tolerance threshold. The amount deviation rate is defined as: ; in, This indicates the rate of deviation between the amount of a unified accounting event on the source side and a unified accounting event on the target side. This indicates the transaction amount of the unified accounting event on the source side. This indicates the transaction amount of the unified accounting event on the target side. It represents a very small positive constant that prevents the denominator from being zero.

[0030] The time offset is defined as: ; in, This indicates the offset of the business time between the source-side unified accounting event and the target-side unified accounting event. This indicates the business time of the unified accounting event on the source side. This indicates the business time of the unified accounting event on the target side. This indicates the minimum value to prevent the denominator from being zero.

[0031] By using the above method, the system avoids performing a full Cartesian combination on all unverified events, and instead only retains candidate matching edges that may have a verification relationship, thereby controlling the computational scale.

[0032] S304: Perform cross-shard forwarding for unified accounting events for which no candidate matching edge has been established; For unified accounting events that have not established any candidate matching edges within the current shard processing node and whose cancellation start time is less than the preset maximum processing window time threshold, cross-shard forwarding is further performed. Specifically, the system determines other shard processing nodes related to the unified accounting event based on the routing key mapping table, and distributes unified accounting events that meet the above conditions to other shard processing nodes for processing. These unified accounting events distributed to other shard processing nodes will re-execute the processing steps S301 to S304 after arriving at the shard processing node until they are cancelled, any candidate matching edges are established, or they are distributed again.

[0033] S400: Perform feature extraction and score calculation on the candidate matching edges in the candidate matching graph to obtain the matching score of the candidate matching edges; Since corporate financial reconciliation anomalies are mostly characterized by three types of discrepancies: amount, time, and accounting subject, anomaly scores are calculated using amount matching features, time matching features, and accounting subject matching features to identify abnormal data reconciliation relationships.

[0034] S401: Perform candidate feature vector construction processing on the candidate matching edges to obtain candidate feature vectors; For any candidate matching edge, construct a candidate feature vector: ; in, Indicates candidate matching edge Candidate feature vectors, Indicates the monetary matching feature. Indicates time-matching features. This represents the matching features of accounting subjects, and the value range of each feature is as follows: A higher value indicates a higher degree of matching. The amount matching feature is defined as: ; in, This indicates the feature value for matching amounts. This indicates the transaction amount of the unified accounting event on the source side. This indicates the transaction amount of the unified accounting event on the target side. It represents a very small positive constant that prevents the denominator from being zero.

[0035] The time matching feature is defined as: ; in, Indicates time-matching feature values. This indicates the posting time of a unified accounting event on the source side. This indicates the recording time of a unified accounting event on the target side. This indicates the upper limit of the preset time tolerance.

[0036] Accounting subject matching features A tiered assignment method is adopted: the value is 1 when the accounting subject of the unified accounting event on the source side completely matches the accounting subject of the unified accounting event on the target side, the value is 0.6 when the prefixes are consistent, and the value is 0 otherwise.

[0037] S402: Perform a comprehensive matching degree calculation on the candidate feature vectors to obtain the comprehensive matching degree; After obtaining the above features, calculate the comprehensive matching degree of the candidate matching edges: ; in, Indicates candidate matching edge Overall matching degree , and These represent the preset weight coefficients for the amount matching feature, time matching feature, and accounting subject matching feature, respectively. .

[0038] S403: Calculate the matching score of the candidate matching edge based on the comprehensive matching degree; For a candidate matching edge's source-side unified accounting event, the maximum value of its comprehensive matching degree with all target-side unified accounting event candidate edges is taken as the source-side local score; for a candidate matching edge's target-side unified accounting event, the maximum value of its comprehensive matching degree with all source-side unified accounting event candidate edges is taken as the target-side local score; the source-side local score and the target-side local score are weighted to obtain the matching score of the candidate matching edge.

[0039] S500: Perform threshold verification and anomaly output processing based on the matching score of candidate matching edges; S501: Perform threshold cancellation processing on the candidate matching edge matching score; After obtaining the matching scores of candidate matching edges, the system identifies candidate matching edges with matching scores greater than a preset threshold as verifiable candidate matching edges and performs verification processing on these verifiable candidate matching edges. The source-side unified accounting event and the target-side unified accounting event corresponding to the verifiable candidate matching edge are identified as successfully verified unified accounting events, and they are removed from the source-side unverified unified accounting event set and the target-side unverified unified accounting event set. At the same time, other candidate matching edges associated with the source-side unified accounting event or the target-side unified accounting event are deleted to avoid duplicate verification.

[0040] S502: Perform a pending determination for unresolved unified accounting events and output an abnormal data report; After all candidate matching edge reconciliation processes are completed, if there are still unreconciled unified accounting events in the source-side unreconciled unified accounting event set or the target-side unreconciled unified accounting event set, then check the difference between the reconciliation start time and the current time of the unreconciled unified accounting event. When the difference is greater than or equal to the preset maximum processing window time threshold, the unreconciled unified accounting event is marked as abnormal data and removed from the corresponding source-side unreconciled unified accounting event set or the target-side unreconciled unified accounting event set. When the difference is less than the preset maximum processing window time threshold, it is retained in its corresponding source-side unreconciled unified accounting event set or the target-side unreconciled unified accounting event set, and continues to participate in reconciliation and candidate matching processes in subsequent processing cycles.

[0041] Based on the unified accounting events marked as abnormal data, the system generates an abnormal data report. The abnormal data report includes at least: shard processing node identifier, source system identifier, enterprise entity identifier, account set identifier, business time, accounting time, transaction amount, currency identifier, counterparty identifier, time window range, and original record index.

[0042] Example 2, as Figure 2 As shown, this application also provides a distributed anomaly data detection system for enterprise financial reconciliation, the system comprising: The standardization module is used to collect and standardize accounting data from multiple business systems to obtain a unified accounting event sequence. The sharding and distribution module is used to perform routing and sharding and distribution processing on the unified accounting event sequence, and to distribute the unified accounting event to multiple sharding processing nodes; The candidate graph construction module is used to perform the first round of reconciliation and candidate matching construction processing on the unified accounting event in each of the sharding processing nodes to obtain the candidate matching graph. The matching score calculation module is used to perform feature extraction and score calculation on the candidate matching edges in the candidate matching graph to obtain the matching score of the candidate matching edges. The verification and anomaly detection module is used to perform threshold verification and anomaly output processing based on the matching score of the candidate matching edge.

[0043] In practical use, enterprises can first access data from ERP systems, online banking systems, and general ledger systems through standardized modules. Then, they construct routing keys based on the enterprise entity, account set, currency, business time, and counterparty to complete the sharding and distribution. Each shard processing node first performs a first round of precise reconciliation, then constructs a candidate matching graph for unreconciled records, extracts candidate feature vectors, and calculates anomaly scores. Records below the adaptive anomaly threshold are automatically reconciled; records above the adaptive anomaly threshold are automatically generated and sent for review. Through this process, enterprises can automate the reconciliation and anomaly screening of massive amounts of accounting data without significantly increasing the burden of manual review.

[0044] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0045] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0046] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application intends to include such modifications and variations.

Claims

1. A distributed anomaly detection method for enterprise financial reconciliation, characterized in that, The method includes: The accounting data from multiple business systems is collected and standardized to obtain a unified accounting event sequence. The unified accounting event sequence is routed and distributed in a sharded manner, and the unified accounting events are distributed to multiple sharded processing nodes; In each of the sharding processing nodes, the first round of reconciliation and candidate matching construction processing is performed on the unified accounting event to obtain a candidate matching graph; Feature extraction and scoring are performed on the candidate matching edges in the candidate matching graph to obtain the matching score of the candidate matching edge; Threshold verification and anomaly output handling are performed based on the matching scores of candidate matching edges.

2. The method as described in claim 1, characterized in that, The process of collecting and standardizing accounting data from multiple business systems yields a unified sequence of accounting events, including: By configuring connections and defining SQL for multiple business systems, a unified set of accounting event collection rules is obtained. Based on a unified set of accounting event collection rules, fixed-frequency collection and text standardization processing are performed to obtain a unified accounting event sequence.

3. The method as described in claim 1, characterized in that, The process of routing and sharding the unified accounting event sequence to distribute the unified accounting events to multiple sharding processing nodes includes: The routing key for a unified accounting event is constructed based on the core business attributes of the unified accounting event. The number of shards is estimated based on the number of unified accounting events to be processed and the CPU utilization of the nodes. The container orchestration platform then performs elastic scaling based on the number of shards to dynamically adjust the number of shard processing nodes. A mapping table is generated and maintained between the routing key and the sharding processing node to obtain the routing key-sharding processing node mapping table. Based on this mapping table, unified accounting events are distributed to multiple sharding processing nodes.

4. The method as described in claim 1, characterized in that, The first round of reconciliation and candidate matching construction processing is performed on the unified accounting event in each of the sharding processing nodes to obtain a candidate matching graph, including: The unified accounting events are divided into source-side and target-side processing to obtain the source-side unified accounting event set and the target-side unified accounting event set; Perform the first round of write-off judgment processing on the unified accounting events on the source side and the target side to obtain the set of unified accounting events that have not been written off on the source side and the set of unified accounting events that have not been written off on the target side; Based on the source-side unreconciled unified accounting event set and the target-side unreconciled unified accounting event set, candidate matching edge construction is performed to obtain a candidate matching graph.

5. The method as described in claim 1, characterized in that, The process of performing feature extraction and scoring calculation on candidate matching edges in the candidate matching graph to obtain matching scores for candidate matching edges includes: Perform candidate feature vector construction processing on the candidate matching edges to obtain candidate feature vectors; Perform a comprehensive matching degree calculation on the candidate feature vectors to obtain the comprehensive matching degree; The matching score of the candidate matching edge is calculated based on the comprehensive matching degree.

6. The method as described in claim 1, characterized in that, The step of performing threshold verification and anomaly output processing based on the matching scores of candidate matching edges includes: Perform threshold cancellation processing on the candidate matching edge matching scores; For unresolved unified accounting events, a pending determination is performed, and an abnormal data report is output.

7. The method as described in claim 4, characterized in that, Also includes: Perform cross-shard forwarding for unified accounting events for which no candidate matching edge has been established.

8. A distributed anomaly data detection system for enterprise financial reconciliation, characterized in that, include: The standardization module is used to collect and standardize accounting data from multiple business systems to obtain a unified accounting event sequence. The sharding and distribution module is used to perform routing and sharding and distribution processing on the unified accounting event sequence, and to distribute the unified accounting event to multiple sharding processing nodes; The candidate graph construction module is used to perform the first round of reconciliation and candidate matching construction processing on the unified accounting event in each of the sharding processing nodes to obtain the candidate matching graph. The matching score calculation module is used to perform feature extraction and score calculation on the candidate matching edges in the candidate matching graph to obtain the matching score of the candidate matching edges. The verification and anomaly detection module is used to perform threshold verification and anomaly output processing based on the matching score of the candidate matching edge.