Information processing device, information processing system, and program
The information processing device enhances reconciliation by weighting and pattern detection, reducing manual effort and improving accuracy in matching claim and payment data, addressing inefficiencies and errors in existing methods.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- FUJIFILM BUSINESS INNOVATION CORP
- Filing Date
- 2022-01-27
- Publication Date
- 2026-04-21
AI Technical Summary
Existing reconciliation processes between claim data and payment data are inefficient and labor-intensive, especially when names do not match or total amounts are paid in lump sums, leading to increased manual workload and potential errors.
An information processing device that acquires and weights claim and payment data, calculates a 'degree of relevance' for each item, and extracts primary and secondary candidates for reconciliation, detecting incorrect processes based on patterns.
Reduces manual workload, improves accuracy, and detects errors before recording sales, presenting matched billing data patterns, thus minimizing unnecessary administrative work.
Smart Images

Figure 0007848489000001 
Figure 0007848489000002 
Figure 0007848489000003
Abstract
Description
Technical Field
[0001] The present invention relates to an information processing apparatus, an information processing system, and a program.
Background Art
[0002] Techniques for assisting the reconciliation process between a plurality of claim data and a plurality of payment data have been proposed conventionally (for example, Patent Document 1).
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] However, it cannot handle complex reconciliation processes such as when the name of the obligee included in the claim data does not match the name of the payer included in the payment data, or when the total amount for a plurality of claim data is paid in a lump sum. Therefore, individual reconciliation processing by the person in charge is required. However, when there are a large number of claim data (for example, thousands to tens of thousands of cases), the workload of the person in charge increases. Furthermore, if a mistake occurs during manual work, administrative follow-up (for example, refund processing, etc.) and follow-up to avoid loss of credibility (for example, apology by a supervisor, etc.) are required, and the burden on the person in charge becomes extremely large.
[0005] An object of the present invention is to reduce the burden of manual work in the reconciliation process between a plurality of claim data and a plurality of payment data more than before.
Means for Solving the Problems
[0006] The invention described in claim 1 comprises a processor, which acquires a plurality of claim data including at least information that can identify the claimant and the claim amount, and a plurality of payment data including at least information indicating the payer and the amount paid, and extracts claim data and payment data that were deemed unsuitable for the first reconciliation process from the plurality of claim data and the plurality of payment data as a reconciliation process to match and reconcile the plurality of claim data and the payment data, weights each item of information contained in each of the claim data and the payment data according to the degree of importance of each item, calculates a value indicating the degree of relevance of the information for each item based on the result of the weighting, and extracts the plurality of claim data from the claim data that are candidates for the second reconciliation process for each payment data based on the degree of relevance Then, based on the degree of relevance of the multiple pieces of information contained in each of the multiple billing data extracted as candidates for the second reconciliation process, a combination of billing data that will be a secondary candidate for the second reconciliation process is extracted from the multiple billing data. This is an information processing device characterized by the following: Claim 2 The invention described herein is characterized in that the processor extracts the plurality of claim data and combinations of the claim data based on a value indicating the degree of relevance calculated from the results of the first and second reconciliation processes. 1 This is the information processing device described above. Claim 3 The invention described is Equipped with a processor, The aforementioned processor, Multiple invoice data containing at least information that can identify the claimant and the invoiced amount, and multiple payment data containing at least information that indicates the payer and the amount paid, and from the multiple invoice data and multiple payment data, a reconciliation process is performed to match and reconcile the multiple invoice data and the multiple payment data, extracting invoice data and payment data that were deemed unsuitable for the first reconciliation process, weighting each item of information contained in each of the invoice data and payment data according to its degree of importance, calculating a value indicating the degree of relevance of the information for each item based on the weighting result, and based on the degree of relevance, extracting from the invoice data multiple invoice data that are candidates for the second reconciliation process for each payment data, This information processing device is characterized by estimating patterns of the invoice data and payment data from the results of the first and second reconciliation processes, and detecting incorrect reconciliation processes from the results of the second reconciliation process based on the results of the estimation. Claim 4The invention described herein includes an acquisition means for acquiring a plurality of claim data including at least information that can identify the claimant and the claim amount, and a plurality of payment data including at least information indicating the payer and the amount paid, an unreconcilable data extraction means for extracting claim data and payment data that are deemed unsuitable for the first reconciliation process, as a reconciliation process in which the plurality of claim data and the plurality of payment data are matched and reconciled, a calculation means for weighting each item of information contained in each of the claim data and the payment data according to the degree of importance of each item, and calculating a value indicating the degree of relevance of the information for each item based on the result of the weighting, a primary candidate extraction means for extracting a plurality of claim data from the claim data that will be primary candidates for the second reconciliation process for each of the payment data based on the degree of relevance, and each of the plurality of claim data extracted as primary candidates Multiple pieces of information included The information processing system is characterized by having a secondary candidate extraction means for extracting a combination of billing data that will be a secondary candidate for the second reconciliation process from among the plurality of billing data based on the degree of relevance of the above, and an output means for outputting the plurality of billing data extracted as the primary candidate and the combination of billing data extracted as the secondary candidate. The invention described in claim 5 includes an acquisition means for acquiring a plurality of claim data including at least information that can identify the claimant and the claim amount, and a plurality of payment data including at least information indicating the payer and the amount paid; an unreconcilable data extraction means for extracting claim data and payment data that are deemed unreconcilable in the first round of reconciliation processing, as a reconciliation process in which the plurality of claim data and the plurality of payment data are matched and reconciled; a calculation means for weighting each item of information contained in each of the claim data and the payment data according to the degree of importance of each item, and calculating a value indicating the degree of relevance of the information for each item based on the result of the weighting; and, based on the degree of relevance, for each payment data, the contents of the claim data The information processing system is characterized by comprising: a primary candidate extraction means for extracting a plurality of invoice data that will be primary candidates for the second reconciliation process; a secondary candidate extraction means for extracting a combination of invoice data that will be secondary candidates for the second reconciliation process from the plurality of invoice data extracted as primary candidates, based on the degree of relevance of each of the plurality of invoice data extracted as primary candidates; an output means for outputting the plurality of invoice data extracted as primary candidates and the combination of invoice data extracted as secondary candidates; and a detection means for estimating patterns of the invoice data and payment data from the results of the first and second reconciliation processes, and detecting incorrect reconciliation processes from the results of the second reconciliation process based on the results of the estimation. Claim 6The invention described herein includes a function for a computer to acquire a plurality of claim data including at least information that can identify the claimant and the claim amount, and a plurality of payment data including at least information indicating the payer and the amount paid, a function to extract claim data and payment data that were deemed unsuitable for the first reconciliation process from the plurality of claim data and the plurality of payment data, as a reconciliation process to match and reconcile the plurality of claim data and the payment data, a function to weight each item according to the degree of importance of each item of information contained in each of the claim data and the payment data, and to calculate a value indicating the degree of relevance of the information for each item based on the result of the weighting, and a function to extract a plurality of claim data from the claim data that are candidates for the second reconciliation process for each payment data based on the degree of relevance, A function to extract a combination of invoice data that will be a secondary candidate for the second reconciliation process from among the multiple invoice data extracted as candidates for the second reconciliation process, based on the degree of relevance of multiple pieces of information contained in each of the multiple invoice data extracted as candidates for the second reconciliation process, This is a program designed to achieve that. The invention described in claim 7 is a program for a computer to implement: a function to acquire a plurality of claim data including at least information that can identify the claimant and the claim amount, and a plurality of payment data including at least information that indicates the payer and the amount paid; a function to extract claim data and payment data that were deemed unsuitable for the first reconciliation process from the plurality of claim data and the plurality of payment data, as a reconciliation process in which the plurality of claim data and the payment data are matched and reconciled; a function to weight each item of information contained in each of the claim data and the payment data according to the degree of importance of each item, and to calculate a value indicating the degree of relevance of the information for each item based on the result of the weighting; a function to extract a plurality of claim data from the claim data that are candidates for the second reconciliation process for each payment data based on the degree of relevance; and a function to estimate the pattern of the claim data and the payment data from the results of the first and second reconciliation processes, and to detect incorrect reconciliation processes from the results of the second reconciliation process based on the result of the estimation. [Effects of the Invention]
[0007] According to the present invention as described in claim 1, an information processing device is provided that reduces the burden of manual work in the reconciliation process between multiple billing data and multiple payment data compared to conventional methods. Furthermore, since the "value indicating the degree of relevance" calculated for at least one item of the billing data and payment data is calculated based on the weighting results, practical reconciliation processing according to the importance of the information for each item becomes possible. Furthermore, it becomes possible to present users (billers) with combinations of billing data that match complex payment patterns. Claim 2 According to the present invention, a "value indicating the degree of relevance" is calculated based on the results of the first and second reconciliation processes, so the accuracy of the extraction results can be improved with each reconciliation process. Claim 3 According to the present invention, This information processing device reduces the manual workload involved in reconciling multiple invoice data and multiple payment data. Furthermore, since the "degree of relevance" calculated for at least one item in either the invoice data or payment data is based on weighting, practical reconciliation processing tailored to the importance of each item becomes possible.Since incorrect reconciliation processes can be detected from the reconciliation history, errors can be found before sales are recorded. As a result, unnecessary administrative work (such as correcting sales figures) can be reduced. Furthermore, because incorrect reconciliation processes are detected based on patterns estimated from the reconciliation history, errors can be detected with greater accuracy before sales are recorded. Claim 4 According to the present invention, an information processing system can be provided that reduces the manual workload in the reconciliation process between multiple billing data and multiple payment data compared to conventional methods. Furthermore, since the "value indicating the degree of relevance" calculated for at least one item of the billing data and payment data is based on the weighting results, practical reconciliation processing according to the importance of the information for each item becomes possible. Furthermore, it becomes possible to present users (billers) with combinations of billing data that match complex payment patterns. According to claim 5 of the present invention, an information processing system can be provided that reduces the burden of manual work in the reconciliation process between multiple billing data and multiple payment data compared to conventional methods. Furthermore, since the "value indicating the degree of relevance" calculated for at least one item of the billing data and payment data is based on the weighting results, practical reconciliation processing according to the importance of the information for each item becomes possible. In addition, incorrect reconciliation processing can be detected from the reconciliation processing results, so errors in processing can be found before sales are recorded. As a result, unnecessary administrative processing (e.g., correction of sales amounts) can be suppressed. Furthermore, since incorrect reconciliation processing can be detected based on patterns estimated from the reconciliation processing results, errors in processing can be detected with greater accuracy before sales are recorded. Claim 6 According to the present invention, a program is provided that reduces the manual workload involved in reconciling multiple billing data and multiple payment data compared to conventional methods. Furthermore, since the "value indicating the degree of relevance" calculated for at least one item of the billing data and payment data is based on the weighting results, practical reconciliation processing according to the importance of the information for each item becomes possible. Furthermore, it becomes possible to present users (billers) with combinations of billing data that match complex payment patterns. According to claim 7 of the present invention, a program is provided that reduces the manual workload in the reconciliation process between multiple billing data and multiple payment data compared to conventional methods. Furthermore, since the "value indicating the degree of relevance" calculated for at least one item of the billing data and payment data is based on the weighting results, practical reconciliation processing according to the importance of the information for each item becomes possible. In addition, since incorrect reconciliation processing is detected based on patterns estimated from the actual reconciliation processing, errors in processing before sales are recorded can be detected with greater accuracy. [Brief explanation of the drawing]
[0008] [Figure 1] This figure shows an example of the overall configuration of an information processing system to which this embodiment is applied. [Figure 2] This figure shows the hardware configuration of the management server as an information processing device to which this embodiment is applied. [Figure 3] This diagram shows the functional configuration of the control unit of the management server. [Figure 4] This diagram shows the functional configuration of the control unit of the user terminal. [Figure 5] This is a flowchart showing the processing flow of the management server. [Figure 6]It is a flowchart showing the processing flow of the user terminal. [Figure 7] It is a diagram showing a specific example of a combination of deposit data and billing data for which the first write-off process is successful. [Figure 8] It is a diagram showing a specific example of a combination of deposit data and billing data for which the first write-off process is not successful. [Figure 9] It is a diagram showing a specific example of billing data extracted as a candidate for the second write-off process from the billing data for which the first write-off process was not successful. [Figure 10] It is a diagram showing a specific example of a process of extracting a combination of billing data that becomes a secondary candidate from the primary candidates for the second write-off process. [Figure 11] It is a diagram showing a specific example of a user interface displayed on the display unit of the user terminal. [Figure 12] It is a diagram showing a specific example of information indicating the basis for extracting a combination of billing data that becomes a secondary candidate for the second write-off process displayed on the user interface. [Figure 13] It is a diagram showing a specific example of data to be the target of machine learning. [Figure 14] It is a diagram showing a specific example of calculating the confidence level using a machine learning model.
Embodiments for Carrying Out the Invention
[0009] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. (Configuration of Information Processing System) FIG. 1 is a diagram showing an example of the overall configuration of an information processing system 1 to which the present embodiment is applied. The information processing system 1 is configured by connecting a management server 10 and a user terminal 30 via a network 90. The network 90 is, for example, a LAN (Local Area Network), the Internet, or the like.
[0010] The management server 10 is an information processing device that acts as a server for managing the entire information processing system 1. For example, the management server 10 acquires information that can identify the person (hereinafter referred to as the "billed party") who is billed for the amount stated on the invoice (hereinafter referred to as the "billed amount"), and data related to multiple invoices that include at least the billed amount (hereinafter referred to as "billing data"). Examples of "information that can identify the billed party" include the name of the billed party, an ID assigned to each billed party, and a billing management number assigned to each piece of billing data.
[0011] Furthermore, for example, the management server 10 acquires information indicating the person who made a deposit into a predetermined account for payment of the invoiced amount (hereinafter referred to as "depositor"), and data on multiple deposits, including at least the deposit amount (hereinafter referred to as "deposit data"). Examples of "information indicating the depositor" include the name of the depositor, an ID assigned to each depositor, and the account number to which the deposit was made.
[0012] Furthermore, for example, the management server 10 performs the first reconciliation process by matching multiple invoice data with multiple payment data. The management server 10 then extracts the combinations of invoice data and payment data for which the first reconciliation process was successful, as well as the invoice data and payment data for which the first reconciliation process was unsuccessful. The acquired or extracted invoice data, payment data, and combinations of invoice data and payment data are stored and managed in the database of the storage unit 13 (see Figure 2), respectively.
[0013] Furthermore, for example, the management server 10 determines the degree of correlation between multiple pieces of information contained in the billing data that failed the first reconciliation process and multiple pieces of information contained in the payment data. Here, the billing data includes, in addition to the "information that can identify the billed party" and "billing amount" mentioned above, information such as the billing date and payment deadline. The payment data includes, in addition to the "information indicating the payer" and "payment amount" mentioned above, information such as the payment date.
[0014] Then, based on the results of the correlation assessment, the management server 10 extracts multiple invoice data from the invoice data that failed the first reconciliation process, for each payment data that failed the first reconciliation process, that are candidates for the second reconciliation process. Details of the processing performed by the management server 10 will be described later.
[0015] The user terminal 30 is an information processing device such as a personal computer, smartphone, or tablet terminal operated by the user as the requester. For example, the user terminal 30 displays a predetermined user interface on its display unit. Also, for example, the user terminal 30 acquires various information transmitted from the management server 10 or an external source and displays the acquired information on the user interface. Also, for example, the user terminal 30 receives information entered into the user interface and transmits it to the management server 10. Details of the processing performed by the user terminal 30 will be described later.
[0016] The functions of the management server 10 and user terminal 30 that constitute the information processing system 1 described above are merely examples, and the information processing system 1 as a whole only needs to have the functions to realize the above-described processing. For this reason, some or all of the functions that realize the above-described processing may be shared or collaborated within the information processing system 1. That is, some or all of the functions of the management server 10 may be functions of the user terminal 30, or some or all of the functions of the user terminal 30 may be functions of the management server 10. Furthermore, some or all of the functions of the management server 10 and user terminal 30 that constitute the information processing system 1 may be transferred to other servers, etc., not shown in the diagram. This will facilitate processing for the information processing system 1 as a whole, and it will also be possible for the processing to be complemented by each other.
[0017] (Management server hardware configuration) Figure 2 shows the hardware configuration of the management server 10, which is an information processing device to which this embodiment is applied. The management server 10 includes a control unit 11, a memory 12, a storage unit 13, a communication unit 14, an operation unit 15, and a display unit 16. These units are connected by a data bus, an address bus, a PCI (Peripheral Component Interconnect) bus, etc.
[0018] The control unit 11 is a processor that controls the functions of the user terminal 30 through the execution of various software such as the OS (operating system) and application software. The control unit 11 is composed of, for example, a CPU (Central Processing Unit). The memory 12 is a storage area that stores various software and data used for its execution, and is used as a work area during calculations. The memory 12 is composed of, for example, RAM (Random Access Memory).
[0019] The memory unit 13 is a memory area that stores input data for various software and output data from various software. The memory unit 13 is composed of, for example, an HDD (Hard Disk Drive), an SSD (Solid State Drive), or semiconductor memory used to store programs and various setting data. The memory unit 13 stores a database that stores various types of information.
[0020] The memory unit 13 stores databases such as: Invoice DB901, which stores all invoice data; Payment DB902, which stores all payment data; Unreconciled Invoice DB903, which stores invoice data for which reconciliation was unsuccessful; and Unreconciled Payment DB904, which stores payment data for which reconciliation was unsuccessful. It also stores Candidate DB905, which stores invoice data that is a candidate for a second reconciliation process; and Reconciliation Processing Results DB906, which stores the results of reconciliation processes, including combinations of invoice data and payment data for which the first or second reconciliation process was successful, and combinations of invoice data and payment data for which the first or second reconciliation process was unsuccessful. In addition, it stores Difference DB907, which stores the difference between the invoiced amount and the payment amount, such as transfer fees and consumption tax (hereinafter sometimes simply referred to as "fees"), and Model DB908, which stores machine learning models.
[0021] The communication unit 14 transmits and receives data between the management server 10 and the outside world via the network 90. The operation unit 15 consists of, for example, a keyboard, mouse, mechanical buttons, and switches, and accepts input operations. The operation unit 15 also includes a touch sensor that forms a touch panel integrally with the display unit 16. The display unit 16 consists of, for example, a liquid crystal display or an organic EL (=Electro Luminescence) display used for displaying information, and displays image and text data.
[0022] (User terminal hardware configuration) The hardware configuration of the user terminal 30 is the same as that of the management server 10 shown in Figure 2, so its illustration and explanation are omitted.
[0023] (Functional configuration of the control unit of the management server) Figure 3 shows the functional configuration of the control unit 11 of the management server 10. The control unit 11 of the management server 10 functions as follows: information acquisition unit 101, billing data management unit 102, payment data management unit 103, matching unit 104, matching result extraction unit 105, relationship determination unit 106, primary candidate extraction unit 107, secondary candidate extraction unit 108, transmission control unit 109, error detection unit 110, processing performance management unit 111, and model generation unit 112.
[0024] The information acquisition unit 101 acquires various types of information as an acquisition means. For example, the information acquisition unit 101 acquires input information transmitted from the user terminal 30. Examples of "input information" include billing data, information entered by the user to select information displayed in a selectable format, and information entered by the user to start processing on the management server 10. In addition, for example, the information acquisition unit 101 acquires deposit data transmitted from the user terminal 30 or from an external source (for example, a server managed by a financial institution).
[0025] The billing data management unit 102 stores and manages billing data in the billing DB 901 of the storage unit 13. For example, the billing data management unit 102 stores and manages billing data acquired by the information acquisition unit 101 in the billing DB 901. The payment data management unit 103 stores and manages payment data in the payment DB 902 of the storage unit 13. For example, the payment data management unit 103 stores and manages payment data acquired by the information acquisition unit 101 in the payment DB 902.
[0026] The matching unit 104 performs reconciliation processing of invoice data and payment data by matching the invoice data and payment data. The matching result extraction unit 105 extracts the results of the matching performed by the matching unit 104. For example, the matching result extraction unit 105 extracts combinations of invoice data and payment data for which the first reconciliation process was successful. Alternatively, for example, the matching result extraction unit 105 extracts invoice data and payment data for which the first reconciliation process was unsuccessful, as a means for extracting data that could not be reconciled.
[0027] The relationship determination unit 106 determines the degree of relationship between multiple pieces of information contained in each of the billing data and payment data extracted by the matching result extraction unit 105. For example, the relationship determination unit 106 determines this "degree of relationship" based on the reconciliation processing results stored in the reconciliation processing results DB 906.
[0028] Furthermore, the relevance determination unit 106 calculates a value indicating the "degree of relevance." Specifically, for example, the relevance determination unit 106 estimates patterns of billing data and payment data based on the reconciliation processing results stored in the reconciliation processing results DB 906, and calculates a "value indicating the degree of relevance" based on the results of that estimation. The "value indicating the degree of relevance" is calculated for each item of information contained in the billing data and payment data, respectively. Specific examples of the "value indicating the degree of relevance" will be described later with reference to Figure 9, etc.
[0029] Among the patterns of billing data and payment data estimated by the relevance determination unit 106, the billing data patterns include, for example, patterns of information that can identify the billed party, patterns of the billing amount, and patterns of the payment deadline. The payment data patterns include, for example, patterns of information that indicates the payer, patterns of the payment amount, and patterns of the payment date.
[0030] Furthermore, for example, the relevance determination unit 106 calculates a "value indicating the degree of relevance" based on the results of machine learning targeting the reconciliation processing results stored in the reconciliation processing results DB 906. Alternatively, for example, the relevance determination unit 106 calculates a "value indicating the degree of relevance" based on the results of weighting according to the degree of importance of each information item contained in the billing data and payment data, respectively. In this case, the "weighting" of each information item may be performed based on the results of machine learning by AI (artificial intelligence) or based on user input.
[0031] The primary candidate extraction unit 107, as a primary candidate extraction means, extracts multiple invoice data that will be primary candidates for the second reconciliation process from among the invoice data that failed the first reconciliation process, based on the result of the degree of relevance determination by the relevance determination unit 106, for each payment data for which the first reconciliation process was unsuccessful. For example, the primary candidate extraction unit 107 extracts multiple invoice data that will be primary candidates for the second reconciliation process based on the "value indicating the degree of relevance" calculated by the relevance determination unit 106. When the primary candidate extraction unit 107 extracts multiple invoice data that will be primary candidates for the second reconciliation process, it can use a machine learning model generated by the model generation unit 112, which will be described later.
[0032] The secondary candidate extraction unit 108, as a secondary candidate extraction means, extracts combinations of invoice data that will become secondary candidates for the second reconciliation process from among the multiple invoice data extracted as primary candidates. Specifically, the secondary candidate extraction unit 108 extracts combinations of invoice data that will become secondary candidates for the second reconciliation process based on the "value indicating the degree of relevance" calculated by the relevance determination unit 106. When the secondary candidate extraction unit 108 extracts combinations of multiple invoice data that will become secondary candidates for the second reconciliation process, it can use a machine learning model generated by the model generation unit 112, which will be described later.
[0033] The transmission control unit 109 controls the transmission of various information to the user terminal 30 or an external source via the communication unit 17. For example, the transmission control unit 109 controls the transmission of the results of the reconciliation process, which involves matching invoice data and payment data, to the user terminal 30. Specifically, for example, the transmission control unit 109 controls the transmission of combinations of invoice data and payment data for which the first reconciliation process was successful, invoice data and payment data for which the first reconciliation process was unsuccessful, and invoice data that are candidates for the second reconciliation process, etc., to the user terminal 30.
[0034] The error detection unit 110 detects incorrect reconciliation processes. For example, the error detection unit 110 detects incorrect reconciliation processes from the records of the first and second reconciliation processes based on the reconciliation process records stored in the reconciliation process record DB 906. Specifically, the error detection unit 110 estimates patterns of billing data and payment data from the reconciliation process records, and detects incorrect reconciliation processes based on the results of that estimation.
[0035] The processing performance management unit 111 stores and manages the results of the reconciliation process in a database. Specifically, the processing performance management unit 111 stores invoice data for which the reconciliation process was unsuccessful in the unreconciled invoice DB 903, stores payment data for which the reconciliation process was unsuccessful in the unreconciled payment DB 904, and stores and manages the reconciliation process results, including combinations of invoice data and payment data for which the reconciliation process was successful and combinations of invoice data and payment data for which the reconciliation process was unsuccessful, in the reconciliation process results DB 906.
[0036] The model generation unit 112 generates a machine learning model using the results of the reconciliation process stored in the database. Specifically, the model generation unit 112 performs preprocessing on the reconciliation process results stored in the reconciliation process results DB 906, and then generates a machine learning model using AI (artificial intelligence). Preprocessing includes, for example, noise removal, normalization, conversion of kanji and hiragana to katakana, and word embedding. The machine learning model is generated using methods such as pattern recognition models like SVM (Support Vector Machine), decision trees, and deep learning. The machine learning model generated by the model generation unit 112 is stored and managed in the database. Specifically, it is stored and managed in the model DB 908 of the storage unit 13.
[0037] (Functional configuration of the user terminal's control unit) Figure 4 shows the functional configuration of the control unit of the user terminal 30. The control unit of the user terminal 30 functions as follows: an information acquisition unit 301, a display control unit 302, an input operation reception unit 303, and a transmission control unit 304.
[0038] The information acquisition unit 301 acquires various types of information as an acquisition means. For example, the information acquisition unit 301 acquires billing data and payment data. Also, for example, the information acquisition unit 301 acquires the results of the reconciliation process, which is performed by matching billing data and payment data, that has been sent from the management server 10.
[0039] The display control unit 302 controls the display of various information on the display unit as a display means. For example, the display control unit 302 controls the display of a user interface on the display unit. The user interface can be displayed by launching dedicated application software for the user that is pre-installed on the user terminal 30, or by accessing a dedicated website for the user.
[0040] The display control unit 302 controls the display of the results of the reconciliation process, which is performed by matching the invoice data and payment data acquired by the information acquisition unit 301, on the user interface. For example, the display control unit 302 controls the display of combinations of invoice data and payment data for which the reconciliation process was successful on the user interface. Alternatively, for example, the display control unit 302 controls the display of invoice data and payment data for which the reconciliation process was unsuccessful on the user interface.
[0041] Furthermore, for example, the display control unit 302 controls the display of the billing data that are candidates for the second reconciliation process on the user interface. Specifically, the display control unit 302 controls the display of each combination of billing data that are primary candidates for the second reconciliation process and billing data that are secondary candidates for the second reconciliation process, which have been sent from the management server 10, in a manner that allows the user to compare them.
[0042] Here, "a configuration that allows users to compare" includes, for example, a configuration in which multiple billing data that are primary candidates for the second reconciliation process and combinations of billing data that are secondary candidates for the second reconciliation process are sorted in descending order, based on the "value indicating the degree of relevance" calculated by the management server 10. Specific examples of the combinations of multiple billing data that are primary candidates for the second reconciliation process and combinations of billing data that are secondary candidates for the second reconciliation process, as displayed on the user interface, will be described later with reference to Figure 11.
[0043] Furthermore, for example, the display control unit 302 controls the display of information on the user interface that indicates the basis for the combination extracted by the management server 10. This information can be displayed together with the combination of billing data that is the secondary candidate for the second reconciliation process, or it can be displayed separately from the combination of billing data that is the secondary candidate for the second reconciliation process. A specific example of the information displayed on the user interface that indicates the basis for the combination of billing data that is the secondary candidate for the second reconciliation process by the management server 10 will be described later with reference to Figure 12.
[0044] The input operation reception unit 303 accepts user input operations as a means of reception. For example, the input operation reception unit 303 accepts input operations to the user interface. Examples of input operations to the user interface include touch operations by the user's finger and click operations by a mouse.
[0045] The transmission control unit 304 controls the transmission of various information to the management server 10 or an external source via the communication unit. For example, the transmission control unit 304 controls the transmission of various information, such as billing data and payment data, acquired by the information acquisition unit 301, to the management server 10. Also, for example, the transmission control unit 304 controls the transmission of input information received by the input operation reception unit 303 to the management server 10.
[0046] (Processing by the management server) Figure 5 is a flowchart showing the processing flow of the management server 10. When billing data is sent from the user terminal 30 (YES in step 601), the management server 10 retrieves the sent billing data (step 602). If no billing data has been sent (NO in step 601), the management server 10 repeats step 601 until billing data is sent.
[0047] When the management server 10 receives deposit data from the user terminal 30 or an external source (YES in step 603), it retrieves the received deposit data (step 604). If no deposit data has been received (NO in step 603), the management server 10 repeats step 603 until deposit data is received.
[0048] The management server 10 performs the first reconciliation process for billing data and payment data by matching the billing data and payment data stored in the database (step 605). If there is any billing data or payment data for which the first reconciliation process was unsuccessful (YES in step 606), the management server 10 extracts the billing data and payment data for which the first reconciliation process was unsuccessful (step 607). Conversely, if there is no billing data or payment data for which the first reconciliation process was unsuccessful (NO in step 606), the management server 10 terminates the process, indicating that the first reconciliation process was successful without any problems.
[0049] The management server 10 determines the degree of correlation between multiple pieces of information contained in each of the billing data and payment data extracted in step 607 for which the first reconciliation process was unsuccessful (step 608). If it determines that there is billing data that can serve as a primary candidate for the second reconciliation process (YES in step 609), it extracts the billing data that can serve as a primary candidate for the second reconciliation process (step 610). Specifically, for each payment data for which the first reconciliation process was unsuccessful, multiple pieces of billing data that can serve as primary candidates for the second reconciliation process are extracted from the billing data for which the first reconciliation process was unsuccessful. On the other hand, if there is no billing data that can serve as a primary candidate for the second reconciliation process (NO in step 609), the management server 10 sends information to the user terminal 30 indicating that there is no billing data that can serve as a primary candidate for the second reconciliation process (step 611) and terminates the process.
[0050] If the management server 10 finds that there are combinations of invoice data that can serve as secondary candidates among the invoice data extracted as primary candidates for the second reconciliation process in step 610 (YES in step 612), it extracts combinations of invoice data that can serve as secondary candidates for the second reconciliation process (step 613) and sends the extracted combinations to the user terminal 30 (step 614). Specifically, combinations of invoice data that can serve as secondary candidates are extracted based on the degree of correlation of multiple pieces of information in each of the multiple invoice data extracted as primary candidates and sent to the user terminal 30. On the other hand, if there are no combinations of invoice data that can serve as secondary candidates for the second reconciliation process (NO in step 612), the management server 10 sends information to the user terminal 30 indicating that there are no combinations of invoice data that can serve as secondary candidates for the second reconciliation process (step 615) and terminates the process.
[0051] (Processing on the user terminal) Figure 6 is a flowchart showing the processing flow of the user terminal 30. In the example shown in Figure 6, it is assumed that the deposit data is sent from an external source (for example, a server managed by a financial institution) to the user terminal 30, rather than to the management server 10. If billing data is generated (YES in step 701), the user terminal 30 retrieves the generated billing data (step 702) and sends the retrieved billing data to the management server 10 (step 703). Conversely, if billing data is not generated (NO in step 701), the user terminal 30 repeats step 701 until billing data is generated.
[0052] Subsequently, when deposit data is sent from an external source (for example, a server managed by a financial institution) (YES in step 704), the user terminal 30 retrieves the received deposit data (step 705) and sends the retrieved deposit data to the management server 10 (step 706). If no deposit data has been sent (NO in step 704), the user terminal 30 repeats step 704 until deposit data is received.
[0053] Subsequently, the management server 10 extracts the invoice data and payment data for which the first reconciliation process was unsuccessful, and extracts the invoice data that will be the primary candidate for the second reconciliation process. When the invoice data extracted as the primary candidate for the second reconciliation process is sent (YES in step 707), the user terminal 30 retrieves the transmitted invoice data (step 708). However, if the invoice data extracted as the primary candidate for the second reconciliation process has not been sent (NO in step 707), the user terminal 30 repeats step 707 until the invoice data extracted as the primary candidate for the second reconciliation process is sent.
[0054] The user terminal 30 displays the billing data extracted as the primary candidate for the second reconciliation process, obtained in step 708, on the user interface (step 709). If an input operation is performed to display a combination of billing data that will be the secondary candidate for the second reconciliation process on the user interface (YES in step 710), the user terminal 30 accepts the input operation (step 711) and sends the input information to the management server 10 (step 712). If, however, no input operation is performed to display a combination of billing data that will be the secondary candidate for the second reconciliation process on the user interface (NO in step 710), the user terminal 30 repeats step 710 until the input operation is performed.
[0055] Subsequently, the management server 10 extracts combinations of invoice data that are secondary candidates for the second reconciliation process. When these extracted combinations of invoice data are sent (YES in step 713), the user terminal 30 retrieves the transmitted combinations of invoice data (step 714). However, if no combinations of invoice data extracted as secondary candidates for the second reconciliation process have been sent (NO in step 713), the user terminal 30 repeats step 713 until a combination of invoice data extracted as a secondary candidate for the second reconciliation process is sent.
[0056] If an input operation is performed to display the combination of billing data extracted as a secondary candidate for the second reconciliation process on the user interface (YES in step 715), the user terminal 30 accepts the input operation (step 716) and displays the combination of billing data extracted as a secondary candidate for the second reconciliation process, obtained in step 714, on the user interface (step 717). Conversely, if no input operation is performed to display the combination of billing data extracted as a secondary candidate for the second reconciliation process on the user interface (NO in step 715), the user terminal 30 repeats step 715 until the input operation is performed.
[0057] (Specific example) Figure 7 shows a specific example of a combination of payment data and invoice data that results in a successful first reconciliation process. The deposit data shown in Figures 7(A) and (B) includes the "Deposit Date," which indicates the date the deposit was processed; the "Account Number," which indicates the recipient's account; the "Deposit Notification Name," which indicates the name of the depositor's account or the name entered at the time of transfer; and the "Deposit Notification Amount," which indicates the amount deposited. The invoice data includes the "Invoice Amount," which indicates the invoice amount; the "Invoice Date," which indicates the invoice date stated on the invoice; the "Payment Due Date," which indicates the payment deadline for the invoice amount; the "Invoice Management Number," which is assigned to each invoice data as unique identification information; and the "Customer Name," which indicates the recipient of the invoice.
[0058] Figure 7(A) shows a specific example of a combination of payment data and invoice data in which the first reconciliation process succeeds because the "payment notification name" in the payment data and the "customer name" in the invoice data are considered to match. At first glance, there is a discrepancy between the payment notification name "Fuji(ka)" in the payment data and the customer name "Fuji Co., Ltd." in the invoice data. However, in the reconciliation process by matching the two data, the following processing is performed based on predetermined rules, and the reconciliation process succeeds.
[0059] In other words, the payment notification name "Fuji(ka)" is split into "Fuji" and "(ka)", and the customer name "Fuji Co., Ltd." is split into "Fuji" and "Co., Ltd.". Of these, "(ka)" in the payment notification name and "Co., Ltd." in the customer name are both determined to be standard characters indicating a company and are deleted. Also, "Fuji" in the customer name is converted to the katakana spelling "Fuji". As a result, a match is found between the payment notification name "Fuji" and the customer name "Fuji", and the reconciliation process is successful.
[0060] Figure 7(B) shows a specific example of a combination of payment data and invoice data in which the first reconciliation process is successful because the "payment notification amount" in the payment data and the "invoiced amount" in the invoice data are considered to match. At first glance, looking at the payment data and invoice data in Figure 7(B), there is a discrepancy between the payment notification amount of "1,080,037" yen in the payment data and the invoiced amount of "1,079,927" yen in the invoice data. However, in the reconciliation process by matching the two data, the following process is performed based on predetermined rules, and the reconciliation process is successful.
[0061] In other words, there is a difference of 110 yen between the payment notification amount of 1,080,037 yen and the invoiced amount of 1,079,927 yen. This difference is considered to be the sum of the predetermined fee (110 yen). As a result, the amount obtained by subtracting the difference of 110 yen from the payment notification amount of 1,080,037 yen, which is 1,079,927 yen, matches the invoiced amount of 1,079,927 yen, and the reconciliation process is successful.
[0062] This difference of "110" yen is stored and managed in the difference DB907 in the storage unit 13 of the management server 10. In addition to "110" yen, other fee patterns such as "220" yen, "275" yen, and "330" yen are also pre-stored in the difference DB907. Specific examples of the differences stored in the difference DB907 will be described later with reference to Figure 10.
[0063] Figure 8 shows a specific example of a combination of payment data and invoice data that fails to complete the first reconciliation process. The deposit data shown in Figures 8(A) and 8(B), respectively, includes "Deposit Date," "Account Number," "Deposit Notification Name," and "Deposit Notification Amount," similar to the example in Figure 7. Similarly, the billing data includes "Billing Amount," "Billing Date," "Payment Commitment Date," "Billing Management Number," and "Customer Name."
[0064] Figure 8(A) shows a specific example of a combination of payment data and invoice data in which the first reconciliation process fails because the "payment notification name" in the payment data and the "customer name" in the invoice data are not considered to match. As shown in the payment data and invoice data in Figure 8(A), there is a discrepancy between the payment notification name "Fuji(Ka)" in the payment data and the customer name "Fuji Chiba Office" in the invoice data. In this case, the reconciliation process by matching the two data will perform the following processing based on predetermined rules, similar to the example in Figure 7(A), but the reconciliation process will not succeed.
[0065] In other words, similar to the example in Figure 7(A), the payment notification name "Fuji(Ka)" is split into "Fuji" and "(Ka)", and the customer name "Fuji Chiba Office" is split into "Fuji" and "Chiba Office". While "(Ka)" in the payment notification name is determined to be a standard character indicating a corporation, "Chiba Office" in the customer name is not determined to be a standard character indicating a corporation. Therefore, no match is found, and the reconciliation process fails. As a result, manual reconciliation is required.
[0066] Figure 8(B) shows a specific example of a combination of payment data and invoice data where the relationship between the payment data and the invoice data is 1:n (where n is an integer greater than or equal to 2), resulting in the first reconciliation process failing. Normally, payment data and invoice data have a 1:1 relationship, but some payers may make payments for multiple invoices in a single batch to save on transfer fees or to simplify payment procedures. Hereafter, this method of payment will be referred to as "lump-sum payment."
[0067] In the example in Figure 8(B), there are three invoice data entries: one with the customer name "Fuji Co., Ltd." and an invoice amount of "21,672" yen; one with the customer name "Fuji Co., Ltd." and an invoice amount of "929,134" yen; and one with the customer name "Fuji Chiba Office" and an invoice amount of "129,121" yen. For each of these, there is one payment data entry where the payment notifier is "Fuji(ka)" and the payment amount is "1,079,927" yen.
[0068] In this case, the total amount of the invoices for the three invoice data, "1,079,927 yen," matches the payment notification amount of "1,079,927 yen" in the payment data. Furthermore, for the invoice data where the customer name is "Fuji Co., Ltd." and the two invoice data where the customer name is "Fuji Corporation," the match between the payment notification name and the customer name is recognized for the same reasons as in Figure 7(A). However, for the invoice data where the customer name is "Fuji Chiba Office," the match between the "payment notification name" and the "customer name" is not recognized, similar to the example in Figure 8(A) above. As a result, the reconciliation process is unsuccessful, and manual reconciliation is required.
[0069] Figure 9 shows a specific example of invoice data extracted as a candidate for a second reconciliation process from invoice data for which the first reconciliation process was unsuccessful. Figure 9 shows a specific example of invoice data extracted as primary candidates for the second reconciliation process from invoice data that failed the first reconciliation process. As shown in Figure 9, the top 10 invoice data extracted as primary candidates for the second reconciliation process are listed in descending order of the "value indicating the degree of relevance" estimated by the management server 10. Note that in the specific examples shown in Figures 9 to 14, the "degree of confidence," which is expressed as a percentage of the "value indicating the degree of relevance," is used.
[0070] For example, the invoice data ranked "1st" due to the highest confidence level has an invoice amount of "21,672" yen, a customer name of "Fuji Co., Ltd.", and a confidence level of "0.98". The invoice data ranked "2nd" has an invoice amount of "10,001" yen, a customer name of "Fuji Electric Wire Industry Co., Ltd.", and a confidence level of "0.97". Also, for example, the invoice data ranked "3rd" has an invoice amount of "929,134" yen, a customer name of "Fuji Co., Ltd.", and a confidence level of "0.95". The invoice data ranked "4th" has an invoice amount of "129,121" yen, a customer name of "Fuji Co., Ltd.", and a confidence level of "0.93". Invoice data ranked 5th or lower are shown in Figure 9. Users can reduce the burden of manual reconciliation by referring to the list of primary candidates shown in Figure 9.
[0071] Figure 10 shows a specific example of the process of extracting combinations of invoice data that will become secondary candidates from the primary candidates for the second reconciliation process. The management server 10 performs a process to extract combinations of invoice data that will become secondary candidates from the primary candidates for the second reconciliation process (secondary candidate extraction process in Figure 10). First, it calculates the combinations of m invoice data (where m is an integer value of 2 or greater) that were extracted as primary candidates. For example, in the example in Figure 9 above, 10 invoice data were extracted as primary candidates, so calculations are performed for 1023 combination patterns.
[0072] Next, the management server 10 compares the payment notification amount of the payment data with the billing amount of each billing data and the difference stored in the database. In the example in Figure 10, 11 patterns of fees are shown as examples of differences stored in the difference DB 907. By comparing with the information stored in the difference DB 907, it becomes possible to perform calculations that take into account the difference (for example, fees) that may be included in the payment notification amount of the payment data. Note that there are cases where the difference is included in the payment notification amount of the payment data and cases where it is not included (for example, cases where the transfer fee is free).
[0073] Next, the management server 10 calculates the average confidence score of the combination of billing data extracted as secondary candidates. For example, suppose that from the 10 primary candidates (see Figure 9) extracted as primary candidates for reconciliation processing by matching with payment data (payment notification amount "1,079,927"), a combination of billing data ranked 1st, 3rd, and 4th is extracted as a secondary candidate. In this case, the average of the confidence scores of the billing data ranked 1st (0.98), the 3rd (0.95), and the 4th (0.93) is calculated as 0.953.
[0074] Furthermore, suppose, for example, that combinations of billing data ranked 1st, 3rd, 5th, and 6th are extracted. In this case, the average of the confidence scores of the billing data ranked 1st (0.98), 3rd (0.95), 5th (0.91), and 6th (0.88) is calculated (0.93). Note that in the example in Figure 10, these two types of billing data combinations were extracted as secondary candidates.
[0075] Next, the management server 10 sorts the combinations of billing data extracted as secondary candidates in descending order of average confidence score, and assigns a "combination rank" to the combinations with the highest average confidence score, ranking them 1st and 2nd. In the example in Figure 10, the above two types of combinations have been extracted, so the combination of billing data with an average confidence score of "0.953" (combinations of billing data with estimated ranks 1st, 3rd, and 4th) is assigned a combination rank of 1st, and the combination of billing data with an average confidence score of "0.93" (combinations of billing data with estimated ranks 1st, 3rd, 5th, and 6th) is assigned a combination rank of 2nd. The list of secondary candidates to which combination ranks have been assigned is displayed in the user interface.
[0076] Figure 11 shows a specific example of a user interface displayed on the user terminal's display unit. Once the combinations of invoice data that are secondary candidates for the second reconciliation process are extracted and assigned a ranking, a list of these combinations is displayed in the user interface. As an example, Figure 11 shows the combinations of payment data subject to reconciliation and the secondary candidates for invoice data in the user interface. In the information displayed in the user interface shown in Figure 11, under the notation "Payment information subject to reconciliation," the content of the payment data subject to reconciliation is shown. Also, under the notation "List of invoice reconciliation candidates," the content of the combinations of invoice data that are secondary candidates for reconciliation is shown, ranked by combination ranking.
[0077] The user, referring to the content of the payment data to be reconciled and the content of the secondary candidate combinations of invoice data displayed on the user interface, selects the combination of invoice data to be reconciled by pressing button T2 or T3 labeled "Select" and then pressing button T1 labeled "Execute". This triggers a second reconciliation process by matching the payment data with the selected combination of invoice data. This reduces the burden of manual reconciliation on the user.
[0078] Figure 12 shows a specific example of the information displayed in the user interface that indicates the basis for extracting combinations of billing data that are secondary candidates for the second reconciliation process. If a user wants to know the basis for extracting a combination of billing data that has been extracted as a secondary candidate for the reconciliation process, they can have this information displayed and referenced in the user interface. As an example, Figure 12 shows a graph representing the degree of importance (hereinafter referred to as "importance") for each type of information in the billing data used as the basis for the extraction.
[0079] The graph shown in Figure 12 has "importance" on the horizontal axis (maximum value of 100) and "type of information" on the vertical axis. As shown in Figure 12, among the information included in the billing data, the information with the highest importance setting is "customer name," and the information with the second highest importance setting is "billing amount." The information with the third highest importance setting is "payment due date." In other words, in the example in Figure 12, when extracting secondary candidates, the degree of correlation between the "payment notification name" in the payment data and the "customer name" in the billing data was given the most importance. "Importance" is basically set by the AI (artificial intelligence) to serve as the basis for extracting secondary candidates, but it can also be set in advance by the user.
[0080] Figure 13 shows a specific example of data that will be used for machine learning. As described above, the management server 10 determines the "degree of relevance" of the information contained in the payment data and billing data based on the reconciliation processing results stored in the reconciliation processing results DB 906. Specifically, a machine learning model generated by AI (artificial intelligence) learning targeting the reconciliation processing results is stored in the database (for example, the model DB 908 in Figure 2), and the determination is made using this machine learning model. The reconciliation processing results that are the target of machine learning are stored in the database (for example, the reconciliation processing results DB 906 in Figure 2) in the form of data as shown in Figure 13, for example.
[0081] In the data shown in Figure 13, data area d stores the following information from the payment data: "payment date," "account number," "payment type," "payment notification name," and "payment notification amount." Of these, "payment type" refers to the payment method, and contains coded information such as bank transfer and direct debit. Data area b stores the following information from the billing data: "billing amount," "account number," "payment promise date," "billing management number," and "customer name." Of these, "account number" refers to the account number specified as the recipient account at the time of billing.
[0082] Furthermore, in the data shown in Figure 13, data area j stores information indicating whether the combination of payment data stored in data area d and invoice data stored in data area b is correct or incorrect for matching. Of these, combinations of payment data and invoice data that are determined to be correct for matching are recorded as "1", and combinations of payment data and invoice data that are determined to be incorrect for matching are recorded as "0".
[0083] For example, in the data shown in Figure 13, the data stored in the first row does not match the "payment notification amount" and the "invoiced amount," but the result of the judgment is "1," indicating that it is a correct match. In other words, it indicates that there is a record of a lump-sum payment being made for multiple invoices.
[0084] Figure 14 shows a specific example of calculating confidence using a machine learning model. As described above, the generated machine learning model is stored in the model DB908 of the storage unit 13 of the management server 10, and when extracting billing data that will be the primary candidate for the second reconciliation process, the machine learning model calculates the confidence level for each billing data.
[0085] The form of the generated machine learning model is not particularly limited, but for example, the machine learning model can be generated as a single function. In this case, the management server 10 learns the reconciliation process data stored in the reconciliation process data DB 906 and adjusts the parameters of the machine learning model to generate a single function for calculating the confidence score. If the variables input to the generated single function are a combination of "payment data" and "invoice data", and the confidence score output from that function f(payment data, invoice data) is Y, then it can be expressed by the formula Y=f(payment data, invoice data), 0<=Y<=1. The output Y (confidence score) will be a decimal value between incorrect "0" and correct "1".
[0086] Specifically, during the learning phase in which the management server 10 learns the results of the reconciliation process, the parameters of the function f(payment data, invoice data) are adjusted. This enables the management server 10 to perform highly accurate estimations during the estimation phase in which it calculates the confidence level.
[0087] In this embodiment, deep learning, one of the representative machine learning methods, can be used during the learning phase. Deep learning is a method that enhances learning ability by connecting multiple neural networks, which are mathematical models that mimic a part of the neural circuit of the brain, in a multi-layered manner. The value obtained by multiplying multiple parameters (weight parameters) W, which are coefficients used in the connection, is input to the neurons in the output layer.
[0088] For the sake of simplicity, if we consider the function f(deposit data, invoice data) as the simplest linear model and set the weight parameters to "W deposit data" and "W invoice data", the following adjustments are made during the learning phase. That is, for example, the weight parameters of the function f(deposit data, invoice data) are adjusted as follows: correct answer "1" = W deposit data × deposit data Da + W invoice data × invoice data Ba, correct answer "1" = W deposit data × deposit data Db + W invoice data × invoice data Bb, incorrect answer "0" = W deposit data × deposit data Da + W invoice data × invoice data Bb, incorrect answer "0" = W deposit data × deposit data Dc + W invoice data × invoice data Ba.
[0089] Suppose that during the learning phase, the weight parameters are adjusted to values such as "0.7" for W payment data and "0.3" for W invoice data. In this case, Y (confidence) = f(payment data, invoice data) = 0.7 × payment data + 0.3 × invoice data. Note that in this formula, for the sake of simplicity, there is only one weight parameter, but in reality, since each of the payment data and invoice data consists of multiple pieces of information, multiple weight parameters are adjusted.
[0090] Next, in the estimation phase where the management server 10 calculates the confidence score, the confidence score for each combination of unknown payment data and billing data is calculated using a function f(payment data, billing data) whose weight parameters (W payment data and W billing data) are fixed by the adjustments made during the learning phase. Specifically, the confidence score for each combination of unknown payment data and billing data is calculated by substituting the unknown payment data and billing data into the above formula. For example, if the unknown payment data is "0.5" and the unknown billing data is "1", then Y(confidence score) = f(payment data, billing data) = 0.7 × 0.5 + 0.3 × 1 = 0.65.
[0091] In calculating the confidence score, for example as shown in Figure 14, machine learning is performed on the "Deposit Date" in deposit data D and the "Payment Commitment Date" in invoice data B (i.e., date learning); on the "Account Number" in deposit data D and the "Account Number" in invoice data B (i.e., account number learning); on the "Deposit Notification Name" in deposit data D and the "Customer Name" in invoice data B (i.e., name matching learning); and on the "Deposit Notification Amount" in deposit data D and the "Invoice Amount" in invoice data B (i.e., amount learning).
[0092] In the "Date Learning" section, for example, the system learns the actual "Payment Date" in the payment data, and the actual number of days between the "Payment Date" in the payment data and the "Payment Due Date" in the invoice data. Specifically, it learns things like whether payments are made at the end of each month, and whether the number of days between the "Payment Date" and the "Payment Due Date" each month is between 1 and 3 business days. In the "Account Number Learning" section, the system learns whether the "Account Number" in the payment data matches or does not match the "Account Number" in the invoice data. Specifically, for example, if there is a record of a lump-sum payment, there will be cases where the "Account Number" in the payment data and the "Account Number" in the invoice data do not match, and this record is learned.
[0093] Also, in "learning the name consistency", the performance of the match or mismatch between the "payment notice name" in the payment data and the "customer name" in the billing data is learned. Specifically, for example, when there are fluctuations in the monthly billing data, such as the difference between "Corporation" and "(Inc.)" included in the "customer name" of the billing data, that performance is learned. Also, in "learning the amount", the performance of the match or mismatch between the "payment notice amount" in the payment data and the "billing amount" in the billing data is learned. Specifically, for example, when there is a record of lump-sum payment, a difference will occur between the "payment notice amount" in the payment data and the "billing amount" in the billing data, so that performance and the like are learned.
[0094] As described above, this embodiment has been explained, but the present invention is not limited to the above-described embodiment. Also, the effects of the present invention are not limited to those described in the above-described embodiment. For example, the configuration of the information processing system 1 shown in FIG. 1 and the hardware configuration of each of the management servers 10 shown in FIG. 2 are merely examples for achieving the object of the present invention and are not particularly limited. Also, the functional configuration of the management server 10 shown in FIG. 3 and the functional configuration of the user terminal 30 shown in FIG. 4 are merely examples and are not particularly limited. It is sufficient that the information processing system 1 in FIG. 1 is provided with a function capable of executing the above-described processing as a whole, and the functional configuration used to realize this function is not limited to the examples in FIGS. 3 and 4.
[0095] Also, the order of the steps of the processing of each of the management server 10 and the user terminal 30 shown in FIGS. 5 and 6 is merely an example and is not particularly limited. Not only the processing performed in time series along the illustrated order of steps, but also the processing may be performed in parallel or individually without necessarily being processed in time series. Also, the specific examples shown in FIGS. 7 to 14 are merely examples and are not particularly limited.
[0096] Furthermore, in the above-described embodiment, the user interface is configured to display a list of primary candidate billing data for the second reconciliation process and a list of secondary candidate billing data combinations. However, the system is not limited to this configuration. For example, the user interface may be configured to display a list of primary candidate billing data only when no secondary candidate billing data combinations are extracted. [Explanation of Symbols]
[0097] 1...Information processing system, 10...Management server, 11...Control unit, 30...User terminal, 90...Network, 101...Information acquisition unit, 102...Invoice data management unit, 103...Payment data management unit, 104...Matching unit, 105...Matching result extraction unit, 106...Relevance determination unit, 107...Primary candidate extraction unit, 108...Secondary candidate extraction unit, 109...Transmission control unit, 110...Error detection unit, 111...Processing performance management unit, 112...Model generation unit, 301...Information acquisition unit, 302...Display control unit, 303...Input operation reception unit, 304...Transmission control unit
Claims
1. Equipped with a processor, The aforementioned processor, Obtain multiple billing data that includes at least information that can identify the claimant and the amount billed, and multiple payment data that includes at least information that identifies the payer and the amount paid. From the aforementioned multiple billing data and multiple payment data, as a reconciliation process to match and reconcile the multiple billing data and the payment data, the billing data and payment data that were deemed unsuitable for the first reconciliation process are extracted. Depending on the degree of importance of each item of information contained in the aforementioned billing data and payment data, each item is weighted, and based on the result of this weighting, a value indicating the degree of relevance of the information is calculated for each item. Based on the degree of relevance, for each payment data, the multiple invoice data that are candidates for the second reconciliation process are extracted from the invoice data. The method is characterized by extracting a combination of invoice data that will be a secondary candidate for the second reconciliation process from among the multiple invoice data extracted as candidates for the second reconciliation process, based on the degree of relevance of multiple pieces of information contained in each of the multiple invoice data extracted as candidates for the second reconciliation process. Information processing device.
2. The processor is characterized by extracting the plurality of billing data and combinations of the billing data based on a value indicating the degree of relevance calculated from the results of the first and second reconciliation processes. The information processing apparatus according to claim 1.
3. comprising a processor, The aforementioned processor, Obtain multiple billing data that includes at least information that can identify the claimant and the amount billed, and multiple payment data that includes at least information that identifies the payer and the amount paid. From the aforementioned multiple billing data and multiple payment data, as a reconciliation process to match and reconcile the multiple billing data and the payment data, the billing data and payment data that were deemed unsuitable for the first reconciliation process are extracted. Depending on the degree of importance of each item of information contained in the aforementioned billing data and payment data, each item is weighted, and based on the result of this weighting, a value indicating the degree of relevance of the information is calculated for each item. Based on the degree of relevance, for each payment data, the multiple invoice data that are candidates for the second reconciliation process are extracted from the invoice data. The method is characterized by estimating patterns of the invoice data and payment data from the results of the first and second reconciliation processes, and detecting incorrect reconciliation processes from the results of the second reconciliation process based on the results of the estimation. Information processing device.
4. An acquisition means for acquiring multiple billing data, which include at least information that can identify the claimant and the billing amount, and multiple payment data, which include at least information that indicates the payer and the payment amount. From among the aforementioned multiple billing data and multiple payment data, a reconciliation process is performed by matching the multiple billing data and the payment data, and a means for extracting unreconcilable data is provided for extracting billing data and payment data that were deemed unsuitable for the first reconciliation process. A calculation means that, according to the degree of importance of each item of information contained in the aforementioned billing data and payment data, assigns weights to each item, and calculates a value indicating the degree of relevance of each item based on the result of the weighting, Based on the degree of relevance, a primary candidate extraction means extracts multiple invoice data from the invoice data to be primary candidates for the second reconciliation process for each payment data, A secondary candidate extraction means extracts a combination of billing data that will be a secondary candidate for the second reconciliation process from among the multiple billing data extracted as primary candidates, based on the degree of relevance of multiple pieces of information contained in each of the multiple billing data extracted as primary candidates. Output means for outputting the plurality of billing data extracted as primary candidates and the combination of the billing data extracted as secondary candidates, A feature having Information processing system.
5. Acquisition means for acquiring a plurality of claim data including at least information that can identify the claimant and the claim amount, and a plurality of payment data including at least information indicating the payer and the amount paid, From among the aforementioned multiple billing data and multiple payment data, a reconciliation process is performed by matching the multiple billing data and the payment data, and a means for extracting unreconcilable data is provided for extracting billing data and payment data that were deemed unsuitable for the first reconciliation process. A calculation means that, according to the degree of importance of each item of information contained in the aforementioned billing data and payment data, assigns weights to each item, and calculates a value indicating the degree of relevance of each item based on the result of the weighting, Based on the degree of relevance, a primary candidate extraction means extracts multiple invoice data from the invoice data to be primary candidates for the second reconciliation process for each payment data, A secondary candidate extraction means for extracting a combination of billing data that will be a secondary candidate for the second reconciliation process from among the multiple billing data extracted as primary candidates, based on the degree of relevance of each of the multiple billing data extracted as primary candidates, Output means for outputting the plurality of billing data extracted as primary candidates and the combination of the billing data extracted as secondary candidates, A detection means that estimates the patterns of the invoice data and payment data from the results of the first and second reconciliation processes, and detects incorrect reconciliation processes from the results of the second reconciliation process based on the results of the estimation, A feature having Information processing system.
6. On the computer, A function to acquire multiple billing data, which include at least information that can identify the billed party and the billed amount, and multiple payment data, which include at least information that indicates the payer and the amount paid. From the aforementioned multiple billing data and multiple payment data, a reconciliation process is performed to match and reconcile the multiple billing data and the payment data, and a function is provided to extract the billing data and payment data for which the first reconciliation process could not be performed. A function that assigns weights to each item of information contained in the aforementioned billing data and payment data according to the degree of importance of each item, and calculates a value indicating the degree of relevance of the information for each item based on the result of the weighting, Based on the degree of relevance, a function is provided to extract multiple invoice data from the invoice data that are candidates for the second reconciliation process for each payment data, A function to extract a combination of invoice data that will be a secondary candidate for the second reconciliation process from among the multiple invoice data extracted as candidates for the second reconciliation process, based on the degree of relevance of multiple pieces of information contained in each of the multiple invoice data extracted as candidates for the second reconciliation process, A program to achieve this.
7. A computer, A function to acquire multiple billing data, which include at least information that can identify the billed party and the billed amount, and multiple payment data, which include at least information that indicates the payer and the amount paid. From the aforementioned multiple billing data and multiple payment data, a reconciliation process is performed to match and reconcile the multiple billing data and the payment data, and a function is provided to extract the billing data and payment data for which the first reconciliation process could not be performed. A function that assigns weights to each item of information contained in the aforementioned billing data and payment data according to the degree of importance of each item, and calculates a value indicating the degree of relevance of the information for each item based on the result of the weighting, Based on the degree of relevance, a function is provided to extract multiple invoice data from the invoice data that are candidates for the second reconciliation process for each payment data, A function to estimate the patterns of the invoice data and payment data from the results of the first and second reconciliation processes, and to detect incorrect reconciliation processes from the results of the second reconciliation process based on the results of the estimation, A program to achieve this.
Citation Information
Patent Citations
Payment processing system and method
JP2004302574A
Method, system and program for managing deposit
JP2007305080A
Checking and matching method and checking and matching support system
JP2008033643A
System and program for deletion processing
JP2014059667A
Data checking program and data checking method
JP2018073249A