Factoring service matching system

Abstract

To provide fairer and more transparent factoring services. [Solution] A factoring service system for buying and selling accounts receivable over a network is provided. The system comprises a client terminal and a server configured to communicate with the client terminal. The server includes a listing reception unit that receives listing requests from the client terminal, a determination unit that determines the creditworthiness of accounts receivable listed via the client terminal, and a listing execution unit that lists accounts receivable determined by the determination unit to meet a predetermined threshold for creditworthiness.

Description

Technical Field

[0001] The present disclosure relates to a system for realizing matching between sellers and buyers of claims in the field of factoring, and more specifically, to a system for realizing online transactions in the form of auctions or the like.

Background Art

[0002] Conventionally, factoring services are known. Factoring refers to a framework and mechanism for realizing capitalization by selling (transferring rights) accounts receivable (uncollected payments) to a purchasing company (factoring company). Note that the factoring framework can be mainly divided into three-party transactions and two-party transactions.

[0003] A three-party transaction is a transaction carried out based on an agreement among three parties: a person who hopes to raise funds, a purchasing company (factoring company), and a debtor (original recipient business). A two-party transaction is a transaction between two parties: a person who hopes to raise funds and a purchasing company (factoring company). In this case, generally, the debtor (original recipient business) is not notified of the fact of the transaction.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] In recent years, with the increasing opacity of the economy, the number of user businesses has been on the rise, and the number of purchasing companies (factoring companies) has also been increasing. Under such circumstances, the examination based on the credit information of debtors has become increasingly strict, and costs such as time and expenses are also on the rise.

[0006] While it offers the advantage of potentially providing funds on the same day, the fees for purchasing accounts receivable can be higher compared to other methods of fundraising. Furthermore, among those seeking funding, there are a significant number of cases where they are unable to obtain the understanding of their customers (prime contractors), and as a result, are forced to conduct transactions between the two companies without notifying their customers.

[0007] In two-party transactions, not only the credit information of the debtor (prime contractor) but also the credit information of the person seeking funding becomes an important factor in the screening process. Therefore, in two-party transactions, the purchase fee is even higher than in three-party transactions, and the factoring company often has the upper hand.

[0008] In addition to increased market competition due to the growing number of factoring companies, factoring companies face the long-standing challenge of difficulty in identifying the needs of those seeking funding. As a result, they are experiencing rising costs for customer acquisition and funding. Consequently, it is becoming increasingly difficult to provide services that satisfy those seeking funding.

[0009] This disclosure aims to resolve the aforementioned challenges faced by both those seeking funding and factoring companies, and to realize the provision of fairer and more transparent factoring services. [Means for solving the problem]

[0010] This disclosure relates to a factoring service system for buying and selling accounts receivable over a network, comprising a client terminal and a server configured to communicate with the client terminal.

[0011] The server comprises a listing reception unit that receives listing requests from the client terminal, a determination unit that determines the creditworthiness of accounts receivable listed via the client terminal, and a listing execution unit that lists accounts receivable that the determination unit has determined to meet a predetermined threshold for creditworthiness.

[0012] According to the factoring service system disclosed herein, the creditworthiness of accounts receivable is determined, and accounts receivable that are determined to meet a predetermined threshold in creditworthiness—that is, accounts receivable that are determined to meet a certain level of creditworthiness—are put up for sale and traded on the network, thereby enabling safer transactions. [Brief explanation of the drawing]

[0013] [Figure 1] This is a network configuration diagram of the factoring service system of this embodiment. [Figure 2] This is a hardware configuration diagram of the factoring service system of this embodiment. [Figure 3] This block diagram shows the user registration flow in the factoring service system of this embodiment. [Figure 4] This flowchart shows the user registration process in the factoring service system of this embodiment. [Figure 5] This flowchart shows the process flow for password reset in the factoring service system of this embodiment. [Figure 6] This flowchart shows the processing flow for registering basic information for simplified assessment in the factoring service system of this embodiment. [Figure 7] This is a flowchart showing the processing flow for receivable registration in the factoring service system of this embodiment. [Figure 8] This flowchart shows the processing flow for setting simplified assessment items (management screen) in the factoring service system of this embodiment. [Figure 9]It is a flowchart showing the process flow of bidding in the factoring service system of this embodiment. [Figure 10] It is a flowchart showing the process flow of winning the bid in the factoring service system of this embodiment. [Figure 11] It is a flowchart showing the process flow of chat processing in the factoring service system of this embodiment. [Figure 12] It is a flowchart showing the process flow of document disclosure processing in the factoring service system of this embodiment. [Figure 13] It is a block diagram showing an overview of screen transitions in the factoring service system of this embodiment.

Mode for Carrying Out the Invention

[0014] Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. FIG. 1 is a network configuration diagram of the factoring service system of this embodiment. The factoring service system is a system for selling (transferring rights) accounts receivable (uncollected payments) to a purchasing company (factoring company). In other words, it is a system for online matching between those who need to raise funds and purchasing companies. In particular, this transaction is realized in an auction format. That is, for the accounts receivable (claims) of those who need to raise funds, purchasing companies submit bids, and the purchasing company with the highest bid amount can purchase them, or the transaction is concluded when the bid amount reaches the desired amount of those who need to raise funds.

[0015] Also, as a feature of this factoring service system, the submitted claims are automatically appraised by the system, the creditworthiness is analyzed and evaluated, and the result is returned as a numerical value, and the price (reference price) is also calculated.

[0016] The factoring service system has a proxy server, a WEB server, and an API server. A proxy server is a server that receives requests from users. Upon receiving a request, it performs SSL encryption. The SSL-encrypted signal is then sent to the web server.

[0017] When a web server receives a signal (request) from a proxy server, it sends that signal to the API server. When an API server receives a signal (request), it activates and executes functions to control and mediate access between servers.

[0018] Each function may use its own server, or a single server may perform multiple functions. Figure 2 is a hardware configuration diagram of the factoring service system of this embodiment.

[0019] A Linux server is a server configured to communicate with various devices via the internet. A Linux server can also be configured to be accessible from a separate cloud storage service.

[0020] This Linux server will implement Docker containers. The advantages and benefits of Docker include the ability to easily set up the environment, enable lightweight and rapid development, and allow for postponing consideration of physical servers during the development phase (physical servers are not required).

[0021] A Docker container includes (implements) a database (DB), an API, a web, and a web server, either as hardware, software, or functionality. One example of a database is MySQL. MySQL is an open-source SQL relational database management system managed and supported by Oracle.

[0022] An API is an interface used for software to exchange information and data with each other, making communication between software programs easy. Laravel is an example of an API. Laravel is a web application framework known as a general-purpose framework with a wide range of features.

[0023] In the web, one example is next.js. next.js is a front-end framework. More specifically, it is a framework that streamlines development by using the JavaScript language to build UIs on websites, based on a library.

[0024] One example of a web server is nginx. Nginx is a web server software that receives requests from users, processes them, and returns responses to the users.

[0025] Figure 3 is a block diagram showing the user registration flow in the factoring service system of this embodiment. As shown in Figure 3, the registration process begins with the client terminal (hereinafter referred to as the client terminal) displaying a new registration screen. The new registration screen displays a seller CTA button (hereinafter referred to simply as the button) for registering as a seller, and a buyer button for registering as a buyer. Pressing either button will take you to the screen where you can enter the information required for registration. If you wish to register as both a seller and a buyer, you will need to complete the registration process for each separately.

[0026] The user enters and selects the necessary information according to the input fields and selection fields shown on the input screen. The information required for registration (input) includes, at a minimum, name (or company name and representative's name if applicable), address, telephone number, email address, gender, and trading account information (account information for deposits). Individuals will also be required to provide official identification documents such as a driver's license or resident registration certificate, while corporations will be required to provide official documents such as a certified copy of their company registration.

[0027] Furthermore, from the perspective of placing greater importance on the credibility and safety of the listed items, the registration requirements for sellers could be made stricter. In addition, both sellers and buyers must set a User ID and password. The User ID and password are required for logging in.

[0028] The information entered on the input screen is sent from the client terminal to the server upon the user's final confirmation action, such as clicking the "Register" button. When the server receives new user registration information from a client terminal, it stores that information (data) in the user information DB (database).

[0029] Once the server has finished storing (registering) user information in the user information database, a message indicating that the user has been provisionally registered is sent from the server to the client terminal via email. On the client terminal, clicking the URL provided in the email and navigating to that link will send a confirmation to the server that the action has been performed (the registration process).

[0030] On the server, upon confirmation that the registration operation has been performed on the client terminal, the server stores information indicating that authentication has been completed in the email authentication information database and completes the registration. After this series of processes, user registration is completed, and the user becomes able to use the factoring service system.

[0031] We will explain user registration in more detail. Figure 4 is a flowchart showing the user registration process in the factoring service system of this embodiment.

[0032] When a user performs a specific operation on their terminal (client terminal) to register a user, such as pressing the "New Registration" button, the new registration screen is displayed. On the new registration screen, the user first selects the type of registrant. Specifically, they choose whether to be a "seller" who lists accounts receivable or a "buyer" who purchases accounts receivable.

[0033] Then, you will enter the required information depending on whether you are a "seller" or a "buyer." In addition, individuals will need to attach (upload) identification documents such as a driver's license or resident registration certificate, or other official documents such as a company registration certificate if they are a corporation.

[0034] The entered information is sent to the server. The server stores the user information received from the client terminal in the user information database. Once the server stores user information in the user information database, it sends an email message to the client terminal indicating that the user has been provisionally registered.

[0035] On the client terminal, clicking the URL provided in the temporary registration email sent from the server and navigating to that link confirms that the operation has been performed (the operation of final registration) and is sent back to the server.

[0036] On the server, upon confirmation that the registration operation has been performed on the client terminal, the server stores information indicating that authentication has been completed in the email authentication information database and completes the registration. Once registration is complete, a confirmation message will be sent from the server to the client terminal. Furthermore, if you are a "seller," you will be able to list items after approval on the management screen.

[0037] After this series of processes, user registration is completed, and the user becomes able to use the factoring service system. Figure 5 is a flowchart showing the process flow for password reset in the factoring service system of this embodiment.

[0038] If you forget your password, you can click a button (link) such as "Forgot your password?" displayed on the user ID and password input screen to be taken to a screen where you can enter your registered email address. After entering your registered email address on that screen and clicking "Submit," a request to reset your password is sent from the client terminal to the server. Upon receiving the request, the server sends an email to the client terminal containing a link to a URL where you can reset your password. On the client terminal, you can click the URL in the email to go to a screen where you can reset your password. On that screen, you can enter (set) a new password and click "Register," sending a request to reset your password to the server. Upon receiving the password reset request from the client terminal, the server overwrites the password in the user information database with that password, completing the password reset.

[0039] Figure 6 is a flowchart showing the processing flow for registering basic information for simplified assessment in the factoring service system of this embodiment. This process involves inputting (registering) information about the claim to be put up for auction, analyzing and evaluating the claim based on the registered basic information (referred to here as a "simplified assessment"), and calculating and registering its value (specifically, an amount). However, it is important to note that this amount is not intended to be used as the listing price or desired winning bid price when putting the claim up for auction, but rather as a reference amount only.

[0040] It is assumed that the seller will ultimately manually enter (set) the listing price, winning bid price (desired winning bid price), and buy-it-now price, based on the amount calculated through the preliminary assessment. This process first retrieves basic information for the simplified assessment from the database. Then, it transitions to the screen displaying the basic information for the simplified assessment. Next, it determines whether the basic information for the simplified assessment is image data or not. If it is image data, the image data is stored on the external service server. If it is not image data, it is saved back to the original database.

[0041] In the simplified assessment, the target debt is evaluated (assessed) based on past data stored in the database, including information on similar debts and transaction history. In addition to past data stored in the database, any data that can be obtained, such as data that can be obtained by accessing other external databases or storage, or data that can be obtained via the internet, may be used.

[0042] Figure 7 is a flowchart showing the processing flow for receivable registration in the factoring service system of this embodiment. In this process, clicking the "Register Bond" button displays the bond registration screen. Following the instructions on the bond registration screen, you are first prompted to enter simplified assessment items for a preliminary assessment. Once the simplified assessment items are entered according to the input screen, the entered items are stored in the database. Next, you enter the actual bond information. The system determines whether the entered bond information is image data or not. If it is image data, the image data is stored on the external service server. If it is not image data, it is stored in the database.

[0043] Figure 8 is a flowchart showing the flow of the setting process for configuring simplified assessment items in the factoring service system of this embodiment. This setting process is performed on what is known as the management screen.

[0044] This process is accessed by clicking the "Settings" button for the simplified assessment items in the administration panel. When this process is initiated, the simplified assessment item settings screen will be displayed first. The simplified assessment item settings screen displays a list of basic information items that make up the simplified assessment item, and it is configured so that you can select and set any item from these basic information items.

[0045] The basic assessment items include, at a minimum, information about the customer of the accounts receivable, the amount of the accounts receivable, the attributes and type of accounts receivable (invoice, delivery note, etc.), the effective date (invoice issuance date, etc.), and the payment deadline (invoice payment deadline, etc.). Additionally, copies of documents (invoice copies) can also be included as items. In this case, uploading image data of the document copies (invoice copies) will be required.

[0046] Select (set) any item and click the "Confirm" button to retrieve the selected basic information from the database. Next, for each of the selected basic information items, i.e., the simplified assessment items, enter placeholders, options, scores, etc., according to the input format. In other words, enter an assessment value for each of the simplified assessment items.

[0047] The assessment values ​​can be entered by a person based on their judgment, or they can be automatically calculated and entered by an evaluation function implemented in the system (calculation by the application). Alternatively, the calculation can be performed automatically by the system (computer), and a person can enter the values ​​based on (or referencing) the calculation results.

[0048] Once input is complete, the entered values ​​are stored in the designated database. In this disclosure, the system may perform an assessment of whether the accounts receivable are genuine and authentic. This assessment may be performed using, for example, at least one of the following criteria: • Whether the customer actually exists (for example, whether they can obtain a corporate number, etc.) • Check if there are any abnormal values ​​in the accounts receivable amount (for example, if it is significantly higher / lower than the average or a predetermined threshold). • Check if there are any abnormal values ​​in the dates on the documents in question (such as invoices) (for example, the date is a date that does not actually exist, the issue date and payment due date are reversed, the year is incorrect, etc.) • Are there any errors in other documents (such as invoices)? (e.g., typographical errors, missing required information, inconsistent fonts, presence or absence of seals / stamps, smudged or misaligned stamps, double stamps, etc.) • The documents in question (invoices, etc.) themselves are dirty, torn, or otherwise damaged. Regarding the anomalies in the target documents mentioned above, one possible approach is to perform image analysis (image processing) on ​​the uploaded image data, and then have a computer automatically make a judgment and determination based on the results of the image analysis. Alternatively, while the computer performs the image analysis, the final decision may be made by a human.

[0049] Based on the above evaluation, a function may be implemented to assign a score to the authenticity (creditworthiness) of accounts receivable. For example, a scoring system out of 100 points could be used. Alternatively, the results could be returned using a 10-point scale, a 5-point scale, or an A / B / C scale.

[0050] Furthermore, such evaluations may be linked to the simplified assessment described above. Specifically, accounts receivable that are highly valued (i.e., have high authenticity and creditworthiness) may be assessed on a positive side (higher price). Conversely, accounts receivable that are poorly valued (i.e., have low authenticity and creditworthiness) may be assessed on a negative side (lower price).

[0051] Figure 9 is a flowchart showing the bidding process in the factoring service system of this embodiment. This process is, so to speak, part of the process (function) that realizes online transactions in an auction format.

[0052] This process is initiated by clicking the "Bid" button on the factoring service system's interface screen. When the "Bid" button is clicked, the user is first taken to a list of accounts receivable. This list screen may be configured to display accounts receivable that are currently listed and available for bidding, accounts receivable that have been successfully bid on, accounts receivable that are scheduled to be listed in the future, etc., according to the user's selection.

[0053] Furthermore, the list of accounts receivable may be configured to allow sorting and display according to factors such as listing date, listing price, listing deadline, debtor, creditworthiness, and fees. Each account receivable entry in the list has a "Details" button attached to it. Clicking this button will take you to a detailed information screen. The detailed information screen displays more detailed information about the account receivable.

[0054] Each accounts receivable has an associated "Bid" button. Clicking this button will take you to the bidding screen. If the "Bid" button is not clicked, you will not be taken to the bidding screen, and the bidding process will not proceed.

[0055] Bidding is conducted in an auction format. The bidding screen displays an input field for entering the bid amount and a bid execution button. After entering the bid amount and clicking the bid execution button, a confirmation screen will appear, such as "Do you want to bid XXXX yen?". Clicking the "Confirm" button on the confirmation screen will execute the bid. Once the bid is executed, the entered bid information is stored in a designated database.

[0056] A bid is valid as long as the bid amount is higher than the auction's starting price or the current price (if bids have been made and a price has been set). However, if another bidder has made a higher bid (the amount entered), the bid will be automatically updated to match the higher bid.

[0057] Figure 10 is a flowchart showing the process of successful bids in the factoring service system of this embodiment. This process is performed on accounts receivable that have been bid on. First, it proceeds when the bidding deadline has passed or when the seller has selected a bidder to accept as the winner. Next, it determines whether 48 hours have passed without the seller canceling their bid. If a bidder cancels their bid within 48 hours, the winning bid is canceled.

[0058] If the bidder does not cancel the transaction within 48 hours, the winning bid becomes valid, and the amount of the winning debt is debited from the bidder's registered account. Subsequently, the amount minus any fees is transferred to the seller's registered account.

[0059] Figure 11 is a flowchart showing the chat processing flow in the factoring service system of this embodiment. The chat function enables text-based communication between the seller and the prospective bidder or bidder. Functions for voice and video call communication may also be implemented.

[0060] The chat function is revealed when the "Chat" button is clicked on the interface screen. First, a list of chat partners is displayed. This list may include both currently active partners who are immediately available for chat and those who are currently inactive and unavailable for chat. However, the system may be configured to display only currently active partners who are immediately available for chat, through selection (settings). Furthermore, a reservation function may be provided to schedule chats for a predetermined date and time.

[0061] Once a chat partner is selected, the chat screen (text input screen) will appear. On the chat screen, you can send a message (text) by typing text and pressing the Enter key, or by clicking the "Send" button. The chat function also allows you to select and send requests to cancel bids or successful bids.

[0062] Figure 12 is a flowchart showing the document disclosure process in the factoring service system of this embodiment. This process can be performed as a function within the chat feature shown in Figure 11. In the chat screen, the buyer can use a "Disclosure Request" button to request disclosure of documents. When this button is clicked, a disclosure request is sent to the seller.

[0063] On the seller's side, when a "disclosure request" is made, an "approve" or "deny" button will be displayed. If "approve" is selected, detailed information about the accounts receivable in question will become viewable on the buyer's screen. If "deny" is selected, the detailed information will not be viewable.

[0064] Figure 13 is a block diagram showing an overview of screen transitions in the factoring service system of this embodiment. From the main screen, users can log in or register new accounts.

[0065] Additionally, the main screen includes a contact form, allowing users to submit inquiries through this form. Upon logging in, users can access the seller page and the buyer page. The seller page allows sellers to list their accounts receivable. The buyer page allows buyers to view information and bid on listed accounts receivable.

[0066] The seller page allows users to enter basic and detailed information about the accounts receivable they wish to sell. Once the necessary information is entered, the accounts receivable can be listed for sale. The seller page also provides a chat screen, allowing users to communicate with buyers via chat.

[0067] When accounts receivable are put up for sale, a buyer who wishes to purchase them submits a bid, and if certain conditions are met, such as no cancellations, the transaction is completed. The following are the specifications and requirements of this system. However, please understand that this is just an example and not necessarily exhaustive, but rather only a part of the system. <Purpose, Target> Accounts receivable auction system Simple appraisal system <Overview> <System Configuration / Plan> • Main page ·Seller • Buying companies ·Administrator Each database • Simple appraisal system <Term definition> -Seller This refers to a business that puts receivables up for auction. - Buying company This refers to a business that wins bids on and purchases debts. -Administrator This refers to a system operating company. - Simple appraisal system This refers to a system that provides a simplified assessment of submitted debts based on its own criteria. -bid This refers to a situation where a buyer offers terms and conditions for a claim put up for sale by an seller. - Successful bid This refers to a situation where a seller puts a claim up for sale, a buyer offers terms, and an agreement is reached between both parties. <Usage Flow Requirements> <Usage Flow> 1. Both the seller and the buyer must register as new users. 2. The seller puts the debt up for sale. 3. The buyer selects the debts they wish to purchase. 4. Buyers bid on the bonds that are being offered for sale. 5. Negotiating terms and conditions between the seller holding the bidded debt and the buyer. 6. The conditions are met and the item is successfully bid on by a buyer. 7. Actually enter into a contract according to the conditions decided on the website (※Execute using the method specified by the buyer). <List of Users> -Seller - Buying company -Administrator <Functional Requirements> <List of Features> - User registration function - Simple appraisal function - Chat function -Notification function - Document upload function -Data storage function <Screen> #User page - Top page - Debt details page - Inquiry page - Log in - Password Reset - Password Reset - New registration - Identity verification screen - Edit basic information - Transaction history confirmation - Business User My Page - Edit basic information - Transaction history confirmation - Chat list - Individual chat #Administration screen - Transaction history - List of receivables - Listing for sale - Bidding in progress - Successful bid - User list - Customer list (filtered to show applications awaiting review) - Customer details (screening result registration) - List of vendors (filtered to those awaiting approval) - Vendor details (screening result registration) - Send message -column - List - New registration -edit - Chat confirmation - Talk List (Newest First) Customer*Vendor Vendor*Customer - Talk details - Registration of debt valuation standards <permissions> - Project Leader -Administrator Only the above-mentioned individuals can make changes. <Forms> The following email will be output by this system. - As a result of registration, you will receive emails tailored to your transaction status. <Information / Data> - Import log data - Detailed log data regarding the import process - Unconfirmed import data <External Interface> - Email Notifications will be sent when there is a new registration, bid, or successful bid. - CSV processing Execute the import process via API.

Claims

[Claim 1] A factoring service system for buying and selling accounts receivable on a network, Client terminal and The server is configured to communicate with the aforementioned client terminal, The aforementioned server, A listing reception unit that receives listing requests from the aforementioned client terminal, A determination unit for determining the creditworthiness of accounts receivable submitted via the client terminal, A listing execution unit that lists accounts receivable for which the determination unit has determined that the creditworthiness meets a predetermined threshold, A factoring service system equipped with [features / equipment].

Images