JP2023001390A - Information processing method, program, and information processing apparatus - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an information processing method, or the like, for allowing a personal user to use a factoring service.

SOLUTION: An information processing method causes a computer to execute processing of: receiving settings on association with accounting software used by a user and configured to generate an invoice and send the invoice to a partner; displaying, on a display unit, a list of invoices issued from the user to the trading partner and acquired from an external device that provides the accounting software; displaying a service charge required for purchasing accounts receivable; and outputting a purchase request to purchase the accounts receivable at a purchase price in accordance with the amount billed in the invoice selected out of the multiple invoices for applying for purchasing the accounts receivable.

SELECTED DRAWING: Figure 1

COPYRIGHT: (C)2023,JPO&INPIT

Description

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

One of the financial services is a factoring service that purchases accounts receivable from a creditor and collects the accounts receivable from a debtor. For example, Patent Document 1 discloses a factoring system for factoring electronically recorded monetary claims stipulated in the Electronically Recorded Monetary Claims Act.

JP 2015-204063 A

However, as described in Patent Document 1, factoring is generally performed between corporations, and it has been difficult for individuals to use factoring services.

An object of one aspect is to provide an information processing method or the like that allows even an individual user to use a factoring service.

In one aspect, the information processing method accepts a setting for linking with accounting software used by the user that creates an invoice and sends it to the other party, and the user sends the displaying a list of a plurality of issued bills obtained from an external device that provides the accounting software on a display unit, and displaying a fee required when purchasing accounts receivable; The computer is caused to execute a process of outputting a purchase request to purchase the accounts receivable from the plurality of bills at a purchase amount corresponding to the billing amount of the bill selected for applying for the purchase of the accounts receivable.

In one aspect, even individual users can use the factoring service.

It is a schematic diagram which shows the structural example of a factoring system. It is a block diagram which shows the structural example of a server. FIG. 4 is an explanatory diagram showing an example of record layouts of a user DB, an invoice DB, a user evaluation table, and a client evaluation table; FIG. 4 is an explanatory diagram showing an example of record layouts of a transaction evaluation table, transaction cluster DB, and material determination table; FIG. 4 is an explanatory diagram showing an example of record layouts of a fee evaluation table and a fee cluster DB; It is an explanatory view showing an outline of a factoring system. FIG. 10 is an explanatory diagram showing an example of an invoice list screen; It is explanatory drawing regarding the transmission process of transaction data. 4 is a flow chart showing an example of a processing procedure executed by a server; It is a flowchart which shows the processing procedure of the subroutine of factoring.

Hereinafter, the present invention will be described in detail based on the drawings showing its embodiments. (Embodiment)
FIG. 1 is a schematic diagram showing a configuration example of a factoring system. In this embodiment, a factoring system that provides factoring services for individual users will be described. The factoring system has an information processing device 1, 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 types of information processing and transmission/reception of information, and is, for example, a server device, a personal computer, or the like. In the present embodiment, the information processing device 1 is assumed to be a server device, and the information processing device 1 is replaced with the server 1 for the sake of simplicity in the following description. The server 1 is a management device that manages the factoring service related to this system, and performs processes such as management of financial accounts used for factoring, screening accompanying factoring, and remittance to users.

As will be described later, in this embodiment, the server 1 performs factoring for individual users. Specifically, the server 1 performs a transaction between an individual user (sole proprietor, etc.) and a counterparty to a transaction (hereafter referred to as a “client”) who requests the user to receive delivery of goods, etc. Factoring is performed to purchase accounts receivable generated by transactions and pay the user the amount after deducting a commission from the accounts receivable.

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

FIG. 2 is a block diagram showing a configuration example of the server 1. As shown in FIG. The server 1 includes a control section 11 , a main storage section 12 , a communication section 13 and an auxiliary storage section 14 .
The control unit 11 has an arithmetic processing unit such as one or more CPU (Central Processing Unit), MPU (Micro-Processing Unit), GPU (Graphics Processing Unit), etc., and executes the program P stored in the auxiliary storage unit 14. By reading and executing, various information processing, control processing, etc. related to the server 1 are performed. The main storage unit 12 is a temporary storage area such as SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), flash memory, etc., and temporarily stores data necessary for the control unit 11 to perform arithmetic processing. Remember. The communication unit 13 includes a processing circuit and the like for performing processing related to communication, and transmits and receives information to and from the terminal 2 and the like.

The auxiliary storage unit 14 is a large-capacity memory, a hard disk, or the like, and stores programs 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 material determination table 147, a fee evaluation table 148, and a fee cluster DB 149. ing.

The user DB 141 is a database that stores information on each user. The bill DB 142 is a database that stores bill data issued by each user to a counterparty of the transaction. The user evaluation table 143 is a table for performing user credit evaluation. The client evaluation table 144 is a table for credit evaluation of the client who is the counterparty of the transaction. The transaction evaluation table 145 is a table for evaluating the degree of credibility, ie, how credible the transaction between the user and the client is in factoring, based on the credit information of the user and the client.

The transaction cluster DB 146 is a database that stores information on categories (hereinafter referred to as “transaction clusters”) representing the degree of credit of transactions, which are classified in stages according to the evaluation by the transaction evaluation table 145 . The material determination table 147 is a table storing information on transaction materials necessary for examination of transactions. The fee evaluation table 148 is a table for evaluating factoring fees according to transaction clusters and transaction amounts. The fee cluster DB 149 is a database that stores information on fee classifications (hereinafter referred to as “fee clusters”) according to the evaluation by the fee evaluation table 148 .

Incidentally, the auxiliary storage unit 14 may be an external storage device connected to the server 1 . Moreover, the server 1 may be a multicomputer consisting of a plurality of computers, or may be a virtual machine virtually constructed by software.

Further, in the present embodiment, the server 1 is not limited to the configuration described above, and may include, for example, a reading unit for reading information stored in a portable storage medium.

FIG. 3 is an explanatory diagram showing an example of record layouts of the user DB 141, invoice DB 142, user evaluation table 143, and client evaluation table 144. As shown in FIG.
The user DB 141 includes a user ID column, name column, user information column, personal account column, factoring account column, account link column, and accounting link column. The user ID column stores identification information for identifying each user. The name column stores names of users in association with user IDs. The personal account column is associated with the user ID, and is the financial account opened by the individual user at a predetermined financial institution, and the financial account set by the user as the remittance destination of the price (purchase amount) of factoring (hereinafter referred to as (referred to as a “personal account”). The factoring account column stores information of a factoring account, which 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 the account number of the administrator's financial account and the name of the user are issued in association with the account number of the financial institution system. It is a virtual transfer account in The account linkage column stores whether or not the user has given permission to link the deposit/withdrawal information of the user's personal account with this system in association with the user ID. The accounting linkage column is associated with the user ID, and stores whether or not the user has set whether or not to upload invoice data to the server 1 in collaboration with predetermined accounting software used by the user. there is

The invoice DB 142 includes an invoice ID column, a user column, a client column, a transaction amount column, a billing date column, a deadline 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 issued the bill in association with the bill ID. The client column stores the identification information of the client who is the billing destination in association with the invoice ID. The transaction amount column stores the transaction amount between the user and the client, that is, the billed amount of the bill, in association with the invoice ID. The billing date column stores billing dates in association with invoice IDs. The term column stores the term of payment of accounts receivable in association with the invoice ID. The same-day settlement column stores whether factoring (same-day settlement) was performed using this service in association with the invoice ID. "Under examination" in the same-day settlement column means that the administrator is examining whether or not to authenticate factoring. The purchased amount column stores the purchased amount when factoring is performed in association with the invoice ID.

The user evaluation table 143 includes a score column, rating column, status column, criteria column, and transaction limit column. The score column stores a score obtained by digitizing the credit information of the user. The rating column stores the rating given to the user according to the score in association with the score. The status column stores a status representing the user's credit information in association with the score. The criteria column stores various conditions used as score calculation criteria in association with scores. The transaction limit column stores the transaction limit amount to be 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 criterion column. The score column stores scores obtained by digitizing the client's credit information. The rating column stores the rating given to the client according to the score in association with the score. The status column stores a status representing the client's credit information in association with the score. The criteria column stores various conditions used as score calculation criteria in association with scores.

FIG. 4 is an explanatory diagram showing an example of record layouts of the transaction evaluation table 145, transaction cluster DB 146, and material determination table 147. As shown in FIG.
The transaction evaluation table 145 is a correspondence table in which ratings of users and clients are associated with classifications (transaction clusters) representing graded degrees of credit of transactions between the users and clients. As shown in FIG. 4, the transaction evaluation table 145 stores transaction clusters from "T1" to "N", which indicate the degree of credit of transactions in stages, in association with user and client ratings. Based on the user's credit information (rating) evaluated according to the user evaluation table 143 and the user's credit information (rating) evaluated according to the client evaluation table 144, the server 1 performs a plurality of transactions between the user and the client. Classify into one of the clusters.

The transaction cluster DB 146 includes a category column, a rating column, an evaluation column, an automatic review limit column, a manual review limit column, a transaction data column, and a PD expected value column. The division column stores the major classification of each transaction cluster. The rating column stores a rating (symbol) representing each transaction cluster in association with the division. The evaluation column stores the evaluation indicated by each transaction cluster in association with the division and rating. The automatic examination limit amount and the manual examination limit amount respectively store the limit amount of factoring to be approved according to the transaction cluster. Specifically, the automatic review limit stores the limit approved by automatic review by the server 1, and the manual review limit stores the limit approved by manual review by the administrator. The transaction data column stores the degree (rating) of the transaction data requested at the time of manual review in association with the classification and rating. The transaction data is data that proves that a transaction has been made between the user and the client, and is used as a reference for the administrator's examination. The PD expected value column stores the probability that the accounts receivable will become uncollectible (so to speak, accident rate) in the transactions classified into each transaction cluster in association with the classification and rating.

The material determination table 147 includes a rating column, a condition standard column, and a required material column. The rating column stores ratings that indicate the degree of necessity of transaction materials. The condition criteria column stores the specific degree (quantity, etc.) of transaction data required for each rating in association with the rating. The required information column stores the specific transaction information that is required in association with the rating.

FIG. 5 is an explanatory diagram showing an example of record layouts of the fee evaluation table 148 and the fee cluster DB 149. As shown in FIG.
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 commission evaluation table 148 stores commission clusters from "C1" to "C10" in association with transaction clusters and transaction amounts. The server 1 determines a commission cluster according to the transaction clusters classified according to the transaction evaluation table 145 and the billing amount (transaction amount) described in the invoice.

The fee cluster DB 149 includes a rating column, an expected PD column, a standard fee column, a collection period column, and a fee column. The rating column stores the rating representing each fee cluster. The expected PD column stores the PD expected value assumed in each commission cluster in association with the rating, similar to the transaction cluster DB 146 . The standard commission column stores the standard commission for each commission cluster in association with the rating. The collection period column stores the period from the issue date of the invoice to the payment deadline, that is, the collection period of the accounts receivable, in association with the rating. The column of commissions stores factoring commissions that are actually charged, which are individual commissions that are varied from the basic commissions according to the collection period, in association with ratings and collection periods.

FIG. 6 is an explanatory diagram showing an overview of the factoring system. Based on FIG. 6, the outline of this system will be described.
As already explained, factoring for individual users is performed in this embodiment. FIG. 6 illustrates how the server 1 performs factoring on accounts receivable generated by a transaction between a user who is an individual and a client who is a corporation. A user is a deliverer who receives a request from a client and delivers products (or services), and a client is a requester who receives delivery of products from the user.

As is generally done, the user issues an invoice for the transaction price to the client after delivery of the product, and requests the payment. However, there will be some time difference between the time of billing and the time of actual payment. In the meantime, the user needs funds, and there is a demand to earn income even if it is some percentage of the accounts receivable.

In response to the above demand, factoring services are provided. Factoring is the purchase of accounts receivable, and is a financial service that purchases accounts receivable from a creditor (deliverer) and collects the accounts receivable from a debtor (client). In this embodiment, the server 1 is a factoring service for individuals, which purchases accounts receivable between a user and a client, and provides a service for the user to settle part of the accounts receivable on the same day.

Factoring processing according to the present embodiment will be described in detail. First, the user issues an invoice and sends it to the client after delivery of the product. The invoice may be sent by mail or e-mail, or may be created and sent using predetermined accounting software provided by an external service provider. The server 1 acquires the bill data via the network N. FIG. For example, the server 1 receives an invoice uploaded from the user's terminal 2 in a predetermined file format (for example, a PDF (Portable Document Format, registered trademark) file). Further, for example, when the user uses accounting software, the server 1 may cooperate with the accounting software to acquire invoice data from the 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) for receiving factoring services at a predetermined financial institution. 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, accounts receivable are deposited and withdrawn via 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 "administrative account"), and the account is associated with the account number of the administrative account and the name of the user. It is a transfer-only account with a number issued. More specifically, the factoring account is a so-called virtual account, and although the account holder is the user, in reality, it is a virtual account in the system of the financial institution associated with the management account that organizes the factoring accounts of each user. financial accounts. In general, a virtual account is used by a company to distinguish payments from each customer. To easily identify accounts receivable deposited in

A user using this system issues an invoice specifying his/her own factoring account as the payment destination (transfer destination) of the transaction fee. As a result, the client deposits the transaction amount (accounts receivable) into the factoring account.

When the server 1 accepts a request for same-day settlement (remittance) of accounts receivable from a terminal 2, that is, an application for factoring, the server 1 immediately remits the purchase amount obtained by deducting a commission from the accounts receivable and remits the purchase amount to the user's personal account. Specifically, as will be described later, the server 1 refers to the user evaluation table 143 and the client evaluation table 144 to obtain 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. Evaluate (set). Then, the server 1 evaluates the degree of credit (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 examines the factoring, and immediately remits the purchased amount after deducting the calculated fee from the management account to the user's personal account for the bills below the limit amount.

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

After the factoring is performed, the account receivable is credited from the client to the user's factoring account. In this case, the server 1 transfers the accounts receivable to a management account that collects the factoring accounts of each user. That is, the server 1 collects accounts receivable.

If the account receivable is deposited into the factoring account without being factored, the server 1 directly transfers the account receivable from the factoring account to the user's personal account. In this way, by utilizing the factoring account in addition to the personal account of the user and the management account of the manager who purchases accounts receivable, the series of deposits and withdrawals associated with factoring is facilitated, and the credit of financial transactions is higher than that of corporations. To provide a factoring service that can be used even by a low-cost individual user.

FIG. 7 is an explanatory diagram showing an example of an invoice list screen. Below, the display screen on the terminal 2 and the factoring process based on the operation on the screen will be described.

The list screen displays a credit score 71, a bank account link 72, an accounting software link 73, a transaction limit 74, and a standard fee 75 in addition to a list of invoices. The credit score 71 is the credit information of the user evaluated according to past transaction results (history information) regarding factoring. The bank account linkage 72 indicates whether or not there is linkage setting between the system of the financial institution that manages the personal account of the user and the present system regarding the deposit/withdrawal information in the user's personal account. Accounting software linkage 73 indicates whether or not there is linkage setting between this system and accounting software. The transaction upper limit 74 is the upper limit total amount of factoring set according to the credit information of the user. A standard commission 75 is a factoring standard commission according to the user's credit information.

In addition to the various types of information described above, the terminal 2 displays information on each of a plurality of bills issued by the user to each client on a list screen. For example, as shown in FIG. 7, the terminal 2 displays the client name (client name), billing amount, billing date, payment deadline (payment deadline), purchase amount, etc. for each invoice. Although the purchase amount is already displayed in FIG. 7, the purchase amount displayed on the list screen is a provisional amount. , determine the specific purchase amount.

Also, the terminal 2 displays an application box 76 corresponding to each bill. When an operation input to the application box 76 is received, the terminal 2 requests the server 1 to purchase the accounts receivable related to the corresponding invoice, and applies for factoring. When an application for factoring is accepted from the terminal 2, the server 1 evaluates the credit information of the user and the client related to the bill, examines the factoring based on the credit information, Transfer the purchase amount of accounts receivable to a personal account.

First, the server 1 refers to the user evaluation table 143 and evaluates the credit information representing the degree of credit of the user who is the obligee of the accounts receivable. Specifically, the server 1 reads the user's past factoring results, that is, history information and the like from the invoice DB 142, and determines the rating of the user according to the user's history information. For example, the server 1 assigns a user's rating from "AAA" to "N" according to the user's past rating, the number of times of factoring, the amount of money, the presence or absence of delayed cases and uncollectible cases, and other user information. Decide on the rating.

Next, the server 1 refers to the client evaluation table 144 and evaluates the credit information of the client who is the debtor of the accounts receivable. Specifically, as in the case of the user, the server 1 refers to the client's past factoring performance, that is, history information, and the client's past rating, number of factorings, amount, delay cases and uncollectible cases The presence or absence, and other client information determines the rating.

If the client listed on the invoice as the billing destination for the transaction fee is a new client for this system and the client information is not stored in each database, the server 1 inputs the client information. to the terminal 2. For example, the server 1 requests the terminal 2 to input the corporation number of the corporation that is the client. Specifically, the server 1 searches for the corporation number of the corporation that is the same as the corporation name of the client based on the client name described in the invoice using a predetermined external API (Application Programmable Interface), and searches for the corporation number. Output the result 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 client information on the network N based on the notified corporate number. The server 1 evaluates credit information based on the retrieved client information.

In this way, if there is no track record of factoring and the client cannot be identified even by referring to the history information, the server 1 requests the terminal 2 to enter the corporate number, and based on the entered corporate number, the client Evaluate the credit information of As a result, the server 1 can appropriately evaluate the credit information of even a new client.

The server 1 evaluates the degree of credit of the transaction between the user and the client described in the bill based on the credit information of the user and the client evaluated above. Specifically, the server 1 refers to the transaction evaluation table 145 and classifies the transaction into one of a plurality of transaction clusters representing the degree of credit of the transaction in stages based on the rating of the user and the client. For example, the server 1 classifies transactions into one of transaction clusters from "T1" to "N" as shown in FIG.

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

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

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

The server 1 outputs the determined commission to the terminal 2 and presents the purchase amount of the accounts receivable to the user on a screen (not shown). Then, the server 1 receives an input from the terminal 2 as to whether or not the purchase price (commission) presented is agreed. When the user agrees, the server 1 sets the purchase amount to the purchase amount obtained by subtracting the handling fee from the billed amount, and remits the purchase amount to the user's personal account.

When determining that the billed amount of the invoice is equal to or greater than the automatic examination limit, the server 1 determines whether the billed amount is less than or equal to the manual examination limit. If it is determined that the amount is equal to or less than the manual examination limit, the server 1 outputs the bill data to a predetermined terminal device (not shown) operated by the administrator. The administrator examines the output bill and inputs the result of the examination into the server 1 as to whether or not to approve the factoring.

When performing manual review, the server 1 requests the terminal 2 to transmit transaction data indicating that the transaction has actually been carried out according to the transaction evaluation (transaction cluster) described above. Transaction materials are, for example, invoices of products delivered by the user to the client, e-mails notifying the completion of delivery, and the like, and are materials that the administrator can refer to in manual examination. The server 1 requests the terminal 2 to transmit transaction data for manual examination.

FIG. 8 is an explanatory diagram relating to transmission processing of transaction data. For example, the server 1 requests the terminal 2 to transmit transaction data when the transaction cluster is classified as risk trading (see FIG. 4). In this case, the server 1 generates a one-time address as the destination of the transaction data and outputs it to the terminal 2 . FIG. 8 shows an example of the display screen of the one-time address transmitted from the server 1. As shown in FIG. The terminal 2 attaches a predetermined attached file, which is transaction data, and sends back an e-mail to the address according to the operation input from the user. As a result, the server 1 acquires the transaction data from the terminal 2 . For example, the server 1 outputs information on examination criteria stored in the material determination table 147 together with the transaction material acquired from the terminal 2, and presents it to the manager (see FIG. 4).

The manager judges whether or not to approve the factoring by referring to the transaction data, and inputs the examination result into the server 1.例文帳に追加When factoring is approved, the server 1 implements factoring and remits the purchase amount of accounts receivable to the user's personal account. Specifically, as in the case of automatic examination, the server 1 refers to the fee evaluation table 148 to determine the fee, and transfers the amount obtained by deducting the fee from the billed amount to the user's personal account.

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

In the above description, the account receivable (billing amount) is received from the client according to the transaction, and factoring is performed normally, but there may be cases where the account receivable becomes uncollectible. Therefore, in this system, a credit guarantee that guarantees a certain amount of accounts receivable is also performed.

Specifically, for transactions that have not been factored, if the invoiced amount has not been deposited into the factoring account from the client even after the payment deadline specified on the invoice has passed, the accounts receivable will be guaranteed. In the above case, the server 1 remits to the user's personal account a predetermined percentage (for example, 10%) of the billed amount billed by the user to the client in the invoice as a guaranteed amount.

Note that the timing of remittance of the guaranteed amount is not limited to immediately after the payment deadline, and may be after a predetermined period has passed from the payment deadline. In other words, the timing of remittance of the guaranteed amount should be at least after the expiration of the payment deadline.

As described above, the server 1 utilizes the factoring account to purchase accounts receivable and guarantee the receivable. By utilizing a factoring account opened for each user, it is possible to easily manage accounts receivables paid from a client to each user, and even individual users can perform factoring stably and appropriately. In addition, the user is the holder of the factoring account, and the factoring in the present embodiment is a so-called two-party (two-company) factoring. Therefore, it is not necessary to notify the client, who is the debtor, of the transfer of the account receivable, and it is possible to avoid a situation in which the user's trust in the client is damaged.

FIG. 9 is a flow chart showing an example of a processing procedure executed by the server 1. As shown in FIG. Based on FIG. 9, the contents of processing executed by the server 1 will be described.
The control unit 11 of the server 1 acquires the data of the bill issued by the user to the client who is the other party of the transaction (step S11). For example, the control unit 11 may receive invoice data uploaded from the terminal 2, cooperate with predetermined accounting software used by the user, and operate an external service provider that provides the accounting software. Bill data may be obtained from the device.

The control unit 11 determines whether or not the account receivable specified in the acquired bill is the user's factoring account (purchase account) (step S12). A factoring account is a financial account opened individually by a user to receive factoring services in this system, and is an account for factoring that is different from the user's personal account. Specifically, the factoring account is a financial account associated with the financial account (management account) of the administrator of this system who purchases the accounts receivable from the user, and the account number of the management account and the name of the user This is a transfer-only account with an associated account number issued. The control unit 11 determines whether or not the payment destination specified in the invoice is the 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 stores (registers) the acquired invoice data in the invoice DB 142 in association with the user ID (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 shifts the process to step S15.

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

The control unit 11 receives a selection input for selecting a bill to apply for purchase of accounts receivable, that is, a bill to be factored from the plurality of bills output in step S15 (step S16). When receiving a selection input of an invoice, the control unit 11 purchases the accounts receivable related to the selected invoice from the user and executes a subroutine of factoring processing for remittance of the purchase amount to the user's personal account ( step S17).

The control unit 11 determines whether or not the billing amount billed to the client by the invoice has been deposited from the client to the user's factoring account (step S18). If it is determined that the payment has been received (S18: YES), the control unit 11 has already factored the bill corresponding to the received invoice amount, and checks whether the purchase amount has been remitted to the user's personal account. Determine (step S19). When it is determined that the remittance has been completed (S19: YES), the control unit 11 transfers the invoiced amount deposited in the user's factoring account from the client to the management account (step S20). If it is determined that the remittance has not been completed (S19: NO), the control unit 11 remits the billed amount received from the client to the user's personal account as it is (step S21). After executing the process of step S20 or S21, the control unit 11 ends the series of processes.

When it is determined that the billed amount has not been received from the client (S18: NO), the control unit 11 determines whether or not the payment deadline specified in the bill has passed (step S22). If it is determined that the payment deadline has not passed (S22: NO), the control unit 11 terminates the series of processes. When it is determined that the payment deadline has passed (S22: YES), the control unit 11 remits a predetermined guarantee amount corresponding to the amount billed in the invoice to the user's personal account (step S23). The control unit 11 ends the series of processes.

FIG. 10 is a flow chart showing the processing procedure of the factoring subroutine. Based on FIG. 10, the processing content of the subroutine of step S17 will be described.
The control unit 11 of the server 1 refers to factoring history information stored in the invoice DB 142, and determines whether or not the client described as the billing destination on the invoice selected by the user can be specified. (step S31). If it is determined that it is not identifiable (S31: NO), the control unit 11 outputs a request to input the corporate number of the client to the terminal 2, and receives 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 same corporation as the client name, and outputs the search result to the terminal 2 . The terminal 2 performs selection input to select the correct client as the billing destination from the search result. As a result, the control unit 11 acquires the corporate number of the client. The control unit 11 acquires information on the client from the network N based on the acquired corporate number (step S33).

YES in step S31, or after executing the process in step S33, the control unit 11 reads the factoring history information of the user and the client from the invoice DB 142, and evaluates the credit information indicating the degree of credit for both the user and the client. (setting) (step S34). Specifically, based on the user evaluation table 143, the control unit 11 evaluates the user's credit information based on the user's past factoring frequency, amount, rating, and the like. The control unit 11 also evaluates the credit information of the client based on the client evaluation table 144 . Note that when the client information is acquired based on the corporate number in step S33, the server 1 evaluates the credit information based on the acquired client information.

The control unit 11 evaluates the degree of credit for factoring transactions between the user and the client according to 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) representing the degree of credit 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 or not the transaction between the user and the client is a predetermined evaluation (step S36). That is, the control unit 11 determines whether or not the transaction cluster classified in step S35 is a transaction cluster with a predetermined rating or higher.

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

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

If it is determined that the amount is equal to or less than the manual review limit (S39: YES), the control unit 11 transmits transaction data indicating that a transaction has been made between the user and the client according to the evaluation of the transaction in step S35. The destination address is issued and notified to the user's terminal 2 (step S40). Specifically, when the control unit 11 evaluates a transaction related to an invoice for which factoring has been applied as a risk transaction, the control unit 11 issues a one-time address and notifies the terminal 2 of it. The control unit 11 acquires the transaction data sent to the address from the terminal 2 (step S41). For example, the control unit 11 acquires a statement of delivery from the user to the client, a delivery completion email, etc. as transaction materials. The manager examines whether or not to approve the factoring by referring to various information including transaction materials, and inputs the examination result into the server 1.例文帳に追加The control unit 11 determines whether or not to approve the factoring according to the examination result input by the administrator (step S42).

In the case of NO in step S36, S39, or S42, the control unit 11 outputs to the terminal 2 an examination result indicating that factoring has not been approved (step S43), and returns the subroutine.

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

If it is determined that the fee has been agreed (S45: YES), the control unit 11 remits the purchased amount obtained by deducting the fee from the invoiced amount to the user's personal account (step S46). The control unit 11 stores factoring information related to the invoice in the invoice DB 142, and returns the subroutine.

In the above description, the user who is the obligee of the accounts receivable is assumed to be an individual, but the obligee may be a legal entity such as a company. Similarly, the client who is the debtor may be an individual rather than a corporation.

In addition, the server 1 passively accepts an application for factoring from the user and performs remittance, but the present embodiment is not limited to this, and a push notification prompting the user for factoring good too. For example, the server 1 sends a push notification prompting factoring to the terminal 2 of each user at a predetermined timing (for example, end of the month, weekend, etc.) at which user demand is expected to increase. As a result, user demand can be aroused, and use of the system can be encouraged.

As described above, according to the present embodiment, a factoring account (purchase account) dedicated to factoring that is different from the user's personal account (financial account) is opened for each user, and factoring is performed using the factoring account. By utilizing the factoring account opened for each user, it becomes easy to manage accounts receivables paid from the client to each user, and even individual users can appropriately perform factoring.

In addition, according to the present embodiment, the factoring account is a transfer-only account in which the account number is issued in association with the account number of the management account (financial account) of the manager who implements factoring and the name of the user. As a result, it is possible to facilitate the management of deposits and withdrawals related to accounts receivable, prevent a situation in which the user's trust in the client is damaged, and perform factoring for individuals more appropriately.

Further, according to the present embodiment, user convenience can be enhanced by accepting an application for factoring from the terminal 2 and performing factoring on the bill for which the application has been made.

In addition, according to the present embodiment, it is possible to provide credit guarantees, thereby enhancing the stability of transactions for users.

Further, according to the present embodiment, invoices to be factored can be selected from the invoice list screen, which further enhances convenience for the user.

In addition, according to the present embodiment, the credit information of the user and the client is evaluated and screened before factoring is implemented, and the purchase limit and fee are determined. This allows the system to be properly operated.

In addition, according to the present embodiment, credit information can be evaluated based on the corporate number even for a client (corporation) that has no track record (history) of factoring, and a situation in which factoring becomes impracticable can be avoided. can be done.

Further, according to the present embodiment, more accurate examination can be performed by obtaining the submission of transaction materials from the user.

Further, according to the present embodiment, a push notification may be sent at a predetermined timing when it is assumed that the demand for factoring will increase, and the user may be urged to apply for factoring. Thereby, user convenience can be improved.

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

1 server (information processing device)
11 Control Unit 12 Main Storage Unit 13 Communication Unit 14 Auxiliary Storage 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 Material Judgment Table 148 Commission Evaluation Table 149 Commission Cluster DB

Claims (10)

Receiving linkage settings with the accounting software used by the user that creates invoices and sends them to the other party,
displaying, on a display unit, a list of a plurality of invoices issued by a user to a transaction counterparty, the list being obtained from an external device that provides the accounting software;
Displays the fee required when purchasing accounts receivable,
outputting a purchase request to purchase the accounts receivable from the plurality of bills at a purchase amount corresponding to the billing amount of the bill selected for applying for the purchase of the accounts receivable Information processing for causing a computer to execute processing Method. 2. The information processing method according to claim 1, further comprising: displaying in the list the invoices for which the accounts receivable have been purchased and the invoices for which the accounts receivable have not been purchased in response to the purchase request. 1. Displaying a remaining purchaseable amount obtained by subtracting the total purchase amount related to the invoice for which the accounts receivable has been purchased from the transaction upper limit amount of the purchase of the accounts receivable specified for each of the users. Or the information processing method according to 2. 4. The information processing method according to claim 3, further comprising: displaying a graph showing the maximum transaction amount, the total purchase amount, and the remaining purchaseable amount. 5. The information processing method according to any one of claims 1 to 4, further comprising: displaying credit information representing creditworthiness of said user according to history information relating to purchase of said accounts receivable. When receiving the selection input of the invoice for applying for the purchase of the accounts receivable, receiving the input of the counterparty's corporate number related to the invoice,
The information processing method according to any one of claims 1 to 5, further comprising: outputting the purchase request including the corporate number. The invoice is an invoice that designates, as a payment destination, an individual purchase account for each user for purchasing accounts receivable, unlike the financial account of the user;
outputting a remittance request for remittance of the purchase amount to the user's financial account to a management device that manages the purchase account, when a selection input of the invoice for applying for purchase of the accounts receivable is accepted; 7. The information processing method according to any one of 6. displaying the purchase amount after deducting the commission for purchasing the accounts receivable on the display unit;
outputting a purchase request to purchase the accounts receivable from the plurality of invoices obtained from the external device providing the accounting software at the balance purchase amount of the invoice selected for applying for the purchase of the accounts receivable; The information processing method according to any one of claims 1 to 7. Receiving linkage settings with the accounting software used by the user that creates invoices and sends them to the other party,
displaying, on a display unit, a list of a plurality of invoices issued by a user to a transaction counterparty, the list being obtained from an external device that provides the accounting software;
Displays the fee required when purchasing accounts receivable,
A program for causing a computer to execute a process of outputting a purchase request to purchase the accounts receivable from the plurality of bills at a purchase amount corresponding to the billing amount of the bill selected to apply for the purchase of the accounts receivable. a reception unit that receives settings for cooperation with accounting software used by the user that creates invoices and sends them to the other party;
a first display unit displaying a list of a plurality of invoices issued by a user to a transaction counterparty and obtained from an external device that provides the accounting software;
a second display unit that displays a fee required when purchasing accounts receivable;
an output unit for outputting a purchase request to purchase the accounts receivable from the plurality of bills at a purchase amount corresponding to the billing amount of the bill selected for applying for the purchase of the accounts receivable. .

Images