A multi-source payment industry finance full-link account reconciliation and difference checking processing method and system

Abstract

This invention discloses a method and system for multi-source payment business and financial end-to-end reconciliation and discrepancy verification. By constructing an end-to-end data lake and using a unified business transaction number as the primary key for querying, this invention deeply integrates the dispersed heterogeneous data from the business end, the invoice end, and the bank end, completely breaking down information silos and laying a data foundation for penetrating verification. Secondly, it adopts an adaptive grouping reconciliation strategy based on dynamic time windows to replace the traditional mechanical verification mode of "rigid amount matching," which can flexibly handle complex and abnormal scenarios such as multiple merged entries and cross-period settlements. More importantly, it innovatively introduces a pre-trained large language model for discrepancy diagnosis, enabling the system to no longer simply report errors but to understand the essence of the business and output intelligent reports containing root cause analysis and decision-making suggestions. This significantly reduces verification costs and the risk of human error, effectively ensuring the accuracy of cash flow and the authenticity of accounts.

Description

Technical Field

[0001] This invention belongs to the fields of medical financial informatization, big data governance and artificial intelligence application technology, specifically involving a method and system for reconciliation and discrepancy verification of multi-source payment business finance across the entire chain. Background Technology

[0002] Currently, the comprehensive payment business of large public hospitals and general institutions is characterized by high concurrency, multiple channels, and non-standardization. The business scope covers dozens of fees such as continuing education fees, internship fees, accommodation fees, quality assurance deposits, parking revenue, equipment usage fees, and research fees. Among them, quality assurance deposits and research fees often involve corporate bank transfers, resulting in significant differences between cash flow and business flow in terms of time and space. This makes it impossible for existing automated reconciliation systems to meet the reconciliation needs of multi-source data.

[0003] Currently, existing automated reconciliation systems (the closest existing technology) mainly suffer from the following drawbacks: (1) "Information silos" lead to broken links; the payment of various fees (business end), invoicing (invoice end), accounting (bank end), refund, and reconciliation are scattered in different heterogeneous systems. The key business information of the fee recipients (such as trainee number and scientific research project code) and the summary information in the bank statements (often only vague notes, abbreviations or garbled characters) lack underlying connection, making it difficult to conduct penetrating verification.

[0004] (2) Rigid rules cannot cope with complex anomalies; existing systems usually rely on rigid threshold verification of “total amount - amount received = 0”. When faced with unstructured anomalies such as non-standard bank transaction summary, multiple small amounts combined into large amounts, cross-period settlement (such as T+1 and T+N mixed), and handling fee deduction, the system cannot understand the business substance and can only mechanically report errors (such as outputting “amount mismatch”) and cannot identify the root cause.

[0005] (3) Manual verification is costly and risky: Once the reconciliation fails, the difference diagnosis relies heavily on the financial staff to manually download multiple reports and compare unstructured transaction summaries one by one. This is not only inefficient (each person spends several hours / day), but also prone to the risk of fund loss or accounting fraud due to visual misjudgment.

[0006] Therefore, given the aforementioned shortcomings, how to provide a multi-source payment business finance full-chain reconciliation and discrepancy verification method that is accurate, can achieve intelligent diagnosis, and has low verification costs has become an urgent problem to be solved. Summary of the Invention

[0007] The purpose of this invention is to provide a method and system for reconciliation and discrepancy verification of multi-source payment business and finance across the entire chain, in order to solve the problems of fragmented business and finance data, rigid reconciliation rules, and lack of anomaly diagnosis capabilities in the existing technology.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a method for reconciliation and discrepancy verification across the entire payment chain for multi-source payments is provided, including: Collect several payment records generated on the business end, several invoice information generated on the bill end, and several transaction records generated on the bank end when executing payment business; Based on the payment records, invoicing information, and transaction records corresponding to each payment transaction, a transaction number corresponding to each payment transaction is generated. The transaction number corresponding to each payment transaction is used as the primary key for querying, and the payment records, invoicing information, and transaction records corresponding to each payment transaction are stored as query values ​​in the end-to-end data lake. An adaptive grouping reconciliation strategy based on dynamic time windows is adopted to collect payment records, invoicing information and transaction records corresponding to the transaction dates to be checked in the full-link data lake as reconciliation data; The reconciliation data is verified for funds, and it is determined whether the fund verification passes. If not, then based on the reconciliation data, generate a reconciliation discrepancy verification prompt; The reconciliation discrepancy verification prompts are input into a pre-trained LLM model to diagnose reconciliation discrepancies and obtain a reconciliation verification report, which includes a diagnostic report and decision recommendations.

[0009] Based on the aforementioned disclosures, this invention constructs a full-link data lake and uses a unified business transaction number as the primary key for querying, deeply integrating the heterogeneous data scattered across the business, bill, and banking ends. This completely breaks down information silos, establishing a fundamental link between key business information and bank transaction summaries, laying the data foundation for penetrating verification. Secondly, it adopts an adaptive grouping reconciliation strategy based on dynamic time windows to replace the traditional mechanical verification mode of "rigid amount matching," flexibly handling complex and abnormal scenarios such as multiple merged entries and cross-period settlements. More importantly, it innovatively introduces a pre-trained large language model for difference diagnosis, enabling the system to go beyond simple error reporting and instead understand the essence of the business and output intelligent reports containing root cause analysis and decision-making suggestions. This frees financial personnel from time-consuming manual comparisons of each transaction, significantly reducing verification costs and the risk of human error, effectively ensuring the accuracy of cash flow and the authenticity of accounts. Therefore, this invention significantly improves the level of financial risk control, making it highly suitable for large-scale application and promotion.

[0010] In one possible design, an adaptive grouping reconciliation strategy based on dynamic time windows is adopted. Payment records, invoicing information, and transaction records corresponding to the transaction dates to be checked are statistically analyzed in the end-to-end data lake to serve as reconciliation data, including: Determine whether there is a transaction record corresponding to a specified date in the end-to-end data lake, wherein the specified date is the date preceding the date of the transaction to be inspected; If not, then perform a transaction record retrieval in the full-link data lake until the transaction record that is before the date of the transaction to be inspected and has the shortest interval with the date of the transaction to be inspected is retrieved, and the date corresponding to the retrieved transaction record is used as the backtracking date; From the end-to-end data lake, filter out all transaction records that fall between the retrospective date and the date of the transaction to be inspected; Based on the primary key corresponding to all the selected transaction records, the payment records and invoicing information corresponding to each selected transaction record are retrieved from the full-link data lake. The reconciliation data is constructed by using the selected transaction records, as well as the corresponding payment records and invoicing information for each transaction record.

[0011] In one possible design, determining whether a transaction record corresponding to a specified date exists in the end-to-end data lake includes: If so, then filter out the transaction records corresponding to the transaction dates to be inspected from the end-to-end data lake as the target records; Based on the query primary key corresponding to the target record, the payment record and invoicing information corresponding to the target record are retrieved from the full-link data lake; The reconciliation data is composed of the target record, the corresponding payment record, and the invoicing information.

[0012] In one possible design, the reconciliation data undergoes a funds verification process to determine whether the verification passes, including: From the reconciliation data, filter out all payment records and all transaction records; Based on all the selected payment records, the total transaction amount is calculated, and based on all the selected transaction records, the total amount actually received by the bank is calculated. Determine whether the total transaction amount is the same as the total amount actually received by the bank; If yes, the funds verification is considered successful; otherwise, the funds verification is considered unsuccessful.

[0013] In one possible design, based on the reconciliation data, reconciliation discrepancy verification prompts are generated, including: Context extraction is performed on the reconciliation data to obtain the transaction details, time range, and amount difference in the reconciliation data, as well as the unstructured summary text in the transaction records within the reconciliation data; Based on the transaction details, the time range, the amount difference, and the unstructured summary text, the reconciliation discrepancy verification prompt words are generated.

[0014] In one possible design, the reconciliation discrepancy verification prompts are input into a pre-trained LLM model for reconciliation discrepancy diagnosis to obtain a reconciliation verification report, including: Using the pre-trained LLM model, semantic parsing is performed on the reconciliation discrepancy verification prompt words to extract the implicit date and item features in the reconciliation discrepancy verification prompt words. The implicit date is a date in a non-standard format, and the item features are used to characterize the business type, expense account and / or financial intent. Convert the implicit date and the project characteristics into a feature vector; Based on feature vectors and a pre-set financial knowledge base, and using a pre-trained LLM model, the system performs reconciliation discrepancy reasoning and diagnosis to generate decision recommendations and structured diagnostic reports. The reconciliation and verification report is generated using the diagnostic report and the decision recommendations.

[0015] In one possible design, after obtaining the reconciliation report, the method further includes: Store the reconciliation discrepancy verification prompts and the reconciliation verification report into a vector database; Based on a vector database and using the LoRA algorithm, the LLM model is incrementally fine-tuned to obtain an optimized LLM model, which can then be used for reconciliation discrepancy diagnosis.

[0016] In one possible design, after obtaining the reconciliation report, the method further includes: In response to human-computer interaction requiring manual confirmation, the decision recommendations in the reconciliation and verification report are executed.

[0017] In one possible design, the transaction serial number includes: a transaction type code, a merchant number, and a timestamp, wherein the transaction type code is generated based on payment records, the merchant number is generated based on invoicing information, and the timestamp is generated based on transaction records.

[0018] Secondly, a multi-source payment business and finance full-chain reconciliation and discrepancy verification system is provided, including: The data acquisition layer is used to collect several payment records generated on the business side, several invoice information generated on the invoice side, and several transaction records generated on the bank side when executing payment business. The data acquisition layer is also used to generate a business transaction number for each payment transaction based on the payment record, invoice information and transaction record corresponding to each payment transaction, and to use the business transaction number corresponding to each payment transaction as the primary key for querying, and store the payment record, invoice information and transaction record corresponding to each payment transaction as the query value in the end-to-end data lake; The logic processing layer is used to employ an adaptive grouping reconciliation strategy based on dynamic time windows to statistically analyze the payment records, invoicing information, and transaction records corresponding to the transaction dates to be inspected in the end-to-end data lake, which will serve as reconciliation data. The logic processing layer is also used to perform fund verification on the reconciliation data and determine whether the fund verification passes. The intelligent analysis layer is used to generate reconciliation discrepancy verification prompts based on the reconciliation data when the logic processing layer determines that the fund verification has failed. The intelligent analysis layer is also used to input the reconciliation discrepancy verification prompts into a pre-trained LLM model to diagnose reconciliation discrepancies and obtain a reconciliation verification report, wherein the reconciliation verification report includes a diagnostic report and decision suggestions.

[0019] Thirdly, a multi-source payment business and finance full-link reconciliation and discrepancy verification processing device is provided. Taking the device as an electronic device as an example, it includes a memory, a processor and a transceiver connected in sequence. The memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer programs and execute the multi-source payment business and finance full-link reconciliation and discrepancy verification processing method as described in the first aspect or any possible design in the first aspect.

[0020] Fourthly, a storage medium is provided, on which instructions are stored, which, when executed on a computer, perform the multi-source payment business and finance full-link reconciliation and discrepancy verification processing method as described in the first aspect or any possible design in the first aspect.

[0021] Fifthly, a computer program product containing instructions is provided, which, when executed on a computer, causes the computer to perform the multi-source payment business finance full-link reconciliation and discrepancy verification processing method as described in the first aspect or any possible design of the first aspect.

[0022] Beneficial effects: (1) This invention constructs a full-link data lake and uses a unified business transaction number as the query primary key to deeply integrate the heterogeneous data scattered across the business end, the bill end, and the bank end, completely breaking down information silos and establishing a fundamental association between key business information and bank transaction summaries, laying the data foundation for penetrating verification. Secondly, it adopts an adaptive grouping reconciliation strategy based on dynamic time windows to replace the traditional mechanical verification mode of "rigid matching of amounts," which can flexibly cope with complex and abnormal scenarios such as multiple merged entries and cross-period settlements. More importantly, it innovatively introduces a pre-trained large language model for difference diagnosis, so that the system no longer simply reports errors, but can understand the business substance and output intelligent reports containing root cause analysis and decision-making suggestions. In this way, financial personnel can be freed from the time-consuming manual comparison of each transaction, significantly reducing verification costs and the risk of human error, and effectively ensuring the accuracy of cash flow and the authenticity of accounts. Thus, this invention greatly improves the level of financial risk prevention and control, making it very suitable for large-scale application and promotion.

[0023] (2) The present invention constructs a closed loop of “diagnosis-feedback-fine-tuning”; therefore, as financial personnel confirm or correct the suggestions of the large model, the system will accumulate positive and negative sample data, continuously optimize the model’s adaptability to specific scenarios (such as newly added scientific research project fee rules), and the system becomes “smarter” with long-term use, thereby improving the accuracy of reconciliation and verification diagnosis.

[0024] (3) Significant cost reduction and efficiency improvement: In practical applications, the verification time for complex differences has been shortened from 4 hours / day per person to minutes, and the exposure rate of financial risks has been greatly reduced. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the steps of the multi-source payment business and finance full-link reconciliation and discrepancy verification method provided in this embodiment of the invention; Figure 2 This is a logical architecture diagram of link data association provided in an embodiment of the present invention; Figure 3 A logical diagram illustrating an adaptive grouping reconciliation strategy based on a dynamic time window, provided in an embodiment of the present invention. Figure 4 A flowchart of the large-scale model difference diagnosis and decision-making closed loop provided in the embodiments of the present invention; Figure 5 This is a structural diagram of the multi-source payment business and finance full-link reconciliation and discrepancy verification processing system provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0027] It should be understood that although the terms first, second, etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another. For example, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit, without departing from the scope of the exemplary embodiments of the invention.

[0028] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0029] Example: See Figure 1 As shown, the multi-source payment business and financial full-link reconciliation and discrepancy verification method provided in this embodiment can be executed by computer equipment with certain computing resources, including but not limited to servers, edge computers, personal computers (PCs, which are multi-purpose computers of a size, price and performance suitable for personal use; desktop computers, laptops to mini-laptops and tablets and ultrabooks are all personal computers), smartphones or personal digital assistants (PDAs). It is understood that the aforementioned execution subject does not constitute a limitation on the embodiments of this application. Accordingly, the operation steps of this method can be, but are not limited to, the steps S1 to S6 below.

[0030] S1. Collect several payment records generated on the business side, several invoice information generated on the invoice side, and several transaction records generated on the bank side when executing payment transactions. In specific applications, for example, data from the three ends can be collected periodically through API interfaces or intermediate libraries, that is, the data corresponding to the aforementioned business end, invoice end, and bank end can be collected periodically. Among them, the payment records on the business end can be, but are not limited to, payment records from the HIS system or payment platform, which at least include information such as payment type (further education / research, etc.), amount, operator, and refund mark. Similarly, the invoice information generated on the invoice end (electronic invoice system) can include, but is not limited to, invoice number (invoice number), invoice time, and red-inking status. The transaction records generated on the bank side can include, but are not limited to, transaction summaries of online banking transactions (including arrival time, transaction amount, etc.), counterparty name, transaction remarks, and loan / credit mark.

[0031] Thus, after completing the data collection from the three ends, this embodiment designs a unique identifier generation rule with business meaning for multi-source heterogeneous data (business end, invoice end, bank end). Based on this rule, a business transaction number corresponding to the payment record, invoice information and transaction record under the same payment business is generated. Then, the business transaction number is used to establish a precise mapping relationship of "business-invoice-bank" three-code integration.

[0032] The process of establishing the aforementioned mapping relationship can be, but is not limited to, the steps shown in step S2 below.

[0033] S2. Based on the payment record, invoice information, and transaction record corresponding to each payment transaction, generate a transaction number corresponding to each payment transaction, and use the transaction number corresponding to each payment transaction as the primary key for querying, and store the payment record, invoice information, and transaction record corresponding to each payment transaction as the query value in the end-to-end data lake.

[0034] In this embodiment, before generating the transaction serial number, for example, but not limited to, using an ETL (Extract-Transform-Load) tool, the aforementioned three-terminal data can be cleaned. Then, based on the cleaned three-terminal data, the transaction serial number corresponding to each payment transaction is generated.

[0035] See Figure 2As shown, the business transaction number, for example, includes: a 1-digit transaction type code, a 6-digit merchant number, and a 13-digit timestamp. The transaction type code is generated based on the payment record, i.e., based on the payment type in the payment record. The merchant number is generated based on the invoice information (i.e., based on the invoice number in the invoice information, the last 6 digits of the invoice number can be used as the merchant number), and the timestamp is generated based on the transaction record (the arrival time in the transaction summary of the transaction record). Thus, for each payment transaction, a corresponding key-value pair can be established based on its corresponding business transaction number. That is, the business transaction number of a payment transaction is used as the primary key for querying, and the payment record, invoice information, and transaction record corresponding to the payment transaction are used as the query values ​​to construct the query key-value pair. Finally, each query key-value pair is written into the end-to-end data lake, which can achieve accurate mapping of payment record-invoice data-bank transaction in the same payment transaction, so that records at any end can be indexed to the other two ends.

[0036] Therefore, this embodiment constructs a data lake with full-chain traceability of business, invoices, and bank transactions, thereby solving the data silo problem and laying a data foundation for penetrating verification.

[0037] After constructing a full-link data lake based on a unique business serial number, data reconciliation can be performed based on this, and the process can be, but is not limited to, the steps shown in step S3 below.

[0038] S3. An adaptive grouping reconciliation strategy based on dynamic time windows is adopted. Payment records, invoicing information, and transaction records corresponding to the transaction dates to be checked are statistically analyzed in the end-to-end data lake to serve as reconciliation data. In practical applications, to address issues such as "false discrepancies" caused by irregular bank settlement cycles (e.g., combined settlements for holidays), this embodiment abandons the traditional daily reconciliation and adopts a dynamic grouping strategy for fund reconciliation; see [link to relevant documentation]. Figure 3 As shown, the implementation process of the aforementioned adaptive grouping reconciliation strategy based on dynamic time windows can be, but is not limited to, the steps S31 to S35 below.

[0039] S31. Determine whether there is a transaction record corresponding to a specified date in the end-to-end data lake, wherein the specified date is the date preceding the transaction date to be checked; in this embodiment, assuming the transaction date to be checked is T, then first determine whether there is a transaction record for day T-1 in the end-to-end data lake, wherein if there is, the payment record, invoice record and transaction record corresponding to the transaction date to be checked are grouped together as reconciliation data, that is: first, filter out the transaction record corresponding to the transaction date to be checked from the end-to-end data lake as the target record; then, based on the query primary key (the business transaction number corresponding to the target record) corresponding to the target record, query the payment record and invoice information corresponding to the target record from the end-to-end data lake; finally, the reconciliation data can be composed based on the target record and the payment record and invoice information corresponding to the target record.

[0040] Further, see Figure 3 As shown, if there is no transaction record for day T-1 in the end-to-end data lake, it is determined that a flow interruption has occurred. At this time, the traceback mode is entered, which is to recursively query forward until a date with a transaction record is found. Then, all data between the date with the transaction record and the date of the transaction to be checked are merged into a "super reconciliation group". The payment records, invoicing information and transaction records in the "super reconciliation group" are used to form reconciliation data. The recursive query process is shown in steps S32 to S35 below.

[0041] S32. If not, perform a transaction record retrieval in the full-link data lake until the transaction record that is prior to the date of the transaction to be inspected and has the shortest interval with the date of the transaction to be inspected is retrieved, and the date corresponding to the retrieved transaction record is used as the backtracking date.

[0042] After retrieving the date closest to the transaction date to be inspected and for which there is a transaction record, the data can be merged, as shown in steps S33 to S35 below.

[0043] S33. Filter out all transaction records from the end-to-end data lake that fall between the retrospective date and the date of the transaction to be inspected.

[0044] After filtering out all transaction records between the retrospective date and the transaction date to be inspected, the payment records and invoicing information associated with each transaction record can be queried based on the business transaction number corresponding to each transaction record, so that data merging can be achieved subsequently. The process is shown in steps S34 and S35 below.

[0045] S34. Based on the query primary key corresponding to all the filtered transaction records, query the payment record and invoicing information corresponding to each of the filtered transaction records from the full-link data lake.

[0046] S35. Using the selected transaction records, as well as the corresponding payment records and invoicing information for each transaction record, the reconciliation data is constructed.

[0047] Through the aforementioned steps S31 to S35, this embodiment adopts an adaptive grouping reconciliation strategy based on dynamic time windows to determine the actual reconciliation data. This avoids the problem of "false discrepancies" caused by the irregular settlement cycle of banks (such as the combined settlement of holidays). At the same time, compared with the traditional mechanical verification mode of "rigid matching of amounts" on a daily basis, this reconciliation strategy can flexibly cope with complex and abnormal scenarios such as multiple combined entries and cross-cycle settlements. Therefore, it improves the accuracy and adaptability of reconciliation.

[0048] After obtaining the reconciliation data, funds can be verified, as shown in step S4 below.

[0049] S4. Perform fund verification on the reconciliation data and determine whether the fund verification passes. In specific implementation, for example, but not limited to, first filter out all payment records and all transaction records from the reconciliation data; then, calculate the total transaction amount based on the payment amount in all the filtered payment records, and calculate the total amount actually received by the bank based on the transaction amount in all the filtered transaction records; next, determine whether the total transaction amount is the same as the total amount actually received by the bank (i.e., whether |total transaction amount - total amount actually received by the bank| equals 0); if the two are the same, the fund verification is determined to pass; otherwise, the fund verification is determined to fail.

[0050] Optionally, when the funds verification is successful, the reconciliation data is marked as successful; otherwise, the reconciliation data is marked as "abnormal". In this case, the difference value needs to be recorded and incorporated into the subsequent intelligent difference diagnosis and decision-making process, as shown in steps S5 and S6 below.

[0051] S5. If not, generate reconciliation discrepancy verification prompts based on the reconciliation data. In specific implementation, for example, but not limited to, context extraction of the reconciliation data, to obtain transaction details, time range, and amount difference in the reconciliation data, as well as unstructured summary text in the transaction records within the reconciliation data; then, generate the reconciliation discrepancy verification prompts based on the transaction details, the time range, the amount difference, and the unstructured summary text.

[0052] In practice, the aforementioned unstructured summary text is free text in fields such as "Summary / Postscript / Remarks" in the log record, such as "0505_171698_Research Q2", "Quality Assurance Deposit Deduction", "Refund Cancellation", etc.

[0053] The difference between it and structured data is as follows: Structured data includes transaction time, amount, account number, currency, etc., which are fields in the database with a fixed format and can be directly statistically analyzed. Unstructured summary text, on the other hand, is manually entered or generated by the system, lacks a unified format, and has ambiguous semantics, requiring semantic parsing for understanding. Optionally, the following provides a method for recognizing unstructured summary text, which may include, but is not limited to, the following: (1) Agent+ RPA perception access: Through the robot to simulate financial operations, the original text of the "summary / remarks" area is accurately captured from the online banking or receipt; (2) Intelligent noise reduction: The meaningless noise (such as serial number and teller number) is automatically filtered out, and only the core text with financial semantics is retained; (3) Semantic anchor annotation: The key information such as date, project code and business action in the text is annotated to obtain unstructured summary text.

[0054] Thus, after extracting the aforementioned transaction details, time range, amount difference, and unstructured summary text, it can be added to the prompt word template to generate reconciliation discrepancy verification prompt words, such as: Input build: { Context: Transaction dates: May 3-6; Total transaction amount: 15,000; Bank transfer received: 14,500; Difference: -500 "Bank_Abstract": "Summary: 0505_171698_Refund Reversal", "Biz_Details": [{"Date": "5.5", "Type": "Refund", "Amount": 500}, ...] }

[0055] Of course, the examples mentioned above are merely illustrative, and this embodiment is not limited thereto.

[0056] After receiving the reconciliation discrepancy verification prompt, large-scale model inference can be performed to obtain the reconciliation verification report, as shown in step S6 below.

[0057] S6. Input the reconciliation discrepancy verification prompts into the pre-trained LLM model to diagnose reconciliation discrepancies and obtain a reconciliation verification report, wherein the reconciliation verification report includes a diagnostic report and decision recommendations; for specific implementation, see [link to relevant documentation]. Figure 4As shown, for example, but not limited to, the following steps S61 to S64 can be used to generate a reconciliation and verification report.

[0058] S61. Using the pre-trained LLM model, semantic parsing is performed on the reconciliation discrepancy verification prompts to extract the implicit date and item features from the reconciliation discrepancy verification prompts, wherein the implicit date is a non-standard format date, and the item features are used to characterize the business type, expense account, and / or financial intent; in this embodiment, Figure 4 The abnormal context data in the data is the reconciliation discrepancy verification prompt words. When these are input into the LLM model, the semantic parsing capability of the model (i.e. the semantic parsing module in the model) can be used to extract the aforementioned implicit date and item features.

[0059] It should be noted that the implicit date is in unstructured text and is not in the standard YYYY-MM-DD format, but it is a number or abbreviation with a clear time meaning, such as "0505" → May 5th, "24Q2" → the second quarter of 2024, "last month's payment" → the month before the transaction month, etc. When reconciling accounts, it determines the "settlement bias" of this cash flow on the timeline and determines whether there is a cross-period entry.

[0060] Meanwhile, the project department's characteristics are semantic keywords in the reconciliation discrepancy verification prompts that can be mapped to specific business types, expense accounts, and / or financial intentions, such as "scientific research" → pointing to expense accounts, "171698" → pointing to internal project codes, "refund reversal" → pointing to the reversal logic of accounting entries, etc. Therefore, as a "business constraint operator", it can accurately locate the corresponding business documents in the full-link data lake.

[0061] After extracting the implicit date and project features through the aforementioned steps, they can be converted into feature vectors for subsequent logical matching and attribution judgment, as shown in step S62 below.

[0062] S62. Convert the implicit date and the project features into feature vectors; in this embodiment, the aforementioned features are encoded into high-dimensional vectors (such as "0505" representing "refund" and "-500 yuan"), so that the system can perform mathematical matching; of course, the specific encoding method can be set according to actual use, and this embodiment does not make specific limitations.

[0063] After obtaining the feature vector, logical matching and attribution judgment can be performed, as shown in step S63 below.

[0064] S63. Based on feature vectors and a pre-set financial knowledge base, and using a pre-trained LLM model, perform reconciliation discrepancy reasoning and diagnosis to generate decision suggestions and structured diagnostic reports.

[0065] In this embodiment, firstly, based on the feature vector, business logic matching is performed in a pre-set financial knowledge base (i.e., using the logic reasoning module in the model and employing RAG retrieval enhancement technology to search the knowledge base) to obtain the corresponding business logic rules, such as: Rule 1: If the project is a "quality assurance deposit", the difference is approximately 1%, which is likely a handling fee deduction; or Rule 2: If it is a "refund", the actual amount received will be less than the amount receivable, and there is often a settlement lag.

[0066] After retrieving the business logic rules, multi-dimensional conflict detection can be performed, namely: time axis comparison: determine whether the implicit date (e.g., May 5th) is on the edge of the current reconciliation period (e.g., May 3rd-May 6th), thereby identifying whether there is cross-period settlement; arithmetic verification: check whether the difference (e.g., -500 yuan) completely corresponds to the absolute value of the single amount corresponding to the project feature (refund).

[0067] Thus, after obtaining the multidimensional conflict detection results, attribution analysis can be performed. That is, when the "time conflict" and "amount characteristics" are logically closed, LLM will output a diagnostic conclusion, such as: "This difference is not an accounting error, but a cross-expectation entry caused by the T+N settlement cycle." The following example will illustrate this point: The input prompts include: difference is -500 yuan, summary text 0505_refund cancellation.

[0068] Identification: The implicit date is May 5th, and the project characteristic is a refund.

[0069] Knowledge Base: Refunds can result in actual receipts being less than receivables, and there may be settlement delays.

[0070] Reasoning: The refund on May 5th was not included in the current period's transaction history due to the bank's settlement cycle → the discrepancy in amount is a false difference.

[0071] Thus, after obtaining the reasoning result, i.e. the diagnostic report, the corresponding decision recommendations can be generated based on the diagnostic report; then, the reconciliation and verification report can be generated based on the diagnostic report and the decision recommendations, as shown in step S64 below.

[0072] S64. Using the diagnostic report and the decision recommendations, generate the reconciliation and verification report.

[0073] Thus, through the aforementioned steps S61 to S64, the detailed process of diagnosing the aforementioned reconciliation discrepancies can be summarized as follows: First, construct structured prompts (Prompt Engineering): The system first assembles the messy information collected by the Agent into an expert-level "task list"; such as: "Please analyze this summary '0505_171698_Refund Reversal' as a financial expert, and identify the dates and business types involved."

[0074] Secondly, semantic deconstruction and slot filling; after receiving the prompt word, LLM will perform the following three steps: pattern recognition: the model uses its knowledge learned from large-scale corpora to identify that "0505" conforms to date features (MMDD) and converts it into standardized date data.

[0075] Semantic Relationship: The model understands that "refund reversal" is not just four words, but a financial action (i.e., project feature) representing "negative financial adjustment"; Logical Mapping: The LLM will automatically fill the identified results into a preset structured container; Slot A (Date): May 5th, Slot B (Project): Refund business.

[0076] Then, the LLM, combined with the financial knowledge base, performed causal chain reasoning; a conflict was found: the reconciliation group was short 500 yuan as of May 6; features were retrieved: a "refund" feature was extracted on May 5; rule collision: the knowledge base showed that "refunds will lead to a reduction in bank deposits"; causal loop closure: because the extracted feature (500 yuan refund) can explain the current accounting gap in terms of both amount and time (May 5), the reason for the difference was determined to be "a false difference caused by cross-period refunds".

[0077] Therefore, after receiving the reconciliation and verification report, manual confirmation of the decision recommendations can be carried out. See [link / reference]. Figure 4 As shown, the decision execution process is as follows: in response to the human-computer interaction operation of manual confirmation, the decision suggestions in the reconciliation and verification report are executed, thereby automatically performing the adjustment.

[0078] Optionally, but not limited to, the decision recommendations can be displayed on a visual interface and a "one-click adoption" button can be provided. Therefore, when the finance personnel click the "one-click adoption" button on the interface, the backend microservice can be automatically invoked to execute the decision recommendations, thereby achieving self-healing of discrepancies. For example, if the decision recommendation is: to adjust the reconciliation group to re-verify from May 3 to May 5 and to include the transactions on May 6 in the next cycle, then, in response to the human-computer interaction operation of manual confirmation, the time boundary of the reconciliation group can be updated, and the verification logic in the aforementioned step S3 can be re-run.

[0079] In addition, in this embodiment, after obtaining the reconciliation verification report, the model can be optimized by feedback, that is, storing the reconciliation discrepancy verification prompt words and the reconciliation verification report into a vector database; then, based on the vector database and using the LoRA algorithm, the LLM model is incrementally fine-tuned to obtain an optimized LLM model, so that the optimized LLM model can be used for reconciliation discrepancy diagnosis; in this way, the model can be continuously optimized, thereby improving the accuracy of reconciliation diagnosis.

[0080] Thus, through the detailed explanation of the aforementioned multi-source payment business and finance full-link reconciliation and discrepancy verification method in steps S1 to S6, the present invention has the following beneficial effects: (1) Full-chain traceability; This invention, through its unique "three-code integration" association mechanism, connects the originally fragmented business flow and capital flow, enabling every change in funds to be traced back to the specific business document, thus solving the long-standing problem of "unclear accounts and actual situation" that has plagued hospital finances. (2) Deep intelligent attribution; This invention adopts an adaptive grouping reconciliation strategy based on dynamic time windows to replace the traditional mechanical verification mode of "rigid matching of amounts". It can flexibly deal with complex and abnormal scenarios such as multiple merged entries and cross-period settlement. At the same time, it uses a large model to break through the bottleneck of traditional systems being unable to understand unstructured text, enabling this invention to accurately identify complex scenarios such as cross-period settlement, garbled summary characters, and hidden deduction of handling fees, thereby greatly improving the accuracy of difference identification.

[0081] (3) System adaptive evolution; This invention constructs a closed loop of "diagnosis-feedback-fine-tuning". Therefore, as financial personnel confirm or correct the suggestions of the large model, the system will accumulate positive and negative sample data and continuously optimize the model's adaptability to specific scenarios (such as newly added scientific research project fee rules), making the system "smarter" with long-term use.

[0082] (4) Significant cost reduction and efficiency improvement; In practical applications, the verification time for complex differences has been shortened from 4 hours / day per person to minutes, and the exposure rate of financial risks has been greatly reduced.

[0083] like Figure 5 As shown, the second aspect of this embodiment provides a hardware system for implementing the multi-source payment business and finance full-link reconciliation and discrepancy verification processing method described in the first aspect of the embodiment, including: The data acquisition layer is used to collect several payment records generated on the business side, several invoice information generated on the invoice side, and several transaction records generated on the bank side when executing payment business.

[0084] The data acquisition layer is also used to generate a transaction number for each payment transaction based on the payment record, invoice information and transaction record corresponding to each payment transaction. The transaction number corresponding to each payment transaction is used as the primary key for querying, and the payment record, invoice information and transaction record corresponding to each payment transaction are used as query values ​​and stored in the end-to-end data lake.

[0085] The logic processing layer is used to employ an adaptive grouping reconciliation strategy based on dynamic time windows to statistically analyze the payment records, invoicing information, and transaction records corresponding to the transaction dates to be inspected in the end-to-end data lake, which will serve as reconciliation data.

[0086] The logic processing layer is also used to verify the funds in the reconciliation data and determine whether the fund verification passes.

[0087] The intelligent analysis layer is used to generate reconciliation discrepancy verification prompts based on the reconciliation data when the logic processing layer determines that the fund verification has failed.

[0088] The intelligent analysis layer is also used to input the reconciliation discrepancy verification prompts into a pre-trained LLM model to diagnose reconciliation discrepancies and obtain a reconciliation verification report, wherein the reconciliation verification report includes a diagnostic report and decision suggestions.

[0089] In this embodiment, the system's core computing layer (ComputeLayer) is deployed entirely within the core security domain; the application server cluster (AppServer, i.e., the business logic layer and intelligent analysis layer) serves as the central hub for business logic processing, establishing connections with the underlying data storage layer (DataStore)'s relational database (RDB) and end-to-end data lake (Lake) via high-speed TCP / IP protocol, enabling high-throughput read and write exchange of business data and log data, and ensuring the stability of massive pipeline processing.

[0090] Meanwhile, to address the needs of intelligent diagnostics, this system introduces a dedicated AI inference server (AIServer). This server is equipped with high-performance GPU accelerator cards (such as NVIDIA A100 / H800) to provide deep learning computing power. The AIServer communicates directly with the application server cluster via an internal physical dedicated line, avoiding public network congestion and ensuring that the end-to-end response latency of large models during attribution inference is less than 500ms, meeting the requirements for real-time interaction. In addition, the system is configured with an industrial-grade hardware firewall (FW) and physical network gateway to achieve physical-level isolation of internal and external network risks. It adopts a strict access control policy (ACL) to only allow connection requests from bank core system IPs within the whitelist, thus eliminating the risk of leakage of financial data at the physical level.

[0091] The working process, working details and technical effects of the system provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0092] like Figure 6 As shown, the third aspect of this embodiment provides a multi-source payment business and finance full-link reconciliation and discrepancy verification processing device. Taking the device as an electronic device as an example, it includes: a memory, a processor, and a transceiver connected in sequence. The memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer programs and execute the multi-source payment business and finance full-link reconciliation and discrepancy verification processing method as described in the first aspect of the embodiment.

[0093] For specific examples, the memory may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or first-in-last-out (FILO) memory, etc.; specifically, the processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor, also known as the CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state.

[0094] In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. For example, the processor may not be limited to microprocessors of the STM32F105 series, reduced instruction set computer (RISC) microprocessors, x86 architecture processors, or processors with integrated neural network processing units (NPUs). The transceiver may be, but is not limited to, a Wi-Fi transceiver, a Bluetooth transceiver, a General Packet Radio Service (GPRS) transceiver, a ZigBee (a low-power LAN protocol based on the IEEE 802.15.4 standard) transceiver, a 3G transceiver, a 4G transceiver, and / or a 5G transceiver. Furthermore, the device may also include, but is not limited to, a power module, a display screen, and other necessary components.

[0095] The working process, working details and technical effects of the electronic device provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0096] The fourth aspect of this embodiment provides a storage medium that stores instructions containing the multi-source payment business and finance full-link reconciliation and difference verification processing method described in the first aspect of the embodiment. That is, the storage medium stores instructions, and when the instructions are run on a computer, the multi-source payment business and finance full-link reconciliation and difference verification processing method described in the first aspect of the embodiment is executed.

[0097] The storage medium refers to a carrier for storing data, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or memory sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0098] The working process, working details and technical effects of the storage medium provided in this embodiment can be found in the first aspect of the embodiment, and will not be repeated here.

[0099] The fifth aspect of this embodiment provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the multi-source payment business and finance full-link reconciliation and discrepancy verification processing method as described in the first aspect of the embodiment, wherein the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0100] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for reconciliation and discrepancy verification across the entire financial chain of multi-source payment services, characterized in that, include: Collect several payment records generated on the business end, several invoice information generated on the bill end, and several transaction records generated on the bank end when executing payment business; Based on the payment records, invoicing information, and transaction records corresponding to each payment transaction, a transaction number corresponding to each payment transaction is generated. The transaction number corresponding to each payment transaction is used as the primary key for querying, and the payment records, invoicing information, and transaction records corresponding to each payment transaction are stored as query values ​​in the end-to-end data lake. An adaptive grouping reconciliation strategy based on dynamic time windows is adopted to collect payment records, invoicing information and transaction records corresponding to the transaction dates to be checked in the full-link data lake as reconciliation data; The reconciliation data is verified for funds, and it is determined whether the fund verification passes. If not, then based on the reconciliation data, generate a reconciliation discrepancy verification prompt; The reconciliation discrepancy verification prompts are input into a pre-trained LLM model to diagnose reconciliation discrepancies and obtain a reconciliation verification report, which includes a diagnostic report and decision recommendations.

2. The method according to claim 1, characterized in that, An adaptive grouping reconciliation strategy based on dynamic time windows is adopted. Payment records, invoicing information, and transaction records corresponding to the transaction dates to be inspected are statistically analyzed in the end-to-end data lake to serve as reconciliation data, including: Determine whether there is a transaction record corresponding to a specified date in the end-to-end data lake, wherein the specified date is the date preceding the date of the transaction to be inspected; If not, then perform a transaction record retrieval in the full-link data lake until the transaction record that is before the date of the transaction to be inspected and has the shortest interval with the date of the transaction to be inspected is retrieved, and the date corresponding to the retrieved transaction record is used as the backtracking date; From the end-to-end data lake, filter out all transaction records that fall between the retrospective date and the date of the transaction to be inspected; Based on the primary key corresponding to all the selected transaction records, the payment records and invoicing information corresponding to each selected transaction record are retrieved from the full-link data lake. The reconciliation data is constructed by using the selected transaction records, as well as the corresponding payment records and invoicing information for each transaction record.

3. The method according to claim 2, characterized in that, Determining whether a transaction record corresponding to a specified date exists in the end-to-end data lake includes: If so, then filter out the transaction records corresponding to the transaction dates to be inspected from the end-to-end data lake as the target records; Based on the query primary key corresponding to the target record, the payment record and invoicing information corresponding to the target record are retrieved from the full-link data lake; The reconciliation data is composed of the target record, the corresponding payment record, and the invoicing information.

4. The method according to claim 1, characterized in that, Perform a fund verification on the reconciliation data to determine whether the fund verification passes, including: From the reconciliation data, filter out all payment records and all transaction records; Based on all the selected payment records, the total transaction amount is calculated, and based on all the selected transaction records, the total amount actually received by the bank is calculated. Determine whether the total transaction amount is the same as the total amount actually received by the bank; If yes, the funds verification is considered successful; otherwise, the funds verification is considered unsuccessful.

5. The method according to claim 1, characterized in that, Based on the reconciliation data, generate reconciliation discrepancy verification prompts, including: Context extraction is performed on the reconciliation data to obtain the transaction details, time range, and amount difference in the reconciliation data, as well as the unstructured summary text in the transaction records within the reconciliation data; Based on the transaction details, the time range, the amount difference, and the unstructured summary text, the reconciliation discrepancy verification prompt words are generated.

6. The method according to claim 1, characterized in that, The reconciliation discrepancy verification prompts are input into a pre-trained LLM model to diagnose reconciliation discrepancies and obtain a reconciliation verification report, including: Using the pre-trained LLM model, semantic parsing is performed on the reconciliation discrepancy verification prompt words to extract the implicit date and item features in the reconciliation discrepancy verification prompt words. The implicit date is a date in a non-standard format, and the item features are used to characterize the business type, expense account and / or financial intent. Convert the implicit date and the project characteristics into a feature vector; Based on feature vectors and a pre-set financial knowledge base, and using a pre-trained LLM model, the system performs reconciliation discrepancy reasoning and diagnosis to generate decision recommendations and structured diagnostic reports. The reconciliation and verification report is generated using the diagnostic report and the decision recommendations.

7. The method according to claim 1, characterized in that, After receiving the reconciliation and verification report, the method further includes: Store the reconciliation discrepancy verification prompts and the reconciliation verification report into a vector database; Based on a vector database and using the LoRA algorithm, the LLM model is incrementally fine-tuned to obtain an optimized LLM model, which can then be used for reconciliation discrepancy diagnosis.

8. The method according to claim 1, characterized in that, After receiving the reconciliation and verification report, the method further includes: In response to human-computer interaction requiring manual confirmation, the decision recommendations in the reconciliation and verification report are executed.

9. The method according to claim 1, characterized in that, The transaction serial number includes: transaction type code, merchant number, and timestamp. The transaction type code is generated based on payment records, the merchant number is generated based on invoicing information, and the timestamp is generated based on transaction records.

10. A multi-source payment business finance full-link reconciliation and discrepancy verification and processing system, characterized in that, include: The data acquisition layer is used to collect several payment records generated on the business side, several invoice information generated on the invoice side, and several transaction records generated on the bank side when executing payment business. The data acquisition layer is also used to generate a business transaction number for each payment transaction based on the payment record, invoice information and transaction record corresponding to each payment transaction, and to use the business transaction number corresponding to each payment transaction as the primary key for querying, and store the payment record, invoice information and transaction record corresponding to each payment transaction as the query value in the end-to-end data lake; The logic processing layer is used to employ an adaptive grouping reconciliation strategy based on dynamic time windows to statistically analyze the payment records, invoicing information, and transaction records corresponding to the transaction dates to be inspected in the end-to-end data lake, which will serve as reconciliation data. The logic processing layer is also used to perform fund verification on the reconciliation data and determine whether the fund verification passes. The intelligent analysis layer is used to generate reconciliation discrepancy verification prompts based on the reconciliation data when the logic processing layer determines that the fund verification has failed. The intelligent analysis layer is also used to input the reconciliation discrepancy verification prompts into a pre-trained LLM model to diagnose reconciliation discrepancies and obtain a reconciliation verification report, wherein the reconciliation verification report includes a diagnostic report and decision suggestions.

Images