Reconciliation and fund management method and device, reconciliation server and reconciliation system

Abstract

The invention relates to a reconciliation and fund management method and device, a reconciliation server and a reconciliation system. The method comprises the steps that business data is acquired from a data source system, the data source system comprises a financial system, an order system, a payment system and a third-party payment system, and the business data comprises order data and bill data; cleaning, converting and normalizing the order data and the bill data; automatically identifying abnormal conditions in the processed order data and bill data based on a preset rule and a difference identification algorithm, generating a difference report and an account checking result report, and automatically marking the abnormal conditions; and according to the difference report and the reconciliation result report, generating and outputting a reconciliation result. According to the method and the system, millions of data volumes can be efficiently processed, differential orders can be accurately identified and processed, a standardized account checking result is output, and a powerful guarantee is provided for fund safety and business operation.

Description

Technical Field

[0001] The present application relates to the technical field of financial data processing, and in particular to a reconciliation and fund management method, device, reconciliation server and system. Background Art

[0002] In recent years, the Chinese government has introduced a series of policies in the areas of financial technology and fund security management, placing higher demands on enterprises' fund flows and transaction data management. The Cybersecurity Law of the People's Republic of China and the Fintech Development Plan clearly emphasize the security and stability of the financial system, requiring enterprises to strengthen monitoring of fund flows and ensure the accuracy and integrity of transaction data. Furthermore, the Administrative Measures for Online Payment Businesses of Non-Bank Payment Institutions stipulate that payment institutions must establish and improve risk management and internal control systems to ensure fund security. These policies provide a solid foundation and guiding direction for the development of high-availability reconciliation and settlement management systems.

[0003] With the rapid growth of online business, the daily order volume in existing reconciliation and fund management systems has exceeded tens of millions, the scale of capital flow has expanded significantly, and the issue of fund security has become increasingly prominent. To ensure the accuracy of each transaction and protect business interests, in addition to strictly optimizing the research and development code (RD) logic, it is also necessary to efficiently check the order flow on a daily or even hourly basis to promptly detect and handle anomalies. However, faced with such a large order volume, traditional manual reconciliation methods are not only inefficient but also prone to omissions, making it difficult to meet the needs of rapid business development. Therefore, building a highly available reconciliation and settlement management system has become a top priority.

[0004] Although the reconciliation models designed for existing reconciliation and treasury management systems each have their own characteristics, they often face some common problems in actual operation:

[0005] First, there's the issue of balancing the allocation and utilization of massive real-time data throughput and computing resources. For example, in aggregated payment, order volumes have reached tens of millions, and each event source has varying amounts of data. This creates thousands of real-time reconciliation tasks, each requiring varying amounts of computing power. This places extremely high demands on the reconciliation system's data processing capabilities and performance. The system needs to possess efficient data storage, computing, and query capabilities, while also allocating sufficient computing power to each real-time reconciliation task to handle the real-time processing of large amounts of data.

[0006] Second, the processing defects of abnormal difference orders. Abnormal situations such as day cutting, multiple accounts, and few accounts occur frequently. How to quickly identify and handle these difference orders to ensure the accuracy and consistency of the account is a key problem in the design of the reconciliation system. The system needs to have intelligent difference identification and automatic reconciliation capabilities, while supporting manual intervention and abnormal processing procedures to deal with complex and variable business scenarios.

[0007] Third, the inconsistency of the bill format, the download bill time and the download method. The bill format of different payment channels or business systems may differ greatly, and the download time and method are also different, which puts higher requirements on the compatibility and flexibility of the reconciliation system. The system needs to support the parsing and adaptation of multiple bill formats, and can flexibly configure the time and method of bill download to ensure the integrity and timeliness of the reconciliation data.

[0008] In summary, there is an urgent need for an automatic reconciliation and fund management system with high mass data processing efficiency, identifiable abnormal difference orders, and consistent bill format and download method. SUMMARY

[0009] Therefore, it is necessary to provide a million-level data volume, distributed, high-availability automatic reconciliation and fund management method, device, reconciliation server and system in view of the above technical problems.

[0010] An automatic reconciliation and fund management method, the method is applicable to a reconciliation and fund management system adopting a distributed architecture, the system processes data through message queue Kafka shards and performs real-time calculation through Spark, and the method comprises the following steps:

[0011] Obtaining business data from a data source system, the data source system comprising a financial system, an order system, a payment system and a third-party payment system, the business data comprising order data and bill data;

[0012] Cleaning, converting and normalizing the order data and bill data;

[0013] Automatically identifying abnormal situations in the processed order data and bill data based on preset rules and difference identification algorithms, generating a difference report, a reconciliation result report and automatically marking abnormal situations, the abnormal situations comprising one or more combinations of day cutting, multiple accounts, few accounts, amount inconsistency and state abnormality;

[0014] Generating a reconciliation result and outputting according to the difference report and the reconciliation result report, the reconciliation result comprising a detailed account, a summary account, a summary voucher and a monthly closing report.

[0015] In one embodiment, the method further includes: processing the order data and billing data that cannot be reconciled temporarily due to time delays or other unsatisfied reconciliation conditions through a delay center to ensure that they can be rescheduled and processed when the reconciliation conditions are met.

[0016] In one embodiment, the cleaning, conversion, and normalization of the order data and billing data includes:

[0017] The order data and bill data are cleaned by a data cleaning algorithm to remove outliers and noise data;

[0018] Converting the order data and billing data in different formats into a unified format using a data conversion tool;

[0019] Normalize the order data and billing data to ensure consistency in naming, units, and formats of data fields;

[0020] The processed order data and billing data are stored in a database accessible to the reconciliation engine.

[0021] In one embodiment, the preset rules adopt a Drools 7.0 rule template, specifically including an amount tolerance rule, a state machine jump rule, and a timeliness rule. The automatic identification of anomalies in the processed order data and billing data based on the preset rules and the difference identification algorithm, the generation of a difference report, and the automatic marking of the anomalies include:

[0022] Extract order data and billing data from business data parsed through preset configurations;

[0023] Matching the order data and billing data according to preset reconciliation rules;

[0024] Extract key fields from the successfully matched order data;

[0025] Divide the order data into different batches according to business scenarios or time dimensions;

[0026] Locate the cause of the discrepancy based on preset rules and discrepancy identification algorithms, generate a discrepancy report, and automatically mark abnormalities;

[0027] Based on the difference report, the results of the automatic reconciliation are classified, analyzed and stored, and a reconciliation result report is generated.

[0028] In one embodiment, the method further comprises:

[0029] Receive processing instructions and execute processing for special scenarios, including rolling back reconciled data and restoring to the state before reconciliation and / or historical version recovery when a task is canceled.

[0030] In one embodiment, after classifying, analyzing, and storing the results of the automatic reconciliation and generating a reconciliation result report, the method further includes:

[0031] Receive modification instructions and / or review instructions, and modify or confirm the difference report and reconciliation result report; and / or

[0032] Receive query instructions and generate multi-dimensional reports based on summary report fields of preset dimensions and preset calculation rules. The preset dimensions include those based on legal persons, channels and / or product types.

[0033] In one embodiment, the method further comprises:

[0034] Before reconciliation begins, the order data and billing data within the reconciliation period are frozen. The reconciliation period may include a fiscal month, fiscal quarter, semi-annual, fiscal year, or other set period. The freezing method may include locking the data through a database transaction lock or file lock mechanism, generating a data snapshot as a reconciliation benchmark, and recording a freezing log.

[0035] After the reconciliation is completed, automatically unfreeze the order data and billing data; or / and

[0036] Automatically generate GAAP-compliant audit trail reports every month, including complete discrepancy handling and blockchain evidence.

[0037] A reconciliation and fund management device, suitable for a reconciliation and fund management system using a distributed architecture, wherein the system processes data through Kafka message queue sharding and performs real-time computing through Spark, and comprises:

[0038] A data acquisition module is used to acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems. The business data includes order data and billing data.

[0039] A data processing module, used to clean, convert and normalize the order data and billing data;

[0040] A reconciliation engine module, configured to automatically identify anomalies in the processed order and billing data based on preset rules and a difference identification algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies, including one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status;

[0041] The result output module is used to generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly statements.

[0042] A reconciliation server includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0043] Acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems, and the business data includes order data and billing data;

[0044] Cleaning, converting and normalizing the order data and billing data;

[0045] Automatically identify anomalies in the processed order and billing data based on preset rules and a difference recognition algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies. The anomalies include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status;

[0046] Generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly reports.

[0047] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the following steps:

[0048] Acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems, and the business data includes order data and billing data;

[0049] Cleaning, converting and normalizing the order data and billing data;

[0050] Automatically identify anomalies in the processed order and billing data based on preset rules and a difference recognition algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies. The anomalies include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status;

[0051] Generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly reports.

[0052] A reconciliation and fund management system, comprising: a reconciliation server, a user terminal, and a data source system, wherein the user terminal and the data source system both communicate with the reconciliation server over a network, and the system processes data through Kafka message queue sharding and performs real-time calculations through Spark, wherein

[0053] The reconciliation service end includes:

[0054] A data acquisition module is used to acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems. The business data includes order data and billing data.

[0055] A data processing module, used to clean, convert and normalize the order data and billing data;

[0056] A reconciliation engine module, configured to automatically identify anomalies in the processed order and billing data based on preset rules and a difference identification algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies, including one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status;

[0057] The result output module is used to generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly statements.

[0058] The above-mentioned reconciliation and fund management method, device, reconciliation server and system obtain business data from the data source system, which includes the financial system, order system, payment system and third-party payment system, and the business data includes order data and billing data; cleans, converts and normalizes the order data and billing data; automatically identifies abnormalities in the processed order data and billing data based on preset rules and difference recognition algorithms, generates difference reports, reconciliation result reports and automatically marks abnormalities, and the abnormalities include one or more combinations of daily cuts, multiple accounts and fewer accounts; generates and outputs reconciliation results based on the difference reports and reconciliation result reports, and the reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly statements. The reconciliation system of this application can efficiently process tens of millions of data volumes, accurately identify and process difference orders, and output standardized reconciliation results, providing strong protection for fund security and business operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 This is an application scenario diagram of the reconciliation and fund management system in one embodiment;

[0060] Figure 2A schematic diagram of the architecture of a reconciliation and fund management system in one embodiment;

[0061] Figure 3 is a schematic diagram of a data processing module in one embodiment;

[0062] Figure 4 Schematic diagram of a reconciliation process in one embodiment;

[0063] Figure 5 1. A flowchart of a method for reconciliation and fund management according to an embodiment of the present invention;

[0064] Figure 6 A structural block diagram of an account reconciliation and fund management device in one embodiment;

[0065] Figure 7 FIG. 4 is a diagram showing the internal structure of a reconciliation server in one embodiment. DETAILED DESCRIPTION

[0066] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0067] In one embodiment, Figure 1 and 2 As shown, a reconciliation and fund management system is provided, which is applied to Figure 1The reconciliation server 104 in FIG. 1 is used as an example to illustrate the system, which includes: a reconciliation server 104, a user terminal 102, and a data source system. The user terminal 102 and the data source system communicate with the reconciliation server 104 through a network. The system processes data through Kafka message queue sharding and performs real-time computing through Spark. The reconciliation server 104 includes: a data acquisition module for acquiring business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems. The business data includes order data and billing data; a data processing module for cleaning, converting, and normalizing the order data and billing data; a reconciliation engine module for automatically identifying anomalies in the processed order data and billing data based on preset rules and a difference recognition algorithm, generating a difference report and a reconciliation result report, and automatically marking anomalies. The anomalies include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status; and a result output module for generating and outputting reconciliation results based on the difference report and reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers, and monthly statements. The user terminal 102 may be, but is not limited to, various personal computers, laptops, smartphones, and tablet computers, and is used to query reconciliation results, send processing instructions, modification instructions, and / or review instructions. The reconciliation server 104 may be implemented as a standalone server or a server cluster consisting of multiple servers.

[0068] The reconciliation server 104 adopts a multi-level pipeline processing architecture: the transaction reconciliation engine uses Apache Beam to implement shard processing for each reconciliation project. The reconciliation server 104 allocates cloud resources to different clusters through dynamic cluster allocation. Each cluster is responsible for a designated task and has dynamic adjustment capabilities. The high-priority task cluster enjoys high-priority resource guarantees. Weighted load balancing is adopted within the cluster. The script computing power requirements are calculated regularly, and the reconciliation event source and computing power are rebalanced to ensure load balancing of each node and avoid resource waste or overload. At the same time, combined with the horizontal automatic scaling strategy (Horizontal Pod Autoscaling, HPA), a computing power buffer is reserved in each sub-cluster. When a sudden increase in traffic causes insufficient computing power, the HPA-expanded machine is automatically allocated to the high-priority cluster according to priority, and computing power is replenished in time to ensure high availability of the platform and real-time execution of tasks. Due to the order of order payment and refund association, cross-day and other factors, the reconciliation must be carried out in chronological order and cross-day reconciliation is not allowed. For example, even if the current date is the 15th, if the project start date is the 1st, the reconciliation must also start from the 1st, because the unilateral account of day t needs to be reconciled on day t+1, and jumping reconciliation will cause unnecessary trouble. The reconciliation engine is designed with our reconciliation data as the base point and the order number as the association key to compare our reconciliation data with the channel party's reconciliation data item by item. The comparison results include balance, unilateral (long and short payments), and wrong accounts. The creation and query of reconciliation tasks are done by the financial staff in the system, setting the start and end dates of the reconciliation, and checking the order library that needs to be reconciled. The reconciliation engine will automatically complete the reconciliation task, and the financial staff will handle the errors after the reconciliation is completed. It ensures the efficiency and accuracy of the reconciliation process, while reducing manual intervention and improving the overall reconciliation efficiency.

[0069] The system leverages a distributed architecture and the decoupling capabilities of Kafka's message queues to process massive amounts of data in shards. Combined with a dynamic resource scheduling algorithm, it allocates computing resources based on the real-time demands of reconciliation tasks. Through efficient data storage and computing engines like Spark and Flink, it enables real-time processing of tens of millions of data points, achieving peak throughput of 80,000+ TPS and reconciliation task processing capabilities of 200,000+ QPS.

[0070] like Figure 2 As shown, this application constructs a closed-loop system of data acquisition-data processing-reconciliation processing-output results, covering core modules such as data acquisition module, data processing module, reconciliation engine module and output results module, forming an efficient and collaborative workflow.

[0071] like Figure 3As shown, after the business data of this application is configured and parsed, it is sent to the corresponding reconciliation engine and delay center through the routing distribution mechanism. The delay center is used to process data that cannot be reconciled temporarily due to time delays or unsatisfied conditions, ensuring that the data can be rescheduled and processed when the reconciliation conditions are ripe. Subsequently, the data is filtered by the filtering script to remove invalid information and finally flows to the reconciliation script execution engine. The reconciliation script execution engine is the core calculation module of the reconciliation system, responsible for calling public functions and obtaining comparison data from third-party payment systems (such as payment platforms, order systems, etc.), that is, reference data for comparison with event data. The execution engine performs data verification according to the preset reconciliation script rules, and the verification results are transferred to the result processing module. The result processing module is responsible for classifying, analyzing and storing the verification results, generating difference reports, reconciliation result reports, etc., and supporting manual intervention and further processing. Through the above process, the system realizes the full process automation management from data analysis, reconciliation execution to result processing, ensuring the efficiency, accuracy and traceability of reconciliation.

[0072] like Figure 4As shown, reconciliation data freezing, difference processing, and freezing the current fiscal month play important roles in the reconciliation process, ensuring the system's efficiency, accuracy, and compliance from three dimensions: data stability, difference processing efficiency, and financial data integrity. By freezing reconciliation data, the system avoids the risk of data being tampered with or lost during the reconciliation process; through difference processing logic, the system achieves rapid location and efficient processing of difference orders; and by freezing the current fiscal month, the system ensures the integrity and traceability of financial data. The purpose of reconciliation data freezing is to freeze relevant data before the reconciliation begins, ensuring that the data is not modified or lost during the reconciliation process. This includes locking data through database transaction locks or file lock mechanisms, generating data snapshots as reconciliation benchmarks, recording freeze logs for auditing, and automatically unfreezing data after the reconciliation is completed, effectively avoiding the risk of data being tampered with or lost during the reconciliation process.The purpose of the difference processing is to quickly locate the difference orders and generate difference reports through intelligent difference recognition and automated reconciliation capabilities, and through preset rules such as amount discrepancies and status anomalies. The preset rule engine adopts Drools 7.0 rule templates, which include three core rules: amount tolerance rules, state machine jump rules, and timeliness rules. The amount discrepancy detection adopts a dynamic dual-threshold strategy, with the hard threshold setting ±1% absolute deviation, and the soft threshold dynamically calculated using the 3σ principle. The rolling window statistics are maintained through RedisTimeSeries. The state anomaly detection is modeled through a finite state machine, and multiple legal state jump paths are defined. Illegal jumps trigger SNMP alarms. At the machine learning level, a multi-task learning model based on Transformer is constructed (sharing the underlying BERT encoding layer, the upper branch generates an amount difference classification head (Softmax outputs multiple categories) ) and state anomaly detection head (BiLSTM-CRF sequence labeling). The training data uses semi-automatically generated adversarial samples (using the GAN generator to construct boundary cases, and the discriminator is the XGBoost model). Feature engineering includes time series features (using TSFRESH to extract multiple time series features), cross-system correlation features (using the relationship graph embedding vector generated by GraphSAGE) and business context features (NLP features extracted by RoBERTa). The model service uses the Triton inference server (configured with dynamic batch processing max_batch_size = 30), and the online learning module is implemented through Flink. Stateful functions enable real-time model updates (hourly incremental training, feature drift detection using the KS test, and full retraining triggered when p < 0.02). In engineering implementation, rules and models collaborate using a weighted voting mechanism (rule weight 0.3 + model weight 0.7). Real-time feature splicing is achieved through Apache Kafka's Streams API. Difference determination results are written to Apache Cassandra partitioned tables (sharded by processing status). Typical difference cases are automatically stored in the Neo4j knowledge graph (nodes contain entities such as difference patterns, treatment plans, and associated systems). Differences that can be automatically fixed (such as time differences within the allowable range) are automatically processed, forming a continuously evolving intelligent recognition system. Detailed reports are generated for complex differences and pushed to a manual review interface, allowing financial personnel to make manual adjustments or communicate with business departments for confirmation. Once the difference is resolved, the system feeds the results back to the core reconciliation module, re-triggering the reconciliation process to ensure that the discrepant orders are fully resolved. The freezing process for the current fiscal month is used to freeze the reconciliation data for the current fiscal month at the end of the fiscal month to prevent the data from being modified and ensure the integrity and traceability of the financial data.Specific practices include freezing data through database transaction locks or file locks, generating detailed ledgers, summary ledgers, summary vouchers, and monthly reports, supporting multi-dimensional query and analysis by legal person, channel, and other factors, and pushing approved vouchers to third-party financial systems. The system supports periodic financial processing needs such as monthly, quarterly, and annual summaries, and outputs comprehensive reports covering key information such as total transaction amounts, variance amounts, and taxes. This node ensures the integrity and traceability of financial data, while also providing strong support for a company's financial management and business operations through automated report generation and voucher push capabilities.

[0073] In the above-mentioned reconciliation and fund management system, the system realizes full-process automated management through three stages: before, during and after. In the before stage, the data acquisition module uses ETL technology to extract, clean, convert and load data from the order system, payment system and third-party payment platforms (such as WeChat, Alipay, UnionPay, etc.) to ensure data integrity and consistency; the data processing module further cleans and normalizes the data to provide standardized input for the reconciliation engine. In the during stage, the reconciliation engine module quickly compares order and bill data based on preset rules and intelligent difference recognition algorithms, identifies difference orders and generates difference reports, supports the combination of automatic reconciliation and manual intervention, and ensures the accuracy of reconciliation results. In the after stage, the result processing module and the result output module generate detailed accounts, summary accounts, summary vouchers and monthly statements, support multi-dimensional query and analysis, and push the approved vouchers to the financial system to ensure the integrity and traceability of financial data. This application provides efficient solutions to problems such as massive data throughput, abnormal difference order processing and inconsistent billing formats. Distributed computing and dynamic batch partitioning algorithms optimize data throughput and computing power allocation. Intelligent discrepancy identification algorithms and rule engines automatically classify and process discrepant orders, improving discrepancy processing efficiency by 50%. Adapter patterns and data cleansing tools unify multi-source, heterogeneous data formats to ensure data compatibility. The system significantly improves reconciliation efficiency and accuracy, reduces data errors by 95%, lowers labor costs, and provides reliable protection for fund security and business operations.

[0074] In one embodiment, Figure 5 As shown, a reconciliation and fund management method is provided, which is applied to Figure 1 Taking the reconciliation server 104 in FIG. 1 as an example, the following steps are included:

[0075] Step S501: Acquire business data from data source systems, where the data source systems include financial systems, order systems, payment systems, and third-party payment systems. The business data includes order data and billing data.

[0076] In the embodiment, the business data is obtained from the data source systems such as the financial system, the order system, the payment system and the third-party payment system by the optimized ETL technology and the standardized process to obtain the complete original order data and the original billing data. Specifically, the data is extracted from the data source of each data source system through an API interface or a file transfer protocol (FTP). In the actual embodiment, if the order and billing center is already available, the business data can be directly obtained by connecting to the order and billing center, and if the data provided by the order and billing center cannot meet the requirements of the reconciliation center, such as lacking of core fields or state information, the reconciliation center needs to make a supplementary requirement to the data source system. In special cases, a small amount of communication and coordination with the data source system may be needed to ensure the integrity and accuracy of the data to meet the functional requirements of the reconciliation center.

[0077] Among them, in order to meet the data access needs of different business parties, multiple data access methods are provided, including supporting business party self-defined field conversion rules for Excel file upload, calling polling full or incremental data pulling through Dubbo or HTTP interface, and supporting regularized data writing to the source data pool. After multiple business data is imported into the source data pool, in order to distinguish between various types of business data, the system uses business data types, such as "retailspues" representing the retail commodity warehouse commodity ES reconciliation data, and execution cycle version numbers, such as "20200101" representing the version batch loaded by the current business data iterator, for data isolation and identification. Due to the high complexity of business data, the Class parsing according to each business definition will bring high maintenance cost, therefore, the source data format standardized access is provided, which is stored in JSON data format serialization, and when used, it is deserialized according to Map.class for use, thereby reducing the complexity of data parsing and improving the flexibility and scalability of data. Through unified data connection and standardized processing, the data can be efficiently integrated.

[0078] Step S502, cleaning, converting and normalizing the order data and billing data.

[0079] In this embodiment, the order data and billing data are cleaned, converted and normalized, and outliers, duplicate values ​​and noise data are removed through deduplication, completion and error correction operations, and are sent to the corresponding reconciliation engine and delay center respectively through the routing distribution mechanism. The specific processing process is as follows: the order data and billing data are cleaned by a data cleaning algorithm to remove outliers and noise data; the order data and billing data in different formats are converted into a unified format through a data conversion tool; the order data and billing data are normalized to ensure that the naming, unit and format of the data fields are consistent, such as unifying the transaction time format of different channels into "YYYY-MM-DD HH:MM:SS" and the amount unit into "yuan"; the data fields are standardized and classified to ensure that the meaning of the fields is consistent; the processed order data and billing data are stored in a database accessible to the reconciliation engine, and the processed data are stored in a unified reconciliation data table to provide high-quality input data for subsequent reconciliation tasks. Furthermore, for data that cannot be reconciled due to time delays or unmet conditions, the order and billing data can be processed by the delay center to ensure that it can be rescheduled and processed when the reconciliation conditions are met. Subsequently, the data is filtered through a filtering script to clean, transform, and normalize the order and billing data, ensuring accuracy and consistency and providing standardized input data for reconciliation.

[0080] Step S503, based on preset rules and a difference identification algorithm, automatically identifies abnormalities in the processed order data and billing data, generates a difference report and a reconciliation result report, and automatically marks abnormalities, wherein the abnormalities include one or more combinations of daily cuts, over-accounts, and under-accounts.

[0081] In this embodiment, the preset rules utilize a Drools 7.0 rule template, specifically including amount tolerance rules, state machine transition rules, and timeliness rules. The discrepancy identification algorithm incorporates cluster analysis and a decision tree model. Abnormal conditions include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status. The amount discrepancy detection adopts a dynamic dual-threshold strategy, with the hard threshold set to ±1% absolute deviation and the soft threshold dynamically calculated using the 3σ principle. The rolling window statistics are maintained through RedisTimeSeries. State anomaly detection is modeled through finite state machines, and multiple legal state jump paths are defined. Illegal jumps trigger SNMP alarms. At the machine learning level, a Transformer-based multi-task learning model is constructed (sharing the underlying BERT encoding layer, and the upper layer branches out the amount difference classification head (Softmax output multi-class) and the state anomaly detection head (BiLSTM-CRF sequence labeling)). The training data uses semi-automatically generated adversarial samples, and the boundary cases are constructed through the GAN generator. The discriminator is the XGBoost model. Feature engineering includes time series features (extracting multiple time series features through TSFRESH), cross-system correlation features (using the relationship graph embedding vector generated by GraphSAGE), and business context features (NLP features extracted by RoBERTa). The model service adopts the Triton inference server (configured with dynamic batch processing max_batch_size = 30), and the online learning module is implemented through Flink Stateful This function implements real-time model updates, with hourly incremental training. Feature drift detection uses the KS test, triggering full retraining when p < 0.02. In engineering implementation, rules and models collaborate using a weighted voting mechanism, with a rule weight of 0.3 and a model weight of 0.7. Real-time feature splicing is achieved through Apache Kafka's Streams API. Difference determination results are written to an Apache Cassandra partitioned table, sharded by processing status. Typical difference cases are automatically deposited into the Neo4j knowledge graph (where nodes contain entities such as difference patterns, processing solutions, and associated systems). Differences that can be automatically fixed (such as time differences within the allowable range) are automatically processed, forming a continuously self-evolving intelligent recognition system. Detailed reports are generated for complex differences and pushed to a manual review interface, allowing financial personnel to complete manual adjustments or communicate with the business department for confirmation.

[0082] The automatic identification of the abnormal situation in the processed order data and bill data based on the preset rule and difference identification algorithm, the generation of a difference report and the automatic marking of the abnormal situation include: extracting order data and bill data from business data parsed through a preset configuration; matching the order data and bill data according to a preset reconciliation rule; extracting key fields from the order data that are successfully matched; dividing the order data into different batches according to business scenarios or time dimensions; locating the difference causes based on the preset rule and difference identification algorithm, and generating a difference report and automatically marking the abnormal situation; and classifying, analyzing and storing the results of automatic reconciliation according to the difference report, and generating a reconciliation result report.

[0083] Preferably, the reconciliation task can be configured according to dimensions such as channels, time ranges and transaction types, and the task scheduler can be used to realize timed reconciliation or manually triggered reconciliation. Various reconciliation types such as general ledger reconciliation and detailed reconciliation can be realized, and multiple reconciliations can be performed on the same batch of data to ensure the accuracy of the results. The specific methods include: first, using the CityHash64 algorithm to quickly bucket the serial numbers, using the Redis cluster to build a distributed hash index, and realizing millisecond-level serial number matching; high-precision Decimal128 calculation is used for amount verification, state matching is based on a predefined variety of state transition matrix, verification is performed through a finite state machine, a dynamic sliding window algorithm is used for time window verification, the reference window = 3 minutes, and ± 30% is automatically adjusted according to the historical transaction frequency; the core of the comparison engine uses the Apache Beam batch-flow integrated processing framework, real-time triggers a compensation query for transactions that fail to match, filters 98% of non-abnormal cases through BloomFilter, enables a secondary backtracking mechanism in complex scenarios, and builds a transaction trace tree based on Merkle Patricia Trie; the amount difference is calculated in parallel through the SIMD instruction set, the Columnar storage format is used to speed up field reading, and the CUDA kernel function state matrix operation is used, which realizes full-amount comparison in less than 3 minutes in a test of ten million transactions, and maintains high performance of the system through regular hash shard reconstruction and rule pre-compilation, realizes 99.99% of the serial number instantaneous matching success rate and 100% of the amount verification accuracy in the actual production environment, and controls the abnormal transaction detection delay within 200 ms, and more than 85% of the pseudo-difference transactions can be automatically repaired daily. For abnormal situations such as day cutting, multiple accounts and few accounts, the system realizes intelligent identification and automatic processing of differences through the difference reconciliation and rollback mechanism.

[0084] Through machine learning models, we analyze differential orders and identify potential causes, such as network delays and system failures; automatically adjust differences that can be automatically repaired (such as time differences within the allowable range); generate detailed reports for complex differences and push them to the manual review interface. Differentiated reconciliation mainly uses a differential root cause analysis engine based on the XGBoost-GRU hybrid model. The input features include transaction time offset (calculated by DTW dynamic time warping), system heartbeat interval (30-second granularity indicators collected by Prometheus), network packet loss rate (TCP retransmission times / total number of packets) and other multi-dimensional features. The output layer uses Softmax to give the probability distribution of multiple types of abnormal causes (daily cut anomalies, network delays, system failures, human errors, unknown types), and the model accuracy rate reaches 93.5%; automatic repair uses a multi-stage processing pipeline: for time differences (<3 seconds), the NTP time synchronization service is called for automatic calibration, and for amount drift (within ±0.01%), the fund automatic leveling interface is triggered, and a two-phase commit protocol is used to ensure atomic The reversal process is initiated for duplicate accounts (transactions with a similarity of >99% detected by SimHash) based on the Saga transaction model; complex difference reports are generated using an NLG model fine-tuned based on GPT-3.5, which inputs difference feature vectors and outputs natural language reports containing three parts: root cause speculation, impact range assessment, and treatment suggestions. An interactive visual dashboard is built using D3.js, with Sankey diagrams showing abnormal fund flows and heat maps showing abnormal spatiotemporal distribution. In terms of implementation, KafkaStreams is used to build a real-time event processing topology, with Exactly-Once semantics set, and the difference processing status is persisted to Cassandra (partitioned by trading day). A full reconciliation check is performed every morning through Spark, using Merkle Tree quickly locates discrepant blocks. After the system was launched, the daily exception processing time was shortened from an average of 4 hours to 9 minutes, the automatic repair rate of over-account / under-account issues was increased to 78%, and the monthly manual intervention hours were reduced by approximately 1,200 hours. At the same time, by continuously collecting and processing feedback, the model is continuously optimized, achieving a self-evolutionary capability with an average monthly improvement of 1.2% in the accuracy of difference processing.

[0085] Reconciliation processing is the core module of the entire reconciliation and fund management system, and its design needs to fully consider the complete closed loop of the forward and reverse processes. In the forward process, order data and billing data are extracted from the standardized reconciliation data table to ensure the integrity and real-time nature of the data; data is matched according to preset rules (such as amount, time, status, etc.) to ensure the consistency of transactions; key fields such as transaction number, amount, time, etc. are extracted from successfully matched transactions for the calculation and output of subsequent reconciliation results; massive data is divided into different batches according to business scenarios or time dimensions to improve reconciliation efficiency and optimize resource allocation; the cause of the difference is quickly located through the difference recognition algorithm, such as daily cuts, multiple accounts, fewer accounts, etc., and a difference report is generated. Through the difference processing logic, the difference orders are quickly located and efficiently processed; detailed accounts, summary accounts, summary vouchers and monthly statements are generated based on the reconciliation results, supporting multi-dimensional query and analysis, and the vouchers that have passed the review are pushed to the financial system. In the reverse process, processing instructions are received and special scenarios are handled. These include rolling back reconciled data to its pre-reconciliation state and / or restoring historical versions when a task is canceled, ensuring data traceability and operational flexibility. Through the collaborative design of forward and reverse processes, the reconciliation engine module efficiently handles complex reconciliation scenarios, ensuring the accuracy, completeness, and traceability of reconciliation results, and providing strong technical support for fund security and business operations.

[0086] This invention uses an intelligent discrepancy recognition algorithm to identify discrepancy types (such as inconsistent amounts and abnormal status), generating detailed reconciliation reports containing information such as discrepancy order numbers, discrepancy types, and discrepancy amounts. The report can also be exported to Excel or PDF formats, making it easier for financial personnel to track and process the discrepancy. For example, a clustering algorithm can be used to categorize discrepancy orders by amount, time, status, and other dimensions, automatically generating a discrepancy report and pushing it to the manual review interface, improving discrepancy processing efficiency by 50% and reducing manual intervention time by 40%.

[0087] Preferably, the method further comprises:

[0088] Receive modification instructions and / or review instructions, and modify or confirm the difference report and reconciliation result report; and / or

[0089] Receive query instructions and generate multi-dimensional reports based on the summary report fields and preset calculation rules for pre-set dimensions, including those based on legal entity, channel, and / or product type. These modification instructions, review instructions, and query instructions all originate from user terminals, which can be used by financial personnel, legal entities, and other relevant public officials.

[0090] Step S504: Generate and output a reconciliation result based on the difference report and the reconciliation result report. The reconciliation result includes the total number of reconciliation items, total differences, detailed accounts, summary accounts, summary vouchers, and monthly report.

[0091] In this embodiment, reconciliation results are divided into two categories: transaction reconciliation results and fund reconciliation results. Transaction reconciliation results are the result of checking each reconciliation item by number of transactions. They are primarily used to compare order data with payment data for consistency in terms of transaction count, amount, status, and other information. Through an intelligent difference recognition algorithm and a preset rule engine, the system automatically classifies the difference type and generates a detailed report containing information such as the difference order number, difference type, and difference amount. The system employs a multi-stage pipeline processing architecture: the transaction reconciliation engine implements sharding processing for each reconciliation item using Apache Beam. The core difference detection algorithm combines similar transaction identification, treating Hamming distances ≤ 3 as duplicates, employing a hard threshold of ±0.01% absolute error, a dynamic threshold of ±3σ rolling intervals, and PPO algorithm training, supporting multiple state transition rules. The fund reconciliation layer uses a CRNN-based OCR model to recognize 20+ bank formats with an accuracy rate of 99.2%. The difference report generation module integrates XGBoost multi-classifiers and automatically generates natural language analysis conclusions, outputting basic difference details, root cause analysis, impact assessment, and an ECharts dynamic Sankey diagram to display abnormal fund flows. , Plotly heat map presents the temporal and spatial distribution of differences; the core reconciliation algorithm is accelerated by CUDA, Redis caches hot transaction data, and regular expression matching is accelerated by FPGA hardware, reducing the invoice tax rate recognition delay from 50ms to 1.2ms; after the system is launched, it can process more than 200 million transaction reconciliations per day, and the automatic repair rate of fund differences reaches 83%. At the same time, through blockchain evidence storage and smart contracts, difference arbitration is automatically executed, reducing the reconciliation dispute processing cycle from an average of 7 days to 4 hours, and generating a full-link tracking report that meets SOX audit requirements (including the complete chain of evidence from original data to adjustment entries). A hash algorithm is used to quickly match transaction serial numbers to ensure comparison efficiency; the rule engine verifies the amount, status, and time window of each transaction to identify inconsistent transactions; a machine learning model is used to analyze the causes of differences (such as network delays, system failures, etc.) and generate difference reports, which improves the efficiency of difference processing by 50%; the fund reconciliation result is the result of checking each fund account reconciliation item according to the expense amount, which is mainly used to verify the accuracy and completeness of fund flows, covering the verification of fee items such as handling fees, service fees, and taxes. Through the preset fee item mapping rules, the fee items of different channels (such as handling fees, service fees, taxes, etc.) are uniformly mapped to standard fields, and Delta Lake is used to store the reconciliation results. Airflow is used to trigger subsequent processing in a targeted manner (if the difference is greater than 10,000 yuan, the reconciliation workflow is automatically initiated). Zero-knowledge proof is introduced in the key verification link to verify data integrity without exposing sensitive information; the expense amount is checked item by item using an automated fund reconciliation tool to ensure the balance of income and expenditure; the credit and debit balance verification mechanism is used to ensure that the debit and credit amounts of the fund account are consistent to avoid fund errors.Through comprehensive analysis of transaction and fund reconciliation results, we can fully understand the matching status of reconciliation items, identify the causes of discrepancies, and provide a reliable data basis for fund security and business operations. Based on the reconciliation results, a detailed ledger containing detailed records of each transaction is generated, which can be queried by dimensions such as transaction time and transaction type. A summary ledger is generated by dimensions such as order and channel, which can be queried and analyzed in multiple dimensions. Based on the summary ledger, summary vouchers that comply with financial regulations are generated, which can verify the balance of credits and debits. At the end of each fiscal month, a comprehensive financial statement is generated, covering key information such as total transaction amount, discrepancy amount, and tax. Finally, the approved vouchers are pushed to the third-party financial system to ensure the integrity and traceability of financial data.

[0092] Output the final reconciliation results, displaying key information such as the total price including tax, the total price before tax, and the total tax. The relevant calculation formulas are as follows: Unit price including tax = Unit price before tax × tax rate (1 + 13%), Unit price before tax = Unit price including tax ÷ Tax rate (1 + 13%), Tax = Unit price before tax × Tax rate (13%). The specific implementation can adopt a multi-layer classification model architecture: the first layer uses LightGBM (num_leaves = 31, feature_fraction = 0.8) for coarse classification (amount / status / time difference). The second layer uses isolation forest (contamination = 0.01) to detect outliers for amount differences. The state difference uses LSTM state machine (hidden_size = 64) to identify illegal jumps. The time difference uses DTW algorithm (window_size = 5) to calculate the timing offset. The report generation engine is based on Apache POI and Flying Built by Saucer, it dynamically generates Excel through JXLS templates (supports conditional formatting to highlight differences), uses PDFBox to render interactive charts for PDF conversion, and generates difference distribution heat maps through ECharts; the manual intervention interface integrates React+Redux to achieve real-time collaborative editing, with built-in intelligent suggestion components (case retrieval based on Faiss index, TOP3 recommendation accuracy of 92%), and the processing flow is driven by the Camunda workflow engine. SLAs are configured: 4 hours for ordinary differences and 30 minutes for major differences; the tax calculation module uses a high-precision Decimal operation library, and the core algorithm realizes lossless calculation of two-way conversion of tax-inclusive / tax-exclusive prices, and has built-in intelligent matching of three tax rates of 13%, 9%, and 6%, and extracts the tax rate identifier in the invoice remarks column through regular expressions; the output report is output through Spark SQL aggregation (daily incremental calculation) uses a three-layer verification mechanism for key indicator display: original data verification, intermediate process verification, and final result verification (comparison with the Golden Tax System API). The actual tax calculation error is <0.0001 yuan under the order volume of tens of millions. At the same time, the robustness of the calculation engine is ensured by regularly performing fuzzing tests (generating random amount / tax rate combinations). Ultimately, the average time for the entire process from identification to closed-loop processing of differential orders is shortened from the traditional 8 hours to 1.5 hours, and the tax calculation accuracy rate remains 100%.

[0093] Preferably, the method further comprises:

[0094] Automatically generate GAAP-compliant audit trail reports every month, including complete discrepancy handling and blockchain evidence.

[0095] This system achieves automated management of the entire process, from data access to output, significantly improving reconciliation efficiency and accuracy, reducing labor costs, and ensuring the transparency and security of capital flows. Summary ledgers can be generated by legal entity, channel, and other dimensions, providing flexible query capabilities. Summary vouchers also support configurable voucher formats and content value rules to ensure compliance with financial regulations. Monthly reports include key information such as total price including tax, total price before tax, and total tax amount, and feature multi-dimensional data analysis and auditing capabilities to ensure transparency, accuracy, and traceability of capital flows, providing strong support for financial management and decision-making.

[0096] In the above-mentioned reconciliation and fund management method, business data is obtained from the data source system, which includes a financial system, an order system, a payment system and a third-party payment system, and the business data includes order data and billing data; the order data and billing data are cleaned, converted and normalized; based on preset rules and difference recognition algorithms, abnormalities in the processed order data and billing data are automatically identified, a difference report is generated and abnormalities are automatically marked, and the abnormalities include one or more combinations of daily cuts, multiple accounts and fewer accounts; based on the difference report and the reconciliation result report, a reconciliation result is generated and output, and the reconciliation result includes a detailed account, a summary account, a summary voucher and a monthly report. The reconciliation system of this application can efficiently process tens of millions of data volumes, accurately identify and process difference orders, and output standardized reconciliation results, providing strong protection for fund security and business operations.

[0097] Furthermore, the method further comprises:

[0098] Before reconciliation begins, the order data and billing data within the reconciliation period are frozen. The reconciliation period may include a fiscal month, fiscal quarter, semi-annual, fiscal year, or other set period. The freezing method may include locking the data through a database transaction lock or file lock mechanism, generating a data snapshot as a reconciliation benchmark, and recording a freezing log.

[0099] After the reconciliation is completed, the order data and billing data are automatically unfrozen.

[0100] In this embodiment, relevant data is frozen before reconciliation begins to ensure that the data is not modified or lost during the reconciliation process. This includes locking the data through a database transaction lock or file lock mechanism, generating a data snapshot as a reconciliation benchmark, recording a frozen log for audit purposes, and automatically unfreezing the data after the reconciliation is completed. This effectively avoids the risk of data tampering or loss during the reconciliation process. It implements periodic financial processing requirements such as monthly, quarterly, and annual summaries, and outputs comprehensive reports covering key information such as total transaction amounts, difference amounts, and taxes. This ensures the integrity and traceability of financial data, while providing strong support for the company's financial management and business operations through automated report generation and voucher push functions.

[0101] It should be understood that although Figure 5 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. In addition, Figure 5 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0102] In one embodiment, Figure 6 As shown, a reconciliation and fund management device is provided, including: a data acquisition module 61, a data processing module 62, a reconciliation engine module 63 and a result output module 64, wherein:

[0103] Data acquisition module 61, used to acquire business data from data source systems, such as financial systems, order systems, payment systems, and third-party payment systems. The business data includes order data and billing data.

[0104] Data processing module 62, for cleaning, converting and normalizing the order data and billing data;

[0105] A reconciliation engine module 63 is configured to automatically identify anomalies in the processed order data and billing data based on preset rules and a difference identification algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies. The anomalies include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status.

[0106] The result output module 64 is used to generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly reports.

[0107] Furthermore, the device further comprises:

[0108] The delayed processing module is used to process the order data and billing data that cannot be reconciled temporarily due to time delay or other reconciliation conditions not being met, so as to ensure that they can be rescheduled and processed when the reconciliation conditions are ripe.

[0109] Furthermore, the data processing module 62 is specifically configured to remove outliers and noise data from the order data and bill data through a data cleaning algorithm;

[0110] Converting the order data and billing data in different formats into a unified format using a data conversion tool;

[0111] Normalize the order data and billing data to ensure consistency in naming, units, and formats of data fields;

[0112] The processed order data and billing data are stored in a database accessible to the reconciliation engine.

[0113] Furthermore, the preset rules adopt Drools 7.0 rule templates, specifically including amount tolerance rules, state machine jump rules and timeliness rules. The reconciliation engine module 63 is specifically used to extract order data and bill data from the business data parsed by the preset configuration;

[0114] Matching the order data and billing data according to preset reconciliation rules;

[0115] Extract key fields from the successfully matched order data;

[0116] Divide the order data into different batches according to business scenarios or time dimensions;

[0117] Locate the cause of the discrepancy based on preset rules and discrepancy identification algorithms, generate discrepancy reports, and automatically mark abnormalities;

[0118] Based on the difference report, the results of the automatic reconciliation are classified, analyzed and stored, and a reconciliation result report is generated.

[0119] Furthermore, the device further comprises:

[0120] The reconciliation recovery module is used to receive processing instructions and execute processing for special scenarios, including rolling back reconciled data and restoring it to the state before reconciliation and / or historical version recovery when a task is canceled.

[0121] 进一步地,所述装置还包括:

[0122] A manual processing module is used to receive modification instructions and / or review instructions, and to modify or confirm the difference report and reconciliation result report;

[0123] The query generation module is used to receive query instructions and generate multi-dimensional reports based on the summary report fields of preset dimensions and preset calculation rules. The preset dimensions include those based on legal persons, channels and / or product types.

[0124] 进一步地,所述装置还包括:

[0125] A data freezing module is configured to freeze the order data and billing data within a reconciliation period before reconciliation begins. The reconciliation period may include a fiscal month, fiscal quarter, semi-annual, fiscal year, or other set period. The freezing method may include one or more combinations of locking data through a database transaction lock or file lock mechanism, generating a data snapshot as a reconciliation benchmark, and recording a freeze log.

[0126] A data unfreezing module, used to automatically unfreeze the order data and billing data after the reconciliation is completed; or / and

[0127] The monthly report generation module is used to automatically generate an audit trail report that complies with GAAP standards every month. The audit trail report includes complete discrepancy processing and blockchain evidence.

[0128] The specific definition of the reconciliation and fund management device can be found in the definition of the reconciliation and fund management method above and will not be repeated here. Each module in the reconciliation and fund management device described above may be implemented in whole or in part via software, hardware, or a combination thereof. Each of the modules described above may be embedded in or independent of a processor in the reconciliation server in hardware form, or may be stored in memory in the reconciliation server in software form, so that the processor can call and execute the corresponding operations of each module.

[0129] In one embodiment, a reconciliation server is provided. The reconciliation server may be a server or a server cluster. The internal structure diagram thereof may be as follows: Figure 7As shown. The reconciliation server includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the reconciliation server is used to provide computing and control capabilities. The memory of the reconciliation server includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the reconciliation server is used to store business data. The network interface of the reconciliation server is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a reconciliation and fund management method is implemented. The following steps are implemented:

[0130] Acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems, and the business data includes order data and billing data;

[0131] Cleaning, converting and normalizing the order data and billing data;

[0132] Automatically identify anomalies in the processed order and billing data based on preset rules and a difference recognition algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies. The anomalies include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status;

[0133] Generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly reports.

[0134] Those skilled in the art will understand that Figure 7 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application and does not constitute a limitation on the reconciliation server to which the solution of the present application is applied. The specific reconciliation server may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0135] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0136] Acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems, and the business data includes order data and billing data;

[0137] Cleaning, converting and normalizing the order data and billing data;

[0138] Automatically identify anomalies in the processed order and billing data based on preset rules and a difference recognition algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies. The anomalies include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status;

[0139] Generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly reports.

[0140] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0141] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0142] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A method for reconciliation and fund management, characterized in that: The method is applicable to a reconciliation and fund management system using a distributed architecture. The system processes data through Kafka message queue sharding and performs real-time computing through Spark. The method includes: Acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems, and the business data includes order data and billing data; Cleaning, converting and normalizing the order data and billing data; Automatically identify anomalies in the processed order and billing data based on preset rules and a difference recognition algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies. The anomalies include one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status; Generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly reports.

2. The method according to claim 1, characterized in that The method further comprises: The order data and billing data that cannot be reconciled temporarily due to time delays or other unsatisfied reconciliation conditions are processed through the delay center to ensure that they can be rescheduled and processed when the reconciliation conditions are ripe.

3. The method according to claim 1, characterized in that The cleaning, conversion and normalization of the order data and billing data includes: The order data and bill data are cleaned by a data cleaning algorithm to remove outliers and noise data; Converting the order data and billing data in different formats into a unified format using a data conversion tool; Normalize the order data and billing data to ensure consistency in naming, units, and formats of data fields; The processed order data and billing data are stored in a database accessible to the reconciliation engine.

4. The method according to claim 1, wherein The preset rules adopt the Drools 7.0 rule template, specifically including amount tolerance rules, state machine jump rules and timeliness rules. The automatic identification of anomalies in the processed order data and billing data based on the preset rules and the difference recognition algorithm, the generation of a difference report and the automatic marking of anomalies include: Extract order data and billing data from business data parsed through preset configurations; Matching the order data and billing data according to preset reconciliation rules; Extract key fields from the successfully matched order data; Divide the order data into different batches according to business scenarios or time dimensions; Locate the cause of the discrepancy based on preset rules and discrepancy identification algorithms, generate discrepancy reports, and automatically mark abnormalities; Based on the difference report, the results of the automatic reconciliation are classified, analyzed and stored, and a reconciliation result report is generated.

5. The method according to claim 4, characterized in that The method further comprises: Receive processing instructions and execute processing for special scenarios, including rolling back reconciled data and restoring to the state before reconciliation and / or historical version recovery when a task is canceled.

6. The method according to claim 1, characterized in that After generating and outputting the reconciliation results based on the difference report and the reconciliation result report, the method further includes: Receive modification instructions and / or review instructions, and modify or confirm the difference report and reconciliation result report; and / or Receive query instructions and generate multi-dimensional reports based on summary report fields of preset dimensions and preset calculation rules. The preset dimensions include those based on legal persons, channels and / or product types.

7. The method according to claim 1, characterized in that The method further comprises: Before reconciliation begins, the order data and billing data within the reconciliation period are frozen. The reconciliation period may include a fiscal month, fiscal quarter, semi-annual, fiscal year, or other set period. The freezing method may include locking the data through a database transaction lock or file lock mechanism, generating a data snapshot as a reconciliation benchmark, and recording a freezing log. After the reconciliation is completed, automatically unfreeze the order data and billing data; or / and Automatically generate GAAP-compliant audit trail reports every month, including complete discrepancy handling and blockchain evidence.

8. A reconciliation and fund management device, characterized in that: The device is suitable for a reconciliation and fund management system using a distributed architecture. The system processes data through Kafka message queue sharding and performs real-time computing through Spark. The device includes: A data acquisition module is used to acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems. The business data includes order data and billing data. A data processing module, used to clean, convert and normalize the order data and billing data; A reconciliation engine module, configured to automatically identify anomalies in the processed order and billing data based on preset rules and a difference identification algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies, including one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status; The result output module is used to generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly statements.

9. A reconciliation server comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A reconciliation and fund management system, characterized in that: The system includes: a reconciliation server, a user terminal and a data source system. The user terminal and the data source system are in network communication with the reconciliation server. The system processes data through Kafka message queue sharding and performs real-time calculations through Spark. The reconciliation service end includes: A data acquisition module is used to acquire business data from data source systems, including financial systems, order systems, payment systems, and third-party payment systems. The business data includes order data and billing data. A data processing module, used to clean, convert and normalize the order data and billing data; A reconciliation engine module, configured to automatically identify anomalies in the processed order and billing data based on preset rules and a difference identification algorithm, generate a difference report and a reconciliation result report, and automatically mark anomalies, including one or more combinations of daily cuts, over-accounts, under-accounts, amount discrepancies, and abnormal status; The result output module is used to generate and output the reconciliation results based on the difference report and the reconciliation result report. The reconciliation results include detailed accounts, summary accounts, summary vouchers and monthly statements.

Images