Proposed server, communication system, delivery method, and program

Abstract

This invention provides a proposal server, communication system, delivery method, and program that make it easier for users to understand their future financial situation. [Solution] In a communication system, a proposal server 3 that provides information via a communication network 100 to a user terminal 1 of a user who provides or plans to provide goods or services to a business partner has a transmitting / receiving unit 31 that receives condition information indicating predetermined conditions for fundraising using documents issued in connection with the goods or services provided by the user terminal 1, and transmits data that constitutes a fundraising screen, which is a fundraising screen that shows the future cash flow situation and is based on information from a specific document that satisfies the predetermined conditions, for the user terminal to receive.

Description

Technical Field

[0001] The present disclosure relates to a proposal server, a communication system, a providing method, and a program.

Background Art

[0002] In the world of business transactions, factoring, which is a method of raising funds by quickly cashing accounts receivable generated by transactions, is widely used.

[0003] For example, Patent Document 1 discloses a method for quickly purchasing accounts receivable while reducing the manual clerical burden by a technique for realizing a procedure for purchasing accounts receivable by factoring in a computer system.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, when a user as a creditor owns various debts, the times when the user can collect the debts are various. In such a situation, when the user tries to raise funds using the debts, there arises a problem that it is difficult to grasp the future cash flow situation.

Means for Solving the Problems

[0006] The invention according to claim 1 is a proposal server that provides information via a communication network to a user terminal of a user who provides or plans to provide goods or services to a business partner, and is characterized by having: a receiving means for receiving condition information indicating predetermined conditions for fundraising using documents issued in connection with the provision of goods or services by the user, transmitted by the user terminal; and a transmitting means for transmitting data that constitutes a fundraising screen, which shows the future state of cash flow and is based on information from a specific document that satisfies the predetermined conditions, for the user terminal to receive. [Effects of the Invention]

[0007] As explained above, the present invention has the effect of making it easier for users to understand their future financial situation by visualizing the future financial situation when the accounting documents used for fundraising are identified. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows the relationships between the companies according to this embodiment. [Figure 2] This is a schematic diagram of the communication system of this embodiment. [Figure 3] This is a hardware configuration diagram of the user terminal, proposal server, funding service server, and credit information server of this embodiment. [Figure 4] This is a functional block diagram of the communication system according to this embodiment. [Figure 5] This is a conceptual diagram of a tenant recurring expense management table. [Figure 6] This is a conceptual diagram of the tenant-specific payment management table. [Figure 7] This is a conceptual diagram of a fundraising information management table. [Figure 8] This is a conceptual diagram of the tenant bank account information table. [Figure 9] This is a conceptual diagram of the tenant credit card management table. [Figure 10]It is a conceptual diagram of the tenant management table. [Figure 11] It is a conceptual diagram of the funding service type management table. [Figure 12] It is a conceptual diagram of the funding service management table. [Figure 13] It is a conceptual diagram of the destination information management table. [Figure 14] It is a conceptual diagram of the credit information adjustment management table. [Figure 15] It is a conceptual diagram of the credit information management table. [Figure 16] It is a conceptual diagram of the recommended candidate information management table. [Figure 17] It is a sequence diagram showing the process of displaying the cash flow screen. [Figure 18] It is a flowchart showing the creation process of the cash flow screen. [Figure 19] It is a diagram showing an example of the display of the cash flow screen. [Figure 20] It is a sequence diagram showing the display process of the cash flow screen and the recommended screen. [Figure 21] It is a flowchart showing the process of narrowing down the recommended information. [Figure 22] It is a flowchart showing the process of the preliminary preparation. [Figure 23] It is a flowchart showing the creation process of the recommended candidate information. [Figure 24] It is a flowchart showing the display process of the cash flow screen and the recommended screen. [Figure 25] It is a diagram showing an example of the display of the cash flow screen reflecting the recommended information in the case of fee rate priority. [Figure 26] It is a diagram showing an example of the display of the recommended screen in the case of fee rate priority. [Figure 27] It is a diagram showing an example of the display of the recommended screen after the display change in the case of fee rate priority. [Figure 28] It is a diagram showing an example of the display of the recommended screen after changing the recommended information in the case of fee rate priority. [Figure 29]This diagram shows an example of how the cash flow screen looks after changing the recommended information to prioritize the commission rate. [Modes for carrying out the invention]

[0009] [Relationships between companies] Figure 1 will be used to explain the relationships between the companies. Figure 1 is a diagram illustrating the relationships between the companies according to this embodiment.

[0010] As shown in Figure 1, Service User Company A is a company that uses a service to receive proposals for recommended funding sources from Proposal Company C. Business Partner Company B is a business partner of Service User Company A. In this case, Service User Company A may be the creditor and Business Partner Company B may be the debtor. Proposal Company C is a company that provides the above service to Service User Company A.

[0011] Furthermore, factoring service company D, accounts receivable secured loan service company E, PO finance service company F, and quotation finance service company G are all companies that provide the services indicated by their names, and are all funding service companies. From the perspective of service user company A, funding service companies are sources of funding.

[0012] Factoring service company D is a collective term for multiple factoring service companies D1, D2, ... Dn. Accounts receivable secured financing service company E is a collective term for multiple accounts receivable secured financing service companies E1, E2, ... En. PO finance service company F is a collective term for multiple PO finance service companies F1, F2, ... Fn. Quotation finance service company G is a collective term for multiple quotation finance service companies G1, G2, ... Gn.

[0013] Credit information service company H is a company that possesses reliability information indicating the trustworthiness of the management of companies such as its business partners, and provides this credit information to the proposing company C. Note that "credit information service company H" is a collective term for multiple credit information service companies H1, H2, ... Hn.

[0014] Here, we will briefly describe the process in this embodiment.

[0015] First, service user company A generates accounts receivable, etc., by providing or planning to provide goods or services to business partner company B (S1). Then, service user company A communicates its desired conditions (prioritizing commission rates, prioritizing risk avoidance) to proposing company C in order to receive proposals for funding sources that meet its requirements from multiple sources (S2). Then, proposing company C obtains credit information of business partner company B from credit information service company H, and comprehensively evaluates this credit information, the contents of the documents, the specified conditions from service user company A, etc., and proposes a specific funding source that is recommended to service user company A (S3).

[0016] As a result, service user company A sends documents to the proposed specific funding source (funding service company) to apply for funding (S4). In response, the specific funding service company provides funding to service user company A after reviewing the application (S5). Furthermore, the specific funding service company requests payment of accounts receivable from client company B (S6). As a result, client company B pays the accounts receivable to the specific funding service company on time (S7).

[0017] [Outline of the communication system] Figure 2 is a schematic diagram of the communication system of this embodiment. Figure 2 shows the terminals or servers of each company in Figure 1.

[0018] User company A has a user terminal 1, such as a PC (personal computer), which is operated by user A1. Proposal company C has a proposal server 3. Factoring service company D, accounts receivable secured loan service company E, PO finance service company F, and quotation finance service company G each have funding service servers 5d, 5e, 5f, and 5g, respectively. Credit information service company H has a credit information server 7. Each server is composed of a computer. User terminal 1, funding service servers 5d, 5e, 5f, and 5g, and credit information server 7 can communicate via a communication network 100 such as the Internet. Hereafter, funding service servers 5d, 5e, 5f, and 5g will be collectively referred to as "funding service server 5".

[0019] [Hardware configuration of the communication system] Next, using Figure 3, we will explain the hardware configuration of each terminal and server that make up the communication system shown in Figure 1. Since all of them have the same configuration, we will explain the hardware configuration of user terminal 1 and omit the explanation of the hardware configuration of each server.

[0020] As shown in Figure 3, the user terminal 1 is composed of a computer and includes a CPU 101, ROM 102, RAM 103, HD 104, HDD (Hard Disk Drive) controller 105, display 106, external device connection I / F (Interface) 108, network I / F 109, bus line 110, keyboard 111, pointing device 112, DVD-RW (Digital Versatile Disk Rewritable) drive 114, and media I / F 116.

[0021] Of these components, the CPU 101 controls the operation of the entire computer. The ROM 102 stores programs used to drive the CPU 101, such as the IPL. The RAM 103 is used as the work area for the CPU 101. The HD 104 stores various data, such as programs. The HDD controller 105 controls the reading or writing of various data to the HD 104 according to the control of the CPU 101. The display 106 displays various information such as cursors, menus, windows, characters, or images. The external device connection I / F 108 is an interface for connecting various external devices. In this case, external devices include, for example, USB (Universal Serial Bus) memory and printers. The network I / F 109 is an interface for data communication using the communication network 100. The bus lines 110 are address buses, data buses, etc., for electrically connecting each component, such as the CPU 101 shown in Figure 3.

[0022] The keyboard 111 is a type of input means equipped with multiple keys for inputting characters, numbers, and various instructions. The pointing device 112 is a type of input means for selecting and executing various instructions, selecting processing targets, and moving the cursor. The DVD-RW drive 114 controls the reading or writing of various data to the DVD-RW 113, which is an example of a removable recording medium. Note that it is not limited to DVD-RW, but may also be DVD-R or Blu-ray Disc (registered trademark), etc. The media I / F 116 controls the reading or writing (storage) of data to the recording medium 115, such as flash memory.

[0023] Furthermore, external device connection interfaces can be used to connect devices such as a microphone (an example of a sound collection device), a speaker (an example of a sound output device), and a camera (an example of an imaging device).

[0024] [Functional Configuration of the Communication System] Next, the functional configurations of the communication system in this embodiment will be described using Figures 3 to 16. Figure 4 is a block diagram of the functional components of the communication system according to this embodiment. Note that the fund provision service server 5 and the credit information server 7 do not have any new functions in the communication processing of this embodiment, so their description will be omitted.

[0025] <Functional Configuration of User Terminals> First, the functional configuration of the user terminal 1 will be explained using Figures 3 and 4. As shown in Figure 4, the user terminal 1 has a transmitting / receiving unit 11, a receiving unit 12, a display control unit 14, a determination unit 15, and a storage / reading processing unit 19. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 101 that follow a program deployed from the HD 104 onto the RAM 103. The user terminal 1 also has a storage unit 1000 constructed from the RAM 103 and HD 104 shown in Figure 3.

[0026] (Functional configuration of each user terminal) Next, the components of the user terminal 1 will be described. The transmitting / receiving unit 11 is implemented by commands from the CPU 101 shown in Figure 3, as well as the external device connection I / F 108 and the network I / F 109, and transmits and receives various data (or information) with other terminals, devices, or systems via the communication network 100.

[0027] The reception unit 12 is mainly implemented by commands from the CPU 101 shown in Figure 3, as well as the keyboard 111 and pointing device 112, and accepts various inputs from the user.

[0028] The display control unit 14 is primarily implemented by instructions from the CPU 101 shown in Figure 3, and displays images by outputting image data to the display 106 or an external display connected to the external device connection I / F 108. The display control unit 14 also has a web browser function.

[0029] The decision unit 15 is mainly implemented by instructions from the CPU 101 shown in Figure 3, and performs various decisions.

[0030] The memory and read processing unit 19 is mainly implemented by instructions from the CPU 101 and the HDD controller 105 shown in Figure 3, and performs processing such as storing various data in the memory unit 1000 and reading various data stored in the memory unit 1000.

[0031] <Proposed Server Functional Configuration> Next, the functional configuration of the proposed server 3 will be explained using Figures 3 to 16. As shown in Figure 4, the proposed server 3 has a transmitting / receiving unit 31, a calculation unit 33, a determination unit 35, a creation unit 36, and a storage / reading processing unit 39. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 101 that follow a program deployed from the HD 104 onto the RAM 103. The proposed server 3 also has a storage unit 3000 constructed from the RAM 103 and HD 104 shown in Figure 3.

[0032] (Tenant recurring expense management table) Figure 5 is a conceptual diagram showing the tenant recurring expense management table. The storage unit 3000 has a tenant recurring expense management DB 3001 constructed, which consists of the tenant recurring expense management table shown in Figure 5. In this table, for each tenant ID used to identify tenants receiving services from the proposing company C (such as service user company A), the past expenditure type, expenditure month, and amount of recurring payments are associated and managed. Based on this table, future recurring payments are predicted.

[0033] (Tenant-specific payment management table) Figure 6 is a conceptual diagram showing the tenant-specific payment management table. The storage unit 3000 has a tenant-specific payment management DB 3002 constructed, which consists of the tenant-specific payment management table shown in Figure 6. In this table, as payment information for each tenant, the following information is associated and managed for each tenant ID: ID, billing source, payment due date, amount, and payment status.

[0034] (Funding Information Management Table) Figure 7 is a conceptual diagram showing the fundraising information management table. The memory unit 3000 has a fundraising information management DB 3003 constructed, which consists of the fundraising information management table shown in Figure 7. This table shows the contents of the documents used for fundraising. Therefore, in this table, for each tenant ID, the ID, trading partner, type of fundraising target, payment deadline, amount, and payment status information, as well as the storage location of the document images digitized as PDFs, etc., are associated and managed. The types of fundraising targets include invoices, purchase orders, and quotations.

[0035] (Tenant bank account management table) Figure 8 is a conceptual diagram showing the tenant bank account management table. The storage unit 3000 has a tenant bank account management DB 3004 constructed, which consists of the tenant bank account management table shown in Figure 8. This table contains information about the user's bank account that they have previously registered with the proposed server 3. Therefore, in this table, the bank name, branch name, account number, user name, and password are associated and managed for each tenant ID.

[0036] (Tenant credit card management table) Figure 9 is a conceptual diagram showing the tenant credit card management table. The memory unit 3000 contains a tenant credit card management DB 3005, which is composed of the tenant credit card management table shown in Figure 9. This table contains information about the user's credit card that they have previously registered with the proposal server 3. Therefore, in this table, the card name (card number), user name, and password are associated and managed for each tenant ID. The amount that can be borrowed using this information will later be used for the cash balance.

[0037] (Tenant management table) Figure 10 is a conceptual diagram showing the tenant management table. The storage unit 3000 has a tenant management DB 3006 constructed, which consists of the tenant management table shown in Figure 10. This table contains information about the tenant's company. Therefore, this table manages the tenant ID, tenant name, tenant address (location), tenant industry, and tenant business type in association with each other. This information is used, for example, when a tenant is in the construction industry, to exclude financing service companies that do not provide funding to the construction industry from consideration.

[0038] (Management table for types of funding services) Figure 11 is a conceptual diagram showing the funding service type management table. The memory unit 3000 has a funding service type management DB 3007 constructed, which consists of the funding service type management table shown in Figure 11. In this table, the types of funds to be raised and the types of funding services (procurement types) are managed in association.

[0039] (Funding Service Management Table) Figure 12 is a conceptual diagram showing the fund provision service management table. The memory unit 3000 has a fund provision service management DB 3008 constructed, which consists of the fund provision service management table shown in Figure 12. This table manages the following information in association with each other: fund provision service type, fund provision service name (company name), industries not supported for fund provision, supported regions for fund provision, support for sole proprietorships for fund provision, fund provision amount conditions, and the connection URL (destination information) to the fund provision service server 5 of the fund provision service company. Note that if the support for sole proprietorships for fund provision is "false", the fund provision service company provides funds to businesses but not to individuals.

[0040] (Destination Information Management Table) Figure 13 is a conceptual diagram showing the destination information management table. The memory unit 3000 has a destination information management DB 3009 constructed, which consists of the destination information management table shown in Figure 13. In this table, the destination name (company name) and connection URL (destination information) for retrieving information are associated and managed for each type of information.

[0041] (Credit Information Adjustment Management Table) Figure 14 is a conceptual diagram showing the credit information adjustment management table. The memory unit 3000 has a credit information adjustment management DB 3010 constructed, which consists of the credit information adjustment management table shown in Figure 14. In this table, the credit levels provided by each credit information service company are associated and managed for each credit level. Since the credit levels set by each credit information service company are different, this table is used to adjust and unify them.

[0042] (Credit Information Management Table) Figure 15 is a conceptual diagram showing a credit information management table. The memory unit 3000 has a credit information management DB 3011 constructed, which consists of the credit information management table shown in Figure 15. In this table, the creditworthiness adjusted in the credit information management table in Figure 15 is associated and managed for each business partner.

[0043] (Recommended Candidate Information Management Table) Figure 16 is a conceptual diagram showing the recommended candidate information management table. The memory unit 3000 has a recommended candidate information management DB 3012 constructed, which consists of the recommended candidate information management table shown in Figure 16. This table shows recommended candidate information, including the contents of the documents used for fundraising. Therefore, this table manages the following information in association with each other: the trading partner, the creditworthiness of the trading partner, the transaction amount shown in the document, the type of fundraising target, the type of fundraising service (fundraising type), the name of the fundraising service (company name), the commission rate when providing funds, and the payment date when funds are paid to the service user company. From this recommended candidate information, the recommended information that will be ultimately proposed to the service user company is extracted.

[0044] (Proposed server's functional configuration) Next, we will explain in detail the functional configurations of the proposed server 3. In addition, when explaining the functional configurations of the proposed server 3, we will also explain the relationship between each component shown in Figure 3 and the main components necessary to realize each functional configuration of the proposed server 3.

[0045] The transmitting / receiving unit 31 of the proposed server 3 shown in Figure 4 is implemented by instructions from the CPU 101 shown in Figure 3 and the network I / F 109, and transmits and receives various data (or information) with other terminals, devices, or systems via the communication network 100.

[0046] The calculation unit 33 is implemented by instructions from the CPU 101 shown in Figure 3 and performs predetermined calculations. The calculation details will be described later.

[0047] The decision unit 35 is implemented by instructions from the CPU 101 shown in Figure 3 and performs a predetermined decision. The details of the decision will be described later.

[0048] The creation unit 36 ​​is implemented by instructions from the CPU 101 shown in Figure 3, and performs tasks such as creating the cash flow screen.

[0049] The memory and read processing unit 39 is implemented by instructions from the CPU 101 and the HDD controller 105 shown in Figure 3, and performs processing such as storing various data in the memory unit 3000 and reading various data stored in the memory unit 3000.

[0050] [Processing or operation of the embodiment] Next, the processing or operation of this embodiment will be described using Figures 17 to 29.

[0051] <Display processing for the cash flow screen> First, we will explain the process of displaying the cash flow screen using Figure 17. Figure 17 is a sequence diagram showing the process of displaying the cash flow screen.

[0052] User A1 makes a login request from user terminal 1 to proposed server 3 (S21). This login request includes a tenant ID and password to identify service user company A, which is an example of a tenant. As a result, the sending / receiving unit 31 of proposed server 3 receives the login request. The determination unit 35 of proposed server 3 then performs authentication by determining whether service user company A is a legitimate tenant receiving the service (S22).

[0053] Next, the transmitting / receiving unit 31 sends a response to the user terminal 1 (S23). As a result, the transmitting / receiving unit 11 of the user terminal 1 receives the response. Now, we will continue by explaining the case where the service user company A is a legitimate tenant.

[0054] When user A1 operates user terminal 1, the reception unit 12 receives a request to display the cash flow screen (S24). Then, the transmitting / receiving unit 11 sends a request for cash flow screen data to the proposal server 3 (S25). As a result, the transmitting / receiving unit 31 of the proposal server 3 receives the request for cash flow screen data.

[0055] Next, the proposed server 3 performs the process of creating the cash flow screen (S26). Here, the process of creating the cash flow screen will be explained in detail using Figure 18. Figure 18 is a flowchart of the process of creating the cash flow screen.

[0056] (Process for creating the cash flow screen) As shown in Figure 18, the storage and retrieval processing unit 39 retrieves the corresponding tenant recurring expense information by searching the tenant recurring expense management DB 3001 (see Figure 5) using the tenant ID used during authentication as the search key (S101). The storage and retrieval processing unit 39 also retrieves the corresponding tenant individual payment information by searching the tenant individual payment management DB 3002 (see Figure 6) using the same tenant ID as the search key (S102). Then, the calculation unit 33 calculates the expenditure information for each target period (in this case, one month) to be displayed based on the tenant recurring expense information and the tenant individual payment information (S103). Note that the target period may be expressed as a predetermined period.

[0057] Next, the memory and retrieval processing unit 39 retrieves the corresponding fundraising information by searching the fundraising information management DB 3003 (see Figure 7) using the tenant ID as the search key (S104). Then, the calculation unit 33 calculates the revenue information for each target period (S105).

[0058] Next, the storage and retrieval processing unit 39 retrieves the corresponding tenant bank account information by searching the tenant bank account management DB 3004 (see Figure 8) using the tenant ID as the search key (S106). The storage and retrieval processing unit 39 also retrieves the corresponding tenant credit card information by searching the tenant credit card management DB 3005 (see Figure 9) using the tenant ID as the search key (S107). Then, the calculation unit 33 calculates the cash balance for each target period (S108).

[0059] Next, the creation unit 36 ​​uses the calculation results obtained in steps S103, S105, and S108 to create a cash flow screen as shown in Figure 19 (S109). Figure 19 is a diagram showing an example of the cash flow screen display. With this, the cash flow screen creation process is completed.

[0060] Next, returning to Figure 17, the display control unit 14 of the user terminal 1 uses its web browser function to display the initial cash flow screen shown in Figure 19 on the display 106 of the user terminal 1 (S27).

[0061] (Initial cash flow screen) Here, we will explain the initial cash flow screen 210 using Figure 19. Figure 19 is a diagram showing an example of the cash flow screen display.

[0062] As shown in Figure 19, the cash flow screen 210 includes a tenant ID display field 211, an operation date display field 212, a past income and expenditure performance display field 213, and a future income and expenditure forecast display field 214.

[0063] Of these, the "Operation Date Display" column 212 shows the date on which this cash flow screen was operated (the date it was displayed). The "Past Income and Expenditure Performance Display" column 213 shows the monthly income and expenditure performance (expenses, income, and cash balance) from before the operation date. This income and expenditure performance is the value at the end of the month. For example, in August 2020, income was 1 million yen, cash balance was 1.2 million yen, and expenses were 700,000 yen. Of these, the cash balance is the value of "income + cash balance - expenses" for the previous month, July.

[0064] Furthermore, the future income and expenditure forecast display section 214 shows monthly actuals (expenses, income, and cash balance) for a period beyond the operation date. Since the income and expenditure forecast is based on end-of-month values, if the operation date is September 15th, the income and expenditure for the end of September will be displayed in the income and expenditure forecast display section 214. Here, information 2141 is displayed indicating a shortfall of 2 million yen at the end of October. The expenses for October are 2.6 million yen. Of this 2.6 million yen, only the cash balance of 600,000 yen that will definitely be available by the payment date will be used to cover the shortfall. As a result, the shortfall information 2141 indicating a 2 million yen shortfall in October is displayed. Note that the projected income of 500,000 yen for October may not be available by the payment date of 2.6 million yen, so it will not be used to cover the 2.6 million yen expense. This allows the user to easily and visually understand that there will be a shortfall of 2 million yen at the end of October 2020.

[0065] Furthermore, the future income and expenditure forecast display section 214 shows a line graph 2271 that shows the "difference between cash balance and expenditures" for a predetermined period (in this case, one month). This makes it easier for user A1 to identify months in which the "difference between cash balance and expenditures" will be in deficit, and thus understand that they must raise funds to prepare for the deficit in October.

[0066] Furthermore, the bottom of the cash flow screen 210 includes three input fields 215-217 for receiving selections or inputs from the user. From the user's perspective, the funding service company is the source of funding.

[0067] Of these, the "Recommended Priority Conditions" reception field 215 displays the "Prioritize Fee Rate (Condition)" radio button 2151 and the "Prioritize Risk Avoidance (Condition)" radio button 2152.

[0068] "Prioritizing commission rates" is an example of a predetermined condition for selecting a specific funding source from among multiple funding sources (funding service companies), prioritizing the lowest commission rates for each funding source determined by the contents of each source and multiple documents. When the user presses the "Prioritizing commission rates" radio button 2151, the suggestion server 3 proposes the recommended information described below, prioritizing commission rates.

[0069] Furthermore, "prioritizing risk avoidance" is an example of a predetermined condition for selecting a specific funding source from among multiple funding sources (funding service companies) by prioritizing the low reliability of the trading partner. When the user presses the "prioritizing risk avoidance" radio button 2152, the suggestion server 3 proposes the following recommended information that prioritizes risk avoidance. For example, if there is a high probability that accounts receivable cannot be collected from a debtor company, the system will prioritize funding accounts receivable from such companies.

[0070] Furthermore, the "Payment Deadline for Funding Targets" reception field 216 displays a period input field 2161 for entering a predetermined period (in this case, one month). In Figure 19, the predetermined period is entered from the month including the operation date (in this case, September 2020) to six months later (February 2021). As a result, the recommended information described later is limited to information including ledgers for which payments will be deducted from income up to February 2021.

[0071] Furthermore, in the "Type of Funding Target" reception field 217, checkboxes 2171, 2172, and 2173 are displayed as specific examples of funding targets: "Invoice," "Purchase Order," and "Quotation." The types of documents (including electronic data) checked by the user from checkboxes 2171 to 2173 become eligible for funding. As shown in Figure 19, in this embodiment, the types of funding targets also include "Quotations" that have not yet been finalized as part of a transaction (sale). In other words, by selecting (specifying) the desired type of funding target, the user can narrow down the candidates for funding sources (funding service companies) to use.

[0072] Next, the "Recommendation Request" button 219 is a button that users press when, after making their desired selections and inputs in each of the reception fields 215, 216, and 217, they want the suggestion server 3 of suggesting company C to recommend the most suitable funding source (funding service company) for their needs.

[0073] <Recommended screen display processing> Next, the display process for the recommendation screen will be explained using Figures 19 to 29. Figure 20 is a sequence diagram showing the display process for the cash flow screen and the recommendation screen.

[0074] First, in Figure 19, when user A1 makes desired selections and inputs in each reception field 215 to 217, the reception unit 12 accepts the selections and inputs of priority conditions, etc. (S41). Furthermore, when user A1 presses the "Recommendation Request" button 219, the reception unit 12 accepts the request for the recommendation screen (S42). Then, the transmission / reception unit 11 sends the request for recommendation screen data to the suggestion server 3 (S43). Note that the processing in step S43 corresponds to the processing in step S2 described above. Therefore, this request for recommendation screen data includes the condition information described above (see S2). This condition information is information identified by the selections and inputs accepted in step S41, and indicates predetermined conditions regarding fundraising using documents issued when user A1 provides goods or services.

[0075] Next, the suggestion server 3 performs a filtering process for the recommended information (S44). Here, the filtering process for the recommended information will be explained in detail using Figures 21 to 29.

[0076] (Process for creating recommended screens) Figure 21 is a flowchart showing the process of narrowing down recommended information. As shown in Figure 21, the suggestion server 3 performs preliminary processing to identify the funding service company from among multiple funding service companies (funding sources) that will actually inquire about the fee rate when creating the recommendation screen (S121).

[0077] ((Preparation)) Here, we will further explain the preparation process in detail using Figure 22. Figure 22 is a flowchart illustrating the preparation process.

[0078] First, the storage and retrieval processing unit 39 uses the tenant ID used for authentication in step S22 as a search key to search the tenant management DB 3006 (see Figure 10) and retrieves information such as the tenant's address, industry, and type of business (S141).

[0079] Next, the memory and read processing unit 39 reads the funding information (each record) from the funding information management DB 3003 (see Figure 7) that includes a payment deadline within the "payment deadline for funding target" entered in Figure 19 (S142).

[0080] Next, the memory / read processing unit 39 refers to the funding service type management DB 3007 (see Figure 11) and identifies the type of funding service (procurement type) corresponding to the "type of funding target" selected in Figure 19 (S143).

[0081] Next, the storage and retrieval processing unit 39 uses the information of the type of funding service identified in step S143 as a search key to search the funding service management DB 3008 (see Figure 12) and identify the record information (funding service information) that includes the corresponding funding service name (S144).

[0082] Next, the proposal server 3 repeats the processing of steps S146 to S150 between steps S145 and S151 for each piece of funding service information.

[0083] First, the memory and retrieval processing unit 39 reads out the "non-supported industries," "supported regions," and "support for sole proprietorships" of the funding service information identified in step S145 (S146).

[0084] Next, the decision unit 35 performs a decision process based on the information read (acquired) by the storage / reading processing unit 39 through steps S141 to S146 as described above. Specifically, based on the "unsupported industry" information, it determines whether or not the tenant industry of user A1 is supported (S147). If it is not supported (S147; NO), the decision unit 35 determines whether or not the tenant address of user A1 is outside the supported area (S148). If it is not outside the supported area (S148; NO), the decision unit 35 determines whether or not the business type of user A1's tenant falls under the category of individual business support (S149). If it is supported (S149; YES), the decision unit 35 identifies the funding service (company) to which the commission rate inquiry will actually be made (S150). Then, returning to step S145, the proposal server 3 proceeds with the same process for the next predetermined funding service information. On the other hand, if the answer in step S147 is YES, in step S148 is YES, or in step S149 is NO, the suggestion server 3 does not execute the process in step S150, returns to step S145, and proceeds with the same process for the next predetermined funding service information, thereby completing the process shown in Figure 22.

[0085] As described above, the proposal server 3 can narrow down the specific funding services for which the fee rate is to be queried from among all funding services identified in step S144 (first-level filtering).

[0086] Next, returning to Figure 21, the suggestion server 3 creates candidate recommendation information that will be provided to user A1 (S122).

[0087] ((Creation of recommended candidate information)) Here, we will explain the process of creating recommended candidate information using Figure 23. Figure 23 is a flowchart showing the process of creating recommended candidate information.

[0088] As shown in Figure 23, the storage and retrieval processing unit 39 reads the funding information (each record) from the funding information management DB 3003 (see Figure 7) that includes a payment deadline within the "payment deadline for funding target" entered in Figure 19 (S161). Subsequently, the proposed server 3 repeats the processing of steps S163 to S171 between steps S162 and S172 for each piece of funding information read in step S161.

[0089] First, the memory and read processing unit 39 refers to the funding service type management DB 3007 (see Figure 11) and identifies the type of funding service corresponding to the "type of funding target" selected in Figure 19 (S163).

[0090] Next, the transmitting / receiving unit 31 creates inquiry information for each identified type of funding service among the specific funding services (companies) for which the fee rate inquiry is to be made, and obtains the fee rate from the funding service server 5 that manages the said specific funding service (S164). The transmitting / receiving unit 31 makes the fee rate inquiry by referring to the destination information of each funding service server 5 managed in the destination information management DB 3009 (see Figure 12). In step S164, as shown in Figure 20, the transmitting / receiving unit 31 of the proposal server 3 sends the fee rate inquiry information to each funding service server 5 (S164-1), and receives the latest fee rate information sent by the funding service server 5 (S164-2).

[0091] Next, the memory and read processing unit 39 stores the fee rate information received from each fund provision service server 5 in the memory unit 3000 (S165).

[0092] Next, the creation unit 36 ​​identifies the information that associates the funding service with the lowest commission rate with the funding information as the comparison target for the comparison described later (secondary filtering) (S166). For example, in Figure 16, if the trading partner is Company X1 and the transaction amount is 900,000 yen, services A1, A2, B1, B2, etc. can be listed as potential funding sources. Among these, the information that associates the funding service B2, which has the lowest commission rate (5%) with the funding information (Company X1, creditworthiness rating of 5, invoice for transaction amount of 900,000 yen, etc.) is identified as the comparison target.

[0093] Next, the memory and read processing unit 39 further obtains credit information of the trading partner (company) from the fundraising information read in step S161 (S167).

[0094] Next, the transmitting / receiving unit 31 obtains credit information of trading partner company B from each credit information server 7 (S168). In this case, the transmitting / receiving unit 31 makes a query by referring to the destination information of each credit information server 7 managed in the destination information management DB 3009. Also, in the process of step S168, as shown in Figure 20, the transmitting / receiving unit 31 of the proposal server 3 sends a request for credit information to each credit information server 7 (S168-1), and receives the credit information sent by the credit information server 7 (S168-2).

[0095] However, the content of credit information varies depending on the credit information service company. For example, some companies manage credit information using a three-level system "H, N, L," while others use a seven-level system "7 to 1," so adjustments are necessary. Therefore, in order to match the response information received from each credit information server 7 to a unified credit level, the storage and reading processing unit 39 refers to the credit information adjustment management DB 3010 and replaces the response information received from each credit information server 7 with a unified credit level (S169). Then, the storage and reading processing unit 39 manages the credit level of each trading partner (company) in the credit information management DB 3011 (S170).

[0096] Then, the memory and read processing unit 39 manages the recommended candidate information, which is compiled for each business partner based on the information acquired and managed in steps S161 to S171, in the recommended candidate information management DB 3012 (see Figure 16) (S171).

[0097] In this manner, the suggestion server 3 can manage the recommended candidate information.

[0098] ((Sort by recommended information)) Next, we will return to Figure 21 and explain the process of rearranging (sorting) the recommended candidate information according to the priority information selected in Figure 19.

[0099] If, in Figure 19, priority is set to commission rate (S123), the storage and retrieval processing unit 39 compares each recommended candidate information managed in the recommended candidate information management DB 3012 and sorts the comparison targets, which are each recommended candidate information, using the lowest commission rate as the first condition and the highest creditworthiness as the second condition, in order to extract the recommended information that best suits the commission rate priority (S124). For example, in Figure 16, the comparison targets include recommended candidate information showing service B2 with the lowest commission rate of 5% for an invoice with a transaction amount of 900,000 yen to company X1, recommended candidate information showing service B1 with the lowest commission rate of 6% for an invoice with a transaction amount of 500,000 yen to company X2, and recommended candidate information showing service B2 with the lowest commission rate of 7% for an invoice with a transaction amount of 800,000 yen to company X3. Furthermore, when the comparison targets are sorted in descending order of commission rate (first condition), the results are as follows: a combination of an invoice for 900,000 yen and service B2 for a transaction amount of X1 Corporation (commission rate 5%), a combination of an invoice for 500,000 yen and service B1 for a transaction amount of X2 Corporation (commission rate 6%), and a combination of an invoice for 800,000 yen and service B2 for a transaction amount of X3 Corporation (commission rate 7%). If there are multiple comparison targets with the same commission rate, these targets with the same commission rate are further sorted in descending order of creditworthiness (second condition). That is, the comparison targets are sorted by the first condition, and for comparison targets that meet the same first condition, they are sorted by the second condition. The same applies if risk avoidance priority is selected as the priority condition described later.

[0100] On the other hand, if risk avoidance priority is selected as the priority condition in Figure 19 (S123; risk avoidance priority), the storage and retrieval processing unit 39 compares each of the recommended candidate information managed in the recommended candidate information management DB 3012 and sorts the comparison targets, which are each of the recommended candidate information, using the lowest creditworthiness as the first condition and the lowest commission rate as the second condition, in order to retrieve the recommended information that is best suited to risk avoidance priority (S125).

[0101] Next, the memory and retrieval processing unit 39 extracts the rearranged reports from steps S124 and S125 in order to make up for any shortfalls in the cash flow (S126).

[0102] Then, the memory / reading processing unit 39 reads the recommended screen frame data stored in the memory unit 3000 (S127).

[0103] <Processing to redisplay the cash flow screen> Next, we will return to Figure 20 and explain the process of redisplaying the cash flow screen.

[0104] First, after the filtering process for recommended information is completed in step S44 above, the calculation unit 33 recalculates the income information and cash balance for each target period (in this case, monthly) based on the invoice amount and payment due date in the recommended information (S45). Then, the creation unit 36 ​​creates a cash flow screen that reflects the recommended information (S46).

[0105] Next, the transmitting / receiving unit 31 transmits to the user terminal 1 all of the recommended information recalculated in step S45 and the recommended screen frame data read in step S127 (S47). As a result, the transmitting / receiving unit 11 of the user terminal 1 receives all of the recommended information and the recommended screen frame data. Note that the processing in step S45 corresponds to the processing in step S3 described above.

[0106] Next, on the user terminal 1, the display control unit 14 includes the recommendation information in the recommendation screen frame received in step S47, and displays the cash flow screen as shown in Figure 25 and the recommendation screen as shown in Figure 26 (or Figure 27) on the display 106 of the user terminal 1 (S48). At this point, the checkboxes in Figures 25 to 27 are not checked.

[0107] (Display processing for the cash flow screen and recommendation screen) Here, we will explain the process of step S48 in detail using Figures 24 to 27. Figure 24 is a flowchart showing the display process of the cash flow screen and the recommendation screen.

[0108] As shown in Figure 24, the display control unit 14 displays a cash flow screen on the display 106 of the user terminal 1 that reflects the recommended information received in step S47 (S201).

[0109] (Cash flow management screen reflecting recommended information) Here, we will explain the cash flow screen 220 that reflects the recommended information when prioritizing the commission rate, using Figure 25. Figure 25 is a diagram showing an example of the display of the cash flow screen that reflects the recommended information when prioritizing the commission rate.

[0110] As shown in Figure 25, the cash flow screen 220 displays information 2251 indicating that 2,069,000 yen can be raised if funds are provided, in addition to the information displayed on the cash flow screen 210 in Figure 19. Furthermore, the income and cash balance from October 2020 onward will be changed due to the raising of 2,069,000 yen. In particular, since the funds raised by user A1 in October 2020 will not become subsequent income, information 2261, 2262, and 2263 indicating this amount that will not become income will be displayed.

[0111] Furthermore, the future income and expenditure forecast display section 214 shows a line graph 2272 that shows the "difference between cash balance and expenditures" for the target period (in this case, one month). This makes it easier for user A1 to understand that there are no longer any months in which the "difference between cash balance and expenditures" is in deficit.

[0112] Furthermore, the lower right side of the cash flow screen 220 includes a "View Details" button 228 and a "Confirm" button 229. The "View Details" button 228 is for user A1 to press if they want to display the recommended screen shown in Figure 26. The "Confirm" button 229 is for user A1 to press if they have confirmed the contents shown in Figure 25 and wish to confirm the recommended cash flow. When the "Confirm" button 229 is pressed, the process in step S49 of Figure 20 is performed.

[0113] If user A1 presses the "View Details" button 228 in Figure 25, the reception unit 12 accepts the request to display detailed information, as shown in Figure 24 (S202). As a result, the display control unit 14 displays a recommended screen (prioritizing fee rates) as shown in Figure 26.

[0114] (Recommended screen (prioritizing commission rates)) Here, we will explain the case where the recommendation screen prioritizes the commission rate, using Figure 26. Figure 26 shows an example of the recommendation screen display when the commission rate is prioritized.

[0115] As shown in Figure 26, the recommendation screen 250 includes various recommendation information (information about the documents used for fundraising, such as the trading partner, type of fundraising, transaction amount, payment due date; information about the source of funding, such as the type of funding, source, fee rate, adjustment amount, payment date, and trading partner's creditworthiness). A checkbox for selection is displayed to the left of each recommendation. The transaction amount is the amount the user expects to receive from the trading partner. The fundraising amount is the amount received from the funding service company (source of funding), after deducting fees. All checkboxes are initially checked.

[0116] Furthermore, the total procurement amount and the shortfall are displayed in the lower left corner of the recommendation screen 250. The total procurement amount shows the sum of the procurement amounts for the recommended information that user A1 checked the checkboxes for. From the beginning, the total procurement amount is displayed as the lowest possible amount, even if it exceeds the shortfall.

[0117] Additionally, the "View in Graph" button 256, the "Confirm" button 257, and the "View Other Recommendations" button 258 are displayed on the lower right side of the recommendation screen 250. The "View in Graph" button 256 is for user A1 to press when updating and displaying the cash flow screen 220 shown in Figure 25. The "Confirm" button 257 is for user A1 to press when confirming the displayed content in Figure 26. When the "Confirm" button 257 is pressed, user terminal 1 sends confirmation information to the suggestion server 3 indicating that the selection has been confirmed. The "View Other Recommendations" button 258 is for the user to press when displaying other examples of recommendation information.

[0118] In this state, when user A1 presses the "See other recommendations" button 258, the display control unit 14 changes to the recommendation screen 251 as shown in Figure 27 (S204). Here, two new recommendation items are displayed, but the checkboxes are not checked. When user A1 checks the checkboxes, the reception unit 12 accepts the checked recommendation items (S205). In other words, a third-level refinement is performed based on the recommendation information displayed in Figure 26.

[0119] Now, returning to Figure 24, when user A1 presses the "View in Graph" button 256, the reception unit 12 receives the request to update the cash flow screen (S206; YES). As a result, the display control unit 14 updates and redisplays the cash flow screen based on the latest recommended information received in step S205 (S207). After that, the process returns to step S201.

[0120] On the other hand, if user A1 presses the "Confirm" button 257 without pressing the "View in Graph" button 256, the reception unit 12 receives confirmation that the user will confirm the funding targets (documents) recommended by the proposal server based on the recommended information shown in Figure 24 (S208). This returns to Figure 20, and the transmitting / receiving unit 11 of user terminal 1 sends confirmation information to the proposal server 3 indicating the content confirmed in step S208 (S49). As a result, the transmitting / receiving unit 31 of the proposal server 3 receives the confirmation information.

[0121] Based on the above, user A1 can decide to fund the selected document (invoice) from among the multiple documents (invoices) proposed by the proposal server 3.

[0122] As mentioned above, the recommended screens in Figures 26 and 27 display information about the documents used for fundraising and information about the source of funding. However, it is also possible to display only the information about the documents used for fundraising, or only the information about the source of funding.

[0123] Furthermore, Figure 25 shows the cash flow screen when prioritizing the commission rate, but the display format is similar when prioritizing risk avoidance, so the explanation is omitted. Similarly, Figures 26 and 27 show the recommended screen when prioritizing the commission rate, but the display format is similar when prioritizing risk avoidance, so the explanation is omitted.

[0124] The process when user A1 changes the check status of the recommended information on the recommendation screen 251 shown in Figure 27 will be explained in more detail. Figure 28 shows an example of the display after user A1 has changed the recommended information when prioritizing the commission rate.

[0125] The recommendation screen 252 shown in Figure 28 is the recommendation screen that appears when, in the recommendation screen 251 shown in Figure 27, user A1 unchecks the third checkbox from the top and checks the fourth and fifth checkboxes from the top. The total procurement amount displayed in the lower left of recommendation screen 252 is updated each time the check status of a checkbox is changed to reflect the total procurement amount of the recommended information for which the checkboxes are checked.

[0126] One possible scenario in which you might want to change the documents used for fundraising from the fundraising targets proposed by Proposal Server 3 is as follows: For example, if User A1 has a trading partner from whom they want to collect accounts receivable with priority over the trading partners proposed by Proposal Server 3. One example of this reason might be that, although the trading partner has a high credit rating registered in Credit Information Management DB 3011, recent transactions have led to the conclusion that collecting accounts receivable will be difficult (for example, there is a possibility of bankruptcy in the near future).

[0127] On the recommendation screen 252, when user A1 presses the "View in Graph" button 256, the reception unit 12 receives the request to update the cash flow screen. The display control unit 14 then updates and redisplays the cash flow screen based on the latest recommendation information.

[0128] Figure 29 shows an example of the cash flow screen display after user A1 changes the recommended information when prioritizing the commission rate. As shown in Figure 29, the cash flow screen 221, which is redisplayed after changing the check status of the checkbox on the recommendation screen 252, displays a line graph 2273 showing the "difference between cash balance and expenditures" for the target period, which has been newly recalculated based on the recommended information selected by user A1, compared to the cash flow screen 220 in Figure 25. In addition, the information 2251 showing the amount of funds that can be raised is redisplayed with the amount recalculated based on the recommended information selected by user A1.

[0129] Line graph 2273 is displayed with a different line type than line graph 2272, which shows the "difference between cash balance and expenditures" for the target period, calculated based on the funding targets proposed by proposal server 3. For example, if line graph 2272 is displayed as a solid line, line graph 2273 should be displayed with a line type that is clearly different from a solid line, such as a dotted line, dashed line, or dashed line. Line graphs 2272 and 2273 may also be displayed with different line colors. For example, if line graph 2272 is displayed as a black line, line graph 2273 should be displayed with a line color that is clearly different from black, such as red, blue, or green.

[0130] The cash flow screen 221 shown in Figure 29 displays a line graph 2272 showing the "difference between cash balance and expenditures" for the target period based on the funding targets proposed by the proposal server 3, and a line graph 2273 showing the "difference between cash balance and expenditures" for the target period based on the recommended information selected by user A1, in a manner that allows for comparison. Therefore, user A1 can easily compare the cash flow when the funding targets are changed, and make an appropriate decision on funding targets.

[0131] [Main effects of this embodiment] As explained above, this embodiment has the effect of making it easier for users to understand their future financial situation by visualizing the future financial situation when the documents used for fundraising are identified.

[0132] Furthermore, the proposal server 3 sends a specific funding source (or document) that meets the predetermined conditions requested by user A1 to user terminal 1. In other words, by making a suggestion to user terminal 1 indicating "where" to apply for funding, the proposal server 3 can resolve the problem that user A1 has difficulty finding a funding source (or document) that meets the conditions they expect.

[0133] Furthermore, the proposal server 3 transmits information to the user terminal 1 indicating a specific document, determined based on predetermined conditions, from among multiple documents issued by user A1 in providing goods or services. In other words, the proposal server 3 makes a suggestion to the user terminal 1 indicating "what" user A1 should apply to for funding from a predetermined funding source, thereby resolving the problem that user A1 has difficulty finding a funding source that meets their desired conditions.

[0134] 〔supplement〕 Furthermore, after step S49 in Figure 20, the proposing server 3 may, on behalf of user A1, perform the application in step S4 in Figure 1.

[0135] Note that User Terminal 1 is an example of a communication terminal. User Terminal 1 includes not only PCs, but also smartwatches, game consoles, and video call devices. The Presenter Terminal is another example of a communication terminal.

[0136] Each component, such as each CPU 101, may be single or multiple.

[0137] Furthermore, each of the functions in the above-described embodiments can be realized by one or more processing circuits. Here, the "processing circuit" in this embodiment includes processors programmed to execute each function by software, such as processors implemented by electronic circuits, and devices such as ASICs (Application Specific Integrated Circuits), DSPs (digital signal processors), FPGAs (field programmable gate arrays), SOCs (System on a chip), GPUs, and conventional circuit modules designed to execute each of the above-described functions.

[0138] Furthermore, the servers 3, 5, and 7 described in the above embodiments represent only one of several computing environments for carrying out the embodiments disclosed herein. For example, proposed server 3 may include multiple computing devices, such as a server cluster. The multiple computing devices are configured to communicate with each other via any type of communication link, including a communication network or shared memory, and perform the processing disclosed herein. Similarly, proposed server 3 may include multiple computing devices configured to communicate with each other.

[0139] Furthermore, the proposed server 3 can be configured to share the disclosed processing steps in various combinations. For example, a process executed by the proposed server 3 may be executed by other servers. Similarly, the functions of the proposed server 3 may be executed by other servers. Also, each element of the proposed server 3 and the other servers may be combined into a single server or divided among multiple devices.

[0140] Furthermore, other servers, routers, etc., may relay data during communication between each terminal and each server.

[0141] 〔summary〕 The following is a summary of this embodiment. Note that the statements in parentheses are not intended to limit the scope of the claims, but are merely illustrative examples.

[0142] A proposal server 3, which provides information via a communication network 100 to a user terminal 1 of a user who provides or plans to provide goods or services to a business partner, receives condition information (S43) that indicates predetermined conditions for fundraising using documents issued in connection with the goods or services provided by the user, and transmits data (S47) that constitutes a fundraising screen, which is a fundraising screen that shows the future cash flow situation and is based on information from a specific document that satisfies the predetermined conditions, for the user terminal 1 to receive. [Explanation of symbols]

[0143] 1. User terminal 3. Proposal Server 5. Funding Service Server 7. Credit Information Server 11 Transmitter / Receiver 12 Reception Department 14 Display Control Unit 15 Judgment Department 19 Memory and Retrieval Processing Unit 31 Transmitting and Receiving Unit (Example of transmitting means, example of receiving means) 33 Calculation Section 35 Judgment Department 36 Creation Department 39 Memory and Retrieval Processing Unit 100 Communication Networks

Claims

1. A proposal server that provides information via a communication network to the user terminal of a user who is providing or planning to provide goods or services to a business partner, A receiving means for receiving conditional information indicating predetermined conditions for fundraising using documents issued in providing goods or services offered by the user, transmitted by the user terminal, A transmission means that transmits data to be received by the user terminal, which constitutes a cash flow screen showing the future cash flow situation, based on information from a specific form that satisfies the predetermined conditions, A proposed server characterized by having the following features.

2. The proposed server according to claim 1, characterized in that the information of a specific document that satisfies the aforementioned predetermined conditions is information indicating the amount of the claim relating to the specific document or the payment due date of the claim relating to the specific document.

3. The proposed server according to claim 2, The system has a calculation means for calculating the cash balance in the future cash flow based on the amount of the receivable related to the specific accounting document, The proposed server is characterized in that the data constituting the cash flow screen includes information indicating the cash balance calculated by the calculation means.

4. The calculation means calculates the cash balance for each period in the future cash flow plan based on the payment due date of the claim relating to the specific ledger, The proposed server according to claim 3, characterized in that the data constituting the cash flow screen includes information indicating the cash balance for each target period calculated by the calculation means.

5. The calculation means calculates the difference between the total amount of funds raised using the specific ledger and the cash balance for the period to which the payment due date determined by the specific ledger belongs, and the amount of expenditures for the said period. The proposed server according to claim 3 or 4, characterized in that the data constituting the cash flow screen includes information indicating the difference calculated by the calculation means.

6. The receiving means further receives information transmitted by the user terminal indicating a second document that satisfies the predetermined conditions and is different from the specific document, The calculation means further calculates a second difference, which is the difference between the total amount of funds to be raised and the cash balance for the period to be raised, and the amount of expenditures for the period, using the second ledger. The proposed server according to claim 5, characterized in that the data constituting the cash flow screen further includes information indicating the second difference calculated by the calculation means.

7. The proposal server according to any one of paragraphs 1 to 6, characterized in that the predetermined conditions are either a fee rate priority condition for determining the specific source of funding by prioritizing the low fee rate of the funding determined by the contents of the document, or a risk avoidance priority condition for determining the specific source of funding by prioritizing the low reliability of the trading partner related to the document.

8. The proposed server according to any one of claims 1 to 7, characterized in that the aforementioned document is an invoice, purchase order, or quotation.

9. A communication system constructed with a user terminal of a user that provides or plans to provide goods or services to a business partner, and a proposal server that provides information to said user terminal via a communication network, The user terminal transmits conditional information indicating predetermined conditions for fundraising using documents issued in providing the goods or services provided by the user. The proposed server receives the condition information and transmits data that constitutes a cash flow screen showing the future cash flow situation, based on information from a specific document that satisfies the predetermined conditions. The user terminal receives the data that constitutes the cash flow screen. A communication system characterized by the following.

10. A method of provision performed by a proposal server that provides information via a communication network to the user terminal of a user to whom goods or services are to be provided or to whom goods or services are to be provided to a business partner, A receiving step of receiving conditional information indicating predetermined conditions for fundraising using documents issued in connection with the provision of goods or services by the user, transmitted by the user terminal, A transmission step in which data constituting a cash flow screen that shows the future cash flow situation, based on information from a specific document that satisfies the predetermined conditions, is transmitted for the user terminal to receive; A method for providing a product characterized by performing the following actions.

11. A program that causes a computer to perform the method of provision described in claim 10.

Images