Multi-channel payment account exception positioning method, system and electronic device

Abstract

The application provides a multi-channel payment reconciliation exception positioning method and system and electronic equipment, relates to the information processing technical field of reconciliation systems, and the method first acquires flow data of a multi-channel payment platform and maps the flow data into a target transaction model, and simultaneously constructs an internal business document chain based on a payment instruction, an accounting voucher and a document state; then, a matching operation is performed, and target transaction pairs that fail to match or have inconsistent amounts are screened out; for each target transaction pair, the processing state of the transaction in different systems is extracted from multiple heterogeneous information systems, and a multi-source state combination is generated; finally, exception positioning is performed according to a predefined state combination logic table, and specific links in which exceptions occur are accurately output. The application significantly improves the exception positioning accuracy and interpretability, greatly reduces the manual troubleshooting cost, and realizes a substantial breakthrough from amount inconsistency to link mismatch.

Description

Technical Field

[0001] This application relates to the field of information processing technology for reconciliation systems, and in particular to a method, system, and electronic device for locating reconciliation anomalies in multi-channel payments. Background Technology

[0002] In enterprise multi-channel fund receipt and payment scenarios, financial reconciliation faces three main problems: First, the sources of billing data are heterogeneous. Transaction vouchers provided by different payment channels differ in message structure, field definitions, time precision, and semantic expression, making it difficult to represent them uniformly. Second, there is a lack of correlation between business documents. Data between internal ERP, expense control, and fund systems is isolated from each other, and key documents such as payment instructions, accounting vouchers, and business contracts lack cross-system traceable indexes. Third, anomalies are only reflected as final amount deviations, failing to reflect the consistency of status in the fund flow process, such as instruction issuance, bank acceptance, settlement completion, and accounting entries. This results in the need to manually connect multiple source logs and rely on experience to troubleshoot the root causes of discrepancies. Summary of the Invention

[0003] The purpose of this application is to provide a method, system, and electronic device for locating reconciliation anomalies in multi-channel payments, so as to alleviate the aforementioned technical problems existing in the prior art.

[0004] In a first aspect, the present invention provides a method for locating reconciliation anomalies in multi-channel payments, comprising: Acquire payment transaction data from multiple payment platforms and map the preprocessed payment transaction data to the target transaction model; Obtain payment instructions, accounting vouchers, and document circulation status, and construct an internal business document chain based on the payment instructions, accounting vouchers, and document circulation status; The target transaction model is matched with the internal business document chain to obtain target transaction pairs that fail to match or have inconsistent amounts. For each target transaction pair, system state information representing the progress of the transaction within the system is extracted from multiple heterogeneous information systems participating in payment processing. The extracted system state information is then combined to generate a multi-source state combination. Based on the predefined state combination logic table, the reconciliation anomaly is located for the multi-source state combination, and the specific link in which the reconciliation anomaly occurred is obtained.

[0005] In an optional implementation, payment transaction data from a multi-channel payment platform is acquired, and the preprocessed payment transaction data is mapped to a target transaction model, including: It connects to the bank's front-end system, third-party payment system, and virtual card system, and collects raw payment transaction data with structured field definitions from each system. The original payment transaction data is cleaned by removing duplicate records, filling in missing timestamps, and standardizing the amount value format and currency identification. The scattered transaction elements in the cleaned payment transaction data from various channels are mapped to a set of standard fields, including unique transaction number, payer name, payee name, transaction amount, transaction time, transaction summary, and channel type, to generate the target transaction model.

[0006] In an optional implementation, payment instructions, accounting vouchers, and document circulation status are obtained, and an internal business document chain is constructed based on the payment instructions, accounting vouchers, and document circulation status, including: Extract payment instruction records from the enterprise resource planning system. The payment instruction records include the instruction initiation time, expected payment date, payee account information, and associated business document number. Extract accounting voucher records corresponding to payment instructions from the financial accounting system. The accounting voucher records include the posting time, debit and credit accounts, amount, and voucher status. Establish an index relationship between payment instructions and accounting vouchers based on the business document number, and trace back along the index relationship to the purchase order or expense application form, and forward to the fund accounting details to obtain an internal business document chain with a hierarchical structure.

[0007] In an optional implementation, a matching operation is performed based on the target transaction model and the internal business document chain to obtain target transaction pairs that fail to match or have inconsistent amounts, including: The end-to-end unique identifier generated in the payment instruction is used as the matching identifier. The corresponding transaction record is searched in the target transaction model based on the matching identifier. When the identifiers match and the amount difference is within the allowable tolerance range, direct write-off is performed. When no matching identifier is found, within a preset time window, perform a combination summation match between multiple payment transactions in the target transaction model and multiple payment instructions in the internal business document chain to determine whether there is a total amount of several payment instructions that is equal to the total amount of several payment transactions. If the combination summation match still fails, a comprehensive score is generated based on the similarity of the payer's name, the proximity of the transaction time, and the difference in the amount. When the score exceeds the set threshold, it is confirmed as a fuzzy match. Trading pairs that do not meet any of the above matching conditions will be identified as target trading pairs.

[0008] In an optional implementation, for each target transaction pair, system state information representing the progress of the transaction within its own system is extracted from multiple heterogeneous information systems participating in payment processing. The extracted system state information is then combined to generate a multi-source state combination, including: Extract the current processing status of the payment instructions associated with the target transaction pair from the enterprise resource planning system. The processing status includes approved, sent, posted, or reversed. Extract the transmission status of the payment message corresponding to the target transaction pair from the payment gateway system. The transmission status includes whether the message has been sent, received, rejected, or timed out without response. Extract the actual settlement status of the target transaction pair from bank receipts or data from third-party payment platforms. The actual settlement status includes accepted, settled, refunded, or being processed. Arrange the above three types of states in a fixed order to generate a multi-source state combination consisting of three state fields.

[0009] In an optional implementation, the above three types of states are arranged in a fixed order to generate a multi-source state combination consisting of three state fields, including: The payment instruction processing status extracted from the enterprise resource planning system, the payment message transmission status extracted from the payment gateway system, and the actual settlement status extracted from the feedback data from banks or third-party payment platforms are structured and organized according to the preset system hierarchy. The structured organization is based on the logical sequence of each state in the entire life cycle of payment business, so that the first state reflects the internal decision-making and accounting behavior of the enterprise, the second state reflects the cross-system transmission process of instructions, and the third state reflects the actual settlement result of external funds. Based on this structured organization, a multi-source state vector with a unified dimension is generated, where each dimension corresponds to a state value at a system level, and all multi-source state vectors maintain semantic alignment on the same dimension. Using multi-source state vectors as input, a pre-trained state semantic understanding model is driven to identify temporal consistency, causal dependence, and abnormal coupling patterns among states in various dimensions, and output anomaly attribution categories that match the multi-source state vectors.

[0010] In an optional implementation, based on a predefined state combination logic table, the multi-source state combination is used to locate reconciliation anomalies, revealing the specific steps in which the anomalies occurred, including: The generated multi-source state combinations are compared item by item with the predefined state combination logic table; When the status of the Enterprise Resource Planning system is "accounted" in a multi-source status combination, while the status of the payment gateway system is "issued" and the bank settlement status is blank, the anomaly is determined to have occurred in the payment message transmission stage. When the status of the enterprise resource planning system is "accounted" in a multi-source status combination, while the bank settlement status is "refundable" and the payment gateway system status is "rejected", the anomaly is determined to have occurred in the bank's account verification process. When the status of the enterprise resource planning system is blank in a multi-source status combination, while the bank settlement status is settled, the anomaly is determined to have occurred in the enterprise's internal instruction omission process. Output the name of the specific abnormal step corresponding to the judgment result.

[0011] Secondly, the present invention provides a reconciliation anomaly location system for multi-channel payments, and a payment transaction data acquisition and target transaction model mapping module, which is used to acquire payment transaction data from multi-channel payment platforms and map the preprocessed payment transaction data to the target transaction model; The internal business document chain construction module is used to obtain payment instructions, accounting vouchers and document circulation status, and construct an internal business document chain based on the payment instructions, accounting vouchers and document circulation status; The target transaction pair matching module is used to perform matching operations between the target transaction model and the internal business document chain to obtain target transaction pairs that fail to match or have inconsistent amounts. The multi-source system state information extraction and combination module is used to extract the independently generated system state information representing the progress of the transaction within the system from multiple heterogeneous information systems participating in the payment business processing for each target transaction pair, and combine the extracted system state information to generate a multi-source state combination. The reconciliation anomaly location module is used to locate reconciliation anomalies in a multi-source state combination based on a predefined state combination logic table, thereby identifying the specific step in which the reconciliation anomaly occurred.

[0012] Thirdly, the present invention provides an electronic device including a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the multi-channel payment reconciliation anomaly location method of any of the foregoing embodiments.

[0013] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the reconciliation anomaly location method for multi-channel payments according to any of the foregoing embodiments.

[0014] The method, system, and electronic equipment for locating reconciliation anomalies in multi-channel payments provided in this application eliminate structural differences in format, fields, and semantics among different channels by mapping multi-channel payment flows to a target transaction model, thus making heterogeneous data comparable. An internal business document chain is constructed to achieve a structured association between payment instructions, accounting vouchers, and flow status, enabling cross-system, transaction-by-transaction tracing. Matching based on the target transaction model and document chain no longer relies on hard matching of single fields, providing a reliable comparative reference for subsequent anomaly attribution. The processing progress status independently generated by each system is extracted and combined to generate multi-source status combinations, objectively recording the actual execution snapshots of transactions in ERP, payment gateways, banks, and other stages. Specific stages are located based on a predefined status combination logic table, transforming abstract discrepancies into actionable process breakpoints (e.g., instructions have been issued but the bank has not received an acceptance receipt). This significantly improves the accuracy and interpretability of anomaly location, greatly reduces the cost of manual investigation, and achieves a fundamental leap from monetary discrepancies to stage mismatches. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a method for locating reconciliation anomalies in multi-channel payments, provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of the overall architecture of a multi-channel unified reconciliation system. Figure 3 This application provides a multi-level intelligent reconciliation and matching process for embodiments of the invention. Figure 4 This application provides a schematic diagram of an anomaly location logic throughout the payment lifecycle. Figure 5 This application provides a schematic diagram of discrepancy attribution and automatic reconciliation in an embodiment of the present application. Figure 6 A structural diagram of a multi-channel payment reconciliation anomaly location system provided in this application embodiment; Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0018] 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 the 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.

[0019] It should be noted that similar labels 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.

[0020] This application provides a method for locating reconciliation anomalies in multi-channel payments. See [link to relevant documentation]. Figure 1 As shown, the method mainly includes: Step S110: Obtain payment transaction data from multi-channel payment platforms and map the preprocessed payment transaction data to the target transaction model.

[0021] like Figure 2 As shown in the data source layer, enterprise payment channels include direct bank connections, third-party payment platforms, virtual card platforms, and ERP / expense control systems. In this step, the system connects to the bank's front-end system, third-party payment system, and virtual card system, collecting raw payment transaction data with structured field definitions from each system. For smaller banks that do not support direct connections, the system also supports data acquisition via importing Excel files or OCR recognition of PDF electronic receipts.

[0022] These raw data exhibit significant differences in field naming, time format, amount unit, and currency identification. The system performs field cleaning on the raw payment transaction data: removing duplicate records, completing missing timestamps, and standardizing the amount value format and currency identification. Subsequently, the scattered transaction elements in the cleaned payment transaction data from various channels are mapped to a standard set of fields including a unique transaction number, payer name, payee name, transaction amount, transaction time, transaction summary, and channel type, generating the target transaction model. This model is... Figure 2 The Standard Flow Model (STM) shown serves as the unified data foundation for the subsequent reconciliation core engine.

[0023] Step S120: Obtain payment instructions, accounting vouchers and document circulation status, and construct an internal business document chain based on payment instructions, accounting vouchers and document circulation status.

[0024] like Figure 2 As shown in the internal business system section, the system extracts data from enterprise resource planning (ERP) systems (such as SAP and Oracle) and related systems to construct an internal accounting pool. Specifically, the system extracts payment instruction records from the ERP system. These records include the instruction initiation time, expected payment date, payee account information, and associated business document number. Simultaneously, it extracts accounting voucher records corresponding to the payment instructions from the financial accounting system. These records include the posting time, debit / credit accounts, amount, and voucher status. An index relationship is established between the payment instruction and the accounting voucher based on the business document number. The system then traces backward along the index relationship to purchase orders or expense requisitions and forward to the fund posting details, resulting in a hierarchical internal business document chain. This chain, from top to bottom, is: Purchase Order / Expense Requisition → Payment Instruction → Accounting Voucher → Fund Posting Details.

[0025] Step S130: Perform a matching operation between the target transaction model and the internal business document chain to obtain target transaction pairs that fail to match or have inconsistent amounts.

[0026] Reference Figure 3 The multi-level intelligent reconciliation matching process shown employs a three-level matching strategy. The first level is precise matching using unique IDs: the end-to-end unique identifier generated in the payment instruction is used as the matching identifier. Based on this identifier, the corresponding transaction record is searched in the target transaction model. When the identifiers match and the amount difference is within the allowable tolerance range, direct reconciliation is performed. If no matching identifier is found, the second level, N:M combined matching, is initiated: within a preset time window, multiple payment transactions in the target transaction model are combined and summed with multiple payment instructions in the internal business document chain to determine if the sum of several payment instructions equals the sum of several payment transactions. If the combined summation matching still fails, the third level, fuzzy intelligent matching, is initiated: a comprehensive score is constructed based on payer name similarity, transaction time proximity, and amount difference. When the score exceeds a set threshold, it is confirmed as a fuzzy match. Transaction pairs that do not meet any of the above matching conditions are identified as target transaction pairs and enter the anomaly location process.

[0027] Step S140: For each target transaction pair, extract the independently generated system state information representing the progress of the transaction within the system from multiple heterogeneous information systems participating in payment business processing, and combine the extracted system state information to generate a multi-source state combination.

[0028] Reference Figure 4 The payment lifecycle anomaly localization logic shown is a core innovation that distinguishes it from the traditional approach of "only caring about whether the amount is balanced." The system divides the payment process into multiple key nodes and extracts status snapshots from different systems. Specifically, for each target transaction pair, the system extracts the current processing status of the payment instruction associated with the target transaction pair from the Enterprise Resource Planning (ERP) system, including approved, sent, recorded, or reversed; it extracts the transmission status of the corresponding payment message from the payment gateway system, including sent, received, rejected, or timed out; and it extracts the actual settlement status of the target transaction pair from bank receipts or feedback data from third-party payment platforms, including accepted, settled, refunded, or processing. These three types of statuses are arranged in a fixed order to generate a multi-source status combination consisting of three status fields, such as (recorded, sent, settled).

[0029] Step S150: Based on the predefined state combination logic table, locate the reconciliation anomaly of the multi-source state combination to obtain the specific link in which the reconciliation anomaly occurred.

[0030] The system predefines a state combination logic table, mapping each typical multi-source state combination to a specific anomaly stage. For example: when the enterprise resource planning (ERP) system's state is "posted," while the payment gateway system's state is "issued" and the bank settlement state is blank, the anomaly is determined to occur in the payment message transmission stage; when the ERP system's state is "posted," while the bank settlement state is "returned" and the payment gateway system's state is "rejected," the anomaly is determined to occur in the bank's account verification stage; when the ERP system's state is blank and the bank settlement state is "settled," the anomaly is determined to occur in the internal instruction omission stage. The system compares the generated multi-source state combinations with the predefined state combination logic table item by item, outputting the specific anomaly stage name corresponding to the judgment result for targeted handling by finance or technical personnel.

[0031] The following provides further details on the specific implementation methods of each of the above steps.

[0032] Regarding step S110, in practical applications, raw data from different channels often exhibits unstructured or semi-structured characteristics. For example, the "summary" field in bank statements typically mixes various information such as contract number, employee name, and purpose, and different banks have inconsistent filling standards for this field. To address this issue, the system introduces natural language processing technology at the cleaning layer, specifically using regular expressions to extract key information from the summary, such as contract number, employee name, and reimbursement reason, and stores the extraction results as supplementary fields in the standard transaction model. Simultaneously, to address the issue of some channels potentially pushing the same transaction repeatedly, the system generates an MD5 hash fingerprint based on a combination of account number, transaction number, amount, and transaction time, performing deduplication before data entry to prevent duplicate data from contaminating the reconciliation results. Furthermore, for manually imported Excel files or data obtained through OCR recognition of PDF receipts, the system also processes them according to the aforementioned cleaning and mapping rules to ensure that all data entering the reconciliation engine conforms to the specifications of the standard transaction model.

[0033] In another implementation, the target transaction model in step S110 can also be expanded to include a "transaction fingerprint" field. This fingerprint is generated by the system based on key transaction elements (account number, amount, transaction time, counterparty name) according to a predetermined hash algorithm. When subsequent transactions of the same transaction are imported from different channels (for example, a bank provides both transaction records pushed through the bank-enterprise direct connection interface and Excel statements manually imported by financial personnel), the system can automatically identify duplicate records by comparing fingerprints, retaining only one valid record in the reconciliation engine, while marking the other as "duplicate data." This deduplication mechanism effectively avoids duplicate reconciliation or false discrepancies caused by duplicate data sources.

[0034] Regarding step S120, in large enterprise groups, a single payment may involve multiple levels of approval and data flow across multiple systems. For example, when a manufacturing company pays a supplier, the purchasing department first creates a purchase order in the ERP system. After approval, an accounts payable voucher is generated. Then, the finance department initiates a payment instruction in the finance system. The instruction is sent to the bank via a direct bank-enterprise connection. After the bank processes the instruction, the ERP system generates a cash journal based on the bank's receipt. When constructing the internal business document chain, the system of this invention not only establishes the index relationship between the above-mentioned links but also synchronously collects the timestamp and operator information for each link. When subsequent reconciliation reveals anomalies, the system can quickly locate the specific link with missing or abnormal status along the document chain. For example, if a payment instruction has been generated but the corresponding accounting voucher is missing, the system can determine that it is an "ERP accounting omission." This mechanism greatly improves the efficiency of anomaly detection.

[0035] Regarding step S130, in the scenario of batch payroll disbursement, companies typically send a disbursement file containing hundreds or even thousands of details to the bank. After the bank completes the processing, the returned summary receipt often only shows a total amount, without displaying the independent status of each detail. In this case, the traditional "one-to-one" reconciliation model is completely ineffective. The Subset Sum algorithm used in this invention can automatically search for all payment instruction amount combinations in the internal business document chain within a set time window, finding the instruction sets whose sum equals the bank's summary transaction amount. To avoid computational overload, the system first preprocesses the datasets involved in the matching: sorting by amount, removing records that clearly exceed the tolerance range, and setting a reasonable upper limit for the search depth. In actual testing, for payroll disbursement transactions with no more than 2000 details per batch, the algorithm can complete the matching calculation within seconds. For successfully matched combinations, the system automatically establishes a reconciliation relationship between the summary transaction and each detail instruction within the combination, and marks it in the reconciliation results. In addition, the Levenshtein distance algorithm can be used to calculate the name similarity in fuzzy matching. For example, the similarity between "XX Company" and "XX Limited Liability Company" can be compared. The time window can be set to T±1 days. The comprehensive scoring formula can be expressed as the weighted sum of each factor. When the score exceeds the preset threshold (such as 90 points), it is confirmed as a match.

[0036] For step S140, to enhance the intelligence of anomaly attribution, the system further organizes the payment instruction processing status extracted from the enterprise resource planning system, the payment message transmission status extracted from the payment gateway system, and the actual settlement status extracted from the feedback data of banks or third-party payment platforms into a structured organization according to a preset system hierarchy. This structured organization is based on the logical sequence of each status throughout the entire payment business lifecycle, ensuring that the first status reflects internal enterprise decision-making and accounting behavior, the second status reflects the cross-system instruction transmission process, and the third status reflects the actual external fund transfer result. Based on this structured organization, a multi-source state vector with a unified dimension is generated, where each dimension corresponds to a system-level state value, and all multi-source state vectors maintain semantic alignment on the same dimension. Using the multi-source state vector as input, a pre-trained state semantic understanding model is driven to identify temporal consistency, causal dependence, and anomaly coupling patterns among states in each dimension, outputting anomaly attribution categories that match the multi-source state vectors.

[0037] This model is pre-trained based on historical reconciliation data. During training, the system collects a large number of multi-source state vector samples that have been manually verified and labeled with the cause of anomalies. For example, {posted, issued, processing} corresponds to "channel congestion", {posted, rejected, refunded} corresponds to "account error", and {blank, blank, settled} corresponds to "offline online banking operation", etc. By learning the mapping relationship between state combination patterns in these samples and anomaly attributions, the model can provide reasonable attribution inferences for unseen state combinations. As usage time increases, the system can also use manually corrected results as new training samples to continuously optimize the model's accuracy. This mechanism gives the reconciliation anomaly localization capability of this invention self-learning and self-evolving characteristics, enabling it to adapt to the differentiated business rules of different enterprises, banks, and payment channels.

[0038] Regarding step S150, once the system identifies the specific aspect of the anomaly, it doesn't stop at reporting; instead, it triggers corresponding processing actions. (Refer to...) Figure 5 The illustrated discrepancy attribution and automatic reconciliation closed-loop process utilizes a built-in discrepancy classifier that automatically determines the discrepancy type based on anomaly location results. For discrepancies in handling fees, the system automatically generates a suggested accounting entry: "Debit: Financial Expenses - Handling Fees, Credit: Bank Deposit," and pushes this suggestion to the finance staff's workbench. For discrepancies in interest income, it generates "Debit: Bank Deposit, Credit: Financial Expenses - Interest Income." For discrepancies caused by bank check returns, the system automatically generates a red-ink reversal voucher in the ERP system, changing the status of the original payment instruction to "Payment Failure," releasing the occupied budget quota, and simultaneously notifying the initiator via the company's instant messaging tool to modify the receiving account information and resubmit. For discrepancies in exchange gains and losses, the system automatically calculates the profit or loss amount based on the difference between the exchange rate on the transaction date and the accounting exchange rate and generates corresponding vouchers. After the finance staff confirms all automatically generated voucher suggestions with one click, the system completes the voucher posting through the ERP interface, thus achieving a complete closed loop from discrepancy discovery to discrepancy elimination.

[0039] In addition, based on real-time reconciliation results, the system automatically distinguishes four categories of outstanding items: "Bank received but not received by enterprise," "Bank paid but not paid by enterprise," "Enterprise received but not received by bank," and "Enterprise paid but not paid by bank." It also automatically generates a "Bank Reconciliation Statement" that meets audit standards in accordance with the *Accounting Standards for Business Enterprises*. The system performs aging analysis on outstanding items. If an item under "Enterprise paid but not yet paid by bank" remains unresolved for more than 30 days, the system triggers a high-risk warning, indicating potential misappropriation of funds or significant accounting errors. At the end of each month, the system packages and archives the reconciliation results, original transaction records, and discrepancy analysis report as the audit basis for monthly closing.

[0040] The reconciliation anomaly location method provided by this invention can not only automatically identify the matching results of internal and external fund flows, but also accurately trace the source to a specific stage in the entire lifecycle of the payment process when matching fails or amounts are inconsistent. By constructing a cross-system state machine and state combination logic table, the system can clearly determine whether the discrepancy occurred at nodes such as internal accounting, message transmission, bank processing, or refund feedback, thereby transforming ambiguous reconciliation discrepancies into clear stage locations. This solution significantly reduces the cost of manual investigation, enabling financial personnel to directly correct and adjust problematic stages, and significantly improves the transparency of corporate fund management and the timeliness of anomaly response.

[0041] Furthermore, this application also provides a reconciliation anomaly location system for multi-channel payments, see [link to relevant documentation]. Figure 6 As shown, the system includes the following components: The payment transaction data acquisition and target transaction model mapping module 610 is used to acquire payment transaction data from multi-channel payment platforms and map the preprocessed payment transaction data to the target transaction model. The internal business document chain construction module 620 is used to obtain payment instructions, accounting vouchers and document circulation status, and construct an internal business document chain based on the payment instructions, accounting vouchers and document circulation status; The target transaction pair matching module 630 is used to perform matching operations based on the target transaction model and the internal business document chain to obtain target transaction pairs that fail to match or have inconsistent amounts. The multi-source system state information extraction and combination module 640 is used to extract, for each target transaction pair, the independently generated system state information representing the progress of the transaction within the system from multiple heterogeneous information systems participating in the payment business processing, and combine the extracted multiple system state information to generate a multi-source state combination. The reconciliation anomaly location module 650 is used to locate reconciliation anomalies in the multi-source state combination based on a predefined state combination logic table, thereby obtaining the specific step in which the reconciliation anomaly occurred.

[0042] In one feasible implementation, the payment transaction record acquisition and target transaction model mapping module 610 is further used for: It connects to the bank's front-end system, third-party payment system, and virtual card system, and collects raw payment transaction data with structured field definitions from each system. The original payment transaction data is cleaned by removing duplicate records, filling in missing timestamps, and standardizing the amount value format and currency identification. The scattered transaction elements in the cleaned payment transaction data from various channels are mapped to a set of standard fields, including unique transaction number, payer name, payee name, transaction amount, transaction time, transaction summary, and channel type, to generate the target transaction model.

[0043] In one feasible implementation, the aforementioned internal business document chain construction module 620 is further used for: Extract payment instruction records from the enterprise resource planning system. The payment instruction records include the instruction initiation time, expected payment date, payee account information, and associated business document number. Extract accounting voucher records corresponding to payment instructions from the financial accounting system. The accounting voucher records include the posting time, debit and credit accounts, amount, and voucher status. Establish an index relationship between payment instructions and accounting vouchers based on the business document number, and trace back along the index relationship to the purchase order or expense application form, and forward to the fund accounting details to obtain an internal business document chain with a hierarchical structure.

[0044] In one feasible implementation, the target trading pair matching module 630 is further configured to: The end-to-end unique identifier generated in the payment instruction is used as the matching identifier. The corresponding transaction record is searched in the target transaction model based on the matching identifier. When the identifiers match and the amount difference is within the allowable tolerance range, direct write-off is performed. When no matching identifier is found, within a preset time window, perform a combination summation match between multiple payment transactions in the target transaction model and multiple payment instructions in the internal business document chain to determine whether there is a total amount of several payment instructions that is equal to the total amount of several payment transactions. If the combination summation match still fails, a comprehensive score is generated based on the similarity of the payer's name, the proximity of the transaction time, and the difference in the amount. When the score exceeds the set threshold, it is confirmed as a fuzzy match. Trading pairs that do not meet any of the above matching conditions will be identified as target trading pairs.

[0045] In one feasible implementation, the multi-source system state information extraction and combination module 640 is further used for: Extract the current processing status of the payment instructions associated with the target transaction pair from the enterprise resource planning system. The processing status includes approved, sent, posted, or reversed. Extract the transmission status of the payment message corresponding to the target transaction pair from the payment gateway system. The transmission status includes whether the message has been sent, received, rejected, or timed out without response. Extract the actual settlement status of the target transaction pair from bank receipts or data from third-party payment platforms. The actual settlement status includes accepted, settled, refunded, or being processed. Arrange the above three types of states in a fixed order to generate a multi-source state combination consisting of three state fields.

[0046] In one feasible implementation, the multi-source system state information extraction and combination module 640 is further used for: The payment instruction processing status extracted from the enterprise resource planning system, the payment message transmission status extracted from the payment gateway system, and the actual settlement status extracted from the feedback data from banks or third-party payment platforms are structured and organized according to the preset system hierarchy. The structured organization is based on the logical sequence of each state in the entire life cycle of payment business, so that the first state reflects the internal decision-making and accounting behavior of the enterprise, the second state reflects the cross-system transmission process of instructions, and the third state reflects the actual settlement result of external funds. Based on this structured organization, a multi-source state vector with a unified dimension is generated, where each dimension corresponds to a state value at a system level, and all multi-source state vectors maintain semantic alignment on the same dimension. Using multi-source state vectors as input, a pre-trained state semantic understanding model is driven to identify temporal consistency, causal dependence, and abnormal coupling patterns among states in various dimensions, and output anomaly attribution categories that match the multi-source state vectors.

[0047] In one feasible implementation, the above-mentioned reconciliation anomaly location module 650 is further used for: The generated multi-source state combinations are compared item by item with the predefined state combination logic table; When the status of the Enterprise Resource Planning system is "accounted" in a multi-source status combination, while the status of the payment gateway system is "issued" and the bank settlement status is blank, the anomaly is determined to have occurred in the payment message transmission stage. When the status of the enterprise resource planning system is "accounted" in a multi-source status combination, while the bank settlement status is "refundable" and the payment gateway system status is "rejected", the anomaly is determined to have occurred in the bank's account verification process. When the status of the enterprise resource planning system is blank in a multi-source status combination, while the bank settlement status is settled, the anomaly is determined to have occurred in the enterprise's internal instruction omission process. Output the name of the specific abnormal step corresponding to the judgment result.

[0048] The multi-channel payment reconciliation anomaly location system provided in this application has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the embodiment of the multi-channel payment reconciliation anomaly location system can be referred to the corresponding content in the aforementioned multi-channel payment reconciliation anomaly location method embodiment.

[0049] This application also provides an electronic device, such as... Figure 7 The diagram shows the structure of the electronic device 100, which includes a processor 71 and a memory 70. The memory 70 stores computer-executable instructions that can be executed by the processor 71. The processor 71 executes the computer-executable instructions to implement any of the above-mentioned methods for locating reconciliation anomalies in multi-channel payments.

[0050] exist Figure 7 In the illustrated embodiment, the electronic device further includes a bus 72 and a communication interface 73, wherein the processor 71, the communication interface 73, and the memory 70 are connected via the bus 72.

[0051] The memory 70 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 73 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 72 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 72 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0052] The processor 71 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 71 or by instructions in software form. The processor 71 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory. The processor 71 reads the information in the memory and, in conjunction with its hardware, completes the steps of the multi-channel payment reconciliation anomaly location method of the aforementioned embodiment.

[0053] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the above-mentioned method for locating reconciliation anomalies in multi-channel payments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0054] The computer program product of the multi-channel payment reconciliation anomaly location method, system and electronic device provided in the embodiments of this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0055] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0056] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0057] In the description of this application, it should be noted that the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0058] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for locating reconciliation anomalies in multi-channel payments, characterized in that, include: Acquire payment transaction data from multiple payment platforms and map the preprocessed payment transaction data to the target transaction model; Obtain payment instructions, accounting vouchers, and document circulation status, and construct an internal business document chain based on the payment instructions, accounting vouchers, and document circulation status; Based on the target transaction model, a matching operation is performed with the internal business document chain to obtain target transaction pairs that fail to match or have inconsistent amounts. For each target transaction pair, system state information representing the progress of the transaction within the system is extracted from multiple heterogeneous information systems participating in payment processing. The extracted system state information is then combined to generate a multi-source state combination. Based on the predefined state combination logic table, the reconciliation anomaly is located for the multi-source state combination, and the specific link in which the reconciliation anomaly occurred is obtained.

2. The method for locating reconciliation anomalies in multi-channel payments according to claim 1, characterized in that, Acquire payment transaction data from multiple payment platforms and map the preprocessed payment transaction data to the target transaction model, including: It connects to the bank's front-end system, third-party payment system, and virtual card system, and collects raw payment transaction data with structured field definitions from each system. The original payment transaction data is cleaned by removing duplicate records, filling in missing timestamps, and standardizing the amount value format and currency identifier. The scattered transaction elements in the cleaned payment transaction data from various channels are mapped to a set of standard fields, including unique transaction number, payer name, payee name, transaction amount, transaction time, transaction summary, and channel type, to generate the target transaction model.

3. The method for locating reconciliation anomalies in multi-channel payments according to claim 1, characterized in that, Obtain payment instructions, accounting vouchers, and document circulation status, and construct an internal business document chain based on these information, including: Extract payment instruction records from the enterprise resource planning system. These payment instruction records include the instruction initiation time, expected payment date, payee account information, and associated business document number. Extract accounting voucher records corresponding to the payment instruction from the financial accounting system. The accounting voucher records include the posting time, debit and credit accounts, amount, and voucher status. An index relationship is established between the payment instruction and the accounting voucher based on the business document number. The index relationship is then traced backward to the purchase order or expense application and forward to the fund accounting details to obtain an internal business document chain with a hierarchical structure.

4. The method for locating reconciliation anomalies in multi-channel payments according to claim 1, characterized in that, Based on the target transaction model, a matching operation is performed with the internal business document chain to obtain target transaction pairs that fail to match or have inconsistent amounts, including: The end-to-end unique identifier generated in the payment instruction is used as the matching identifier. Based on the matching identifier, the corresponding transaction record is searched in the target transaction model. When the identifiers match and the amount difference is within the allowable tolerance range, direct reconciliation is performed. When no matching identifier is found, within a preset time window, perform a combination summation match between multiple payment transactions in the target transaction model and multiple payment instructions in the internal business document chain to determine whether there is a total amount of several payment instructions that is equal to the total amount of several payment transactions. If the combination summation match still fails, a comprehensive score is generated based on the similarity of the payer's name, the proximity of the transaction time, and the difference in the amount. When the score exceeds the set threshold, it is confirmed as a fuzzy match. Trading pairs that do not meet any of the above matching conditions will be identified as target trading pairs.

5. The method for locating reconciliation anomalies in multi-channel payments according to claim 1, characterized in that, For each target transaction pair, system state information representing the progress of the transaction within its own system is extracted from multiple heterogeneous information systems participating in payment processing. The extracted system state information is then combined to generate a multi-source state combination, including: Extract the current processing status of the payment instruction associated with the target transaction pair from the enterprise resource planning system. The processing status includes approved, sent, posted, or reversed. Extract the transmission status of the payment message corresponding to the target transaction pair from the payment gateway system. The transmission status includes sent, received, rejected, or timed out without response. Extract the actual settlement status of the target transaction pair from bank receipts or data feedback from third-party payment platforms. The actual settlement status includes accepted, settled, refunded, or being processed. Arrange the above three types of states in a fixed order to generate a multi-source state combination consisting of three state fields.

6. The method for locating reconciliation anomalies in multi-channel payments according to claim 5, characterized in that, Arrange the above three types of states in a fixed order to generate a multi-source state combination consisting of three state fields, including: The payment instruction processing status extracted from the enterprise resource planning system, the payment message transmission status extracted from the payment gateway system, and the actual settlement status extracted from the feedback data from banks or third-party payment platforms are structured and organized according to the preset system hierarchy. The structured organization is based on the logical sequence of each state in the entire life cycle of the payment business, so that the first state reflects the internal decision-making and accounting behavior of the enterprise, the second state reflects the cross-system transmission process of instructions, and the third state reflects the actual settlement result of external funds. Based on this structured organization, a multi-source state vector with a unified dimension is generated, where each dimension corresponds to a state value at a system level, and all multi-source state vectors maintain semantic alignment on the same dimension. Using multi-source state vectors as input, a pre-trained state semantic understanding model is driven to identify temporal consistency, causal dependence, and abnormal coupling patterns among states in various dimensions, and output anomaly attribution categories that match the multi-source state vectors.

7. The method for locating reconciliation anomalies in multi-channel payments according to claim 1, characterized in that, Based on a predefined state combination logic table, the reconciliation anomaly is located for this multi-source state combination, revealing the specific steps in which the anomaly occurred, including: The generated multi-source state combinations are compared item by item with the predefined state combination logic table; When the status of the Enterprise Resource Planning system is "accounted" in a multi-source status combination, while the status of the payment gateway system is "issued" and the bank settlement status is blank, the anomaly is determined to have occurred in the payment message transmission stage. When the status of the enterprise resource planning system is "accounted" in a multi-source status combination, while the bank settlement status is "refundable" and the payment gateway system status is "rejected", the anomaly is determined to have occurred in the bank's account verification process. When the status of the enterprise resource planning system is blank in a multi-source status combination, while the bank settlement status is settled, the anomaly is determined to have occurred in the enterprise's internal instruction omission process. Output the name of the specific abnormal step corresponding to the judgment result.

8. A reconciliation anomaly location system for multi-channel payments, characterized in that, The payment transaction data acquisition and target transaction model mapping module is used to acquire payment transaction data from multiple payment platforms and map the preprocessed payment transaction data to the target transaction model. The internal business document chain construction module is used to obtain payment instructions, accounting vouchers and document circulation status, and construct an internal business document chain based on the payment instructions, accounting vouchers and document circulation status; The target transaction pair matching module is used to perform matching operations with the internal business document chain based on the target transaction model to obtain target transaction pairs that fail to match or have inconsistent amounts. The multi-source system state information extraction and combination module is used to extract the independently generated system state information representing the progress of the transaction within the system from multiple heterogeneous information systems participating in the payment business processing for each target transaction pair, and combine the extracted system state information to generate a multi-source state combination. The reconciliation anomaly location module is used to locate reconciliation anomalies in a multi-source state combination based on a predefined state combination logic table, thereby identifying the specific step in which the reconciliation anomaly occurred.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the reconciliation anomaly location method for multi-channel payments as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the reconciliation anomaly location method for multi-channel payments as described in any one of claims 1 to 7.

Images