Distributed accounting data consistency self-repairing method for heterogeneous financial system

Abstract

This application relates to the field of financial information technology and discloses a distributed accounting data consistency self-repair method for heterogeneous financial systems. The method includes assigning a globally unique and monotonically increasing logical sequence identifier to each transaction in the heterogeneous financial system according to the transaction processing sequence; before performing consistency verification, obtaining the logical sequence identifiers corresponding to currently completed transactions from each heterogeneous financial system and determining the largest logical sequence identifier in each system; defining the minimum value among the largest logical sequence identifiers as the consistency verification boundary; performing consistency verification on the financial data corresponding to transactions whose logical sequence identifiers are within the consistency verification boundary; and performing a preset self-repair operation on inconsistent accounting data based on the consistency verification results. By introducing a globally unique and monotonically increasing logical sequence identifier and a consistency verification boundary, the accuracy of accounting data consistency verification is effectively improved.

Description

Technical Field

[0001] This application relates to the field of financial information technology, and more specifically, to a distributed accounting data consistency self-repair method for heterogeneous financial systems. Background Technology

[0002] In the financial information system construction of group enterprises, it is common to run multiple financial-related systems simultaneously, such as expense reimbursement systems, cash management systems, general ledger systems, and settlement or clearing systems. These systems are usually developed by different vendors or formed at different stages of construction, resulting in significant differences in field names, primary key rules, status names, posting dates, and summary standards of their accounting data. Despite these heterogeneities, daily operations still require that the accounting data across these systems be consistent and that reconciliation be performed after a certain period of time.

[0003] However, distributed operating environments often encounter issues with concurrent writes and message out-of-order delivery. Taking expense reimbursement as an example, after the reimbursement system approves the payment, it generates a payment instruction. The funds system receives the instruction, executes the payment, and generates a receipt. The general ledger system generates different accounting records based on the instruction and the receipt. Due to network jitter, message middleware retries, system rate limiting, and batch job delays, the write time and order of the same transaction may differ across systems. Common scenarios include: the funds system has already generated a payment receipt and recorded it in the cash flow statement, but the general ledger system's voucher generation operation has not yet been executed; the general ledger system first generates a temporary voucher based on the payment instruction, but the subsequent receipt arrives late, causing a delay in status updates; the reimbursement system writes a reversal record due to user withdrawal or reversal, but the reversal message arrives at the funds system and the general ledger system in different orders. In these situations, the accounting status presented by each system within a short period is not the same.

[0004] When performing cross-system consistency checks between heterogeneous financial systems, the same accounting change may result in different amount fields, status fields, or accounting records in different systems within the same time window due to concurrent writes and out-of-order arrival. Existing processes cannot accurately distinguish whether such differences are temporary inconsistencies caused by delays or long-term differences that will not disappear on their own, based on the alignment view. This can lead to premature repairs resulting in duplicate accounting or reversals, or prolonged waiting without repairs resulting in long-term discrepancies between accounts and actual records. Furthermore, the state after repair and write-back may not meet the criteria for definite convergence, leading to repeated checks and repairs.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides a distributed self-repair method for accounting data consistency in heterogeneous financial systems. This method can accurately distinguish between temporary inconsistencies and long-term differences, avoiding premature triggering of repairs or prolonged waiting without repairs, thereby improving the accuracy and efficiency of accounting data consistency verification and repair.

[0007] Firstly, this application provides a distributed accounting data consistency self-repair method for heterogeneous financial systems, including: Assign a globally unique and monotonically increasing logical sequence identifier to each transaction in the heterogeneous financial system based on the transaction processing time sequence. Before performing consistency verification, obtain the logical sequence identifiers corresponding to the currently completed business processes from each heterogeneous financial system, and determine the largest logical sequence identifier in each heterogeneous financial system. Define the minimum value among the largest logical sequence identifiers as the consistency verification boundary; Perform consistency verification on the financial data corresponding to business transactions whose logical order identifiers are within the consistency verification boundary; Based on the results of consistency verification, a pre-defined self-repair operation is performed on inconsistent accounting data.

[0008] By introducing a globally unique and monotonically increasing logical order identifier and consistency verification boundary, this application can effectively distinguish between temporary inconsistencies and long-term differences, avoiding misjudgments caused by concurrent writes and message out-of-order in traditional methods, thereby improving the accuracy of accounting data consistency verification.

[0009] Furthermore, this application also proposes a step of assigning a globally unique and monotonically increasing logical sequence identifier to each transaction in a heterogeneous financial system according to the transaction processing sequence, including: When processing each transaction, a unique incrementing value is obtained from the preset global sequence center as the global sequence number of each transaction, and the global sequence number is encapsulated in the transaction message as a logical order identifier.

[0010] Through the above scheme, this application assigns a unique global sequence number to each business as a logical sequence identifier through a global sequence center, ensuring the global uniqueness and monotonically increasing nature of the business processing sequence, and providing a reliable foundation for subsequent consistency verification.

[0011] Furthermore, this application proposes that the largest logical sequence identifier includes first logical progress information and second logical progress information, wherein the first logical progress information is the absolute maximum value among the logical sequence identifiers corresponding to the business that has been processed and completed by the corresponding heterogeneous financial system, and the second logical progress information is the maximum value among the logical sequence identifiers corresponding to the business that has been processed and completed continuously without omission by the corresponding heterogeneous financial system from a preset observation starting point.

[0012] By using the above scheme, this application can more accurately reflect the processing progress of heterogeneous financial systems by distinguishing between the first logical progress information and the second logical progress information, thus providing a more accurate basis for determining the consistency verification boundary.

[0013] Furthermore, this application also proposes that the step of defining the minimum value among the largest logical order identifiers as the consistency verification boundary includes: If the first logical progress information corresponding to at least one largest logical sequence identifier is greater than its second logical progress information, then the minimum value among the second logical progress information is defined as the consistency verification boundary; otherwise, the minimum value among the first logical progress information is defined as the consistency verification boundary.

[0014] Through the above scheme, this application dynamically adjusts the determination method of consistency verification boundary based on the comparison result of the first logical progress information and the second logical progress information, making the setting of verification boundary more flexible and accurate, and better able to adapt to the differences in processing progress of different systems.

[0015] Furthermore, this application proposes that the steps for performing consistency verification on the financial data corresponding to transactions whose logical sequence identifiers are within the consistency verification boundary include: Extract the verification dimension information corresponding to the financial data; By comparing the verification dimension information corresponding to the business with the same logical order identifier in each heterogeneous financial system, the financial data is determined to be consistent when the verification dimension information between the heterogeneous financial systems is completely matched, and the financial data is marked as materially different when the verification dimension information between at least two heterogeneous financial systems is mismatched.

[0016] By employing the above approach, this application can quickly and accurately identify substantial discrepancies by extracting and comparing verification dimension information, providing a clear objective for subsequent self-repair operations.

[0017] Furthermore, this application also proposes that, based on the results of consistency verification, the steps for performing a preset self-repair operation on inconsistent accounting data include: Based on the substantial difference data, the corresponding self-healing action is matched from the preset repair strategy library; Perform self-repair actions to supplement, reverse, or align data for substantial discrepancies until consistency verification is passed.

[0018] Through the above scheme, this application can achieve automated repair of inconsistent accounting data by matching the self-repair actions in the repair strategy library, reducing manual intervention and improving repair efficiency and accuracy.

[0019] Furthermore, this application also proposes that, after performing the conformity verification step, the following should be included: Real-time monitoring of the displacement of the consistency verification boundary between two consecutive consistency verifications; When the consistency verification is completed for a preset number of consecutive times, and the displacement is lower than the preset activity standard, a progress lag signal is issued. In response to the progress lag signal, the second logical progress information of each heterogeneous financial system is compared, and the heterogeneous financial system whose second logical progress information is lower than the average of the second logical progress information of all heterogeneous financial systems is marked as a lagging node; The minimum value in the second logical progress information of the remaining heterogeneous financial systems, excluding the lagging nodes, is defined as the temporary observation boundary; Repair the financial data of lagging nodes based on temporary observation boundaries.

[0020] By employing the above-mentioned approach, this application can promptly detect and address progress lag issues between systems by real-time monitoring of the displacement of the consistency verification boundary and identifying lagging nodes, thus ensuring the continuity of overall data consistency.

[0021] Furthermore, this application proposes steps for repairing financial data in lagging nodes based on temporary observation boundaries, including: Based on the financial data of heterogeneous financial systems that have a pre-defined business flow dependency relationship with the lagging node, the expected accounting data of the lagging node within the temporary observation boundary is deduced. The expected accounting data is pre-compared with the actual accounting data of the other heterogeneous financial systems, excluding the lagging nodes; If the pre-comparison result meets the preset business flow rules, the business corresponding to the expected accounting data will be marked as pre-approved. After the business processing progress of the lagging node is restored, the actual accounting data of the lagging node will be obtained, and the actual accounting data of the lagging node will be verified a second time with the expected accounting data.

[0022] By employing the above-mentioned approach, this application can predict and mark the data of lagging nodes before their recovery by extrapolating and pre-comparing expected accounting data, thereby improving the efficiency and accuracy of the repair process and reducing waiting time.

[0023] Furthermore, this application proposes a step for secondary verification of the actual accounting data and expected accounting data of lagging nodes, including: If the actual accounting data of the lagging node matches the expected accounting data, the actual accounting data of the lagging node will be written to the corresponding data storage log. If the actual accounting data of a lagging node does not match the expected accounting data, the underlying physical submission sequence associated with the actual accounting data of the lagging node is extracted and compared with the underlying physical submission sequence of the preset business verification rules. If the underlying physical submission sequence conforms to the preset business verification rules, the actual accounting data of the lagging node is determined to be logically reasonable, and the preset business flow rules are updated according to the actual accounting data. If the underlying physical submission sequence does not conform to the preset business verification rules, the actual accounting data is determined to be abnormal data, and the expected accounting data is used to perform forced data alignment on the lagging node.

[0024] Through the above scheme, this application can more thoroughly judge the rationality of the real accounting data of the lagging nodes by comparing the secondary verification and the underlying physical submission sequence, and update or force alignment of the data according to the judgment results, thus ensuring the thoroughness and accuracy of data repair.

[0025] Furthermore, this application proposes that the verification dimension information includes account identifier, transaction amount, and business processing status.

[0026] As can be seen from the above, the distributed accounting data consistency self-repair method provided in this application for heterogeneous financial systems assigns a globally unique and monotonically increasing logical sequence identifier to each transaction in the heterogeneous financial system according to the transaction processing sequence. Before performing consistency verification, the logical sequence identifiers corresponding to the currently completed transactions are obtained from each heterogeneous financial system, and the largest logical sequence identifier in each heterogeneous financial system is determined. The minimum value among the largest logical sequence identifiers is defined as the consistency verification boundary. Consistency verification is performed on the financial data corresponding to transactions whose logical sequence identifiers are within the consistency verification boundary. Based on the consistency verification results, a preset self-repair operation is performed on inconsistent accounting data. This method can accurately distinguish between temporary inconsistencies and long-term differences, avoid premature triggering of repair or long waiting without repair, thereby improving the accuracy and efficiency of accounting data consistency verification and repair. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating the distributed accounting data consistency self-repair method for heterogeneous financial systems provided in this application embodiment. Detailed Implementation

[0028] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0029] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] In the operational environment of modern large corporations, financial management typically relies on a complex network of multiple independent pieces of information. For example, a dedicated expense reimbursement department handles employee expense applications and approval processes, a treasury department focuses on executing actual bank payments and receiving receipts, while a core general ledger handles the final accounting and financial statement generation. These systems often originate from different software vendors or are built in batches at different stages of the company's development. This leads to a common problem: for the same transaction, significant differences can exist in data field naming, primary key generation rules, business status definitions, the specific timing of accounting entries, and even the data aggregation methods used across different departments. However, despite these technical inconsistencies, the fundamental requirement of business management is to ensure that this dispersed data is logically consistent, and that, at least after a reasonable period of time, the accounts must be fully reconciled.

[0031] To address this challenge, traditional cross-reconciliation workflows typically require significant manual intervention. Finance or operations personnel first need to define the scope of accounts requiring reconciliation, such as a batch of payment documents or all expense reimbursement records within a specific time period. Then, they need to abstract and map different expressions of the same business fact across different systems; for example, establishing a correspondence between the approval status of an expense reimbursement and the voucher generation status in the general ledger. Based on this, cross-data comparisons are performed to identify discrepancies. Once discrepancies are found, more manpower is needed to analyze the root cause—whether it's duplicate entries, omissions, or a failure to synchronize status updates—and then select an appropriate remediation solution, such as manually adding missing records or generating reversal vouchers. This entire process is not only inefficient but also highly error-prone.

[0032] In a distributed architecture, this problem becomes even more complex. Factors such as network latency, retry mechanisms in message brokers, and the processing capacity limitations of various heterogeneous financial systems can all lead to uncertainty in the write time and order of the same transaction across different systems. For example, funds may have already been paid and recorded, but the batch task for generating vouchers in the general ledger has not yet been executed; or, the order in which an expense reversal instruction arrives at the funds and general ledger may be reversed. These situations make it highly likely that data inconsistencies will be found when observing the status at any point in time.

[0033] Some of these inconsistencies are temporary and will disappear automatically as delayed tasks are completed or lagging messages arrive. Others, however, can be permanent, such as a critical message being discarded due to a processing error, or a database write failing due to a concurrency conflict and failing to retry successfully. These two types of differences appear very similar, making it difficult for traditional reconciliation methods to accurately distinguish them. Misjudging a temporary delay as a permanent error and triggering premature corrective actions can lead to double-entry bookkeeping or erroneous write-offs, causing more serious financial problems. Conversely, treating a permanent error as a temporary delay and continuing to wait will result in long-term discrepancies between the books and the actual situation, impacting the company's financial decisions.

[0034] To address the difficulty in accurately distinguishing between temporary inconsistencies caused by delays and long-term differences requiring repair when performing cross-consistency checks between heterogeneous financial systems, thereby avoiding issues such as duplicate entries or long-term discrepancies between accounts and actual data due to misjudgments, this application provides a distributed accounting data consistency self-repair method for heterogeneous financial systems.

[0035] This application no longer relies on physical time as the basis for reconciliation, but instead introduces a unified logical timeline to coordinate all heterogeneous financial systems, including: S1. Assign a globally unique and monotonically increasing logical sequence identifier to each transaction in the heterogeneous financial system according to the transaction processing time sequence. S2. Before performing consistency verification, obtain the logical sequence identifiers corresponding to the currently completed business processes from each heterogeneous financial system, and determine the largest logical sequence identifier in each heterogeneous financial system. S3. Define the minimum value among the largest logical sequence identifiers as the consistency verification boundary; S4. Perform consistency verification on the financial data corresponding to the business whose logical sequence identifier is within the consistency verification boundary; S5. Based on the results of consistency verification, perform preset self-repair operations on inconsistent accounting data.

[0036] This application assigns a globally unique and monotonically increasing logical sequence identifier to each transaction, reflecting the logical order in which transactions occur. This ensures that regardless of how data for a reimbursement transaction flows between expense reimbursement, funds, and the general ledger, it can be accurately tracked and associated using this unique logical sequence identifier. Before consistency verification, a query is simultaneously sent to all relevant heterogeneous financial systems to inquire about the largest logical sequence identifier among all successfully processed and persistently stored transactions. The purpose of this query is to ascertain the latest status of logical processing progress for each heterogeneous financial system. After obtaining the largest logical sequence identifier across all heterogeneous financial systems, the crucial step of defining the verification scope begins. The verification program compares the identifier values ​​returned by all heterogeneous financial systems and selects the minimum value, defining this minimum value as the boundary of the consistency verification. This consistency verification boundary represents a definite processing progress that all heterogeneous financial systems have reached. In other words, for all transactions with logical sequence identifiers less than or equal to the consistency verification boundary, it can be ensured that each relevant heterogeneous financial system has completed processing these transactions.

[0037] In some implementations, suppose that at the start of a verification process, the maximum logical order identifier for processed expense reimbursement reports is 1050, for funds reports it is 1040, while the general ledger, due to its batch processing mechanism, is slower, with a maximum logical order identifier of 1030. In this case, 1030 is used as the consistency verification boundary for this operation. Once the consistency verification boundary is determined, only all business data within the logical order identifier range from the starting point to 1030 will be compared for consistency. For business data with logical order identifiers greater than 1030, such as those already existing in expense reimbursement with sequence numbers 1031 to 1050, the verification process will temporarily ignore these differences even if no corresponding records are found in the general ledger. These differences are considered temporary inconsistencies due to different processing speeds, which are normal phenomena and not errors requiring correction. The verification process will wait until subsequent verification cycles, when the general ledger's processing progress catches up and the consistency verification boundary naturally increases, before including these business data in the comparison scope.

[0038] Within the secure area of ​​the consistency verification boundary, a detailed comparison of the financial data for each transaction is performed. If any inconsistencies are found, such as incorrect amounts, mismatched statuses, or missing records, these differences are deemed genuine and require correction because these transactions have been confirmed to have been processed by all heterogeneous financial systems. Once a difference is identified, a pre-defined self-correcting operation is automatically triggered. Depending on the specific type of difference, corresponding corrective actions are performed, such as adding data to missing records or reversing erroneous records.

[0039] By employing this mechanism based on logical sequence identification and dynamic boundary verification, this application cleverly filters out temporary discrepancies caused by processing delays and message out-of-order delivery in distributed systems, focusing only on long-term errors that truly require intervention. This significantly reduces the likelihood of serious financial risks such as double-counting due to premature repairs, ensuring the accuracy and security of automated repairs, thereby achieving efficient and reliable accounting data consistency in complex heterogeneous environments.

[0040] Specifically, the steps of assigning a globally unique and monotonically increasing logical sequence identifier to each transaction in a heterogeneous financial system according to the transaction processing sequence include: When processing each transaction, a unique incrementing value is obtained from the preset global sequence center as the global sequence number of each transaction, and the global sequence number is encapsulated in the transaction message as a logical order identifier.

[0041] To ensure the global uniqueness and monotonically increasing nature of this logical sequence identifier, a separate, centralized global sequence center is typically established. Its sole responsibility is to provide continuously increasing sequence numbers. When any heterogeneous financial system needs to process a new transaction, such as when an expense reimbursement system receives a new expense report, it first sends a request to this global sequence center. Upon receiving the request, the global sequence center returns a currently unique, incrementing value, such as 1051. This value becomes the global sequence number for this expense reimbursement transaction. Subsequently, the expense reimbursement system encapsulates this global sequence number 1051 as a key data field within the transaction message, along with the reimbursement amount, reason for payment, applicant, and other business information. As the data for this transaction flows to the treasury for payment and then to the general ledger for accounting, this global sequence number 1051 always follows the transaction data, ensuring that this transaction has a unified logical identity across all heterogeneous financial systems.

[0042] The global sequence center refers to a centralized service used to generate unique, monotonically increasing numbers over time. In a specific distributed deployment environment, this can be implemented based on an auto-incrementing primary key in a database, or by utilizing the sequential node functionality of a distributed coordination service such as Zookeeper, or by caching the generated numbers in memory using pre-allocated number ranges. The generated numbers serve as the initial logical scale for each business transaction entering the financial process.

[0043] In some implementations, to improve performance and availability, the global sequence center can also adopt a distributed design, such as utilizing a database sequence that supports sequential generation, or based on a distributed coordination service like Zookeeper. The key is to ensure that the sequence number generated at any given time is unique and strictly incremental across all heterogeneous financial systems throughout the entire group.

[0044] Building upon the aforementioned solution, it's important to consider that in a distributed execution environment, individual internal business processes may not be completed strictly in logical order. For instance, when the general ledger is writing a large number of vouchers, due to row-level locking contention in the database or a momentary failure of a specific server node, transactions with sequence numbers 1001 and 1003 might have been successfully written to the database, while transaction number 1002 might still be waiting in the background queue due to a retry mechanism. If the general ledger only reports the highest absolute sequence number it has processed, 1003, the verification program might mistakenly assume that transaction number 1002 has also been completed. This would lead to the discovery of a missing voucher (1002) during comparison, incorrectly triggering a voucher replacement action and ultimately resulting in duplicate entries.

[0045] Furthermore, the largest logical sequence identifier includes first logical progress information and second logical progress information. The first logical progress information is the absolute maximum value among the logical sequence identifiers corresponding to the business that has been processed and completed by the corresponding heterogeneous financial system, and the second logical progress information is the maximum value among the logical sequence identifiers corresponding to the business that has been processed and completed continuously without omission by the corresponding heterogeneous financial system from the preset observation starting point.

[0046] In other words, when responding to a progress query in the verification process, each heterogeneous financial system no longer returns only a single maximum value, but rather two values. The first logical progress information, i.e., the absolute maximum value, reflects the highest point of completed business sequence numbers, but there may be unfinished gaps before this point. In the example above, the first logical progress information for the general ledger is 1003. The second logical progress information, i.e., the maximum value of continuous processing without omissions, provides proof of processing integrity. It indicates that from a certain starting point to this sequence number, no business sequence number has been omitted. In the example above, since business number 1002 has not yet been completed, the second logical progress information for the general ledger is 1001.

[0047] Furthermore, the step of defining the minimum value among the largest logical order identifiers as the consistency verification boundary includes: If the first logical progress information corresponding to at least one largest logical sequence identifier is greater than its second logical progress information, then the minimum value among the second logical progress information is defined as the consistency verification boundary; otherwise, the minimum value among the first logical progress information is defined as the consistency verification boundary.

[0048] When determining the final consistency verification boundary, the first and second logical progress information returned by each heterogeneous financial system are examined. If the first logical progress information of any heterogeneous financial system is found to be greater than its second logical progress information, it means that there is a processing gap within that system. In this case, to ensure accurate verification, a more conservative strategy is adopted: only the second logical progress information reported by all heterogeneous financial systems is considered, and the minimum value is selected as the final consistency verification boundary. This ensures that all business transactions within the verification scope are completed continuously and without omission across all heterogeneous financial systems, thereby completely avoiding misjudgments caused by internal processing gaps.

[0049] Conversely, if the first logical progress information in all heterogeneous financial systems is equal to their second logical progress information, this indicates that the processing progress in all heterogeneous financial systems is continuous and there are no gaps. In this case, the first logical progress information (i.e., the absolute maximum value) of each heterogeneous financial system can be safely used to determine the minimum value as the consistency verification boundary, thereby maximizing the verification scope and improving verification efficiency. This boundary correction mechanism based on proof of processing continuity prevents the false elevation of the consistency verification boundary caused by internal out-of-order completion, fundamentally eliminating the risk of repeated repairs caused by such problems.

[0050] As a specific implementation method, in a heterogeneous financial system architecture deployed across multiple regions, data consistency processing faces the challenge of longer network link fluctuations. Taking the financial settlement of multinational branches as an example, the reimbursement modules in different locations are distributed across different edge cloud nodes. The operation of assigning logical sequence identifiers to each transaction is completed in a globally centralized identifier generator. Before performing verification, the maximum logical identifiers reported from servers in Asia, Europe, and North America are collected. Due to the latency of cross-sea fiber optic cables, at a certain point in time, the reimbursement records in Asia may have reached 1000, while the incoming records in the general ledger center may only have reached 900. At this point, the consistency verification boundary is anchored at 900. The verification process only compares financial data with logical sequence numbers within 900. This operation ensures that even if there are delays of seconds or even minutes in cross-regional message transmission, the automated verification program will not trigger erroneous reconciliation actions due to the lack of synchronization of cross-regional data. Through this dynamically adjusted consistency verification boundary, the differences in data performance caused by physical spatial distance are masked, and difference analysis is performed only on the already determined steady-state interval. This approach enables financial components distributed around the world to reach a logical consensus, avoiding invalid verifications caused by inconsistent observation points.

[0051] Furthermore, the steps for performing consistency verification on the financial data corresponding to business transactions whose logical order identifiers are within the consistency verification boundary include: Extract the verification dimension information corresponding to the financial data; By comparing the verification dimension information corresponding to the business with the same logical order identifier in each heterogeneous financial system, the financial data is determined to be consistent when the verification dimension information between the heterogeneous financial systems is completely matched, and the financial data is marked as materially different when the verification dimension information between at least two heterogeneous financial systems is mismatched.

[0052] Specifically, for each transaction within the consistency verification boundary, predefined key data fields are extracted from various related heterogeneous financial systems. These fields are called verification dimension information. This verification dimension information typically includes account identifier, transaction amount, and transaction processing status. The account identifier is used to confirm whether the entity transferring funds is correct, the transaction amount is the core of the financial data, and the transaction processing status reflects the synchronization of the business process across different systems, such as whether they are all in the approved, paid, or recorded state.

[0053] Verification dimension information refers to the set of core business fields that must be matched during cross-reconciliation. Besides account identifier, transaction amount, and business processing status, it also includes currency information, lending / borrowing direction, cost center code, and transaction date. These fields together form a multi-dimensional coordinate system. Financial data is considered consistent only when all projections of records with the same logical sequence identifier in different heterogeneous financial systems completely overlap in this coordinate system. Using the logical sequence identifier as a guide, the verification dimension information of the same transaction is compared one by one across different systems. For example, for a transaction with a logical sequence identifier of 950, the reimbursement amount in expense reimbursement, the payment amount in funds, and the voucher amount in the general ledger are checked to ensure they are completely equal. If all verification dimension information matches perfectly across all heterogeneous financial systems, the transaction is considered data consistent. However, if any verification dimension information does not match, such as a discrepancy between the accounting entries in the general ledger and expectations, the transaction is marked as materially inconsistent data, awaiting subsequent correction.

[0054] Furthermore, after identifying materially different data, based on the results of the consistency verification, the steps for performing pre-defined self-correction operations on inconsistent accounting data include: Based on the substantial difference data, the corresponding self-repair action is matched from the preset repair strategy library; the self-repair action is executed to supplement, reverse or align the substantial difference data until the consistency verification is passed.

[0055] The repair strategy library stores standardized repair solutions for different types of discrepancies. For example, one strategy might be defined as follows: if the discrepancy type is a missing general ledger voucher, the corresponding self-repair action is to retrieve business data from expense reimbursement and automatically generate a correction voucher by calling the general ledger interface. Another strategy might be defined as follows: if the discrepancy type is a duplicate payment transaction, the self-repair action is to generate a red-ink reversal transaction to offset the duplicate record.

[0056] Once a transaction is flagged as having a substantial discrepancy, its specific characteristics are analyzed, and the most suitable self-repair action is matched against the remediation strategy library. If a match is found, the action is executed automatically. After the remediation action is completed, the transaction is not immediately considered remediated; instead, it is re-included in the consistency verification during the next verification cycle. Only when the data for this transaction has passed consistency verification across all heterogeneous financial systems is the entire remediation process truly closed-loop, ensuring the final effectiveness of the remediation.

[0057] As a specific implementation method, the verification dimension information can be dynamically expanded for different types of business scenarios. When processing cross-border remittance transactions, in addition to account identifiers, transaction amounts, and transaction processing status, the message identifiers of intermediary banks and the exchange rate are also extracted as verification dimensions. When a transaction within the consistency verification boundary is found to have been paid in the reimbursement form, but the amount shown in the general ledger has a percentile error due to exchange rate differences, this mismatch is marked as a material difference. Subsequently, the repair program retrieves the exchange rate difference handling rules from the repair strategy library and automatically generates an adjustment entry for exchange gains and losses, instead of mechanically rolling back the entire transaction. This fine-grained dimension extraction and strategy matching ensures that while maintaining accounting consistency, it can accurately repair specific financial account characteristics. After the repair action is executed, the convergence of the difference data is tracked in real time to ensure that every corrective entry triggered by self-repair can be verified in subsequent verification cycles, forming a complete financial compliance closed loop.

[0058] However, in complex business environments, a finance department's processing progress may stall for an extended period due to underlying database maintenance, hardware failures, or extreme computational pressure. Since the consistency verification boundary is the minimum of all progresses, if even one process falls behind, the entire group's accounting consistency verification progress will be stalled, resulting in a large backlog of unprocessed data.

[0059] To address this situation, after performing the consistency verification step, the following is also included: Real-time monitoring of the displacement of the consistency verification boundary between two consecutive consistency verifications; When the consistency verification is completed for a preset number of consecutive times, and the displacement is lower than the preset activity standard, a progress lag signal is issued. In response to the progress lag signal, the second logical progress information of each heterogeneous financial system is compared, and the heterogeneous financial system whose second logical progress information is lower than the average of the second logical progress information of all heterogeneous financial systems is marked as a lagging node; The minimum value in the second logical progress information of the remaining heterogeneous financial systems, excluding the lagging nodes, is defined as the temporary observation boundary. Finally, the financial data in the lagging nodes is repaired based on the temporary observation boundary.

[0060] By continuously monitoring the progress of the consistency verification boundary, if the boundary shows almost no change over multiple consecutive periods and falls below a preset activity standard, a potential processing bottleneck is identified, and a progress lag signal is issued. Once triggered, the second logical progress information (continuous processing progress) reported by various heterogeneous financial systems is compared to identify the node whose progress value is significantly lower than the average level and marked as a lagging node. To prevent this lagging node from slowing down the overall progress, it is temporarily removed from the current real-time verification chain. Then, using the minimum progress value of the remaining normally operating systems, a higher-level temporary observation boundary is calculated. In this way, most of the verification work can bypass this local failure point and continue moving forward.

[0061] For the missing data of the lagging node within that higher-level provisional observation boundary, the steps to repair the financial data in the lagging node based on the provisional observation boundary include: Based on the financial data of heterogeneous financial systems that have a pre-defined business flow dependency relationship with the lagging node, the expected accounting data of the lagging node within the temporary observation boundary is deduced. The expected accounting data is pre-compared with the actual accounting data of the other heterogeneous financial systems, excluding the lagging nodes; If the pre-comparison result meets the preset business flow rules, the business corresponding to the expected accounting data will be marked as pre-approved. After the business processing progress of the lagging node is restored, the actual accounting data of the lagging node will be obtained, and the actual accounting data of the lagging node will be verified a second time with the expected accounting data.

[0062] Specifically, a business mirroring module with built-in business flow rules will be activated. This module will simulate and deduce the expected accounting data that a lagging general ledger should generate under normal circumstances, based on existing data from upstream sources such as expense reimbursements and funds. For example, based on a paid transaction, it will deduce the corresponding general ledger voucher's account, amount, and summary.

[0063] The projected data is not written directly to the database. Instead, it is first compared with real data from other normally functioning systems in an asynchronous pre-approval space. If the pre-approval results are logically identical—for example, if the projected voucher amount matches the transaction amount—then this part of the business is marked as pre-approved. This is equivalent to confirming the consistency of most of the data before the lagging node recovers.

[0064] As a specific implementation method, when the displacement of the consistency verification boundary is almost zero for three consecutive verification cycles, it indicates a processing bottleneck. At this point, comparison reveals that the continuous processing progress of the general ledger module is far below the average level of the expense and funds modules, marking the general ledger module as a lagging node. Without interrupting the verification process, the smaller progress value in the expense and funds modules is set as a temporary observation boundary. Using a pre-defined financial transfer logic model, the corresponding accounting voucher structure is derived in a temporary memory image based on existing expense application forms and bank payment records. This derived virtual voucher is then logically pre-matched with the actual fund flow. If the matching result conforms to the business flow rules, it is marked as pre-approved. Once the general ledger module replenishes the actual voucher data when the pressure decreases in the early morning, the actual database transaction commit log is retrieved. The actual voucher entries are then compared a second time with the previously derived mirror data. This method allows the financial reconciliation process to complete most of the logical verification through virtual deduction even when facing partial component failures or overload, greatly alleviating the queuing pressure during financial settlement.

[0065] Once the lagging node has finally recovered and the previously backlogged business data has been replenished, the steps for a second verification of the actual accounting data of the lagging node against the expected accounting data include: If the actual accounting data of the lagging node matches the expected accounting data, the actual accounting data of the lagging node will be written to the corresponding data storage log. If the actual accounting data of a lagging node does not match the expected accounting data, the underlying physical submission sequence associated with the actual accounting data of the lagging node is extracted and compared with the underlying physical submission sequence of the preset business verification rules. If the underlying physical submission sequence conforms to the preset business verification rules, the actual accounting data of the lagging node is determined to be logically reasonable, and the preset business flow rules are updated according to the actual accounting data. If the underlying physical submission sequence does not conform to the preset business verification rules, the actual accounting data is determined to be abnormal data, and the expected accounting data is used to perform forced data alignment on the lagging node.

[0066] This secondary verification process is a rapid alignment check. If the newly generated real data from the lagging node is completely consistent with the previously projected expected data, then the data is directly confirmed as correct and written to the log. If a mismatch occurs, the real data is not hastily judged as incorrect. Instead, further in-depth analysis is conducted to extract the underlying physical commit sequence associated with this real accounting data. This can be understood as the most primitive operation record at the database level. This physical commit sequence is then compared with the preset business verification rules.

[0067] The underlying physical commit sequence refers to the original log identifiers that record the order in which transactions are executed at the database level, such as the database transaction identifier or the offset address of the write-ahead log. This sequence reflects the actual physical time order in which data is stored on the storage medium. When the logical business order deviates from the physical commit order, analyzing the physical commit sequence can determine whether there are concurrent conflicts or improper retry operations, thus providing the lowest-level chain of evidence for data repair.

[0068] If the comparison results show that the generation process of this real data, although different from the expectation, is consistent with business logic and rules—for example, because business rules have changed while the inference model has not yet been updated—then the real data will be deemed logically reasonable, accepted, and this new case will be used to update its own business flow rules, achieving adaptive learning.

[0069] However, if the comparison results of the physical submission sequence show that it does not comply with the business verification rules, then it can be determined that this real data is abnormal data. At this time, a forced alignment measure will be taken, using the previously deduced and pre-audited expected accounting data to cover this abnormal data in the lagging node, thereby ensuring the final accounting consistency.

[0070] Through this flexible mechanism of isolating lagging nodes, virtual state deduction, and adaptive secondary verification, this method effectively breaks the "weakest link" effect in distributed reconciliation and greatly improves the overall processing capability and response speed of self-repair of accounts in complex heterogeneous environments.

[0071] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A distributed accounting data consistency self-repair method for heterogeneous financial systems, characterized in that: include: Assign a globally unique and monotonically increasing logical sequence identifier to each transaction in the heterogeneous financial system based on the transaction processing time sequence. Before performing consistency verification, obtain the logical sequence identifier corresponding to the currently completed business from each of the heterogeneous financial systems, and determine the largest logical sequence identifier in each of the heterogeneous financial systems. The minimum value among the largest logical sequence identifiers is defined as the consistency verification boundary; Perform the consistency verification on the financial data corresponding to the business whose logical sequence identifier is within the consistency verification boundary; Based on the results of the consistency verification, a preset self-repair operation is performed on inconsistent accounting data.

2. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 1, characterized in that, The step of assigning a globally unique and monotonically increasing logical sequence identifier to each transaction in the heterogeneous financial system according to the business processing time sequence includes: When processing each of the above services, a unique incrementing value is obtained from a preset global sequence center as the global sequence number of each service, and the global sequence number is encapsulated in the service message as the logical order identifier.

3. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 1, characterized in that, The maximum logical sequence identifier includes first logical progress information and second logical progress information, wherein the first logical progress information is the absolute maximum value among the logical sequence identifiers corresponding to the business that has been processed and completed by the heterogeneous financial system, and the second logical progress information is the maximum value among the logical sequence identifiers corresponding to the business that has been processed and completed by the heterogeneous financial system from a preset observation starting point without omission.

4. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 3, characterized in that, The step of defining the minimum value among the largest logical order identifiers as the consistency verification boundary includes: If the first logical progress information corresponding to at least one of the largest logical sequence identifiers is greater than its second logical progress information, then the minimum value among the second logical progress information is defined as the consistency verification boundary; otherwise, the minimum value among the first logical progress information is defined as the consistency verification boundary.

5. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 1, characterized in that, The step of performing consistency verification on the financial data corresponding to the business whose logical sequence identifier is within the consistency verification boundary includes: Extract the verification dimension information corresponding to the financial data; By comparing the verification dimension information corresponding to the business with the same logical order identifier in each of the heterogeneous financial systems, if the verification dimension information between each heterogeneous financial system is completely matched, the financial data is determined to be consistent; if the verification dimension information between at least two heterogeneous financial systems is not matched, the financial data is marked as materially different data.

6. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 5, characterized in that, The step of performing a preset self-repair operation on inconsistent accounting data based on the consistency verification result includes: Based on the substantial difference data, a corresponding self-repair action is matched from a preset repair strategy library; The self-repair action is performed to supplement, reverse, or align the substantial difference data until the consistency verification is passed.

7. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 3, characterized in that, Following the step of performing the consistency verification is: Real-time monitoring of the displacement of the consistency verification boundary between two consecutive completions of the consistency verification; When the consistency verification is completed for a preset number of consecutive times, and the displacement is lower than the preset activity standard, a progress lag signal is issued. In response to the progress lag signal, the second logical progress information of each heterogeneous financial system is compared, and the heterogeneous financial system whose second logical progress information is lower than the average of the second logical progress information of all heterogeneous financial systems is marked as a lagging node. The minimum value in the second logical progress information of the remaining heterogeneous financial systems, excluding the lagging node, is defined as the temporary observation boundary; The financial data in the lagging nodes is repaired based on the temporary observation boundary.

8. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 7, characterized in that, The step of repairing the financial data in the lagging node based on the temporary observation boundary includes: Based on the financial data of the heterogeneous financial system that has a preset business flow dependency relationship with the lagging node, the expected accounting data corresponding to the lagging node within the temporary observation boundary is deduced. The expected accounting data is pre-compared with the actual accounting data of the other heterogeneous financial systems, excluding the lagging node; If the pre-comparison result conforms to the preset business flow rules, the business corresponding to the expected accounting data is marked as pre-approved. After the lagging node resumes business processing progress, the actual accounting data of the lagging node is obtained, and the actual accounting data of the lagging node is verified a second time with the expected accounting data.

9. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 8, characterized in that, The step of performing a second verification between the actual accounting data of the lagging node and the expected accounting data includes: If the actual accounting data of the lagging node matches the expected accounting data, the actual accounting data of the lagging node is written into the corresponding data storage log. If the actual accounting data of the lagging node does not match the expected accounting data, the underlying physical submission sequence associated with the actual accounting data of the lagging node is extracted and compared with the underlying physical submission sequence of the preset business verification rule. If the underlying physical submission sequence conforms to the preset business verification rule, the actual accounting data of the lagging node is determined to be logically reasonable, and the preset business flow rule is updated according to the actual accounting data. If the underlying physical submission sequence does not conform to the preset business verification rule, the actual accounting data is determined to be abnormal data, and the expected accounting data is used to perform data forced alignment on the lagging node.

10. The distributed accounting data consistency self-repair method for heterogeneous financial systems according to claim 5, characterized in that, The verification dimensions include account identifier, transaction amount, and business processing status.

Images