JP2005107789A - Mortgage processing rationalizing system for credit using fb - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a mortgage processing rationalizing system of credit for rationally performing a mortgage processing of credit even when claim data do not match money payment one to one. <P>SOLUTION: This system comprises: a means for generating money payment scheduled data to be collated with money payment from claim data; a means for receiving money payment notification data through the Internet when receiving money payment notification is received from an FB or the like; a means for automatically collating the money payment schedule data with the money payment; and a means for performing manual collation processing when the automatic collation by the automatic collation processing is impossible. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a rationalization system that rationalizes the allocation process of receivables by using farm banking (FB) and executes it using the Internet or the like.

Conventionally, the following methods are generally used as a method of mechanically checking the accounts receivable and the transfer amount and performing the settlement. (See Patent Document 1)
1. The party who requests the receivable issues an invoice number and sends the invoice displaying the invoice number to the payer.
2. The payer adds the invoice number to the “transfer message” when making the transfer.
3. The side receiving the payment verifies which charge is received from the invoice number attached to the “transfer message”.
JP 2002-183630 A

However, for example, in real estate management, the above method may not be applied. The reason is as follows.
1. You may not be able to deposit as invoiced. For example, in order to save the transfer fee, a plurality of bills may be deposited at a time.
2. In most cases, invoices are not issued for monthly rent / community bills.

  The object of the present invention has been made in view of the above points, and even when claim data and deposit do not coincide with each other in a one-to-one correspondence, the provision processing rationalization system for claims can be reasonably performed. Is intended to provide.

  The rationalization system for the process of allocating claims of the present invention includes a means for generating payment schedule data for collating with payment data, and payment notification data for receiving payment notification from farm banking etc. on the Internet. Data receiving means for receiving via credit, a deposit provision processing means for collating the receipt schedule data and the receipt data, and an output means for outputting a comparison collation result of the claim provision processing means. To do.

  The receivable provision processing means includes automatic check processing means for automatically comparing and checking the payment schedule data from the payment schedule data generating means and the payment data from the data receiving means, and the automatic check processing means automatically And manual verification processing means for manually verifying the deposit data that cannot be processed and returning it to the automatic verification processing means again.

  The automatic collation processing means is a first extraction means for collating a transfer person name in the payment notification data with a payment candidate name / kana name in the payment schedule data and extracting matching payment schedule data; And second search means for searching for a coin that matches the deposit amount from the deposit schedule data.

  The manual collation processing means collates a plurality of receipt schedule data in various combinations when the receipt schedule data and the receipt notification data are not 1: 1, and extracts receipt notification data that matches the deposit amount. It is characterized by that.

  According to the above-described rationalization system of the present invention, it is possible to reasonably process the provision of receivables even when the billing data such as the real estate management business and the deposit do not match.

According to the rationalization system of the present invention, the following means are constructed by a computer system.
a. The payment schedule data for collating with the payment is generated by the payment schedule data generating means.
b. Receive payment notification from FB etc. via the Internet etc. by means of receiving payment notification data.
c. The automatic verification processing means automatically compares and collates the payment schedule data from the payment schedule data generation means and the payment notification data from the payment notification data reception means.
d. A person determines and collates data that could not be automatically processed by the automatic collation processing means by the manual collation processing means, and returns the result to the automatic collation processing means again to perform collation again.

In the automatic verification processing means, the payment schedule data and the payment are compared and verified by the following method.
The first means compares and collates the name of the transfer person in the payment notice and the expected payment person / name of the expected payment data, and extracts matching expected payment data.
The second means searches the extracted deposit schedule data for a match with the deposit amount. At this time, the payment schedule data and the payment notification are not necessarily one-to-one, so a plurality of payment schedule data are variously combined and compared to find a match with the deposit amount.

  According to the above-described rationalization system of the present invention, even when the billing data such as real estate management business and the deposit do not coincide with each other on a one-to-one basis, the provision of receivables can be reasonably processed.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 shows various economic distribution relationships among a lending company 1, a lender 2, a customer (account) 3 of a lender, and a bank 4. The arrows in the figure indicate the financial activities of the lending company, the lender, the accounts receivable of the lender, and the bank.
In other words, the loan company 1 finances the loan 2 through the bank A, and the loan 2 makes an account receivable to the customer (customer) 3 and schedules the receipt of sales. At the same time, the borrower 2 sends the accounts receivable data to the loan company 1. The customer deposits the invoiced amount to the borrower 2 via the bank B. The borrower 2 sends the deposit data from the customer to the loan company 1 via the bank A.
The rationalization system of the present invention can be provided in either the loan company 1 or the loan destination 2 described above.

(Embodiment 1)
The configuration of the rationalization system of the present invention will be described below.
As shown in FIG. 2, the rationalization system for the process of allocating claims of the present invention includes deposit schedule data generation means 10 for generating deposit schedule data for collation with deposit data, and deposits from farm banking (FB) and the like. It comprises data receiving means 12 for receiving notification data via the Internet, etc., a loan provision processing means 13, and an output means 20 for outputting a comparison / collation result of the claim provision processing means.
The claim allocation processing means 13 includes automatic check processing means 14 for automatically checking payment schedule data from the payment schedule data generating means 10 and payment data from the data receiving means 12, and automatic check processing means 14. And manual verification processing means 16 for manually verifying the deposit data that cannot be processed automatically and returning it to the automatic verification processing means 14 again.
The output of the automatic matching processing means is taken out from the output means 20.

  The loan company's receivable by creditor, the accounts receivable details / payment application processing system of the loan company 1 is executed as shown below with reference to FIGS. 3 (a) and 3 (b).

As shown in FIG. 3 (a), an account receivable data capture condition (a) is set.
New addition / change / deletion attribute information of the loan company 1, the borrower 2, and the accounts receivable 3 by loan and the attribute items are imported from the existing host system into the rationalization system of the present invention.
The attribute information includes, in particular, related information (payment / payment) between payment schedule data and payment data, collection conditions (collection bank account, collection accounts receivable, etc.) and the like. For example, if it is necessary to set when the receivables claim destination is a branch office and the collection destination is a head office collective, this attribute item is provided.
Further, supplemental registration of attribute information not registered in the existing system host is performed.
In the future, when the existing system is newly redeveloped, this processing can be centrally managed in the system of the present invention.

The following cases can be considered when setting up a deposit account.
a. When the deposit account is one place (one account) in system operation b. When there are multiple deposit accounts and a deposit account is confirmed (designated) for each transfer person (collection destination) c. The transfer person (collection destination) is set separately depending on the billing content (type) d. When the transfer person (collection destination) selects a deposit account at any time and deposits

Case (a): In this case, a deposit confirmation process is performed for each FB deposit data.
If there is no deposit schedule data, all FB deposit data “unmatch data” is displayed.
Case (b): In this case, the attribute information of the deposit account is set in the deposit schedule data (the key part thereof), and each time the deposit account of the FB deposit data is changed, whether the corresponding data exists in the deposit schedule data is checked. . If not, all FB deposit data of the deposit account will be “unmatch data”.
Case (c): In this case, the content is the same as that of case (a). Therefore, since the deposit account attribute cannot be set in the deposit schedule data (the key part thereof), the process proceeds to the next name identification process.
Case (d): In this case, it is possible to perform batch processing of received data by FB processing or EB processing of a plurality of banks / branches / accounts including reception via CMS.

As shown in FIG. 3 (b), the accounts receivable data is taken in (b).
Account receivable data for the current month (or this time) by borrower from an existing host system or the like is taken into the database (database) of the rationalization system of the present invention.
Basically, on the premise of differential acquisition, setting such as condition setting is also taken into consideration for the maintenance side response to any event.

The payment schedule data is created under the following conditions.
(a) From the billing destination, the collection destination, and the billing data (or claim recording data), the payment schedule data for the transfer deposit is created. As a collection destination information, collection schedule and name identification information are created based on the following conditions.
(1) Billing destination: Collection destination = 1: 1
(2) Billing destination: collection destination = N: 1 and collection for each bill (3) billing destination: collection destination = N: 1 and collection for each billing total (ΣN)
(b) When operating the transfer requester code, set the information.
(c) In the case where payment is confirmed not only with the identification of names but also with the collected amount, first, the payment confirmation for each invoice is used as a standard.
(d) If the conditions in (c) further assume payment at the billing statement level (for example, merchandise sales) or there are conditions (for example, real estate management) such as invoicing, in accordance with that. Create deposit schedule data separately.
* Invoice details level Basic (1) Invoice
Condition (1), (2), and (3) of case (a).
Expansion (2) Invoice + invoice details
It can be handled by the condition (1) or (2) of the case (a).
(e) Calculate and set the transfer fee. The calculation condition of the transfer fee is the transfer designation classification 0: Document handling 1: Telegraph handling,
Fee burden classification 0: Transfer person burden 1: Own burden
When it is set for each bank where the transfer person (collection destination) has transferred as described in the fee limit, the transfer fee is calculated at the previous transfer bank.
At the time of the amount verification confirmation process, it is calculated again under the conditions at the current bank.

Next, an example of collection of accounts receivable (c) will be described with reference to FIG.
A. In case of EB system between borrower and bank: (Figure 4)
In this example, the EB system is operated (d).
By using an EB (Electro Banking) system such as “OFFICE BANK21”, the deposit data (or transfer deposit data) of the customer's bank account is acquired.
The output data format is CSV text data.
In this case, the FB software (e) is not used.
Deposit / withdrawal data acquired by the operation of the EB system (d) is stored in time series as “deposit / withdrawal data” and data processing for remittance to the loan company 1 and output of the deposit / withdrawal schedule is performed. Output a table.
Next, the deposit / withdrawal data is transmitted to the loan company 1 via the Internet or the like. Accordingly, the loan company 1 receives the deposit / withdrawal data through the transfer deposit / data collection process.

Furthermore, another example of collection of accounts receivable (c) will be described with reference to FIG.
B. When using the FB (farm banking) tool between the borrower and the bank: (Figure 5)
In this example, FB software is used (e).
The FB software is executed using an FB tool (verified) such as “Biware”.
When acquiring deposit / withdrawal data, a series of processes from connection to a network via the Internet or the like to creation of deposit / withdrawal data is performed.
The acquired deposit / withdrawal data is stored as “deposit / withdrawal detail data” in time series, and data processing for sending to the loan company 1 and outputting the deposit / withdrawal schedule is performed to output the deposit / withdrawal schedule.
The deposit / withdrawal data is transmitted to the loan company 1 via the Internet or the like. The loan company 1 receives the deposit / withdrawal data through the transfer deposit / data collection process.

Further, as shown in FIG. 6, the bank B collects the trade receivables from the customer 3 and transmits the deposit / withdrawal data (or transfer deposit data) to the loan company 1 via the Internet or the like.
Next, the transfer deposit data is taken in (f).
The loan company 1 receives “payment / withdrawal data (or deposit / payment data)” transmitted from the borrower 2 by the FB software (e).
The data format to be received is CSV text data.
Use the collected deposit / withdrawal data (or transfer deposit / receipt data) and the loan destination database (DB) or the credit receivable by creditor database (DB) in advance for the name identification process by bank and the deposit / withdrawal schedule output. The data is compared and collated by batch processing, and for the deposit data, “current deposit details data” is created and a deposit / withdrawal schedule (or transfer deposit schedule) is output.

Further, referring to FIG. 7, the name identification process (g) of the deposit data is performed.
The provisioning process is executed for “current receipt details data” according to the receipt data receipt condition for each receivable by creditor.
Data for which the allocation has been confirmed is output as “payment confirmation data”, and data for which the allocation has not been determined is output as “unmatch data”.

In performing name identification processing,
◎ Comparison the transfer name.
・ Verify the name of the payer in the “current deposit data” and the name of the account of the receivable. On this occasion,
? Spaces are cut and collated.
? Convert the homonyms (for example, ji-ji-ji, zu-ji-zu).
・ If there is one account with the same name in the above check, the name is a hit. If there are multiple accounts with the same name, they are output as unmatch data. Even if there is no corresponding account name in the accounts receivable account, it is output as “unmatch data”.
◎ If the billing address and the collection address are different,
• Replace the accounts receivable account with a collection account and perform the above verification process.

That is, when performing the name identification process, it is assumed that the search for deposit schedule data is accompanied by deposit account attribute information. (Except when the deposit account is one place (one account) in system operation)
? When performing individual verification with the transfer requester code (if not, proceed to the next section).
・ If the transfer client code in the FB deposit data is not set, proceed to the next section.
・ Search for payment schedule data (search key: payee code) using the transfer requester code in the FB payment data as a key, and if there is such data, proceed to the next section if there is no need to verify the amount, If the amount verification is necessary, the process proceeds to the amount verification determination process. If there is no corresponding data, the process proceeds to the next item.
In addition, about the search of payment plan data, it performs according to the following collation conditions.
Verification conditions (1) Verification of the first 7 digits
(2) Lower 7 digits verification
(3) Verification of all 10 digits
? Verify the transfer requester name in the FB deposit data and the account holder name in the planned deposit data. Actually, the deposit request data (search key: account holder name) is searched by the transfer requester name, and if there is no corresponding data, “unmatch data” is output as no payment schedule data and FB payment data. Read.
If there is corresponding data and there are multiple cases, and there is data with different collection destination (business partner) codes, the transfer name (collection destination) data with the same name exists and “unmatch data” is output and FB Read deposit data.
If there is the corresponding data, if there is no need to check the amount, the payment confirmation data (data classification = 1: name identification confirmation) is output and the FB payment data is read.
When the amount verification is necessary, the process proceeds to the amount verification determination process.
? Output payment confirmation data (data classification = 1: name identification) and read FB payment data.

Next, a name identification determination process (H) is executed with reference to FIG.
The “reservation confirmation list” and “unconfirmed list” are created from the payment confirmation data and the unmatch data, and a measure for allocating unmatch data is entered. Further, if the payment confirmation data needs to be adjusted with the billing details data, the confirmation input is performed.
Again, the process returns to the process of creating the “reservation confirmation list” and the “unconfirmed list” to perform reconfirmation, and “confirmation completion processing for“ current deposit data ”is performed. The deposit / withdrawal statement DB is also updated here.
It can be set as needed whether provision information for billing data and deposit data is provided in the “accounts for accounts receivable by loan” or “details DB for deposits”.

Next, referring to FIG. 9, the allocation result is confirmed (I).
The purpose is to perform alarm management from information on billing history and payment history. In particular, manage / analyze / confirm the status of receivables of loans.
・ Provision of non-payment and arrears information (alarm)
・ Regular delinquency check (preliminary alarm)
・ Include various attributes, especially collection conditions, etc. in the items listed in the “Billing / Payment Reserve Status List” to create materials that are easy to judge.
Clear processing of various detailed information for the loan completion destination and transfer processing to management data such as history information.

A first example of a case summary of deposit confirmation processing by farm banking (FB) will be described with reference to FIG.
First, pre-payment processing is performed.
For example, automatic deposit confirmation exclusion designation input is performed. This is a deposit / withdrawal reception process when it is excluded from the automatic allocation determination of deposits in this situation.
Connect to a bank online (Internet, etc.) and receive deposit data.
EB (OFFCE BACNK21) and FB (ex.Biware) (also known as ex.FB data import) are used as tools.
? Deposit data (payment schedule)
The received data is used as received data and printed as it is. Therefore, it becomes a substitute for a bankbook.

? Deposit confirmation processing a. Select the account for deposit confirmation processing by the deposit account (multiple deposit accounts).
b. Select payment confirmation (transferee name check, various amount check, fictitious account, etc.).
? Deposit confirmation data (Account No. confirmation list)
Prints the deposit data of the account that has been confirmed by the deposit confirmation process (also known as ex.
? Unmatch data (Account No. unconfirmed list)
The deposit data that could not be confirmed by the deposit confirmation process is printed. (Also known as ex. Deposit unmatch list)
? Exclusion data (Account No. fixed exclusion list)
Data that has been confirmed by the deposit confirmation process but is specified to be excluded from the automatic allocation confirmation of the current deposit is printed.

A second example of the case summary of the payment confirmation process for farm banking (FB) will be described below. First,
? Perform the payment confirmation process.
a. Select the deposit confirmation processing target account by the deposit account (multiple deposit accounts).
Select and confirm the account data for the deposit process in the “bank + branch + deposit type + account number” of the deposit account. Thereby, it is possible to cope with the deposit confirmation process target account data for a plurality of deposit accounts.
b. Select payment confirmation (transferee name check, various amount check, fictitious account, etc.).
◎ Verify transfer name.
・ Comparison of the transfer data Kana name of the deposit data and the account name (ex. Debtor name) of the deposit confirmation target account data.
? Spaces are cut and collated.
? Converts homonyms (Gi-ji → Gi, Zu ヅ → z).
・ If there is one account with the same name in the above check, the name is a hit.
If multiple accounts with the same name exist, unmatch data is output.
◎ Verify various amounts.
・ For accounts receivable collection and loan principal and interest collection, the payment is confirmed by the above comparison of the transfer person. However, if there is an excess or deficiency with respect to the scheduled deposit amount and automatic processing cannot be performed, the corresponding action may be input by “FB automatic deposit processing input”.
・ Verify against various deposits.
In case of product sales request
(1) Total invoice (2) Billing item unit
? For real estate management
(1) Total of invoices (2) Tenant billing unit for each property (3) Total of customer bills ・ For fictitious accounts (ex. Perfect accounts)
Individual verification (individual correspondence with the service provider bank) by the transfer client code of the receipt data. The matching condition is
(1) Seven digit verification of transfer requester code
(2) Verification of the last 7 digits of the same code
(3) Verification of all 10 digits of the same code

◎ Amount verification confirmation process a. Amount verification is performed for the FB receipt data that is currently captured, within the range of the name confirmation of the receipt schedule data, and the receipt schedule data is confirmed.
For each payment schedule data, the transfer fee is calculated as described in the calculation of the transfer designation category, the fee burden category, the fee limit and the transfer fee. It is not necessary to calculate when paying the transfer person.
・ Transfer burden: Scheduled collection amount = Transfer notification amount ・ Company pay: Scheduled collection amount-Transfer fee = Transfer notification amount If the amount is verified under the above conditions and the planned deposit data is applicable, proceed to the next section.
If there is no corresponding deposit schedule data within the range of the confirmed deposit of the deposit schedule data, and if there is no “development” level setting, deposit confirmation data is output.
b. In the “development” deposit schedule data, the same amount verification processing as the deposit schedule data is performed.
Amount verification is performed under the above conditions, and payment confirmation data is output if the payment schedule data is applicable.
If there is no corresponding deposit schedule data within the range of the confirmed deposit of the developed deposit schedule data, the deposit confirmation data is output.
c. Output the deposit amount confirmation data (data classification = 2: name identification & amount confirmation / transfer fee calculation) and proceed to reading the FB receipt data.
d. Output receipt name identification data (data classification = 1: identification) and proceed to reading FB receipt data.

Next, various lists are created.
a. Deposit data name identification confirmation list Created from deposit name identification confirmation data (data classification = 1: identification verification).
If there is FB deposit data with the same name collation, it is output in a continuous line, and then the deposit plan data for name collation is output. (If there are more than one, output them on a continuous line)
This is a document for performing confirmation of carrying with the payment schedule details, confirmation processing of the transfer fee, etc. by deposit confirmation input processing.
b. Receipt data amount verification confirmation list This is the receipt confirmation data (data classification = 2: name identification & amount confirmation / transfer fee calculation), and in the deposit confirmation input process, the transfer fee is changed and adjusted with the payment schedule details data. Can do.
c. Unmatch list
? In the deposit confirmation input process, confirm the FB deposit data.
The situation (reason) that was unmatched is also output.
All the above output data is output with a search number attached and specified in the payment confirmation input process.

◎ Receipt confirmation input processing a. Confirmation input of receipt data name identification confirmation data b. Confirmation input of receipt data amount verification confirmation data c. Confirm input of unmatch data This process adjusts / confirms the contents supplemented by creating various lists I do.
In particular, it is possible to handle over-payment, processing of temporary receipts (deposits) accounts where the transferee (collection destination) is fixed but the receivables (billing) items cannot be determined, or the advance payment account and result collection destination can be determined Process the temporary receipt account that did not exist.
? When payment confirmation input is made from unmatch data, the revision function is updated for the item that was unmatched as a knowledge function, and the accuracy is improved next time.
ex. Account holder name
ex. Transfer fee calculation conditions
? Also update the items for the confirmed data as a knowledge function.
ex. Bank information transferred by the transfer person (collection destination).
In the following, a flow chart of claim allocation according to the present invention will be described with reference to FIG.
When there is a deposit from the account receivable, the deposit data is sent to step (101).
In step (101), the client requests the deposit data and searches for the corresponding deposit schedule data (invoice data).
If yes (Yes), the process proceeds to step (102).
For example, there are three deposit schedule Nos. 1 to 3 in FIG. 12B that correspond to “X show” with deposit No. 1 in FIG.
If there is no applicable data (No), this deposit data is used as unmatch data.
In step (102), when the fee burden classification of the payment schedule data is the transfer person burden, the process proceeds to step (103). On the other hand, if the commission burden classification of the deposit schedule data is the company burden, the process proceeds to step (104).
In step (103), the "transfer notice amount" of the deposit data and the "deposit plan amount" of the deposit plan data (billing level) are compared and collated, and if they match (if Yes), the process proceeds to step (111), The deposit amount is fixed (data category = 2).
If not (No), the process proceeds to step (105).
Further, in step (104), the “transfer notice amount” of the deposit data is compared with “scheduled deposit amount-transfer fee” of the scheduled deposit data (invoice unit), and if they match (if Yes), the step (if yes) 111), and the deposit amount is determined (data category = 2).
If not (No), the process proceeds to step (105).
In step (105), “scheduled deposit amount” is added in any combination from the deposit schedule data corresponding to step (101), and compared with “transfer notification amount” in the deposit data.
If there is a matching combination, the process proceeds to step (111), and the deposit amount is confirmed.

Example 1: In the case of “X show” in FIGS. 12 (a) and 12 (b);
Payment No.1 for deposit No. 1 = 22,000
No.1 + 2 scheduled deposit amount = 15,000 (non-coincidence)
No.1 + 3 deposit expected amount = 17,000 (non-coincidence)
Expected deposit amount of claim No. 2 + 3 = 12,000 (non-coincidence)
Deposit No. 1 + 2 + 3, scheduled deposit amount = 22,000 (match) → deposit No. 1 and claims No. 1, 2, 3 correspond.

Example 2: In the case of “Y Showen” in FIGS. 12 (a) and 12 (b), since it is the company's own burden, it is compared and verified in consideration of the transfer fee.
Deposit No. 2 transfer notification amount = 23,400
Claim No. 4 + 5 expected deposit amount = 15,000-300 + 9,000-300 = 23,400 (match)
→ Deposit No. 2 and claim Nos. 4 and 5 correspond.
If there is no matching combination, the process proceeds to step (106).
In step (106), the payment schedule data is totaled for each business partner, and compared with the “transfer notice amount” of the payment data.
If they match, the process proceeds to step (111).

Example 3: In case of “A set” in FIG.
According to FIG. 12 (c), “A Setubi” is under the control of the business partner “XYZ”. Therefore, the transfer amount of “A Setsubi” is compared with the scheduled deposit amount of “XYZ”.
“A Setabi” transfer notification amount = 35,000
Deposit amount for “XYZ Co., Ltd.” = 35,000 → match In step (107), the transfer requester at the detail level of the scheduled payment data is looked up, and the corresponding scheduled payment data is searched from this.
If applicable, the process proceeds to step (108).
The two cases of claim No. = 6 and statement No. = 1-2 in FIG. 12 (d) correspond to the “Z komten” of deposit No. = 3 in FIG. 12 (a);
If there is no applicable data, this deposit data is used as unmatch data.
In step (108), when the fee burden classification of the payment schedule data is the transfer person burden, the process proceeds to step (109).
In step (109), if the company pays, the process proceeds to step (110).
In step (109), the “transfer notice amount” of the deposit data is compared with the “deposit plan amount” of the scheduled deposit data (detail level), and if they match, the process proceeds to step (111) and the deposited amount is confirmed. To do.

Example 4: In the case of “Z” combumene in FIGS. 12 (a) and 12 (d);
Deposit No.3 payment notification amount = 15,000
Expected deposit amount of claim No. 6 / detail No. 1 = 7,000 (non-coincidence)
Claim No. 6 / Detail No. 2 scheduled deposit amount = 15,000 (match) → Deposit No. 3 corresponds to Claim No. 6 / Detail No. 2.

If they do not match, the process proceeds to step (112).
In step (110), the “payment notification amount” in the deposit data is compared with “scheduled deposit amount-transfer fee” in the deposit schedule data (billing level). If they match, the process proceeds to step (111), and the deposit amount Is fixed.
If they do not match, the process proceeds to step (112).
In step (111), the data classification is set to 2 assuming that the deposit data is confirmed.
In step (112), the deposit data is not confirmed, but the data classification is set to 1 assuming that the transfer person and the account holder match.

FIG. 1 is an explanatory diagram showing various economic distribution relationships among a loan company 1, a loan customer 2, a customer (account receivable) 3 of a loan customer, and a bank 4. FIG. 2 shows the configuration of the rationalization system for the allocation process of the claims of the present invention. FIG. 3A is an explanatory view for explaining the setting of the condition for taking in the account receivable data. FIG. 3B is an explanatory diagram showing the taking in of the bill receivable data. FIG. 4 is an explanatory diagram showing collection of accounts receivable when the loan destination and the bank are EB systems. FIG. 5 is an explanatory diagram showing collection of accounts receivable when the FB (farm banking) tool is used between the borrower and the bank. FIG. 6 is an explanatory diagram showing the taking-in of deposit / payment data. FIG. 7 is an explanatory diagram for explaining the name identification process of the deposit data. FIG. 8 is an explanatory diagram showing name identification determination processing. FIG. 9 is an explanatory diagram showing confirmation of the allocation result. FIG. 10 is an explanatory diagram showing an example of a deposit confirmation process by farm banking. FIG. 11 is an explanatory diagram showing a flowchart of the process for allocating bonds. FIG. 12 is an explanatory diagram showing examples of payment data and payment schedule data, FIG. 12 (a) shows payment data, FIG. 12 (b) shows payment schedule data in invoice units, 12 (c) shows the payment schedule data for each supplier, and FIG. 12 (d) shows the payment schedule data at the statement level.

Explanation of symbols

1 Loan company 2 Borrower 3 Loan customer (Accounts receivable)
DESCRIPTION OF SYMBOLS 10 Claim data generation means 12 Data receiving means 13 Claim allocation processing means 14 Automatic verification processing means 16 Manual verification processing means 20 Output means

Claims (4)

Payment schedule data generation means for generating payment schedule data for collation with payment data from billing data, data reception means for receiving payment notification data from farm banking etc. via the Internet, and the payment schedule data A system for rationalizing the allocation of credits, comprising: a credit reserving processing unit for collating the deposit data; and an output unit for outputting a comparison / collation result of the credit reserving processing unit. The receivable provision processing means includes automatic check processing means for automatically comparing and checking the payment schedule data from the payment schedule data generating means and the payment data from the data receiving means, and the automatic check processing means automatically 2. The claim allocation rationalization system according to claim 1, further comprising manual verification processing means for manually verifying the deposit data that cannot be processed and returning it to the automatic verification processing means again. The automatic collation processing means is a first extraction means for collating a transfer person name in the payment notification data with a payment candidate name / kana name in the payment schedule data and extracting matching payment schedule data; 3. The claim allocation rationalization system according to claim 2, further comprising: second search means for searching for a coin that matches the deposit amount from the received deposit schedule data. The manual collation processing means collates a plurality of receipt schedule data in various combinations when the receipt schedule data and the receipt notification data are not 1: 1, and extracts receipt notification data that matches the deposit amount. The system for rationalizing the process of allocating claims according to claim 2.

Images