JP7602003B2 - Information processing method, program, and information processing device - Google Patents

Description

The present invention relates to an information processing method, a program, and an information processing device.

One type of financial service is a factoring service that purchases accounts receivable from creditors and collects the receivables from debtors. For example, Patent Document 1 discloses a factoring system that factors electronically recorded claims as stipulated in the Electronically Recorded Claims Act.

JP 2015-204063 A

However, as described in Patent Document 1, factoring is generally conducted between corporations, making it difficult for individuals to use factoring services.

One aspect of the invention is to provide an information processing method etc. that allows even individual users to use factoring services.

In one aspect, the information processing method displays a list of multiple invoices issued by a user to a trading partner on a display unit, accepts a selection input to select an invoice for which an account receivable is to be purchased from the multiple invoices, determines a screening limit amount if the transaction evaluation between the user and the trading partner is equal to or higher than a predetermined evaluation, and causes a computer to execute a process of transferring a purchase amount corresponding to the invoice amount to the user's financial account if the invoice amount of the selected invoice is equal to or lower than the determined screening limit amount.

On the one hand, even individual users can use factoring services.

FIG. 1 is a schematic diagram showing an example of the configuration of a factoring system. FIG. 2 is a block diagram showing an example of the configuration of a server. 3 is an explanatory diagram showing an example of the record layout of a user DB, an invoice DB, a user evaluation table, and a client evaluation table. 11 is an explanatory diagram showing an example of the record layout of a transaction evaluation table, a transaction cluster DB, and a document determination table. 11 is an explanatory diagram showing an example of a record layout of a fee evaluation table and a fee cluster DB. FIG. 1 is an explanatory diagram showing an overview of a factoring system. FIG. 13 is an explanatory diagram showing an example of an invoice list screen. FIG. 13 is an explanatory diagram regarding a process for transmitting transaction materials. 11 is a flowchart illustrating an example of a processing procedure executed by a server. 13 is a flowchart showing a processing procedure of a factoring subroutine.

The present invention will now be described in detail with reference to the drawings showing embodiments thereof.
(Embodiment)
1 is a schematic diagram showing an example of the configuration of a factoring system. In this embodiment, a factoring system that provides a factoring service for individual users will be described. The factoring system has an information processing device 1 and terminals 2, 2, 2, . . . Each device is connected for communication via a network N such as the Internet.

The information processing device 1 is an information processing device capable of various information processing and sending and receiving information, such as a server device or a personal computer. In this embodiment, the information processing device 1 is a server device, and for the sake of simplicity in the following explanation, the information processing device 1 will be read as server 1. The server 1 is a management device that manages the factoring service related to this system, and performs processes such as managing financial accounts used for factoring, screening associated with factoring, and transferring money to users.

As described below, in this embodiment, the server 1 performs factoring for individual users. Specifically, the server 1 performs factoring by purchasing accounts receivable arising from transactions between individual users (sole proprietors, etc.) and the counterparty to the transaction (hereinafter referred to as a "client") that receives delivery of goods, etc. at the request of the user, and paying the amount of the accounts receivable minus a commission fee to the user.

The terminal 2 is a terminal device of each user who uses the service, and is, for example, an information processing device such as a multi-function terminal or a personal computer. For example, an application program dedicated to the service provided by the server 1 is installed on each terminal 2, and each user applies for factoring, views information, etc. on the application.

2 is a block diagram showing an example of the configuration of the server 1. The server 1 includes a control unit 11, a main memory unit 12, a communication unit 13, and an auxiliary memory unit .
The control unit 11 has one or more arithmetic processing devices such as a central processing unit (CPU), a micro-processing unit (MPU), a graphics processing unit (GPU), etc., and performs various information processing, control processing, etc. related to the server 1 by reading and executing a program P stored in the auxiliary storage unit 14. The main storage unit 12 is a temporary storage area such as a static random access memory (SRAM), a dynamic random access memory (DRAM), a flash memory, etc., and temporarily stores data necessary for the control unit 11 to execute arithmetic processing. The communication unit 13 includes a processing circuit, etc. for performing processing related to communication, and transmits and receives information to and from the terminal 2, etc.

The auxiliary storage unit 14 is a large-capacity memory, a hard disk, etc., and stores the program P and other data necessary for the control unit 11 to execute processing. The auxiliary storage unit 14 also stores a user DB 141, an invoice DB 142, a user evaluation table 143, a client evaluation table 144, a transaction evaluation table 145, a transaction cluster DB 146, a document judgment table 147, a fee evaluation table 148, and a fee cluster DB 149.

User DB 141 is a database that stores information about each user. Invoice DB 142 is a database that stores data on invoices issued by each user to trading partners. User evaluation table 143 is a table for performing a credit evaluation of users. Client evaluation table 144 is a table for performing a credit evaluation of clients who are trading partners. Transaction evaluation table 145 is a table for evaluating the degree of creditworthiness of a transaction between a user and a client when conducting factoring, based on the credit information of the user and client.

The transaction cluster DB 146 is a database that stores information on categories (hereinafter referred to as "transaction clusters") that indicate the creditworthiness of transactions, which are classified in stages according to the evaluation by the transaction evaluation table 145. The document determination table 147 is a table that stores information on transaction documents necessary for reviewing transactions. The fee evaluation table 148 is a table for evaluating factoring fees according to the transaction cluster and transaction amount. The fee cluster DB 149 is a database that stores information on fee categories (hereinafter referred to as "fee clusters") according to the evaluation by the fee evaluation table 148.

The auxiliary storage unit 14 may be an external storage device connected to the server 1. The server 1 may be a multi-computer consisting of multiple computers, or may be a virtual machine virtually constructed by software.

In addition, in this embodiment, the server 1 is not limited to the above configuration, and may include, for example, a reading unit that reads information stored in a portable storage medium.

FIG. 3 is an explanatory diagram showing an example of the record layout of the user DB 141, the invoice DB 142, the user evaluation table 143, and the client evaluation table 144.
The user DB141 includes a user ID column, a name column, a user information column, a personal account column, a factoring account column, an account link column, and an accounting link column. The user ID column stores identification information for identifying each user. The name column stores the user's name in association with the user ID. The personal account column stores information on a financial account (hereinafter referred to as a "personal account") that is a financial account opened by an individual user at a specified financial institution and that the user has set as a remittance destination for the factoring fee (purchase price) in association with the user ID. The factoring account column stores information on a factoring account that is a transfer-only account for receiving the factoring service according to the present embodiment in association with the user ID. The factoring account is a financial account associated with the financial account of the administrator of this system, and is a virtual transfer-only account in the financial institution's system, in which an account number is issued in association with the account number of the administrator's financial account and the name of the user. The account linking column stores, in association with the user ID, whether the user has given permission to link the deposit and withdrawal information of the user's personal account with the system. The accounting linking column stores, in association with the user ID, whether the user has set whether to link with a specific accounting software used by the user and upload invoice data to the server 1.

Invoice DB142 includes an invoice ID column, a user column, a client column, a transaction amount column, a billing date column, a due date column, a same-day settlement column, and a purchase price column. The invoice ID column stores identification information for identifying each invoice. The user column stores the user ID of the user who issues the invoice in association with the invoice ID. The client column stores identification information of the client to whom the invoice is to be billed in association with the invoice ID. The transaction amount column stores the transaction amount between the user and the client, that is, the billing amount of the invoice, in association with the invoice ID. The billing date column stores the billing date in association with the invoice ID. The due date column stores the payment due date of the accounts receivable in association with the invoice ID. The same-day settlement column stores whether or not factoring (same-day settlement) has been performed using this service in association with the invoice ID. Note that "under review" in the same-day settlement column means that the administrator is reviewing whether or not to approve the factoring. The purchase price column stores the purchase price when factoring is performed, corresponding to the invoice ID.

The user evaluation table 143 includes a score column, a rating column, a status column, a judgment criteria column, and a transaction limit column. The score column stores a score that is a numerical representation of the user's credit information. The rating column stores a rating given to the user according to the score, in association with the score. The status column stores a status that represents the user's credit information, in association with the score. The judgment criteria column stores various conditions that are used as the basis for calculating the score, in association with the score. The transaction limit column stores the transaction limit amount approved according to the user's credit information, in association with the score.

The client evaluation table 144 includes a score column, a rating column, a status column, and a criteria column. The score column stores a score that is a numerical representation of the client's credit information. The rating column stores, in association with the score, a rating given to the client according to the score. The status column stores, in association with the score, a status that represents the client's credit information. The criteria column stores, in association with the score, various conditions that are used as the criteria for calculating the score.

FIG. 4 is an explanatory diagram showing an example of the record layout of the transaction evaluation table 145, the transaction cluster DB 146, and the document determination table 147.
The transaction evaluation table 145 is a correspondence table that associates the ratings of each user and client with categories (transaction clusters) that indicate the graded creditworthiness of a transaction between the user and the client. As shown in Fig. 4, the transaction evaluation table 145 stores transaction clusters from "T1" to "N" that indicate the graded creditworthiness of a transaction in correspondence with the ratings of the user and the client. The server 1 classifies a transaction between a user and a client into one of a plurality of transaction clusters based on the credit information (rating) of the user evaluated according to the user evaluation table 143 and the credit information (rating) of the user evaluated according to the client evaluation table 144.

The transaction cluster DB146 includes a category column, a rating column, an evaluation column, an automatic review limit column, a manual review limit column, a transaction document column, and a PD expected value column. The category column stores the major classification of each transaction cluster. The rating column stores a rating (symbol) representing each transaction cluster in association with the category. The evaluation column stores an evaluation indicated by each transaction cluster in association with the category and rating. The automatic review limit and the manual review limit each store the factoring limit to be approved according to the transaction cluster. Specifically, the automatic review limit stores the limit approved in an automatic review by the server 1, and the manual review limit stores the limit approved in a manual review by the administrator. The transaction document column stores the level (rating) of transaction documents required at the time of manual review in association with the category and rating. The transaction documents are documents that prove that a transaction has been conducted between the user and the client, and are documents that the administrator uses as a reference when conducting the review. The PD expected value column stores the probability that accounts receivable will become uncollectible in transactions classified into each transaction cluster (the default rate, so to speak), in correspondence with the classification and rating.

The document determination table 147 includes a rating column, a condition criteria column, and a required documents column. The rating column stores a rating that indicates the degree to which transaction documents are necessary. The condition criteria column stores, in association with the rating, the specific degree (quantity, etc.) of transaction documents required for each rating. The required documents column stores, in association with the rating, the specific transaction documents required.

FIG. 5 is an explanatory diagram showing an example of the record layout of the fee evaluation table 148 and the fee cluster DB 149.
The fee evaluation table 148 is a correspondence table that associates transaction clusters and transaction amounts (billing amounts) with factoring fee classifications (fee clusters). As shown in Fig. 5, the fee evaluation table 148 stores fee clusters from "C1" to "C10" in correspondence with transaction clusters and transaction amounts. The server 1 determines the fee cluster according to the transaction cluster classified according to the transaction evaluation table 145 and the billing amount (transaction amount) stated on the invoice.

The fee cluster DB149 includes a rating column, an expected PD column, a standard fee column, a collection period column, and a fee column. The rating column stores a rating representing each fee cluster. The expected PD column stores the expected PD value expected in each fee cluster, in association with the rating, as in the transaction cluster DB146. The standard fee column stores the standard fee for each fee cluster, in association with the rating. The collection period column stores the period from the invoice issue date to the payment due date, that is, the collection period for the accounts receivable, in association with the rating. The fee column stores the actual factoring fee that is an individual fee that varies from the basic fee depending on the collection period, in association with the rating and collection period.

Fig. 6 is an explanatory diagram showing an overview of a factoring system. The overview of this system will be described with reference to Fig. 6.
As already explained, in this embodiment, factoring is performed for individual users. Fig. 6 illustrates how the server 1 performs factoring on accounts receivable arising from a transaction between an individual user and a corporate client. The user is a supplier that delivers goods (or services) at the request of the client, and the client is a requester that receives delivery of goods from the user.

As is commonly done, after the user delivers the goods, they issue an invoice to the client for the transaction price and request payment. However, there is a time lag between the time the payment is invoiced and the time the payment is actually received. During that time, the user needs funds, and there is a demand to receive some percentage of the accounts receivable.

In response to the above demand, a factoring service is provided. Factoring is the purchase of accounts receivable, and is a financial service in which accounts receivable are purchased from creditors (deliverers) and the accounts receivable are collected from debtors (clients). In this embodiment, server 1 is a factoring service for individuals, which purchases accounts receivable between a user and a client and provides a service of settling a portion of the accounts receivable to the user on the same day.

The factoring process according to this embodiment will now be described in detail. First, after delivery of the product, the user issues an invoice and sends it to the client. The invoice may be sent by mail or email, or may be created and sent by a specific accounting software provided by an external service provider. The server 1 acquires the invoice data via the network N. For example, the server 1 receives an invoice uploaded in a specific file format (e.g., a PDF (Portable Document Format, registered trademark) file) from the user's terminal 2. Also, for example, when the user is using accounting software, the server 1 may cooperate with the accounting software to acquire invoice data from a device of an external service provider. The server 1 stores the acquired invoice data in the invoice DB 142 in association with the user ID.

Here, a user who uses this system opens a financial account (factoring account) at a specified financial institution in order to receive factoring services. A factoring account is a financial account opened for each user, and is a financial account dedicated to factoring that is different from the personal account that the user normally uses. In this embodiment, deposits and withdrawals of accounts receivable are made through the factoring account.

Specifically, the factoring account is a financial account associated with the financial account of the administrator of this system (hereinafter referred to as the "management account"), and is a dedicated transfer account with an account number issued in association with the account number of the management account and the name of the user. More specifically, the factoring account is a so-called virtual account, and although the account holder is the user, it is actually a virtual financial account within the financial institution's system associated with the management account that consolidates the factoring accounts of each user. Generally, virtual accounts are used by companies to distinguish between deposits from each customer, but in this embodiment, the virtual account is used as the deposit destination (transfer destination) of accounts receivable, making it easy to identify accounts receivable deposited to each user.

Users of this system issue invoices specifying their own factoring account as the destination (transfer destination) for the transaction fee. This allows the client to deposit the transaction fee (accounts receivable) into the factoring account.

When the server 1 receives a request for same-day settlement (remittance) of accounts receivable from the terminal 2, that is, an application for factoring, it immediately remits the purchase amount, minus a fee, from the accounts receivable, and transfers the purchase amount to the user's personal account. Specifically, as described below, the server 1 refers to the user evaluation table 143 and the client evaluation table 144 to evaluate (set) the credit information of the user, who is the creditor of the accounts receivable, and the credit information of the client, who is the debtor. The server 1 then evaluates the creditworthiness (transaction cluster) of the transaction related to the accounts receivable based on the credit information of the user and the client, and calculates the factoring limit and fee. In this way, the server 1 performs a factoring review, and for invoices below the limit, it immediately remits the purchase amount, minus the calculated fee, from the management account to the user's personal account.

Note that the server 1 only needs to be able to transfer the purchase amount to the user's personal account in response to a request from the terminal 2, and the timing of the transfer may be the next business day of the financial institution, etc. In other words, the factoring of this system is not limited to same-day settlement.

After factoring is completed, the client deposits the accounts receivable into the user's factoring account. In this case, server 1 transfers the accounts receivable to a management account that consolidates the factoring accounts of each user. In other words, server 1 collects the accounts receivable.

When a deposit is made into a factoring account without factoring the accounts receivable, server 1 transfers the accounts receivable directly from the factoring account to the user's personal account. In this way, by utilizing a factoring account in addition to the user's personal account and the management account of the administrator who purchases the accounts receivable, it becomes easier to manage the series of deposits and withdrawals involved in factoring, and a factoring service is provided that can be used even by individual users who have a lower credit rating in financial transactions than corporations.

Figure 7 is an explanatory diagram showing an example of an invoice list screen. Below, we will explain the display screen on terminal 2 and the factoring process based on operations on that screen.

In addition to the list of invoices, the list screen displays a credit score 71, bank account linkage 72, accounting software linkage 73, transaction limit 74, and standard fee 75. Credit score 71 is the user's credit information evaluated based on factors' past transaction performance (history information), etc. Bank account linkage 72 indicates whether or not the system is linked to the system of the financial institution that manages the user's personal account for deposit and withdrawal information in the user's personal account. Accounting software linkage 73 indicates whether or not the system is linked to accounting software. Transaction limit 74 is the total factoring limit set according to the user's credit information. Standard fee 75 is the standard fee for factoring according to the user's credit information.

In addition to the various types of information mentioned above, terminal 2 displays information on each of the multiple invoices issued by the user to each client on the list screen. For example, as shown in FIG. 7, terminal 2 displays the business partner name (client name), invoice amount, invoice date, payment deadline (payment due date), purchase price, etc. for each invoice. Note that although the purchase price is already displayed in FIG. 7, the purchase price displayed on the list screen is a provisional amount, and as described below, server 1 will review the factoring application after accepting it from the user and then determine the specific purchase price.

In addition, terminal 2 displays an application box 76 corresponding to each invoice. When terminal 2 receives an operation input to application box 76, it requests server 1 to purchase the accounts receivable related to the corresponding invoice, and applies for factoring. When it receives an application for factoring from terminal 2, server 1 evaluates the credit information of the user and client related to the invoice, conducts a factoring review based on the credit information, and transfers the purchase amount of the accounts receivable to the user's personal account depending on the review results.

First, server 1 refers to user evaluation table 143 to evaluate credit information that indicates the creditworthiness of the user, who is the creditor of the accounts receivable. Specifically, server 1 reads the user's past factoring performance, i.e., history information, from invoice DB 142, and determines the user's rating according to the user's history information. For example, server 1 determines the user's rating as anywhere from "AAA" to "N" according to the user's past rating, the number of factorings, the amount, the presence or absence of delayed or uncollectible cases, and other user information.

Next, the server 1 refers to the client evaluation table 144 to evaluate the credit information of the client who is the debtor of the accounts receivable. Specifically, like the user, the server 1 refers to the client's past factoring performance, i.e., historical information, and determines the rating based on the client's past ratings, the number of factorings, the amount, the presence or absence of delayed or uncollectible cases, and other client information.

If the client listed on the invoice as the billing destination of the transaction fee is a new client to this system and the client's information is not stored in each database, the server 1 requests the terminal 2 to input the client's information. For example, the server 1 requests the terminal 2 to input the corporate number of the client corporation. Specifically, based on the client name listed on the invoice, the server 1 searches for the corporate number of the corporation that is the same as the client's corporate name using a specified external API (Application Programmable Interface), and outputs the search results to the terminal 2. The user selects the correct client from the search results and notifies the server 1 of the corporate number. The server 1 searches the network N for client information based on the notified corporate number. The server 1 evaluates credit information based on the searched client information.

In this way, if there is no history of factoring and the client cannot be identified by referring to the history information, the server 1 requests the terminal 2 to input a corporate number and evaluates the client's credit information based on the input corporate number. This allows the server 1 to appropriately evaluate the credit information even for new clients.

Based on the credit information of the user and client evaluated above, the server 1 evaluates the creditworthiness of the transaction between the user and client listed on the invoice. Specifically, the server 1 refers to the transaction evaluation table 145 and classifies the transaction into one of multiple transaction clusters that indicate the creditworthiness of the transaction in stages based on the ratings of the user and client. For example, the server 1 classifies the transaction into one of the transaction clusters from "T1" to "N" as shown in Figure 4.

Server 1 determines the purchase limit for approving factoring according to the transaction cluster classified above. Specifically, server 1 refers to transaction cluster DB 146 to determine the automatic screening limit and manual screening limit for factoring. The automatic screening limit is the limit that can be approved in an automatic screening by server 1. The manual screening limit is the limit that can be approved in a manual screening by an administrator. The manual screening limit is set to an amount higher than the automatic screening limit.

The server 1 determines whether the amount of the invoice for which a factoring application has been received from the terminal 2 is equal to or less than the automatic screening limit. If it is determined that the amount is equal to or less than the automatic screening limit, the server 1 approves the factoring and transfers the amount to the user's personal account.

Specifically, server 1 determines the factoring fee based on the transaction cluster classified above and the invoice amount (transaction amount). For example, server 1 refers to fee evaluation table 148 and classifies the invoice for which factoring has been applied into one of multiple fee clusters that define fees in stages. Server 1 refers to fee cluster DB 149 and determines the fee according to the classified fee cluster.

The server 1 outputs the determined fee to the terminal 2 and presents the purchase price of the accounts receivable to the user on a screen not shown. The server 1 then accepts input from the terminal 2 as to whether or not the user agrees with the presented purchase price (fee). If the user agrees, the server 1 determines the purchase price to be the amount requested on the invoice minus the fee, and transfers the purchase price to the user's personal account.

If it is determined that the invoice amount is equal to or greater than the automatic screening limit, the server 1 determines whether the invoice amount is equal to or less than the manual screening limit. If it is determined that the invoice amount is equal to or less than the manual screening limit, the server 1 outputs the invoice data to a specified terminal device (not shown) operated by the administrator. The administrator reviews the output invoice and inputs the review results to the server 1 as to whether or not to approve the factoring.

When performing a manual review, the server 1 requests the terminal 2 to send transaction documents showing that the transaction has actually been carried out, depending on the above-mentioned transaction evaluation (transaction cluster). The transaction documents are, for example, an invoice for the product delivered by the user to the client, an email notifying the completion of delivery, etc., and are documents that the administrator can use as reference in the manual review. The server 1 requests the terminal 2 to send the transaction documents for use in the manual review.

Figure 8 is an explanatory diagram of the process of sending transaction documents. For example, if the transaction cluster is classified as a risk transaction (see Figure 4), the server 1 requests the terminal 2 to send the transaction documents. In this case, the server 1 generates a one-time address as the destination of the transaction documents and outputs it to the terminal 2. Figure 8 shows an example of a display screen of the one-time address sent from the server 1. The terminal 2, in accordance with the user's operation input, attaches a specified attachment file that is the transaction documents and sends an email back to the address. In this way, the server 1 obtains the transaction documents from the terminal 2. For example, the server 1 outputs the information on the screening criteria stored in the document judgment table 147 together with the transaction documents obtained from the terminal 2 and presents them to the administrator (see Figure 4).

The administrator refers to the transaction documents and decides whether to approve the factoring, and enters the results of the review into server 1. If the factoring is approved, server 1 carries out the factoring and transfers the purchase price of the accounts receivable to the user's personal account. Specifically, just as in the case of automatic review, server 1 determines the fee by referring to fee evaluation table 148, and transfers the amount remaining after deducting the fee from the invoice amount to the user's personal account.

If the amount of the invoice for which factoring has been applied exceeds the manual review limit, or if the factoring is not approved by manual review, the server 1 notifies the terminal 2 of the review result that the factoring has not been approved.

In the above, we have explained the case where the accounts receivable (billing amount) is paid by the client as per the transaction and factoring is carried out normally, but there may be cases where the accounts receivable become uncollectible. Therefore, this system also provides a credit guarantee to guarantee a certain amount of the accounts receivable.

Specifically, for transactions where factoring has not been implemented, if the invoice amount has not been deposited in the factoring account by the payment deadline specified in the invoice, the server 1 will provide a credit guarantee for the accounts receivable. In the above case, the server 1 will transfer a specified percentage (e.g. 10%) of the invoice amount that the user invoiced the client on the invoice to the user's personal account as a guarantee amount.

The timing of transferring the guarantee amount is not limited to immediately after the payment deadline, but may be after a predetermined period of time has passed since the payment deadline. In other words, the timing of transferring the guarantee amount should be at least after the payment deadline has passed.

As described above, server 1 uses factoring accounts to purchase accounts receivable and guarantee the receivables. By utilizing a factoring account opened for each user, it becomes easier to manage accounts receivable paid by clients to each user, and even individual users can perform factoring stably and appropriately. In addition, the factoring account is held in the name of the user, and factoring in this embodiment is so-called two-party (two-company) factoring. Therefore, there is no need to notify the client, who is the debtor, of the assignment of the accounts receivable, and it is possible to avoid a situation in which the user's trust in the client is damaged.

9 is a flowchart showing an example of a processing procedure executed by the server 1. The processing contents executed by the server 1 will be described with reference to FIG.
The control unit 11 of the server 1 acquires invoice data issued by the user to the client who is the other party in the transaction (step S11). For example, the control unit 11 may receive invoice data uploaded from the terminal 2, or may cooperate with a specific accounting software used by the user to acquire invoice data from a device of an external service provider that provides the accounting software.

The control unit 11 determines whether the destination of the accounts receivable specified in the acquired invoice is the user's factoring account (purchase account) (step S12). A factoring account is a financial account opened individually by the user to receive factoring services in this system, and is a factoring account that is different from the user's personal account. Specifically, a factoring account is a financial account associated with the financial account (management account) of the administrator of this system who purchases accounts receivable from the user, and is a transfer-only account with an account number issued in association with the account number of the management account and the name of the user. The control unit 11 determines whether the destination of the accounts receivable specified in the invoice is a factoring account opened by the user for factoring.

If it is determined that the account is a factoring account (S12: YES), the control unit 11 associates the acquired invoice data with the user ID and stores (registers) it in the invoice DB 142 (step S13). If it is determined that the account is not a factoring account (S12: NO), the control unit 11 discards the acquired invoice data (step S14). After executing the process of step S13 or S14, the control unit 11 transitions the process to step S15.

In response to a request from terminal 2, control unit 11 outputs to terminal 2 a list of multiple invoices issued by the user to each client (step S15). For example, as shown in FIG. 7, control unit 11 outputs to terminal 2 a list screen showing the user's credit information and a list of the user's invoices.

The control unit 11 accepts a selection input for selecting an invoice for which the accounts receivable is to be purchased, that is, an invoice to be subject to factoring, from the multiple invoices output in step S15 (step S16). When the control unit 11 accepts a selection input for an invoice, it executes a subroutine for the factoring process to purchase the accounts receivable related to the selected invoice from the user and transfer the purchase amount to the user's personal account (step S17).

The control unit 11 judges whether the invoice amount invoiced from the client by the invoice has been deposited from the client to the user's factoring account (step S18). If it is judged that the amount has been deposited (S18: YES), the control unit 11 judges whether factoring has already been performed for the invoice corresponding to the deposited invoice amount, and whether the purchase amount has been transferred to the user's personal account (step S19). If it is judged that the transfer has already been performed (S19: YES), the control unit 11 transfers the invoice amount deposited from the client to the user's factoring account to the management account (step S20). If it is judged that the transfer has not already been performed (S19: NO), the control unit 11 transfers the invoice amount deposited from the client to the user's personal account as is (step S21). After executing the process of step S20 or S21, the control unit 11 ends the series of processes.

If it is determined that the invoice amount has not been paid by the client (S18: NO), the control unit 11 determines whether the payment deadline specified in the invoice has passed (step S22). If it is determined that the payment deadline has not passed (S22: NO), the control unit 11 ends the series of processes. If it is determined that the payment deadline has passed (S22: YES), the control unit 11 transfers a specified guarantee amount corresponding to the invoice amount to the user's personal account (step S23). The control unit 11 ends the series of processes.

10 is a flowchart showing the processing procedure of the factoring subroutine. The processing contents of the subroutine in step S17 will be described with reference to FIG.
The control unit 11 of the server 1 refers to the factoring history information stored in the invoice DB 142 and judges whether the client listed as the invoice recipient on the invoice selected by the user can be identified (step S31). If it is judged that the client cannot be identified (S31: NO), the control unit 11 outputs a request to input the corporate number of the client to the terminal 2 and accepts the input of the corporate number from the terminal 2 (step S32). For example, the control unit 11 uses a predetermined external API to search for the corporate number of the corporation that is the same as the client name and outputs the search result to the terminal 2. The terminal 2 performs a selection input to select the correct client as the invoice recipient from the search result. As a result, the control unit 11 acquires the corporate number of the client. The control unit 11 acquires the information of the client from the network N based on the acquired corporate number (step S33).

After step S31 is YES or the processing of step S33 is executed, the control unit 11 reads the factoring history information of the user and the client from the invoice DB 142, and evaluates (sets) credit information indicating the degree of credit for both the user and the client (step S34). Specifically, the control unit 11 evaluates the user's credit information based on the user's past track record such as the number of factorings, amount, and rating, based on the user evaluation table 143. The control unit 11 also evaluates the credit information of the client based on the client evaluation table 144. Note that if client information is obtained based on the corporate number in step S33, the server 1 evaluates the credit information based on the obtained client information.

The control unit 11 evaluates the creditworthiness of a transaction between the user and the client for factoring, based on the credit information of the user and the client (step S35). Specifically, as described above, the control unit 11 classifies the transaction into categories (transaction clusters) that indicate the creditworthiness of the transaction in stages, based on the credit information of the user and the credit information of the client. The control unit 11 determines whether the transaction between the user and the client is rated above a predetermined level (step S36). In other words, the control unit 11 determines whether the transaction cluster classified in step S35 is a transaction cluster with a rating above a predetermined level.

If it is determined that the transaction is evaluated at or above a predetermined value (S36: YES), the control unit 11 refers to the transaction cluster DB 146 and determines the factoring purchase limit (step S37). Specifically, the control unit 11 determines the automatic review limit to be approved in an automatic review by the server 1 and the manual review limit to be approved in a manual review by the administrator.

The control unit 11 determines whether the invoice amount for which the user has applied for factoring is equal to or less than the automatic screening limit (step S38). If it is determined that the invoice amount is not equal to or less than the automatic screening limit (S38: NO), the control unit 11 determines whether the invoice amount is equal to or less than the manual screening limit (step S39).

If it is determined that the amount is equal to or less than the manual screening limit (S39: YES), the control unit 11 issues an address to which transaction materials indicating that a transaction has been conducted between the user and the client are sent according to the evaluation of the transaction in step S35, and notifies the user's terminal 2 (step S40). Specifically, if the control unit 11 evaluates a transaction related to an invoice for which factoring has been applied as a risk transaction, it issues a one-time address and notifies the terminal 2. The control unit 11 obtains the transaction materials sent to the address from the terminal 2 (step S41). For example, the control unit 11 obtains a delivery note, delivery completion email, etc. from the user to the client as transaction materials. The administrator examines whether or not to approve the factoring with reference to various information including the transaction materials, and inputs the examination results to the server 1. The control unit 11 determines whether or not to approve the factoring according to the examination results entered by the administrator (step S42).

If the answer is NO in step S36, S39, or S42, the control unit 11 outputs the review result indicating that the factoring was not approved to the terminal 2 (step S43) and returns the subroutine.

If the answer is YES in step S38 or S42, the control unit 11 refers to the fee evaluation table 148 and calculates the fee associated with the factoring (step S44). The control unit 11 outputs the fee to the terminal 2 and confirms consent. The control unit 11 determines whether the user has consented to the fee based on the operation input on the terminal 2 (step S45). If it is determined that the user has not consented to the fee (S45: NO), the control unit 11 returns to the subroutine.

If it is determined that the fee has been agreed to (S45: YES), the control unit 11 transfers the purchase amount, which is the amount claimed in the invoice minus the fee, to the user's personal account (step S46). The control unit 11 stores the factoring information related to the invoice in the invoice DB 142 and returns the subroutine.

In the above, it has been assumed that the user who is the creditor of the accounts receivable is an individual, but the creditor may also be a corporation such as a company. Similarly, the client who is the debtor may also be an individual rather than a corporation.

Although the server 1 passively accepts factoring applications from users and transfers funds, this embodiment is not limited to this, and a push notification may be sent to users to encourage factoring. For example, the server 1 sends a push notification to each user's terminal 2 to encourage factoring at a predetermined time when it is expected that user demand will increase (e.g., the end of the month, weekend, etc.). This stimulates user demand and encourages use of the system.

As described above, according to this embodiment, a factoring account (purchase account) dedicated to factoring, which is different from the user's personal account (financial account), is opened for each user, and factoring is performed using that factoring account. By utilizing the factoring account opened for each user, it becomes easier to manage accounts receivable paid by clients to each user, and even individual users can carry out factoring appropriately.

In addition, according to this embodiment, the factoring account is a transfer-only account to which an account number is issued in association with the account number of the management account (financial account) of the manager who performs the factoring and the name of the user. This makes it easier to manage deposits and withdrawals related to accounts receivable, prevents situations that could damage the user's credibility with clients, and allows factoring for individuals to be implemented more appropriately.

In addition, according to this embodiment, by accepting factoring applications from terminal 2 and performing factoring on invoices for which an application has been made, it is possible to improve user convenience.

In addition, this embodiment can provide a credit guarantee, improving the stability of transactions for users.

In addition, according to this embodiment, the invoices to be factored can be selected from the invoice list screen, further improving user convenience.

In addition, according to this embodiment, the credit information of the user and client is evaluated and examined before factoring is carried out, and the purchase limit and fees are determined. This allows the system to be operated appropriately.

In addition, according to this embodiment, even for clients (corporations) with no track record (history) of factoring, credit information can be evaluated based on the corporate number, making it possible to avoid situations in which factoring becomes impossible.

In addition, according to this embodiment, by obtaining transaction documents from the user, a more accurate review can be carried out.

In addition, according to this embodiment, a push notification may be sent at a predetermined time when it is expected that the demand for factoring will increase, urging the user to apply for factoring. This can increase user convenience.

The embodiments disclosed herein are illustrative in all respects and should not be considered limiting. The scope of the present invention is indicated by the claims, not by the meaning described above, and is intended to include all modifications within the scope and meaning equivalent to the claims.

1 Server (information processing device)
11 Control unit 12 Main memory unit 13 Communication unit 14 Auxiliary memory unit P Program 141 User DB
142 Invoice DB
143 User evaluation table 144 Client evaluation table 145 Transaction evaluation table 146 Transaction cluster DB
147 Document judgment table 148 Fee evaluation table 149 Fee cluster DB

Claims (6)

A remaining receivable amount obtained by subtracting the total amount of the receivables related to the invoices for which the receivables have already been repaid from the upper limit of the receivables receivable transaction amount specified for each user is displayed on the display unit;
displaying on the display unit a list of a plurality of invoices issued by the user to the counterparty of a transaction;
accepting a selection input for selecting an invoice for which an account receivable is to be purchased from the plurality of invoices;
When a transaction evaluation between the user and the other party of the transaction is equal to or higher than a predetermined evaluation, a storage unit that stores the transaction evaluation and the screening limit amount in association with each other is referred to to determine a screening limit amount corresponding to the transaction evaluation ,
An information processing method that causes a computer to execute a process of transferring the amount of the selected invoice minus a fee as the purchase amount to the user's financial account if the amount of the selected invoice is equal to or less than the determined screening limit. The information processing method according to claim 1 , further comprising displaying a graph showing the upper transaction limit, the total resale price, and the remaining resale price. displaying on a display unit credit information representing the degree of credit of the user according to history information regarding the purchase of accounts receivable ;
displaying on the display unit a list of a plurality of invoices issued by the user to the counterparty of a transaction;
receiving a selection input for selecting, from the plurality of invoices, the invoice for which the purchase of the accounts receivable is to be offered;
When a transaction evaluation between the user and the other party of the transaction is equal to or higher than a predetermined evaluation, a storage unit that stores the transaction evaluation and the screening limit amount in association with each other is referred to to determine a screening limit amount corresponding to the transaction evaluation,
If the billing amount of the selected invoice is equal to or less than the determined screening limit, the amount obtained by deducting a handling fee from the billing amount is transferred to the financial account of the user as the purchase amount.
An information processing method for causing a computer to execute processing . A list of multiple invoices issued by the user to the counterparty of a transaction is displayed on the display unit;
The invoice is an invoice that designates a payment destination of an individual purchase account for each user for purchasing accounts receivable, the individual purchase account being different from the financial account of the user,
accepting a selection input for selecting an invoice for which an account receivable is to be purchased from the plurality of invoices;
When a transaction evaluation between the user and the other party of the transaction is equal to or higher than a predetermined evaluation, a storage unit that stores the transaction evaluation and the screening limit amount in association with each other is referred to to determine a screening limit amount corresponding to the transaction evaluation,
If the billing amount of the selected invoice is equal to or less than the determined screening limit, a remittance request is output to a management device that manages the remittance account to remit the amount obtained by deducting a handling fee from the billing amount to the financial account of the user.
An information processing method for causing a computer to execute processing . A remaining receivable amount obtained by subtracting the total amount of the receivables related to the invoices for which the receivables have already been repaid from the upper limit of the receivables receivable transaction amount specified for each user is displayed on the display unit;
displaying on the display unit a list of a plurality of invoices issued by the user to the counterparty of a transaction;
accepting a selection input for selecting an invoice for which an account receivable is to be purchased from the plurality of invoices;
When a transaction evaluation between the user and the other party of the transaction is equal to or higher than a predetermined evaluation, a storage unit that stores the transaction evaluation and the screening limit amount in association with each other is referred to to determine a screening limit amount corresponding to the transaction evaluation ,
A program that causes a computer to execute a process of transferring the amount of the selected invoice minus a handling fee as the purchase amount to the user's financial account if the amount of the selected invoice is equal to or less than the determined screening limit. An information processing device including a control unit,
The control unit is
A remaining receivable amount obtained by subtracting the total amount of the receivables related to the invoices for which the receivables have already been repaid from the upper limit of the receivables receivable transaction amount specified for each user is displayed on the display unit;
displaying on the display unit a list of a plurality of invoices issued by the user to the counterparty of a transaction;
accepting a selection input for selecting an invoice for which an account receivable is to be purchased from the plurality of invoices;
When a transaction evaluation between the user and the other party of the transaction is equal to or higher than a predetermined evaluation, a storage unit that stores the transaction evaluation and the screening limit amount in association with each other is referred to to determine a screening limit amount corresponding to the transaction evaluation ,
When the billing amount of the selected invoice is equal to or less than the determined screening limit, the information processing device transfers the amount obtained by deducting a handling fee from the billing amount to the financial account of the user as a purchase amount.

Images