Financial data automatic cancel-after-verification method and device, electronic equipment and medium

Abstract

The invention provides a financial data automatic cancel-after-verification method and device, electronic equipment and a medium, and is suitable for the fields of financial science and technology, medical service and data processing. The method comprises the steps of obtaining target account screening dimension information; based on the target account screening information and the account dimension information of each piece of account data in the account data pool, screening in the account data pool to obtain a plurality of pieces of account data to be canceled after verification; wherein the multiple pieces of account data to be cancelled after verification comprise account receivable data to be cancelled after verification and account payable data to be cancelled after verification; based on a preset dimension information matching rule and the account dimension information of each piece of account data to be cancelled after verification, identifying a group of target account data to be cancelled after verification from the plurality of pieces of account data to be cancelled after verification; wherein the target verification account data comprises at least one piece of to-be-verified account receivable data and at least one piece of to-be-verified account payable data; and cancel-after-verification processing is carried out on the target cancel-after-verification account data. According to the invention, automatic verification of financial data can be realized, and the financial management efficiency is improved.

Description

Technical Field

[0001] This application applies to the fields of financial technology, medical services, and data processing, and particularly relates to a method and apparatus, electronic device, and medium for automatic reconciliation of financial data. Background Technology

[0002] In modern service industries such as finance and healthcare, the operational activities of enterprises or institutions generate massive amounts of financial data. For example, in the financial sector, this involves accounts receivable and payable such as loans, repayments, and fees; in the healthcare sector, it involves frequent accounts receivable and payable settlements with patients, insurance companies, and pharmaceutical and equipment suppliers. A core aspect of these operations is the management and reconciliation of accounts receivable and accounts payable accounts. Accounts receivable accounts record amounts owed by a company for providing services and other business activities, while accounts payable accounts record amounts payable for purchasing goods and receiving services. By offsetting these two types of accounts, a company's assets and liabilities can be effectively managed.

[0003] In related technologies, the write-off process heavily relies on manual operations by finance personnel. Staff must manually sift through massive amounts of transaction documents to identify receivables and payables, and then manually match and offset them based on currency, summary, and other information. This traditional method is not only inefficient and cumbersome, but also highly susceptible to errors due to human negligence, posing a potential risk to the highly accurate financial and medical settlement sectors. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, electronic device, and medium for automatic reconciliation of financial data, aiming to achieve automatic reconciliation of financial data and improve the efficiency of financial management.

[0005] To achieve the above objectives, a first aspect of this application proposes an automatic financial data reconciliation method, the method comprising:

[0006] Obtain target account filtering dimension information;

[0007] Based on the target account filtering information and the account dimension information of each account in the account data pool, multiple accounts to be written off are obtained by filtering in the account data pool; wherein, the multiple accounts to be written off include accounts receivable data to be written off and accounts payable data to be written off.

[0008] Based on preset dimensional information matching rules and the account dimension information of each of the accounts to be written off data, a set of target accounts to be written off data is identified among the multiple accounts to be written off data; wherein, the target accounts to be written off data includes at least one accounts receivable data to be written off and at least one accounts payable data to be written off.

[0009] The target write-off accounts data are processed for write-off.

[0010] In some embodiments, the target account filtering information includes target transaction object information, target transaction category information, and target accounting time range; the account dimension information includes transaction object information, transaction category information, and transaction time information; and based on the target account filtering information and the account dimension information of each account data in the account data pool, multiple accounts to be written off are obtained by filtering in the account data pool, including:

[0011] The target transaction object information, target transaction category information, and target accounting time range are matched with the transaction object information, transaction category information, and transaction time information of each of the aforementioned accounts receivable data to obtain multiple accounts receivable data and accounts payable data to be written off;

[0012] A pool of accounts receivable and accounts payable to be written off is constructed based on the filtered data of multiple accounts receivable and accounts payable to be written off.

[0013] In some embodiments, the account receivable dimension information includes account receivable association identifiers and transaction currency information. The method of identifying a target set of account receivable data from multiple sets of account receivable data based on preset dimension information matching rules and the account receivable dimension information of each set of account receivable data includes:

[0014] Based on the account association identifier of each of the accounts to be written off data, a first round of matching is performed on the plurality of accounts to be written off data to identify at least one accounts receivable data and at least one accounts payable data to be written off with the same account association identifier as a group of target accounts to be written off data.

[0015] For the remaining accounts receivable data after the first round of matching, a second round of matching is performed according to the predefined matching conditions based on the transaction object information and the transaction currency information in the dimension information matching rules, so as to identify at least one accounts receivable data and at least one accounts payable data that meet the matching conditions as a set of target accounts receivable data.

[0016] In some embodiments, for the remaining accounts receivable data after the first round of matching, a second round of matching is performed according to the predefined matching conditions based on the transaction object information and the transaction currency information in the dimensional information matching rules, so as to identify at least one set of accounts receivable data and at least one set of accounts payable data that meet the matching conditions as a set of target accounts receivable data, including:

[0017] The remaining accounts receivable data to be written off are grouped according to transaction object information and transaction currency information to obtain multiple candidate accounts receivable data groups;

[0018] For each candidate write-off accounts data group, if it contains both the accounts receivable data to be written off and the accounts payable data to be written off, then the candidate write-off accounts data group is identified as a target write-off accounts data group.

[0019] In some embodiments, the accounts receivable dimension information further includes transaction summary information, and the method further includes, before identifying the candidate write-off accounts receivable data group as a set of target write-off accounts receivable data:

[0020] Extract relevant keywords from the transaction summary information of each of the accounts to be written off in the candidate write-off accounts data group;

[0021] Based on the extracted associated keywords, the accounts to be written off that have the same associated keywords within the candidate write-off accounts data group are identified as a subdivided write-off accounts group.

[0022] For each of the aforementioned subdivided write-off accounts group, if it contains both the accounts receivable data to be written off and the accounts payable data to be written off, then the subdivided write-off accounts group is identified as a set of target write-off accounts data.

[0023] In some embodiments, after processing the write-off of the target write-off accounts data, the method further includes:

[0024] Generate an automatic reconciliation log for the target reconciliation data;

[0025] In response to a query request for the target write-off data, the automatic write-off log is returned to the requesting terminal.

[0026] In some embodiments, after processing the write-off of the target write-off accounts data, the method further includes:

[0027] Based on the written-off accounts receivable data in the target write-off accounts receivable data, generate reversal voucher data;

[0028] The reversal voucher data is written back to the accounts receivable data pool from which the accounts receivable data is extracted.

[0029] To achieve the above objectives, a second aspect of this application provides an automatic financial data reconciliation device, the device comprising:

[0030] The acquisition module is used to obtain target account filtering dimension information;

[0031] The filtering module is used to filter multiple accounts receivable data to be written off from the accounts receivable data pool based on the target accounts receivable filtering information and the accounts receivable dimension information of each accounts receivable data in the accounts receivable data pool; wherein, the multiple accounts receivable data to be written off include accounts receivable data to be written off and accounts payable data to be written off.

[0032] The identification module is used to identify a set of target write-off accounts data from multiple write-off accounts data based on preset dimensional information matching rules and the account dimension information of each write-off accounts data; wherein, the target write-off accounts data includes at least one write-off accounts receivable data and at least one write-off accounts payable data.

[0033] The write-off processing module is used to perform write-off processing on the target write-off accounts data.

[0034] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0035] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0036] The financial data automatic reconciliation method, apparatus, electronic device, and medium proposed in this application include: acquiring target account receivable screening dimension information; filtering multiple accounts receivable data to be reconciled in the accounts receivable data pool based on the target account receivable screening information and the account receivable dimension information of each account receivable data in the accounts receivable data pool; wherein, the multiple accounts receivable data to be reconciled include accounts receivable data to be reconciled and accounts payable data to be reconciled; identifying a set of target reconciled accounts receivable data from the multiple accounts receivable data to be reconciled based on preset dimension information matching rules and the account receivable dimension information of each accounts receivable data to be reconciled; wherein, the target reconciled accounts receivable data includes at least one accounts receivable data to be reconciled and at least one accounts payable data to be reconciled; and performing reconciliation processing on the target reconciled accounts receivable data.

[0037] According to the automatic reconciliation method for financial data provided by this invention, the method first obtains target account screening dimension information. Then, based on the target account screening dimension information, it automatically filters the accounts receivable and payable data to be reconciled from the account data pool. This step changes the inefficient mode of existing technologies where financial personnel need to manually search and screen related accounts one by one among complex vouchers. This is particularly beneficial when processing the massive daily transaction volumes of financial institutions or cross-departmental settlement data in the medical system, greatly improving the efficiency and accuracy of data extraction. Subsequently, based on preset dimension information matching rules, the filtered account data is automatically identified and combined. For example, a large payment can be accurately matched to multiple small accounts receivable invoices, overcoming the drawbacks of manual operation being difficult to process quickly and prone to errors. Finally, the reconciliation process is automatically executed on the identified target reconciliation account data. This application, through a fully automated process of automatic screening, intelligent matching, and automatic execution, significantly improves the financial reconciliation and reconciliation capabilities in complex business scenarios, such as financial derivatives settlement and mixed payments of medical insurance and commercial insurance, ultimately achieving automatic reconciliation of financial data and improving financial management efficiency. Attached Figure Description

[0038] Figure 1 This is a flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application;

[0039] Figure 2 This is another flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application;

[0040] Figure 3 This is another flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application;

[0041] Figure 4 This is another flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application;

[0042] Figure 5 This is another flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application;

[0043] Figure 6 This is another flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application;

[0044] Figure 7 This is another flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application;

[0045] Figure 8 This is a schematic diagram of the structure of the automatic financial data reconciliation device provided in the embodiments of this application;

[0046] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0048] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0050] In modern service industries such as finance and healthcare, the operational activities of enterprises or institutions generate massive amounts of financial data. For example, in the financial sector, this involves accounts receivable and payable such as loans, repayments, and fees; in the healthcare sector, it involves frequent accounts receivable and payable settlements with patients, insurance companies, and pharmaceutical and equipment suppliers. A core aspect of these operations is the management and reconciliation of accounts receivable and accounts payable accounts. Accounts receivable accounts record amounts owed by a company for providing services and other business activities, while accounts payable accounts record amounts payable for purchasing goods and receiving services. By offsetting these two types of accounts, a company's assets and liabilities can be effectively managed.

[0051] In related technologies, the write-off process heavily relies on manual operations by finance personnel. Staff must manually sift through massive amounts of transaction documents to identify receivables and payables, and then manually match and offset them based on currency, summary, and other information. This traditional method is not only inefficient and cumbersome, but also highly susceptible to errors due to human negligence, posing a potential risk to the highly accurate financial and medical settlement sectors.

[0052] Based on this, embodiments of this application provide a method, apparatus, electronic device, and medium for automatic reconciliation of financial data, aiming to achieve automatic reconciliation of financial data and improve the efficiency of financial management.

[0053] The automatic reconciliation method, apparatus, electronic device, and medium for financial data provided in this application are specifically described through the following embodiments. First, the automatic reconciliation method for financial data in this application is described.

[0054] The automatic financial data reconciliation method provided in this application is applicable to the fields of fintech, medical services, and data processing. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the automatic financial data reconciliation method, but is not limited to the above forms.

[0055] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0056] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0057] Figure 1 This is an optional flowchart of the automatic reconciliation method for financial data provided in the embodiments of this application. Figure 1The method may include, but is not limited to, steps S101 to S105.

[0058] Step S101: Obtain target account filtering dimension information.

[0059] Step S102: Based on the target account filtering information and the account dimension information of each account in the account data pool, multiple accounts to be written off are obtained by filtering in the account data pool.

[0060] Step S103: Based on the preset dimension information matching rules and the account dimension information of each account to be reconciled, a set of target account reconciled data is identified among multiple account reconciled data.

[0061] Step S104: Perform write-off processing on the target write-off accounts data.

[0062] Steps S101 to S104, as illustrated in this embodiment, firstly, target account filtering dimension information is obtained. Next, based on the target account filtering dimension information, the accounts receivable and payable data to be reconciled are automatically filtered from the account data pool. This step changes the inefficient mode in the prior art where financial personnel need to manually search and filter related accounts one by one among complex vouchers. This is especially beneficial when processing the massive daily transaction volumes of financial institutions or cross-departmental settlement data in the medical system, greatly improving the efficiency and accuracy of data extraction. Subsequently, based on preset dimension information matching rules, the filtered account data is automatically identified and combined. For example, a large payment can be accurately matched to multiple small accounts receivable invoices, overcoming the drawbacks of manual operation being difficult to process quickly and prone to errors. Finally, the identified target account reconciliation data is automatically processed for reconciliation. This application significantly improves the ability to reconcile and verify financial data in complex business scenarios, such as financial derivatives settlement and mixed medical and commercial insurance payments, through a fully automated process of automatic screening, intelligent matching, and automatic execution. Ultimately, it enables the automatic verification of financial data and improves the efficiency of financial management.

[0063] In step S101 of some embodiments, the target accounts receivable screening dimension information is first obtained. The technical purpose of this step is to provide a flexible and configurable starting point for the entire automation method, enabling it to adapt to diverse financial accounting tasks. The "target accounts receivable screening dimension information" is a structured set of parameters that allows financial personnel to define the processing scope based on specific business scenarios (e.g., internal transaction reconciliation between specific subsidiaries, income and expenditure reconciliation of specific business lines, etc.). For example, within a financial group, financial personnel can input the company segment code of the counterparty, the account code of the transaction nature, and the target accounting period as dimension information. In the scenario of a medical group, if financial personnel are performing an accounts receivable / payable reconciliation between the central pharmacy and a member hospital (e.g., Hospital A) in a specific accounting period (e.g., the first quarter of 2025), the target accounts receivable screening dimension information can be specified as follows: the transaction object information is limited to "central pharmacy" and "Hospital A", the transaction category information is limited to "drug procurement and sales", and the target accounting time range is limited to "January 1, 2025 to March 31, 2025". This step enables the determination of filtering criteria for subsequent automated filtering of massive amounts of data.

[0064] In step S102 of some embodiments, based on the filtering information obtained in the previous step, multiple accounts receivable data to be reconciled are filtered out from the accounts receivable data pool. The core technology of this step lies in realizing the automated aggregation and targeted filtering of massive amounts of data. The "accounts receivable data pool" here is a logically unified data set that can be centrally queried by integrating and standardizing the raw accounts receivable data of multiple independent subsidiaries under the group (these subsidiaries may use different financial systems). The execution of this step is essentially to use the parameterized dimension information obtained in S101 as query conditions to perform a programmed data scan and matching on the data pool. Its purpose is to automatically separate a highly relevant subset from the full set of data, namely the "accounts receivable data to be reconciled", which includes all accounts receivable and accounts payable data that meet the conditions.

[0065] Please see Figure 2 In some embodiments, the target account screening information includes target transaction object information, target transaction category information, and target accounting time range, and the account dimension information includes transaction object information, transaction category information, and transaction time information. Step S102 may include, but is not limited to, steps S201 to S202.

[0066] Step S201: Match the target transaction object information, target transaction category information, and target accounting time range with the transaction object information, transaction category information, and transaction time information of each account data to multiple accounts receivable data and accounts payable data to be written off.

[0067] Step S202: Construct a pool of accounts receivable to be written off based on the multiple accounts receivable and accounts payable data to be written off obtained through filtering.

[0068] In step S201 of some embodiments, the target transaction object information, target transaction category information, and target accounting time range are matched with the transaction object information, transaction category information, and transaction time information of each account receivable data to filter out the accounts receivable and payable data to be written off. Specifically, using the target filtering dimensions obtained in S101 as a template, each record in the "accounts receivable data pool" is logically compared. For example, in a financial group scenario, for any account receivable data in the pool, its "transaction object information" is simultaneously verified to be a designated "securities company," its "transaction category information" is "transaction commission settlement," and its "transaction time information" falls within the target accounting time range of "second quarter of 2025." Only when all relevant dimensions of an account receivable data completely match the target filtering information will that data be selected. This step, through multi-condition AND logic, ensures the accuracy of the filtering results, accurately capturing all potentially relevant account receivable records from massive amounts of data.

[0069] In step S202 of some embodiments, the purpose of this step is to structurally aggregate the screening results from the previous step, forming a dedicated data workspace for subsequent processing. This "accounts receivable pool" can technically be an in-memory data structure or a temporary database table. It organizes the scattered records originally dispersed in the main data pool, filtered in S201, into a set. Taking a medical group scenario as an example, after S201 filters out all drug purchase and sales accounts between the central pharmacy and Hospital A in a specific month, S202 loads all these accounts receivable and payable records into this newly constructed "accounts receivable pool." The advantage of doing this is that subsequent intelligent matching (step S103) and other operations will be performed directly in this highly relevant data pool, without having to access the large and complex original "accounts data pool," thereby greatly improving processing efficiency.

[0070] Through steps S201 and S202, this embodiment achieves strict matching of multi-dimensional conditions, ensuring that every record extracted from the source data is highly relevant to the current reconciliation task, fundamentally guaranteeing the data quality for subsequent analysis. Next, it integrates and temporarily stores the filtered, fragmented data, creating an independent data environment. These two steps realize the transformation from "full data" to "target subset," effectively solving the data location problem in financial accounting under a big data context, laying the foundation for the efficient operation of more complex matching and reconciliation logics.

[0071] In step S103 of some embodiments, a set of target reconciliation accounts receivable data is identified from the accounts receivable data to be reconciled based on preset dimensional information matching rules. This step is the core technical link of this method to replace manual judgment and realize intelligent reconciliation. It automatically discovers the accounts receivable and accounts payable that truly correspond in business among many records to be reconciled through a set of algorithmic logic. The "preset dimensional information matching rules" is a set of configurable logical judgment sequences. Among them, the most efficient and reliable rule is based on strong matching of "accounts receivable association identifiers". An "accounts receivable association identifier" is an identifier that can uniquely mark the records of both the borrower and lender in a transaction when a transaction occurs. For example, an invoice number is a typical accounts receivable association identifier. When both accounts receivable and accounts payable records contain this same identifier, the rule can determine that they belong to the same transaction, thereby identifying them as a set of "target reconciliation accounts receivable data".

[0072] Please see Figure 3 In some embodiments, the account dimension information includes account association identifier and transaction currency information. Step S103 may include, but is not limited to, steps S301 to S302.

[0073] Step S301: Based on the account association identifier of each account receivable data to be written off, perform a first round of matching on multiple account receivable data to be written off, so as to identify at least one account receivable data to be written off and at least one account payable data to be written off as a set of target account receivable data to be written off.

[0074] Step S302: For the remaining accounts receivable data to be written off after the first round of matching, a second round of matching is performed according to the predefined matching conditions based on transaction object information and transaction currency information in the dimension information matching rules, so as to identify at least one accounts receivable data and at least one accounts payable data to be written off that meet the matching conditions as a set of target accounts receivable data to be written off.

[0075] In step S301 of some embodiments, the core technology lies in performing precise matching based on unique identifiers. Specifically, this involves traversing all records in the "Pending Write-off Pool" and grouping them based on the key field of "Accounts Related Identifier." When a group contains at least one accounts receivable record and at least one accounts payable record, it proves that these records are associated with the same unique business document (such as an invoice, contract, or settlement statement). To demonstrate its application, taking a medical group scenario as an example, if an accounts receivable record from the central pharmacy and an accounts payable record from Hospital A are found to have the exact same invoice number, they can be unambiguously identified as a set of target write-off accounts. This step prioritizes processing these most explicit matches, ensuring the highest accuracy in write-offs.

[0076] In step S302 of some embodiments, the technical objective of this step is to process relatively vague account records that lack unique identifiers. It infers matching relationships by combining multiple non-unique dimensions of information, thereby expanding the coverage of automatic write-offs. The technical implementation involves applying multi-dimensional matching rules to the records remaining after processing in S301. For example, in the scenario of a financial group, some internal commission settlements may not record a unified settlement number. In this case, the second round of matching rules can be set as follows: the remaining records are categorized according to "transaction object" (i.e., the combination of "securities company" and "asset management company") and "transaction currency" (e.g., "Japanese Yen"). Within these categories, if accounts receivable and payable records with the same or similar amounts and similar transaction dates are found, they can be identified as a new set of target write-off account data according to this preset rule.

[0077] Please see Figure 4 In some embodiments, step S302 may include, but is not limited to, steps S401 to S402.

[0078] Step S401: The remaining accounts receivable data to be written off are grouped according to the transaction object information and transaction currency information to obtain multiple candidate accounts receivable data groups.

[0079] Step S402: For each candidate write-off accounts data group, if it contains both accounts receivable data to be written off and accounts payable data to be written off, then the candidate write-off accounts data group is identified as a target write-off accounts data group.

[0080] In step S401 of some embodiments, "transaction object information" (i.e., the combination of the two parties to the transaction) and "transaction currency information" are used as the basis for grouping, and all pending write-off records with the same parties and the same currency are aggregated into the same logical container. For example, in the business scenario of a financial group, this step will group all remaining accounts receivable data between "securities companies" and "asset management companies" in "US dollars" into one group, and the records between them in "Japanese yen" into another group, thereby forming multiple clearly defined "candidate write-off accounts receivable data groups".

[0081] In step S402 of some embodiments, the technical purpose of this step is to screen the validity of each candidate group divided in the previous step, eliminating those data sets that do not have the possibility of write-off. Each candidate group generated in S401 is traversed, and the type composition of the records within the group is checked. A candidate group is considered a valid set that can proceed to the next matching process only if it simultaneously meets the conditions of "having at least one account receivable record" and "having at least one account payable record". If a candidate group contains only accounts receivable, it means that an offset cannot be formed within the group and it will be ignored. Conversely, if the group contains both accounts receivable and accounts payable, it proves that the group meets the basic conditions for write-off, and therefore the entire group is identified as "target write-off accounts receivable data".

[0082] This application embodiment constructs an efficient, two-stage heuristic matching preprocessing mechanism through steps S401 and S402. The grouping operation in step S401 technically performs a systematic data partitioning of the remaining unordered dataset based on key business dimensions. Following this, the verification operation in step S402 performs a logical validity verification on the partitioned data subsets, excluding subsets that do not meet the reimbursement conditions. This ensures that subsequent, more complex matching algorithms (such as matching based on amount or summary information) are only executed on a small, highly relevant, and logically valid dataset, thereby significantly reducing computational resource consumption and improving the efficiency and reliability of the second round of matching.

[0083] Please see Figure 5 In some embodiments, steps S501 to S503 may be included, but are not limited to, before identifying the candidate write-off data group as a set of target write-off data.

[0084] Step S501: Extract relevant keywords from the transaction summary information of each account to be written off in the candidate write-off data group.

[0085] Step S502: Based on the extracted related keywords, identify the write-off accounts data with the same related keywords within the candidate write-off accounts data group as a subdivided write-off accounts group.

[0086] Step S503: For each subdivided write-off accounts group, if it contains both accounts receivable data to be written off and accounts payable data to be written off, then the subdivided write-off accounts group is identified as a set of target write-off accounts data.

[0087] In step S501 of some embodiments, the core technology lies in applying text information extraction technology to mine structured information that can represent business relevance from unstructured text fields. This technology can be implemented based on a predefined rule base or dictionary, using methods such as regular expression matching and keyword searching to scan the "transaction summary" field. For example, in the business scenario of a financial group, the summary might contain text such as "payment of second-quarter commission for project A" or "payment regarding project A." This step accurately extracts project names or contract numbers, such as "project A," as "related keywords." This step provides a new, key dimension generated from the text for subsequent precise matching.

[0088] In step S502 of some embodiments, the technical purpose of this step is to perform a secondary division based on the business substance of the data that has been initially grouped by transaction object and currency. Within each "candidate write-off account data group" formed in S401, a further grouping operation is performed using "related keywords" as the key value. All records with the same extracted keyword will be aggregated together to form one or more "subdivided write-off account groups". Taking the financial field as an example, the original candidate group between "securities companies" and "asset management companies" with "US dollars" will be further subdivided into multiple smaller sets such as "Project A" group and "Project B" group through this step to enhance the business relevance within the group.

[0089] In step S503 of some embodiments, each subgroup generated in S502 is traversed, and the type of accounts receivable recorded within the group is checked. Taking a medical group scenario as an example, if a subgroup is formed based on the drug batch number "Batch A" in the summary, this step will verify whether the group contains both the central pharmacy's accounts receivable records for this batch of drugs and Hospital A's accounts payable records for this batch. Only when both types of records exist simultaneously in the finest-grained set "Batch A" is the subgroup ultimately confirmed as a set of "target write-off accounts receivable data" that can be executed for write-off.

[0090] This application's embodiments, through steps S501 to S503, address the problem of how to improve matching accuracy using unstructured summary information when structured fields (such as association identifiers) are missing. Step S501, keyword extraction, is a process of feature-enhancing unstructured text; step S502, secondary grouping, utilizes this new feature for deeper aggregation of related data; and step S503, final verification, ensures that only data subsets that form a closed loop at the business substance level (such as specific projects or batches) are confirmed as reimbursement targets. This mechanism significantly improves the accuracy of the second-round matching, deepening the matching dimension from counterparties and currencies to the business event level, thereby significantly improving the success rate of automated processing in complex scenarios and reducing anomalies requiring manual intervention.

[0091] This embodiment of the application constructs a hierarchical intelligent matching engine with high to low confidence through steps S301 and S302. Step S301, as the first layer, utilizes a unique "account association identifier" to achieve high-precision and deterministic identification of account relationships. It efficiently processes the easiest parts to reconcile, ensuring the absolute accuracy of the reconciliation results. Subsequently, step S302, as the second layer, uses multi-dimensional combination rules to supplement the matching for data that failed to match in the first round or had incomplete information. This hierarchical processing strategy technically balances accuracy and coverage. This progressive matching method from precise to fuzzy is significantly superior to a single matching model. It makes the entire automated reconciliation process both robust and comprehensive, maximizing the success rate of automated processing and effectively solving the problem of inconsistent data quality in real-world business.

[0092] In step S104 of some embodiments, it is necessary to accurately perform financial reversal accounting and convert the result of logical judgment into financial record changes containing detailed financial data. Specifically, for each group of identified target reversal accounts data, the process first needs to calculate the amount that can be reversed this time by comparing the reversible amount of accounts receivable and accounts payable within the group and taking the smaller value as the actual reversal amount for this operation. Subsequently, a series of field updates are performed on all relevant accounts receivable and accounts payable records within the group. Key operations include: adding the actual reversal amount to the "Reversed Amount" field of each record; and correspondingly deducting the "Reversible Amount" field. Based on the updated amount, the "Reversal Level" field of the record also needs to be dynamically adjusted. For example, if the "Reversible Amount" of a record becomes zero after this operation, its "Reversal Level" should be updated to "Fully Reversed"; if it is greater than zero but less than the original total, it should be updated to "Partially Reversed". Furthermore, to ensure audit traceability, a detailed write-off record can be generated. This record clearly records the primary keys of all accounts receivable and payable involved in the write-off, the specific amount of the write-off, the operation timestamp, and the execution batch number. This series of automated operations ensures that changes in financial status are reflected in the accounting system in a timely and accurate manner, and supports complex business scenarios such as partial write-offs. It avoids calculation or data entry errors that may be introduced by manual operations, ultimately completing the automated closed loop of the entire write-off process.

[0093] Please see Figure 6 In some embodiments, step S104 may be followed by, but is not limited to, steps S601 to S602.

[0094] Step S601: Generate an automatic reconciliation log for the target reconciliation data.

[0095] In step S602, in response to obtaining a query request for the target write-off account data, the automatic write-off log is returned to the requesting terminal.

[0096] In step S601 of some embodiments, a detailed audit log can be created for each automatically executed reconciliation operation to ensure the transparency and traceability of the process. Technically, after the reconciliation transaction is successfully submitted in step S104, a log data object is constructed. This object contains structured data with rich metadata, such as: a unique log ID, a timestamp of the reconciliation operation, an operation batch number, specific rules triggering the matching (e.g., a first-round matching based on "account association identifier" or a second-round matching based on specific conditions), and a snapshot of the target accounts receivable data being reconciled, including the primary keys of all involved accounts receivable and payable records and the exact amount of this reconciliation. This log data is then persistently stored in a log repository for subsequent review and retrieval.

[0097] In step S602 of some embodiments, a standardized data access interface can be provided, enabling relevant personnel (such as finance and audit personnel) to easily view and verify the results of automated reconciliation. The query service module can receive query requests from front-end applications or other systems. The request can include various filtering conditions, such as time range, transaction object, and reconciliation amount range. Based on these conditions, the module performs a query operation on the log database generated in S601, retrieving log records that meet the conditions. Finally, this structured log data is formatted into a readable report (such as a web table) or data format (such as JSON) and returned to the client terminal that initiated the request.

[0098] Please see Figure 7 In some embodiments, step S104 may be followed by, but is not limited to, steps S701 to S702.

[0099] Step S701: Generate reversal voucher data based on the written-off accounts data in the target write-off accounts data.

[0100] Step S702: Write the reversal voucher data back to the accounts receivable data pool from which the accounts receivable data was extracted.

[0101] In step S701 of some embodiments, the transaction information of the completed write-off is first extracted (including the parties to the transaction, the write-off amount, currency, summary, etc.), and a "write-off voucher data" object is constructed according to the structure of a general accounting voucher. This data object may contain voucher header information (such as voucher date, accounting period, voucher number) and voucher body information. The voucher body consists of standard debit and credit entries, for example, generating an accounting entry that debits the "Accounts Payable" account (to reduce liabilities) and credits the "Accounts Receivable" account (to reduce assets), both of which are the actual amount of this write-off.

[0102] In step S702 of some embodiments, the "reversal voucher data" object generated in S701 can be inserted into the "accounts receivable data pool" as a new record through a database write operation. After this "write-back" operation is completed, the "accounts receivable data pool" not only contains the original accounts receivable and accounts payable records, but also adds a formal reversal voucher that can offset them. Any subsequent accounting queries or report generation will show a complete, closed-loop transaction chain.

[0103] The financial data automatic reconciliation method, apparatus, electronic device, and medium proposed in this application include: acquiring target account receivable screening dimension information; filtering multiple accounts receivable data to be reconciled in the accounts receivable data pool based on the target account receivable screening information and the account receivable dimension information of each account receivable data in the accounts receivable data pool; wherein, the multiple accounts receivable data to be reconciled include accounts receivable data to be reconciled and accounts payable data to be reconciled; identifying a set of target reconciled accounts receivable data from the multiple accounts receivable data to be reconciled based on preset dimension information matching rules and the account receivable dimension information of each accounts receivable data to be reconciled; wherein, the target reconciled accounts receivable data includes at least one accounts receivable data to be reconciled and at least one accounts payable data to be reconciled; and performing reconciliation processing on the target reconciled accounts receivable data.

[0104] According to the automatic reconciliation method for financial data provided by this invention, the method first obtains target account screening dimension information. Then, based on the target account screening dimension information, it automatically filters the accounts receivable and payable data to be reconciled from the account data pool. This step changes the inefficient mode of existing technologies where financial personnel need to manually search and screen related accounts one by one among complex vouchers. This is particularly beneficial when processing the massive daily transaction volumes of financial institutions or cross-departmental settlement data in the medical system, greatly improving the efficiency and accuracy of data extraction. Subsequently, based on preset dimension information matching rules, the filtered account data is automatically identified and combined. For example, a large payment can be accurately matched to multiple small accounts receivable invoices, overcoming the drawbacks of manual operation being difficult to process quickly and prone to errors. Finally, the reconciliation process is automatically executed on the identified target reconciliation account data. This application, through a fully automated process of automatic screening, intelligent matching, and automatic execution, significantly improves the financial reconciliation and reconciliation capabilities in complex business scenarios, such as financial derivatives settlement and mixed payments of medical insurance and commercial insurance, ultimately achieving automatic reconciliation of financial data and improving financial management efficiency.

[0105] Please see Figure 8 This application also provides an automatic financial data reconciliation device, which can implement the above-mentioned automatic financial data reconciliation method. The device includes:

[0106] The acquisition module is used to obtain target account filtering dimension information;

[0107] The filtering module is used to filter multiple accounts receivable data to be written off from the accounts receivable data pool based on the target accounts receivable filtering information and the accounts receivable dimension information of each accounts receivable data in the accounts receivable data pool; wherein, the multiple accounts receivable data to be written off include accounts receivable data to be written off and accounts payable data to be written off.

[0108] The identification module is used to identify a set of target write-off accounts data from multiple write-off accounts data based on preset dimensional information matching rules and the account dimension information of each write-off accounts data; wherein, the target write-off accounts data includes at least one write-off accounts receivable data and at least one write-off accounts payable data.

[0109] The write-off processing module is used to perform write-off processing on the target write-off accounts data.

[0110] The specific implementation of the automatic financial data reconciliation device is basically the same as the specific implementation of the above-mentioned automatic financial data reconciliation method, and will not be repeated here.

[0111] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned automatic financial data reconciliation method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0112] Please see Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0113] The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0114] The memory 902 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 using the automatic financial data reconciliation method of the embodiments of this application.

[0115] The input / output interface 903 is used to implement information input and output;

[0116] The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0117] Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904);

[0118] The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0119] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described automatic financial data reconciliation method.

[0120] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0121] The financial data automatic reconciliation method, apparatus, electronic device, and medium proposed in this application include: acquiring target account receivable screening dimension information; filtering multiple accounts receivable data to be reconciled in the accounts receivable data pool based on the target account receivable screening information and the account receivable dimension information of each account receivable data in the accounts receivable data pool; wherein, the multiple accounts receivable data to be reconciled include accounts receivable data to be reconciled and accounts payable data to be reconciled; identifying a set of target reconciled accounts receivable data from the multiple accounts receivable data to be reconciled based on preset dimension information matching rules and the account receivable dimension information of each accounts receivable data to be reconciled; wherein, the target reconciled accounts receivable data includes at least one accounts receivable data to be reconciled and at least one accounts payable data to be reconciled; and performing reconciliation processing on the target reconciled accounts receivable data.

[0122] According to the automatic reconciliation method for financial data provided by this invention, the method first obtains target account screening dimension information. Then, based on the target account screening dimension information, it automatically filters the accounts receivable and payable data to be reconciled from the account data pool. This step changes the inefficient mode of existing technologies where financial personnel need to manually search and screen related accounts one by one among complex vouchers. This is particularly beneficial when processing the massive daily transaction volumes of financial institutions or cross-departmental settlement data in the medical system, greatly improving the efficiency and accuracy of data extraction. Subsequently, based on preset dimension information matching rules, the filtered account data is automatically identified and combined. For example, a large payment can be accurately matched to multiple small accounts receivable invoices, overcoming the drawbacks of manual operation being difficult to process quickly and prone to errors. Finally, the reconciliation process is automatically executed on the identified target reconciliation account data. This application, through a fully automated process of automatic screening, intelligent matching, and automatic execution, significantly improves the financial reconciliation and reconciliation capabilities in complex business scenarios, such as financial derivatives settlement and mixed payments of medical insurance and commercial insurance, ultimately achieving automatic reconciliation of financial data and improving financial management efficiency.

[0123] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0124] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0125] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0126] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

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

[0128] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0130] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0131] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0132] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a 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 all or part 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 multiple 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 of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0133] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for automatically reconciling financial data, characterized in that, The method includes: Obtain target account filtering dimension information; Based on the target account filtering information and the account dimension information of each account in the account data pool, multiple accounts to be written off are obtained by filtering in the account data pool; wherein, the multiple accounts to be written off include accounts receivable data to be written off and accounts payable data to be written off. Based on preset dimensional information matching rules and the account dimension information of each of the accounts to be written off data, a set of target accounts to be written off data is identified among the multiple accounts to be written off data; wherein, the target accounts to be written off data includes at least one accounts receivable data to be written off and at least one accounts payable data to be written off. The target write-off accounts data are processed for write-off.

2. The automatic reconciliation method for financial data according to claim 1, characterized in that, The target account filtering information includes target transaction object information, target transaction category information, and target accounting time range. The account dimension information includes transaction object information, transaction category information, and transaction time information. Based on the target account filtering information and the account dimension information of each account in the account data pool, multiple accounts to be written off are obtained by filtering from the account data pool, including: The target transaction object information, target transaction category information, and target accounting time range are matched with the transaction object information, transaction category information, and transaction time information of each of the aforementioned accounts receivable data to obtain multiple accounts receivable data and accounts payable data to be written off; A pool of accounts receivable and accounts payable to be written off is constructed based on the filtered data of multiple accounts receivable and accounts payable to be written off.

3. The automatic reconciliation method for financial data according to claim 2, characterized in that, The account receivable dimension information includes account receivable association identifiers and transaction currency information. Based on preset dimension information matching rules and the account receivable dimension information of each of the accounts receivable data to be reconciled, a set of target reconciled account receivable data is identified from multiple accounts receivable data to be reconciled, including: Based on the account association identifier of each of the accounts to be written off data, a first round of matching is performed on the plurality of accounts to be written off data to identify at least one accounts receivable data and at least one accounts payable data to be written off with the same account association identifier as a group of target accounts to be written off data. For the remaining accounts receivable data after the first round of matching, a second round of matching is performed according to the predefined matching conditions based on the transaction object information and the transaction currency information in the dimension information matching rules, so as to identify at least one accounts receivable data and at least one accounts payable data that meet the matching conditions as a set of target accounts receivable data.

4. The automatic reconciliation method for financial data according to claim 3, characterized in that, For the remaining accounts receivable data after the first round of matching, a second round of matching is performed according to the predefined matching conditions based on the transaction object information and the transaction currency information in the dimensional information matching rules. This is to identify at least one set of accounts receivable data and at least one set of accounts payable data that meet the matching conditions as a group of target accounts receivable data, including: The remaining accounts receivable data to be written off are grouped according to transaction object information and transaction currency information to obtain multiple candidate accounts receivable data groups; For each candidate write-off accounts data group, if it contains both the accounts receivable data to be written off and the accounts payable data to be written off, then the candidate write-off accounts data group is identified as a target write-off accounts data group.

5. The automatic reconciliation method for financial data according to claim 4, characterized in that, The accounts receivable dimension information also includes transaction summary information. Before identifying the candidate write-off accounts receivable data group as a target write-off accounts receivable data group, the method further includes: Extract relevant keywords from the transaction summary information of each of the accounts to be written off in the candidate write-off accounts data group; Based on the extracted associated keywords, the accounts to be written off that have the same associated keywords within the candidate write-off accounts data group are identified as a subdivided write-off accounts group. For each of the aforementioned subdivided write-off accounts group, if it contains both the accounts receivable data to be written off and the accounts payable data to be written off, then the subdivided write-off accounts group is identified as a set of target write-off accounts data.

6. The method according to claim 1, characterized in that, After processing the write-off of the target write-off accounts data, the method further includes: Generate an automatic reconciliation log for the target reconciliation data; In response to a query request for the target write-off data, the automatic write-off log is returned to the requesting terminal.

7. The automatic reconciliation method for financial data according to claim 1, characterized in that, After processing the write-off of the target write-off accounts data, the method further includes: Based on the written-off accounts receivable data in the target write-off accounts receivable data, generate reversal voucher data; The reversal voucher data is written back to the accounts receivable data pool from which the accounts receivable data is extracted.

8. An automatic financial data reconciliation device, characterized in that, The device includes: The acquisition module is used to obtain target account filtering dimension information; The filtering module is used to filter multiple accounts receivable data to be written off from the accounts receivable data pool based on the target accounts receivable filtering information and the accounts receivable dimension information of each accounts receivable data in the accounts receivable data pool; wherein, the multiple accounts receivable data to be written off include accounts receivable data to be written off and accounts payable data to be written off. The identification module is used to identify a set of target write-off accounts data from multiple write-off accounts data based on preset dimensional information matching rules and the account dimension information of each write-off accounts data; wherein, the target write-off accounts data includes at least one write-off accounts receivable data and at least one write-off accounts payable data. The write-off processing module is used to perform write-off processing on the target write-off accounts data.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the automatic reconciliation method for financial data 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 a computer program, characterized in that, when the computer program is executed by a processor, it implements the automatic reconciliation method for financial data as described in any one of claims 1 to 7.

Images