Advance payment apparatus and advance payment method

Abstract

To properly process a plurality of bills.SOLUTION: An advance payment apparatus includes: a set amount acquisition unit which acquires set amount information including at least one of the amount to be paid in advance and the amount to be paid normally; a bill information acquisition unit which acquires bill information on a bill; a control unit which determines the amount to be paid in advance, based on the acquired set amount information; and a transfer execution unit which executes transfer processing for a bill for which advance payment has been determined by the control unit.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to an advance payment device and an advance payment method. [Background technology]

[0002] In the past, the sending dates of invoices, etc. from each billing company were different from each other, which made management troublesome. To solve this problem, there was a technology that made it possible to send invoices, etc. together in a lump sum, reducing the expenses incurred by each billing company for sending them (for example, see Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2003-30569 A Summary of the Invention [Problem to be solved by the invention]

[0004] According to the technology described above, a proxy delivery of invoices etc. to a specified bank account is accepted, information to be transferred from the accepted information is tallied, and a consolidated billing document is created. In other words, by using the technology described above, invoices issued over a specified period of time are sent as a consolidated invoice, rather than as individual invoices as in the past. This technology is carried out by a company that performs a delivery agent business, which did not exist before. However, even if this technology is used, there is still a possibility that individual invoices will arrive from companies that are not included in the scheme, and it has not been sufficient to reduce the complexity of processing individual invoices.

[0005] The present invention has been made in consideration of the above circumstances, and has an object to provide an advance payment device and an advance payment method that are capable of suitably processing a plurality of bills. [Means for solving the problem]

[0006] (1) One aspect of the present invention includes a set amount acquisition unit that acquires set amount information including at least one of an advance payment amount indicating the upper limit of an amount to be paid in advance and a normal payment amount indicating the upper limit of an amount to be paid in advance by a method other than the advance payment, a billing information acquisition unit that acquires billing information regarding a bill issued by a biller to a payer, and a set amount acquisition unit that acquires, based on the acquired set amount information, determines that if the billing amount indicated in the billing information is less than the advance payment amount, the entire billing amount indicated in the billing information is to be paid in advance, and if the billing amount indicated in the billing information is more than the advance payment amount, determines that the entire billing amount indicated in the billing information is to be paid in advance. a control unit that determines that, of the billing amount shown in the billing information, the amount indicated in the advance payment amount is to be paid in advance and the remaining amount is to be paid in regular payment, and if the billing amount shown in the billing information is less than the regular payment amount, determines that the entire billing amount shown in the billing information is to be paid in regular payment, and if the billing amount shown in the billing information is more than the regular payment amount, determines that, of the billing amount shown in the billing information, the amount indicated in the regular payment amount is to be paid in regular payment and the remaining amount is to be paid in advance, and a transfer execution unit that executes a transfer process for the bill for which an advance payment has been determined by the control unit.

[0007] (2) In one aspect of the present invention, in the advance payment device described in (1) above, the set amount information acquired by the set amount acquisition unit includes either the advance payment amount or the regular payment amount.

[0008] (3) In one aspect of the present invention, in the advance payment device described in (1) above, the set amount information acquired by the set amount acquisition unit includes both the advance payment amount and the regular payment amount.

[0009] (4) In one aspect of the present invention, in the advance payment device described in any of (1) to (3) above, the set amount acquisition unit further acquires priority information for selecting whether the advance payment or the regular payment is to be prioritized, and the control unit determines that when an excess amount occurs in which the billing amount indicated in the billing information is an amount that is greater than the total amount of the advance payment amount and the regular payment amount, the excess amount is to be paid using the payment method selected by the priority information.

[0010] (5) One aspect of the present invention includes a set amount acquisition step for acquiring set amount information including at least one of an advance payment amount indicating the upper limit of an amount to be paid in advance and a normal payment amount indicating the upper limit of an amount to be paid in advance by a method other than the advance payment, a billing information acquisition step for acquiring billing information relating to a bill issued by a biller to a payer, and a step of determining, based on the acquired set amount information, that if the billing amount indicated in the billing information is less than the advance payment amount, to pay in advance the entire billing amount indicated in the billing information, and if the billing amount indicated in the billing information is more than the advance payment amount, to pay in advance the entire billing amount indicated in the billing information. a control step of determining that, of the billing amount shown in the billing information, an amount shown in the advance payment amount is to be paid in advance and the remaining amount is to be paid in regular payment, and if the billing amount shown in the billing information is less than the regular payment amount, determining that the entire billing amount shown in the billing information is to be paid in regular payment, and if the billing amount shown in the billing information is more than the regular payment amount, determining that, of the billing amount shown in the billing information, an amount shown in the regular payment amount is to be paid in regular payment and the remaining amount is to be paid in advance, and a transfer execution step of executing a transfer process for the bill for which it has been determined by the control step to make an advance payment. Effect of the Invention

[0011] According to the present invention, it is possible to provide an advance payment device and an advance payment method capable of suitably processing a plurality of invoices. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram for explaining an overview of a payment-on-reimbursement system according to an embodiment of the present invention. [Diagram 2] FIG. 13 is a diagram for explaining an example of a case where a payer makes an advance payment for a portion of an invoice in the advance payment system according to the present embodiment. [Diagram 3] FIG. 2 is a functional configuration diagram for explaining an example of the functional configuration of each device included in the advance payment system according to the present embodiment. [Figure 4] 5 is a diagram showing an example of information stored in a billing information storage unit according to the embodiment; FIG. [Diagram 5] FIG. 13 is a diagram showing an example of a screen configuration of a payment list screen presented by the payer device according to the embodiment. [Figure 6] FIG. 4 is a diagram illustrating an example of presetting information according to the embodiment. [Figure 7] 1 is a first flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 8] 13 is a second flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 9] 13 is a third flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 10] FIG. 11 is a diagram showing an example of billing information according to the present embodiment in the case where there is an unpaid bill. [Figure 11] 4 is a fourth flowchart showing the flow of a series of processes performed by the payment advance device according to the present embodiment. [Figure 12] FIG. 13 is a diagram showing an example of a display screen presented on the payer device according to the present embodiment, illustrating a screen configuration for selecting whether or not to make an advance payment when there is an unpaid debt. [Figure 13] FIG. 11 is a functional configuration diagram for explaining a first modified example of the functional configuration of the payment device according to the present embodiment. [Figure 14] FIG. 13 is a diagram showing an example of a management status acquired by the advance payment device according to the present embodiment. [Figure 15]13 is a fifth flowchart showing the flow of a series of processes performed by the payment advance device according to the present embodiment. [Figure 16] 13 is a sixth flowchart showing the flow of a series of processes performed by the payment advance device according to the present embodiment. [Figure 17] FIG. 13 is a functional configuration diagram for explaining a second modified example of the functional configuration of the payment device according to the present embodiment. [Figure 18] FIG. 13 is a diagram showing an example of a screen configuration of a set amount acquisition screen according to the embodiment. [Figure 19] 13 is a seventh flowchart showing the flow of a series of processes performed by the payment advance device according to the present embodiment. [Figure 20] FIG. 13 is a diagram showing a modified example of the screen configuration of the set amount acquisition screen according to the embodiment. [Figure 21] 2 is a block diagram showing an example of an internal configuration of the payment device according to the present embodiment. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] [Embodiment] The following describes in detail preferred embodiments of the advance payment device and advance payment method according to the aspects of the present invention, with reference to the accompanying drawings. Note that the aspects of the present invention are not limited to these embodiments, and include various modifications or improvements. In other words, the components described below include those that a person skilled in the art can easily imagine, and those that are substantially the same, and the components described below can be combined as appropriate. Also, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the present invention. Also, in the following drawings, the scale and number of each structure may be different from the scale and number of the actual structure in order to make each structure easier to understand.

[0014] [Overview of the advance payment system] FIG. 1 is a diagram for explaining an overview of the advance payment system according to this embodiment. First, an overview of the advance payment system 1 will be explained with reference to the diagram. The advance payment system 1 is used by a claimant C, a payer P, and an advance payer R. Of these, there are at least multiple claimants C. The diagram shows claimants C1, C2, and C3 as examples of multiple claimants C. The advance payment system 1 may also include multiple payers P. The diagram shows, as an example, a case where the advance payment system 1 includes only payer P.

[0015] A biller C issues an invoice to a payer P. Multiple billers C each issue an invoice to a payer P at any time and in any format. In the illustrated example, a biller C1 issues an invoice A to a payer P, a biller C2 issues an invoice B to a payer P, and a biller C3 issues an invoice C to a payer P.

[0016] The payer P receives an invoice from the biller C. The payer P receives invoices issued by each of the multiple billers C. In the illustrated example, the payer P receives invoice A from the biller C1, invoice B from the biller C2, and invoice C from the biller C3. The payer P decides whether to make an advance payment for each of the received invoices. Here, an advance payment is a method in which an advance payer R makes a payment to the biller C on behalf of the payer P. The illustrated example shows an example of a case in which an advance payment is made for all received invoices (i.e., invoice A, invoice B, and invoice C). The payer P transmits information about the invoices for which an advance payment is to be made to the advance payer R. Note that the payer P may transmit information about all received invoices to the advance payer R, together with information about which invoices are to be paid in advance.

[0017] The payer R obtains information about the invoices for which he / she will make an advance payment from the payer P. In the example shown, the payer R obtains information about invoices A, B, and C from the payer P as information about the invoices for which he / she will make an advance payment. The payer R makes payment to the biller C based on the obtained invoice information. Specifically, in the example shown, the payer R makes payment to the biller C1 who issued invoice A based on invoice A, makes payment to the biller C2 who issued invoice B based on invoice B, and makes payment to the biller C3 who issued invoice C based on invoice C.

[0018] The payer R issues an invoice to the payer P for the total amount of the invoices that he / she has paid on behalf of (invoice A, invoice B, and invoice C in the illustrated example). The payer P may add a fee when making the payment to the payer R. The payer P pays the total amount of the invoices that he / she has requested to be paid on behalf of the payer R (invoice A, invoice B, and invoice C in the illustrated example) and the necessary fee to the payer R. By adopting such a configuration, the payer P can make a lump-sum payment to the payer R instead of paying each of the multiple billers C. Therefore, according to this embodiment, the payer P can reduce the conventional hassle of processing each invoice separately.

[0019] FIG. 2 is a diagram for explaining an example of a case where a payer makes an advance payment for some invoices in the advance payment system according to this embodiment. This figure is a modified example of the example shown in FIG. 1. In the example shown in FIG. 2, an example of a case where payer P makes an advance payment for some of the invoices received is shown. In the specifically illustrated example, payer P receives invoice A from biller C1, invoice B from biller C2, and invoice C from biller C3. Of these received invoices, payer P pays invoice C to biller C3 himself, and makes an advance payment for the remaining invoices A and B.

[0020] In this case, payer P sends information about invoice A and invoice B to payer R. Alternatively, payer P sends information about invoice A, invoice B, and invoice C, as well as information about invoice A and invoice B to be paid on behalf of payer R. Payer R makes payment to biller C1 who issued invoice A based on invoice A, and makes payment to biller C2 who issued invoice B based on invoice B. Payer R issues an invoice to payer P for the total amount of invoices for which it has made on behalf payments (invoice A and invoice B in the illustrated example). Payer P pays to payer R the total amount of invoices for which it has requested on behalf (invoice A and invoice B in the illustrated example), as well as the necessary fees.

[0021] [Function configuration] FIG. 3 is a functional configuration diagram for explaining an example of the functional configuration of each device included in the advance payment system according to this embodiment. With reference to the same figure, an example of the functional configuration of each device included in the advance payment system 1 will be explained. The advance payment system 1 includes an advance payment device 10, a payer device 20, and a claimant device 30. Each functional unit included in the advance payment device 10, the payer device 20, and the claimant device 30 is realized, for example, by using an electronic circuit. Each functional unit may also include internal storage means such as a semiconductor memory or a magnetic hard disk device, as necessary. Each function may also be realized by a computer having a CPU (Central Processing Unit) and software. All or a part of each functional unit may also be realized by using hardware such as an ASIC (Application Specific Integrated Circuit), a PLD (Programmable Logic Device), or an FPGA (Field-Programmable Gate Array). All or a part of each functional unit may also be realized by a combination of software and hardware. All or part of the functions of the advance payment device 10, payer device 20, and claimant device 30 may exist on, for example, a cloud server. Furthermore, each of the advance payment device 10, payer device 20, and claimant device 30 may be composed of multiple devices (computers), and each functional block may be distributed across multiple devices.

[0022] The advance payment device 10 comprises a billing information acquisition unit 11, a billing information storage unit 12, an advance payment device control unit 13, an output unit 14, an acquisition unit 15, a transfer execution unit 16, and a transfer record acquisition unit 17.

[0023] The billing information acquisition unit 11 acquires billing information BI, which is information regarding a bill issued by a biller C to a payer P. The billing information acquisition unit 11 acquires multiple pieces of billing information BI. The multiple pieces of billing information BI may be issued respectively by multiple billers C, or may be issued by a specific biller C. The billing information BI includes at least information identifying the biller C who issued the invoice.

[0024] The billing information BI acquired by the billing information acquisition unit 11 may have at least two or more modes. That is, the billing information acquisition unit 11 may be configured to acquire billing information BI in a plurality of modes. The plurality of modes includes, first, a first mode in which the billing information BI exists as electronic data provided by the biller C. The billing information BI as electronic data may be, for example, information obtained by performing optical character recognition (OCR) on a paper bill. Also, a second mode in which the billing information BI exists is input to the advance device 10 by the payer P operating an input device (which may be, for example, the payer device 20). The modes of the billing information BI may include modes other than those exemplified above.

[0025] The billing information acquisition unit 11 is thus configured to be able to acquire billing information BI in a plurality of different types, and is thus able to handle bills from a plurality of billers C who issue bills in different formats. The billing information acquisition unit 11 may acquire the billing information BI directly from the biller C, or may acquire the billing information BI indirectly from the payer P after the biller C issues the bill to the payer P. Acquisition of the billing information BI may include acquiring bills stored in a predetermined database. The bills stored in the predetermined database may be, for example, bill information stored by an existing platform provider. That is, the advance payment device 10 may also perform advance payment processing by cooperating with an existing platform. The billing information BI stored in a predetermined database in the existing platform may be arranged in, for example, a unified format.

[0026] The link with the system of the other platform may be performed, for example, through an API (Application Programming Interface). Also, in order to link with the system of the other platform, the payer R may provide an SDK (Software Development Kit) to the existing system of the other platform, or the SDK may be provided on an OEM basis. As a linking method, the service according to this embodiment may be embedded in the system of the other platform, which is to be a partner, or information may be linked from the system of the other platform, which is to be a partner, to the pay-by-payment device 10 according to this embodiment.

[0027] The acquisition of the billing information BI is not limited to the examples of acquisition from a system such as another platform or direct input of information to the advance payment device 10, and it may also be acquired by other methods.

[0028] The billing information storage unit 12 accumulates a plurality of billing information BI acquired by the billing information acquisition unit 11. The billing information storage unit 12 is configured to include a hard disk drive (HDD: Hard Disk Drive), a solid state drive (SSD: Solid State Drive), a flash memory, a ROM (Read Only Memory), etc. The billing information storage unit 12 does not have to exist as a hardware configuration equipped in the advance payment device 10, and may exist in, for example, a server device connected via a network.

[0029] Here, an example of the billing information BI stored in the billing information storage unit 12 will be described with reference to FIGS.

[0030] [Billing Information] FIG. 4 is a diagram showing an example of information stored in the billing information storage unit according to this embodiment. With reference to the diagram, an example of billing information BI stored in the billing information storage unit 12 will be described. In the example shown in the figure, the billing information BI is associated with a “biller”, a “payer”, a “billing amount”, a “scheduled payment date”, a “status”, and “advance payment selection information”. The “biller” is information for identifying the biller C who issued the billing information BI. The “payer” is information for identifying the payer P to whom the billing information BI is issued. The “billing amount” is information indicating the billing amount of the billing information BI. The “scheduled payment date” is information indicating the scheduled payment date of the billing information BI to the biller C. The “status” is information indicating the status of the billing information BI. The “advance payment selection information” is information indicating whether or not the biller P has selected the billing information BI as an advance payment.

[0031] Specific examples of the above-mentioned "status" may include the following: · Unpaid: Payment has not been made to claimant C, and no option has been chosen as to whether or not to make an advance payment. · Applied: Payer P has selected advance payment, and advance payer R is determining whether or not to allow advance payment. Waiting for advance payment to be made: This is the state in which the advance payment is awaited after the payer P selects the advance payment and the advance payer R determines that the advance payment is possible. Advance payment completed: This is the state after the payer P selects advance payment, the advance payer R determines that advance payment is possible, and the advance payment is then executed. · Unpaid (waiting for transfer): After the payer R has made an advance payment, the payer P is waiting for the payer R to transfer the payment. · Paid (transfer completed): This is the state after the payer R has made the advance payment and after the payer P has made a transfer to the payer R.

[0032] In addition, the above-mentioned "status" may include an error-related status. An error-related status may include a case where processing is interrupted for some reason, or the information in the billing information BI is incomplete. In addition, the above-mentioned "status" may include a pattern in which insurance / guarantee has been fulfilled. In addition, the above-mentioned "status" may broadly include statuses regarding the processing status of other billing information BIs.

[0033] Specifically, in the illustrated example, the billing information BI1 shows a case where the "biller" is A Shoji, the "payer" is A Co., Ltd., the "billing amount" is ¥50,000, the "scheduled payment date" is 2023 / 4 / 28, the "status" is unpaid, and the "advance payment selection information" is ◯. The billing information BI2 shows a case where the "biller" is B Shoji, the "payer" is B Co., Ltd., the "billing amount" is ¥20,000, the "scheduled payment date" is 2023 / 4 / 30, the "status" is unpaid, and the "advance payment selection information" is -. The billing information BI3 shows a case where the "biller" is C Shoji, the "payer" is C Co., Ltd., the "billing amount" is ¥30,000, the "scheduled payment date" is 2023 / 4 / 30, the "status" is unpaid, and the "advance payment selection information" is -. Returning to FIG. 3, the explanation of the functional configuration of the payment advance device 10 will be continued.

[0034] The advance device control unit 13 selects claim information BI for an invoice issued to a specific payer from among the multiple claim information BI acquired by the claim information acquisition unit 11 and stored in the claim information storage unit 12. This process may be triggered by, for example, an execution instruction from the payer device 20. When the advance device control unit 13 acquires the execution instruction from the payer device 20, it selects claim information BI associated with the payer P corresponding to the payer device 20 from among the multiple claim information BI stored in the claim information storage unit 12. The advance device control unit 13 outputs the selected claim information BI to the payer device 20 via the output unit 14. In the following description, the advance device control unit 13 may be simply referred to as a control unit.

[0035] The output unit 14 outputs the claim information BI selected by the advance payment device control unit 13 to the payer device 20. The claim information BI selected by the advance payment device control unit 13 is claim information BI associated with a specific payer P. The output unit 14 outputs information to the payer device 20 corresponding to the specific payer P. Note that the claim information BI for a specific payer P may be referred to as specific claim information SBI.

[0036] The acquisition unit 15 acquires information indicating whether or not to make an advance payment from the payer device 20 in accordance with the specific claim information SBI output by the output unit 14. Whether or not to make an advance payment is included in the advance payment information RPI, for example. The advance payment information RPI may include information on the payment method after the advance payment. In other words, when an advance payment is selected, the acquisition unit 15 may further acquire information on the payment method after the advance payment. In addition, it is preferable that the acquisition unit 15 acquires information on the payment method after the advance payment for each biller C. The acquisition unit 15 outputs the acquired advance payment information RPI to the advance payment device control unit 13.

[0037] It is preferable that the information on the payment method after advance payment acquired by the acquisition unit 15 includes at least either a payment by credit card or a payment by bank transfer. In addition, the information on the payment method after advance payment acquired by the acquisition unit 15 may widely include a payment agent, a Business Payments Solution Provider (BPSP) which is a payment by credit card, a format specified by the Japan Bankers Association for transfers via Internet banking, an external transfer, etc. Examples of an external transfer include a transfer at a bank counter and a transfer using an automated teller machine (ATM).

[0038] The advance payment device control unit 13 acquires the advance payment information RPI from the acquisition unit 15, and updates the billing information BI stored in the billing information storage unit 12 according to the acquired advance payment information RPI. That is, the advance payment device control unit 13 updates the billing information BI, so that the billing information BI is associated with information on whether or not an advance payment is to be made.

[0039] The transfer execution unit 16 executes a transfer process for the claimant C based on the billing information BI stored in the billing information storage unit 12 and indicating that an advance payment is to be made. Whether or not a case is subject to transfer processing is determined, for example, by the advance device control unit 13 referring to the billing information storage unit 12. The advance device control unit 13 outputs a control signal CI to the transfer execution unit 16, and the transfer execution unit 16 executes transfer processing (makes payment to the transfer destination account) for the case subject to transfer processing indicated by the control signal CI. The transfer execution unit 16 executes transfer processing for the claimant who issued the invoice. As a result of executing the transfer processing, the transfer execution unit 16 outputs transfer information TI to the claimant device 30 indicating that the transfer processing has been executed.

[0040] The transfer history acquisition unit 17 acquires the transfer history information TRI from the transfer history storage unit 121. The transfer history information TRI is information regarding transfers made by the payer P in the past. The transfer history information TRI may be associated with information on whether or not there is a transfer history for each biller C. The transfer history may be a transfer from the payer P to the biller C, or a transfer from the payer P to the biller C via the advance payer R. Preferably, the transfer history information TRI may be associated with information on the biller C and the transfer amount.

[0041] The transfer history storage unit 121 is configured to include a hard disk drive, a solid state drive, a flash memory, a ROM, etc. The transfer history storage unit 121 may exist in a server device or the like connected via a network, or may exist as a hardware configuration provided in the advance payment device 10, for example.

[0042] Furthermore, the information stored in the transfer record storage unit 121 may be stored in the billing information storage unit 12. That is, even after the status of the billing information BI stored in the billing information storage unit 12 becomes paid (transfer completed), the billing information BI may not be erased and may be used as the transfer record information TRI. In this case, the transfer record acquisition unit 17 may acquire the transfer record information TRI from the billing information storage unit 12.

[0043] Next, the functional configuration of the payer device 20 will be described. The payer device 20 is a terminal device operated by the payer P. The payer device 20 acquires information on whether or not to make an advance payment from the payer PI based on information from the advance device 10. The payer device 20 outputs the information on whether or not to make an advance payment acquired from the payer PI to the advance device 10. The payer device 20 includes a payer device control unit 21, a presentation unit 22, and an operation reception unit 23.

[0044] The payer device control unit 21 acquires specific claim information SBI indicating claim information BI to be paid by the payer P from the advance payment device 10. The payer device control unit 21 presents the claim information BI to be paid by the payer P to the payer P. The payer device control unit 21 outputs information to be presented by the presentation unit 22 as presentation information DI.

[0045] The presentation unit 22 presents the billing information BI output from the advance payment device 10 to the payer P. The presentation unit 22 may include a display unit (not shown) capable of visually displaying the billing information BI to the payer P. The display unit may be, for example, a liquid crystal display, an organic EL (Electroluminescence) display, or the like.

[0046] The operation reception unit 23 receives operations from the payer P. The operation reception unit 23 receives operations from the payer P via an input device such as a keyboard, touch panel, or microphone (not shown). The payer P selects whether or not to make an advance payment for each invoice based on the information displayed on the presentation unit 22. The operation reception unit 23 receives an operation by the payer to select whether or not to make an advance payment in accordance with the presented billing information BI. The payer device control unit 21 outputs advance payment information RPI, including information on whether or not to make an advance payment, to the advance payment device 10 based on the operation received by the operation reception unit 23.

[0047] Next, we will explain the functional configuration of the claimant device 30. The claimant device 30 acquires transfer information TI indicating that a transfer has been executed from the advance device 10. The claimant device 30 may also have a function of issuing claim information BI to the payer device 20.

[0048] [Payment List Screen Layout] FIG. 5 is a diagram showing an example of the screen configuration of a payment list screen presented by the payer device according to this embodiment. With reference to the same figure, an example of the screen configuration of the payment list screen D10 will be described. The payment list screen D10 has a tab D111 and a tab D112 as a screen configuration. The tab D111 is a tab for displaying the unpaid list. The tab D112 is a tab for displaying the payment history. The tabs D111 and D112 are mutually exclusive. In the example shown in the figure, the tab D111 is selected, and therefore the unpaid list is displayed.

[0049] The code D12 indicates the unpaid amount. The unpaid amount is, for example, an amount including a fee. In the example shown, the unpaid amount is "103,000 yen." It is preferable that the amount of the fee out of the unpaid amount is presented so that it can be easily recognized. In the example shown, the fee is "3,000 yen."

[0050] Reference symbol D13 displays a list of unpaid items. The unpaid list displays billing information BI that is unpaid (i.e., payment from the payer P to the biller C or the advance payer R has not been completed). The billing information BI is associated with "business partner name", "billing amount", "scheduled payment date", "status", and "advance payment option". Of these, "business partner name", "billing amount", and "scheduled payment date" are items that are determined at the time the billing information acquisition unit 11 acquires the billing information BI. "Status" and "advance payment option" are items that can be changed by the payer P or the advance payment device 10.

[0051] When the "Status" button is active, the payer P can change the status. For example, the payer P changes the status to "paid" after making a deposit to the biller C at a payment bank counter or ATM. When the "Status" button is inactive, the payer P cannot change the status. The "Status" button becomes inactive, for example, in the case of a payment agent or advance payment. In these cases, the status is changed by the biller device 30, and therefore the payer P cannot change the status.

[0052] The payer P can select advance payment for each piece of claim information BI. Each piece of claim information BI is provided with a check box for selecting whether or not to make an advance payment. The payer P can select each one independently. In the example shown, a check box D141 is provided for claim information BI11, a check box D142 is provided for claim information BI12, and a check box D143 is provided for claim information BI13. Also, in the example shown, the check box D141 is selected (i.e., advance payment is selected only for claim information BI11).

[0053] A collective selection check box D14 may be provided to check all displayed billing information BI at once. The payer P can select advance payment for all billing information BI by selecting the collective selection check box D14. Providing the collective selection check box D14 can reduce the effort required for the payer P to select check boxes one by one. In the example shown in the figure, the collective selection check box D14 is not checked (i.e., collective advance payment is not selected).

[0054] In the illustrated example, billing information BI11, billing information BI12, and billing information BI13 are displayed as unpaid billing information BI. Specifically, the "customer name" of billing information BI11 is A Shoji, the "billing amount" is 50,000 yen, the "scheduled payment date" is April 28, 2023, the "status" is unpaid, and "advance payment selection" is selected. The "customer name" of billing information BI12 is B Shoji, the "billing amount" is 20,000 yen, the "scheduled payment date" is April 30, 2023, the "status" is unpaid, and "advance payment selection" is not selected. The "customer name" of billing information BI13 is C Shoji, the "billing amount" is 30,000 yen, the "scheduled payment date" is April 30, 2023, the "status" is unpaid, and "advance payment selection" is not selected.

[0055] [Automatic Advance Payment] Next, automatic advance payment will be described. Automatic advance payment means that an advance payment is made without the operation of the payer P (i.e., the advance payment device 10 transfers the money to the biller C). Whether or not to make an automatic advance payment may be set, for example, on a statement by statement basis. Whether or not to make an automatic advance payment may be set, for example, by the payer P. The payer P selects whether or not to make an automatic advance payment according to the billing information BI output by the output unit 14 of the advance payment device 10, and the selected information is acquired by the acquisition unit 15. The payer P may set, for example, when making a transfer to the advance payer R, whether or not to make an automatic advance payment for bills from the following month onwards.

[0056] It should be noted that the automatic advance payment according to this embodiment is different from the registration of a transfer destination in the conventional technology of internet banking, etc. For example, in the conventional technology of internet banking, the registration of a transfer destination is performed after a transfer is executed, but the automatic advance payment according to this embodiment can also be set for billing information BI issued by biller C, who has never executed a transfer.

[0057] When the advance payment device 10 supports automatic advance payment, the billing information BI is associated with information on whether or not to make an automatic advance payment. The information on whether or not to make an automatic advance payment may be acquired from the payer device 20. The transfer execution unit 16 executes the transfer process based on the billing information BI indicating that an automatic advance payment is to be made, without the operation of the payer P (i.e., without the payer P determining whether or not to make an advance payment for each invoice).

[0058] The automatic advance payment is not limited to the example set by the payer P. The automatic advance payment may be set automatically by the advance device 10. For example, the advance device 10 may be set to automatically transfer all cases from the following month onward, regardless of the transfer record, once the advance payment process is completed for a bill for which an advance payment has been requested. This is based on the idea that in principle, all cases are advanced and the setting of the automatic advance payment can be cancelled later for cases that the payer P judges not to require an advance payment. After the automatic advance payment has been set, if the payer P requests to cancel the automatic advance payment, the advance device control unit 13 cancels the setting of the automatic advance payment based on the operation of the payer P.

[0059] The automatic advance payment is set by the advance device control unit 13. That is, the advance device control unit 13 sets the billing information BI for which information on advance payment has been acquired by the acquisition unit 15 to perform an automatic advance payment regardless of the operation of the payer P. Note that the advance device control unit 13 may also set the billing information BI for which information on advance payment has been acquired by the acquisition unit 15 to perform an automatic advance payment based on the operation of the payer P.

[0060] The automatic advance payment may be set in a form limited to a specific payee. Also, by registering a payee from the link information before a transfer is made, it is possible to set the automatic advance payment before the transfer is made. Also, the advance payment device 10 may set the automatic advance payment based on the transfer history after the transfer is made.

[0061] [Pre-set Advance Payment Checkbox] The selection of the checkboxes described above may be made based on the results of a predetermined judgment made in advance by the advance device control unit 13. In other words, in this embodiment, advance payment may be preset. As an example, advance payment may be selected as a preset for a claim issued by a biller C who is determined to have a transfer record based on the transfer record information TRI. Advance payment may be preset, for example, for each business partner (each biller C). Information regarding the preset may be determined in advance based on the transfer record information TRI acquired by the transfer record acquisition unit 17, and stored as preset information.

[0062] FIG. 6 is a diagram showing an example of pre-set information according to this embodiment. An example of the pre-set information will be described with reference to the same figure. As shown in the figure, the pre-set information is associated with the business partner name (information identifying the biller C) and the advance payment preset information. The advance payment preset information is information indicating whether or not the check box for selecting the advance payment shown in FIG. 5 is checked in advance. If the advance payment preset information is "YES", the check box is checked in advance. Also. If the advance payment preset information is "NO", the check box is not checked in advance. If there is a transfer record in the past, the advance payment preset information is "YES", and if there is a transfer record in the past, the advance payment preset information is "NO". The pre-set information as shown in the figure may exist for each payer P, for example. Also, the pre-set information as shown in the figure may be set as appropriate, for example, according to the operation of the payer P. Also, the pre-set information described with reference to the same figure may not be generated, and the transfer record information TRI may be used as the pre-set information.

[0063] Even if the checkbox for selecting advance payment shown in Figure 5 has been checked in advance (i.e., even if advance payment has been selected as a pre-setting for the claim), it is possible for payer P to cancel the selection of advance payment (i.e., uncheck the box) in response to his / her operation.

[0064] The advance payment check box may be preset based on the amount of past transfer records. When the advance payment check box is preset based on the amount of past transfer records, the advance payment device control unit 13 compares the transfer amount based on the transfer record information TRI with the transfer amount shown in the billing information BI and calculates the difference. The advance payment device control unit 13 selects advance payment as the preset for bills where the calculated difference is within a predetermined range, and does not select advance payment as the preset for bills where the calculated difference is outside the predetermined range. The predetermined range may be, for example, a range where the transfer amount shown in the billing information BI is within 20% of the transfer amount based on the transfer record information TRI.

[0065] [A series of processes performed by the advance payment device] Next, a flow of a series of processes performed by the payment advance device 10 according to this embodiment will be described with reference to FIG. 7 to FIG.

[0066] 7 is a first flow chart showing the flow of a series of processes performed by the advance payment device according to this embodiment. First, the flow of a series of processes related to the output of billing information will be described with reference to the same figure.

[0067] (Step S11) First, the advance payment device control unit 13 acquires information on a specific billing information BI issued to the target payer P from a plurality of billing information BI stored in the billing information storage unit 12.

[0068] (Step S12) Next, the transfer history acquisition unit 17 acquires the transfer history information TRI. The transfer history information TRI acquired by the transfer history acquisition unit 17 includes information on the transfer history of the target payer P. Preferably, the transfer history information TRI acquired by the transfer history acquisition unit 17 may also include information on the transfer history to the biller C for the billing information BI identified in step S11.

[0069] (Step S13) Next, the advance device control unit 13 judges whether or not a preset pattern for the target payer P exists based on the acquired transfer record information TRI. The preset pattern may be generated at the time when the transfer record information TRI is acquired, or may be generated in advance based on previously acquired transfer record information TRI. If a preset pattern for the target payer P exists (i.e., Step S13; YES), the process proceeds to Step S14. If a preset pattern for the target payer P does not exist (i.e., Step S13; NO), the process proceeds to Step S15.

[0070] (Step S14) If a preset pattern exists, the advance payment is preset according to the preset pattern.

[0071] (Step S15) If there is no preset pattern, the advance payment is preset to OFF.

[0072] (Step S16) The billing information BI is output to the payer device 20. The screen configuration of the information output to the payer device 20 is as described with reference to FIG. 5, and the advance payment setting determined in step S14 or step S15 is reflected in the advance payment selection field (check box).

[0073] 8 is a second flowchart showing the flow of a series of processes performed by the advance payment device according to this embodiment. Next, with reference to the same figure, the flow of a series of processes when advance payment is selected after the output of billing information will be described.

[0074] (Step S21) First, the advance payment device 10 outputs the target billing information BI. This step corresponds to the above-mentioned step S16.

[0075] (Step S22) The advance payment device 10 judges whether or not advance payment has been selected by the payer P as a result of outputting the billing information BI. Cases in which advance payment has been selected by the payer P include cases in which advance payment has been selected as a pre-setting and processing has proceeded without canceling the selection, and cases in which advance payment has not been selected as a pre-setting but the payer P selected advance payment and processing has proceeded. If advance payment has been selected (i.e., step S22; YES), processing proceeds to step S23. If advance payment has not been selected (i.e., step S22; NO), processing ends.

[0076] (Step S23) The advance payment device 10 executes the advance payment process for the bill for which advance payment has been selected. Specifically, the advance payment process is the process in which the advance payment person R makes a payment to the biller C by the payment due date of the bill.

[0077] (Step S24) Here, when selecting advance payment, the payer P may select the payment method for the next payment onwards. As the payment method for the next payment onwards, "same" or "select each time" can be selected. If "same" is selected (i.e., step S24; same), the process proceeds to step S25. If "select each time" is selected (i.e., step S25; select each time), automatic settings for the advance payment are not made and the process ends.

[0078] (Step S25) Next, the advance payment device 10 judges whether or not automatic advance payment is set. If automatic advance payment is set (i.e., step S25; YES), the process proceeds to step S26. If automatic advance payment is not set (i.e., step S25; NO), the process proceeds to step S27.

[0079] (Step S26) If automatic advance payment has been set, the advance payment device 10 sets the automatic advance payment for the next and subsequent bills issued by the biller C. In this case, the advance payment device 10 will automatically make an advance payment even if the payer P does not select an advance payment option.

[0080] (Step S27) If automatic advance payment has not been set, the advance payment device 10 performs a preset setting so that advance payment will be made from the next display onwards for claims issued by the claimant C. In this case, the advance payment device 10 presets the selection of advance payment for claims issued by the claimant C (i.e., checks in advance a check box such as checkbox D141 in FIG. 5), and will perform advance payment in response to the processing being advanced by payer P.

[0081] FIG. 9 is a third flowchart showing the flow of a series of processes performed by the advance payment device according to this embodiment. Next, with reference to the same figure, a series of processes related to the cancellation of an advance payment will be described. According to this embodiment, for claims issued by claimant C who is determined to be likely to make an advance payment based on a predetermined judgment, an advance payment is preset (the advance payment checkbox is checked in advance as a preset setting). Instead, a two-stage cancellation is possible depending on the operation of payer P. Below, with reference to the same figure, a two-stage cancellation method will be described.

[0082] (Step S31) First, the advance payment device 10 automatically makes a payment reservation for a bill for which an advance payment is preset. A payment reservation is a reservation for making an advance payment by the payment due date.

[0083] (Step S32) When a payment reservation has been made, the advance payment device 10 notifies the payer P that a payment reservation has been made. This notification is made by the output unit 14. In other words, the output unit 14 notifies the payer P that an advance payment has been set without any operation by the payer P.

[0084] The advance device 10 may inquire of the payer P whether or not to select advance payment, instead of automatically setting advance payment in advance according to past transfer records. An inquiry may be made, for example, when the billing amount is extremely large compared to past transfer records. In this case, the output unit 14 compares the transfer amount based on the transfer record information TRI acquired by the transfer record acquisition unit 17 with the transfer amount indicated in the billing information BI acquired from the billing information storage unit 12 by the advance device control unit 13, and outputs an inquiry as to whether or not to select advance payment for a bill in which the difference is outside a predetermined range. The predetermined range may be, for example, an amount 20% or more larger than the amount of past transfer records.

[0085] The payer P can cancel the selection of advance payment in response to the notification from the advance payment device 10. Information indicating the cancellation of the selection of advance payment is acquired by the acquisition unit 15 of the advance payment device 10. In response to the information acquired by the acquisition unit 15, the advance payment device control unit 13 cancels the selection of advance payment. In this way, the payer P can perform the first stage of cancellation of the previously set selection of advance payment.

[0086] (Step S33) If the advance payment is cancelled by the payer P in response to the notification from the advance payment device 10 (i.e., Step S33; YES), the process proceeds to Step S36. If the advance payment is not cancelled by the payer P (i.e., Step S33; NO), the process proceeds to Step S34.

[0087] (Step S34) Even if the payer P does not cancel the advance payment in response to the notification from the advance device 10, the payer P can cancel it up to a specified day from the due date for transfer processing. The specified day may be about three days, taking into account the preparation period for transfer. In this way, the payer P can perform a second stage of cancellation of the pre-set advance payment selection. If the payer P does not request cancellation of the advance payment selection (i.e., step S34; NO), the process proceeds to step S35. If the payer P requests cancellation of the advance payment selection (i.e., step S34; YES), the process proceeds to step S36.

[0088] (Step S35) If the payer P does not request cancellation of the selection of the advance payment, the advance payment device 10 executes the advance payment process.

[0089] (Step S36) When the payer P requests cancellation of the selection of the advance payment, the advance device 10 turns off the setting of the automatic advance payment.

[0090] [Processing when there is an unpaid invoice] Next, the processing of the advance device 10 when there is an unpaid invoice will be described. Here, if there is an unpaid invoice among the invoices that the payer P should pay, there is a risk that the credit of the payer P will fall. The payer P processes multiple invoices in the course of daily work, and there are cases where the payer P unintentionally forgets to pay an invoice. Therefore, the advance device 10 according to this embodiment performs processing to prevent missed payments when there is an unpaid invoice.

[0091] FIG. 10 is a diagram showing an example of billing information according to this embodiment when there is an unpaid bill. This figure is a modified example of the billing information BI described with reference to FIG. 4, and the status is different from that of the billing information BI described with reference to FIG. 4. As shown in the figure, the status of billing information BI1 and billing information BI2 is "paid". In other words, billing information BI1 and billing information BI2 indicate that after payer R made an advance payment, payer P further transferred the amount to payer R. On the other hand, the status of billing information BI3 is "unpaid". In other words, billing information BI3 indicates that payment to biller C has not been made, and whether or not to make an advance payment has not been selected.

[0092] In this state, if the payer P does not make payment for the billing information BI3 and the scheduled payment date of April 30, 2023 passes, there is a risk that the credit of the payer P will decline. Therefore, the advance device 10 according to this embodiment performs processing to prevent missed payments when there is such an unpaid bill.

[0093] 11 is a fourth flowchart showing the flow of a series of processes performed by the advance device according to this embodiment. With reference to this figure, an example of the process performed by the advance device 10 to prevent payment omissions will be described.

[0094] (Step S41) First, billing information BI is acquired. The billing information BI may be acquired by the billing information acquisition unit 11, or information stored in the billing information storage unit 12 may be acquired by the advance payment device control unit 13. The billing information BI acquired in step S41 includes at least information (status) indicating the payment status to the biller C.

[0095] (Step S42) Next, it is determined whether or not there is an unpaid claim among the acquired billing information BI. Whether or not there is an unpaid claim is determined based on the status associated with the billing information BI. If the result of the determination is that there is an unpaid claim (i.e., step S42; YES), the advance payment device control unit 13 advances the process to step S43 and performs processing to prevent missed payment to biller C. On the other hand, if there is no unpaid claim (i.e., step S42; NO), the advance payment device control unit 13 ends the process.

[0096] (Step S43) The advance payment device 10 according to this embodiment performs processing to prevent missed payments to the biller C in two stages. First, in the first stage processing, the advance payment device 10 notifies the payer P that there is an unpaid bill. The advance payment device 10 notifies the payer P according to the payment due date. The advance payment device 10 may notify the payer P, for example, five days before the payment due date. The advance payment device control unit 13 decides whether or not to notify the payer P. If it is decided to notify the payer, the output unit 14 outputs to the payer P that there is an unpaid bill.

[0097] (Step S44) The payer P can make a payment reservation in response to the notification from the advance payment device 10. If a payment reservation is made, the payment will be made by the due date by normal payment or advance payment, and the payment deadline can be prevented from passing. If a payment reservation is made (i.e., step S44; YES), the payment deadline can be prevented from passing, and the process to prevent missed payment is terminated. However, depending on the payer P, there are cases where the payer P does not notice the notification from the advance payment device 10. Therefore, if a payment reservation is not made even after a notification, the advance payment device 10 further performs a second stage of processing to prevent missed payment to the biller C. If a payment reservation is not made (i.e., step S44; NO), the process proceeds to step S45.

[0098] (Step S45) If a payment reservation is not made, the advance payer R makes an advance payment to the claimant C on behalf of the payer P, even if there is no instruction from the payer P. Whether or not to make an advance payment is determined by the advance payment device control unit 13. If the advance payment device control unit 13 is unable to obtain information indicating that payment has been made from the payer P by the payment due date, it decides to execute a transfer process for the unpaid claim (i.e., an advance payment). If the advance payment device control unit 13 decides to make an advance payment, the transfer execution unit 16 executes a transfer process for the unpaid claim. In other words, the second stage process is that the advance payer R makes an advance payment to the claimant C on behalf of the payer P, even if there is no instruction from the payer P. By carrying out such a process, the payment is made by the due date, and it is possible to prevent the payment deadline from being exceeded.

[0099] Fig. 12 is a diagram showing an example of a display screen presented on the payer device according to this embodiment, which is a diagram showing an example of a screen configuration when selecting whether or not to make an advance payment when there is an unpaid debt. An example of a screen configuration of a display screen D70 will be described with reference to the same figure. Display screen D70 is displayed when the payment due date is approaching (for example, within three days of the due date) and payment has not been made.

[0100] The display screen D70 is displayed by the presentation unit 22 of the payer device 20 as a result of performing the processing of step S43 described above. The display screen D70 includes symbols D71, D72, and D73 as screen components. The display screen D70 displays a message that informs the payer P that the payment due date is approaching. Examples of messages that inform the payer P that the payment due date is approaching include "There are invoices for which payment has not been confirmed", "The payment due date for the following invoices is approaching", and "Please pay the shortfall by the payment due date".

[0101] In the reference number D71, the payment amount (unpaid amount) of the invoice whose due date is approaching and the breakdown of the invoice are displayed. As the breakdown of the invoice, for example, the "client name", "billing amount", and "payment due date" are displayed. In the illustrated example, specifically, an invoice with a "client name" of A Shoji Co., Ltd., a "billing amount" of 50,000 yen, and a "payment due date" of 2023 / 4 / 28 (2 days remaining) is described as the invoice information BI21. In addition, an invoice with a "client name" of B Shoji Co., Ltd., a "billing amount" of 20,000 yen, and a "payment due date" of 2023 / 4 / 30 (4 days remaining) is described as the invoice information BI22. In addition, an invoice with a "client name" of C Shoji Co., Ltd., a "billing amount" of 30,000 yen, and a "payment due date" of 2023 / 4 / 30 (4 days remaining) is described as the invoice information BI23.

[0102] Reference symbol D72 is a button used when the payer P wishes to log in to the system and check the details of the invoice described in reference symbol D71. When the advance payment device 10 detects that reference symbol D72 has been operated, it transitions to a login screen, and after logging in, displays the details of the invoice described in reference symbol D71.

[0103] Reference symbol D73 is a button used when the payer P wishes to make an advance payment for the invoice indicated by reference symbol D71. When the advance payment device 10 detects that the invoice D73 has been operated, it may transition to a login screen, and after login, display details of the invoice indicated by reference symbol D71 and prompt the payer P to set up an advance payment.

[0104] [Processing based on the payer's financial situation] Next, processing based on the business situation of the payer P will be described. Here, depending on the business situation of the payer P (for example, the state of cash flow, etc.), there are cases where it is better to recommend an advance payment, and cases where it is better not to recommend an advance payment. Thus, according to the advance device 10 of this embodiment, information on the business situation of the payer P is acquired, and an advance payment is recommended based on the acquired information. An example of processing based on the business situation of the payer P will be described below with reference to Figs. 13 to 16.

[0105] Fig. 13 is a functional configuration diagram for explaining a first modified example of the functional configuration of the advance device according to this embodiment. With reference to the same figure, an example of the functional configuration of the advance device 10A, which is a modified example of the advance device 10, will be explained. The advance device 10A differs from the advance device 10 in that it includes a business status acquisition unit 18 instead of the transfer record acquisition unit 17 or in addition to the transfer record acquisition unit 17. In the explanation of the advance device 10A, the same components as those in the advance device 10 are denoted by the same reference numerals and explanations thereof may be omitted. In addition, in the explanation of the advance device 10A, explanations of the same components as those in the advance device 10 may be omitted.

[0106] The business status acquisition unit 18 acquires business status information BCI, which is information related to the business status of the payer P. The business status information BCI is acquired, for example, from the business status visualization SaaS40. The business status visualization SaaS40 may be software used by the payer P. Since the business status visualization SaaS40 stores information related to the business status of the payer P, in the following explanation the business status visualization SaaS40 may be referred to as a business status storage device. The business status storage device stores information related to the business status of the payer P. The business status acquisition unit 18 outputs the acquired business status information BCI to the advance payment device control unit 13.

[0107] The advance payment device control unit 13 judges whether or not to propose to the payer P that they make an advance payment, based on the business status information BCI acquired by the business status acquisition unit 18. The judgment of whether or not to propose to the payer P that they make an advance payment may be made individually for each of the multiple billing information BI stored in the billing information storage unit 12. When the advance payment device control unit 13 judges that it is to propose to the payer that they make an advance payment, the output unit 14 outputs information proposing to the payer P that they make an advance payment.

[0108] The determination of whether to propose to make an advance payment to the payer P may be made based on the result of comparing the future deposits and withdrawals of the payer P. When withdrawals are greater than deposits, it is assumed that the payer P does not have an abundant cash flow. Therefore, the advance device control unit 13 may determine to propose to make an advance payment to the payer P when withdrawals are greater than deposits. Also, when the account balance of the payer P is decreasing, it is assumed that the payer P does not have an abundant cash flow. Therefore, the advance device control unit 13 may determine to propose to make an advance payment to the payer P when the balance of the payer P is less than a predetermined threshold value.

[0109] Fig. 14 is a diagram showing an example of business status acquired by the advance payment device according to this embodiment. With reference to the same figure, an example of business status information BCI acquired from the business status visualization SaaS 40 will be described. The illustrated example shows business status information BCI for a specific payer P (e.g., A Co., Ltd.).

[0110] As shown in the figure, the business status information BCI corresponds to a "date and time", a "deposit amount", a "withdrawal amount", and a "balance". The "date and time" is the date and time when a deposit or withdrawal is made, or the date and time when a deposit or withdrawal is made. The "deposit amount" is the amount deposited to payer P, or the amount to be deposited to payer P. The "withdrawal amount" is the amount withdrawn by payer P, or the amount to be withdrawn by payer P. In other words, the business status information BCI includes information regarding payer P's deposits and withdrawals. The "balance" is the result of the change in payer P's account balance as a result of a deposit or withdrawal. In other words, the business status information BCI includes information regarding payer P's balance.

[0111] The business status information BCI may include information regarding future deposits and withdrawals of the payer P. The information regarding future deposits and withdrawals may be the expected amounts of deposits and withdrawals. The business status information BCI does not necessarily need to include information regarding individual transactions, and may include amounts regarding deposits and withdrawals for a specified period (e.g., month by month), or expected amounts of deposits and withdrawals. The business status information BCI may also include a profit and loss statement of the payer P. The profit and loss statement may include sales, cost of sales, selling and general administrative expenses, non-operating profit and loss, extraordinary profit and loss, corporate tax, etc.

[0112] 15 is a fifth flowchart showing the flow of a series of processes performed by the advance device according to this embodiment. With reference to the same figure, an example of processes based on the business situation of the payer P performed by the advance device 10A will be described.

[0113] (Step S51) First, the business status acquisition unit 18 acquires business status information BCI, which is information on the business status of the payer P, from the business status visualization SaaS 40.

[0114] (Step S52) Next, the advance device control unit 13 refers to the acquired business status information BCI and confirms the deposit and withdrawal data of the payer P.

[0115] (Step S53) As a result of checking the deposit and withdrawal data, firstly, if the withdrawal is greater than the deposit, or secondly, if the balance is less than a predetermined amount (i.e., step S53; YES), the advance device control unit 13 determines that an advance payment should be proposed to the payer P, and proceeds to the process at step S54. On the other hand, if it is not determined that an advance payment should be proposed to the payer P (i.e., step S53; NO), the process ends.

[0116] (Step S54) If it is determined that the advance payment should be proposed to the payer P, the output unit 14 outputs advance payment recommendation information to the payer device 20, thereby proposing the advance payment to the payer P.

[0117] (Step S55) When the payer P receives a proposal for advance payment from the advancing device 10A, the payer P considers whether or not to make an advance payment, taking into account his / her own business situation and the effort involved in processing the invoice. If the payer P decides to make an advance payment as a result of the consideration, the payer P operates the payer device 20 to output advance payment selection information to the advancing device 10A. Note that the selection of advance payment may be made for each billing information BI. If the payer P selects advance payment (i.e., step S55; YES), the process proceeds to step S56. If the payer P does not select advance payment (i.e., step S55; NO), the process ends.

[0118] (Step S56) When the payer P selects the advance payment, the advance payment device 10A applies for the advance payment. When the advance payment is determined to be possible as a result of the application, the advance payment process is executed. The process after the advance payment application is made will be described with reference to FIG. 16.

[0119] 16 is a sixth flowchart showing the flow of a series of processes performed by the advance payment device according to this embodiment. With reference to this figure, an example of the processes performed when an application for advance payment is made by the advance payment device 10A will be described.

[0120] (Step S61) First, after an advance payment is proposed to the payer P, if the payer P selects the advance payment, the acquisition unit 15 acquires information indicating that the advance payment has been selected. That is, the acquisition unit 15 acquires information indicating whether or not the payer P desires the advance payment from the payer P, according to the information output by the output unit 14. If an advance payment application has been made from the payer P (i.e., step S61; YES), the process proceeds to step S62. If an advance payment application has not been made despite the advance payment being proposed to the payer P (i.e., step S61; NO), the process is terminated without carrying out the subsequent process.

[0121] (Step S62) When an advance payment application is made by the payer P, the advance payment device 10A judges whether or not an advance payment is possible. Whether or not an advance payment is possible may be judged based on the payer P's past payment performance, the current business situation, and the like. Note that step S62 may be performed before step S54 in the series of processes described with reference to FIG. 15. In other words, the advance payment device 10A may be configured to judge whether or not an advance payment is possible before proposing an advance payment to the payer P, and to propose an advance payment only to the payer P who is judged to be able to make an advance payment.

[0122] (Step S63) Returning to Fig. 16, the advance payment device 10A feeds back the result of its determination as to whether or not advance payment is possible to the business situation visualization SaaS 40. This feedback process is performed by the advance payment device control unit 13. In other words, the advance payment device control unit 13 can also be said to feed back the result of its determination as to whether or not advance payment is possible to the business situation visualization SaaS 40.

[0123] (Step S64) If it is determined that advance payment is possible, i.e., if the acquisition unit 15 acquires information from the payer P indicating a desire to make an advance payment (i.e., step S64; YES), the process proceeds to step S65, and preparations for the advance payment are made. In preparation for the advance payment, the advance payment device control unit 13 associates an advance payment with the billing information BI if advance payment is possible. However, if it is determined that advance payment is not possible (i.e., step S64; NO), the process ends without carrying out the subsequent processes.

[0124] (Step S65) If it is determined that an advance payment is possible, the advance payment device 10A executes the advance payment. The advance payment process is specifically performed by the transfer execution unit 16. The transfer execution unit 16 executes a transfer process to the account of the biller C based on the billing information BI indicating that an advance payment is to be made.

[0125] [Processing for payers whose advance payment amount or regular payment amount has been determined in advance] Next, the process for the payer P for whom the advance payment amount or normal payment amount is determined in advance will be described. Here, depending on the applicant, the amount for which an advance payment can be made or the amount for which a normal payment can be made may be determined for each month (or for each specified period). Therefore, according to the advance payment device 10 of this embodiment, by setting in advance the amount to be an advance payment or the amount to be a normal payment other than an advance payment among the amounts to be paid by the payer P, it is automatically determined which claims are to be an advance payment and which claims are to be a normal payment. Hereinafter, the process for the payer P for whom the advance payment amount or normal payment amount is determined in advance will be described with reference to Figs. 17 to 20.

[0126] Fig. 17 is a functional configuration diagram for explaining a second modified example of the functional configuration of the advance device according to this embodiment. With reference to the same figure, an example of the functional configuration of the advance device 10B, which is a modified example of the advance device 10, will be explained. The advance device 10B differs from the advance device 10 in that it includes a set amount acquisition unit 19 instead of the transfer record acquisition unit 17 or in addition to the transfer record acquisition unit 17. In the explanation of the advance device 10B, the same components as those in the advance device 10 are denoted by the same reference numerals and explanations thereof may be omitted. In addition, in the explanation of the advance device 10B, explanations of the same components as those in the advance device 10 may be omitted.

[0127] The set amount acquisition unit 19 acquires the set amount information SAI. The set amount information SAI is transmitted to the advance payment device 10B by the payer P operating the payer device 20. The set amount information SAI includes at least one of the following amounts: an advance payment amount indicating the upper limit of the amount to be advanced payment, and a regular payment amount indicating the upper limit of the amount to be ordinary payment. Ordinary payment is a method other than advance payment, in which the payer P pays the biller C directly without going through the advance payment person R.

[0128] The advance payment device control unit 13 determines whether to make an advance payment or a regular payment for an invoice issued to the payer P, based on the set amount information SAI acquired by the set amount acquisition unit 19. Specifically, the advance payment device control unit 13 makes the determination based on the following criteria (1) to (4). (1) If the billing amount shown in the billing information BI is less than the advance payment amount, it is determined that the entire billing amount shown in the billing information BI is to be an advance payment. (2) If the billing amount shown in the billing information BI is greater than the advance payment amount, it is determined that the amount shown in the advance payment amount out of the billing amount shown in the billing information BI will be treated as an advance payment, and the remaining amount will be treated as a regular payment. (3) If the billing amount shown in the billing information BI is less than the regular payment amount, it is determined that the entire billing amount shown in the billing information BI is regular payment. (4) If the billing amount shown in the billing information BI is greater than the regular payment amount, it is determined that the amount shown in the regular payment amount of the billing amount shown in the billing information BI will be treated as regular payment, and the remaining amount will be paid in advance.

[0129] The transfer execution unit 16 executes the transfer process for the invoice for which the advance payment has been decided by the advance device control unit 13.

[0130] FIG. 18 is a diagram showing an example of the screen configuration of the set amount acquisition screen according to this embodiment. With reference to the same figure, an example of the screen configuration of the set amount acquisition screen D80 will be described. The set amount acquisition screen D80 is presented by the presentation unit 22 of the payer device 20. An instruction for presenting the set amount acquisition screen D80 may be given by the advance payment device 10. Note that the illustrated example is an example of a case where only either the advance payment amount or the normal payment amount can be set. In this case, the set amount information SAI acquired by the set amount acquisition unit 19 will include only either the advance payment amount or the normal payment amount.

[0131] Specifically, the set amount acquisition screen D80 has a code D81 which is a text box for setting the normal payment amount, and a code D82 which is a text box for setting the advance payment amount. Note that the code D81 and the code D82 are not limited to the example of a text box, and may be other forms in which the amount can be input, such as a select box.

[0132] FIG. 18(A) is a diagram showing the screen configuration of a set amount acquisition screen D80A, which is an example of a case where only the normal payment amount is set, among the set amount acquisition screen D80. As shown in the figure, only the normal payment amount is set in the set amount acquisition screen D80A. Specifically, "100,000" is entered in code D81. In this case, since information has already been entered in code D81, which is the input section for the normal payment amount, no information can be entered in code D82, which is the input section for the advance payment amount.

[0133] FIG. 18(B) is a diagram showing the screen configuration of a set amount acquisition screen D80B, which is an example of the set amount acquisition screen D80 in which only the advance payment amount is set. As shown in the figure, only the advance payment amount is set in the set amount acquisition screen D80B. Specifically, "100,000" is entered in code D82. In this case, since information has already been entered in code D82, which is the input section for the advance payment amount, no information can be entered in code D81, which is the input section for the normal payment amount.

[0134] 19 is a seventh flowchart showing the flow of a series of processes performed by the advance payment device according to this embodiment. With reference to this figure, an example of the advance payment amount setting process performed by the advance payment device 10B will be described.

[0135] (Step S71) First, the set amount acquisition unit 19 acquires set amount information SAI from the payer P. The set amount information SAI includes information on at least one of the advance payment amount and the regular payment amount. Note that the set amount information SAI may include information on both the advance payment amount and the regular payment amount.

[0136] (Step S72) Next, the advance device control unit 13 acquires the billing information BI stored in the billing information storage unit 12. Here, the set amount information SAI acquired in step S71 exists for each payer P. In addition, the advance device control unit 13 acquires the billing information BI corresponding to the payer P. Therefore, the payer P of the set amount information SAI acquired by the set amount acquisition unit 19 and the payer P of the billing information BI acquired by the advance device control unit 13 match each other.

[0137] (Step S73) The advance payment device control unit 13 determines the amount to be advanced payment based on the acquired information. Specifically, the advance payment device control unit 13 determines the amount to be advanced payment based on the criteria described with reference to Fig. 17. Determining the amount to be advanced payment means, in other words, specifying the billing information BI to be advanced payment.

[0138] (Step S74) Next, an application for advance payment is made for the billing information BI for which it has been decided that an advance payment should be made. When an application for advance payment is made, the payer P's past transfer record, business situation, etc. are referenced to determine whether or not the advance payment should be made.

[0139] (Step S75) The transfer execution unit 16 executes an advance payment process depending on the result of the advance payment decision made in step S74. The transfer execution unit 16 performs an advance payment only for billing information BI for which advance payment is determined to be possible, and does not perform an advance payment for billing information BI for which advance payment is determined to be impossible. At this time, the advance payment device 10B may notify the payer P that advance payment is impossible.

[0140] (Step S76) The advance payment device control unit 13 pays all bills issued to the payer P during the target period (e.g., one month) except for the amount paid in advance in step S73 as regular payments. For bills paid as regular payments, the payer P transfers the money directly to the biller C.

[0141] FIG. 20 is a diagram showing a modified example of the screen configuration of the set amount acquisition screen according to this embodiment. With reference to the same figure, an example of the screen configuration of the set amount acquisition screen D80C, which is a modified example of the set amount acquisition screen D80, will be described. The set amount acquisition screen D80C is similar to the set amount acquisition screen D80 in that it is presented by the presentation unit 22 of the payer device 20. On the other hand, the set amount acquisition screen D80C differs from the set amount acquisition screen D80 in that both the advance payment amount and the normal payment amount can be set. In this case, the set amount information SAI acquired by the set amount acquisition unit 19 includes both the advance payment amount and the normal payment amount. In the description of the set amount acquisition screen D80C, the description of the same configuration as the set amount acquisition screen D80 may be omitted.

[0142] Specifically, the set amount acquisition screen D80C has a code D81C which is a text box for setting the normal payment amount, and a code D82C which is a text box for setting the advance payment amount. Note that the code D81C and the code D82C are not limited to the example of a text box, and may be other forms in which the amount can be input, such as a select box. The code D81C and the code D82C differ from the code D81 and the code D82 in that the amount can be input in both.

[0143] In the illustrated example, specifically, "100,000" is entered in code D81C. Also, "200,000" is entered in code D82C. In this case, of all invoices issued to payer P during the target period (e.g., one month), up to 100,000 yen will be paid normally, and up to 200,000 yen will be paid in advance.

[0144] The set amount acquisition screen D80C further includes a code D83C. Code D83C is used to select a preferred payment method from advance payment or regular payment. Specifically, code D83C allows selection of either advance payment or regular payment. In the example shown, advance payment has been selected. In the example shown, if the billing amount is 200,000 yen or less, the entire amount will be advance payment. Also, if the billing amount exceeds 200,000 yen, regular payment will be used up to 100,000 yen.

[0145] Code D83C may be for selecting a preferred payment method when the amount of the billing information BI exceeds the total amount of the advance payment amount and the regular payment amount inputted in codes D81C and D82C. In other words, the information selected by code D83C can be said to be priority information for selecting whether the advance payment or the regular payment should be prioritized. The priority information is acquired by the set amount acquisition unit 19. More specifically, when the billing amount exceeds 300,000 yen, the payment is made by the advance payment selected by code D83C. In other words, when the billing amount shown in the billing information BI is greater than the total amount of the advance payment amount and the regular payment amount inputted in codes D81C and D82C (the difference amount may be described as the excess amount), the excess amount is paid by the payment method selected by the priority information acquired using code D83C.

[0146] [Internal configuration] FIG. 21 is a block diagram showing an example of the internal configuration of the advance payment device 10, the advance payment device 10A, and the advance payment device 10B (hereinafter, may be simply referred to as the advance payment device 10) according to this embodiment. At least a part of the functions of the advance payment device 10 can be realized using a computer. As shown in the figure, the computer is configured to include a central processing unit 901, a RAM 902, an input / output port 903, input / output devices 904 and 905, etc., and a bus 906. The computer itself can be realized using existing technology. The central processing unit 901 executes instructions included in a program read from the RAM 902, etc. The central processing unit 901 writes data to the RAM 902, reads data from the RAM 902, and performs arithmetic operations and logical operations according to each instruction. The RAM 902 stores data and programs. Each element included in the RAM 902 has an address and can be accessed using the address. Incidentally, RAM is an abbreviation for "random access memory." The input / output port 903 is a port through which the central processing unit 901 exchanges data with external input / output devices. The input / output devices 904 and 905 are input / output devices. The input / output devices 904 and 905 exchange data with the central processing unit 901 via the input / output port 903. The bus 906 is a common communication path used within the computer. For example, the central processing unit 901 reads and writes data in the RAM 902 via the bus 906. Also, for example, the central processing unit 901 accesses the input / output port via the bus 906. Also, all or part of each functional unit provided in the advance payment device 10 may be realized using hardware such as an ASIC, a PLD, or an FPGA. Also, all or part of each functional unit may be realized by a combination of software and hardware.

[0147] The payer device 20 and the claimant device 30 may have an internal configuration as shown in FIG. 20, similar to the claimant device 30.

[0148] [Summary of the embodiment] As described above, the advance payment device 10 includes the billing information acquisition unit 11 to acquire billing information BI related to a bill issued from the biller C to the payer P, includes the transfer history acquisition unit 17 to acquire transfer history information TRI, which is information related to transfers made by the payer P in the past, includes the advance payment device control unit 13 to select billing information BI for a specific payer P from among the multiple billing information BI acquired by the billing information acquisition unit 11, includes the output unit 14 to output the billing information BI selected by the advance payment device control unit 13, and includes the acquisition unit 15 to acquire information indicating whether or not to make an advance payment according to the billing information BI output by the output unit 14. Furthermore, according to this embodiment, for a bill issued by the biller C who is determined to have a transfer history based on the transfer history information TRI, advance payment is selected as a pre-setting. That is, according to this embodiment, when the payer P selects whether or not to make an advance payment, advance payment is preset in advance based on the transfer history information TRI (checked in advance). Therefore, according to this embodiment, the payer P does not need to check whether advance payment is to be made for each billing information BI, which reduces the work of the payer P. Furthermore, according to this embodiment, because advance payment is preset (checked in advance), even if there are multiple invoices, the payer P can be prevented from forgetting to select advance payment for each invoice. Therefore, according to this embodiment, multiple invoices can be processed efficiently.

[0149] Furthermore, according to the above-described embodiment, the transfer record information TRI is associated with information on whether or not there is a transfer record for each biller C. That is, according to this embodiment, the above-described preset is determined for each business partner. Therefore, according to this embodiment, for biller C who has made an advance payment, payer P does not need to check whether or not there is an advance payment for each billing information BI, which reduces the work of payer P. Therefore, according to this embodiment, multiple invoices can be processed more efficiently.

[0150] Furthermore, according to the above-described embodiment, the transfer record information TRI is associated with information on the biller C and the transfer amount, and as a result of comparing the transfer amount based on the transfer record information TRI with the transfer amount shown in the billing information BI, for bills where the difference is outside a predetermined range, advance payment is not selected as a pre-set. For example, even if there is a transfer record, if the billing amount shown on the invoice deviates from the transfer record, the payer P may decide whether to make an advance payment. According to this embodiment, in such a case, a selection based on the judgment of the payer P is possible. Thus, according to this embodiment, the payer P can more appropriately process multiple bills.

[0151] Furthermore, according to the above-described embodiment, even if an advance payment has been selected as a preset setting for a bill, the selection of advance payment can be cancelled in response to an operation by the payer P. That is, according to this embodiment, although an advance payment is preset, if the payer P does not wish to pay, the advance payment setting can be cancelled. Thus, according to this embodiment, the payer P can more suitably process multiple bills.

[0152] Furthermore, according to the embodiment described above, the output unit 14 notifies the payer P that the advance payment has been set regardless of the operation of the payer P, and the acquisition unit 15 acquires information indicating that the selection of the advance payment is to be cancelled in response to the operation of the payer P. That is, according to this embodiment, the payer P can cancel the advance payment setting in two stages. Therefore, according to this embodiment, the payer P can more suitably process multiple invoices.

[0153] According to the above-mentioned embodiment, the transfer record information TRI is associated with information on the biller C and the transfer amount. Furthermore, the output unit 14 compares the transfer amount based on the transfer record information TRI with the transfer amount shown in the billing information BI, and outputs an inquiry as to whether or not to select advance payment for a bill in which the difference is outside a predetermined range. For example, even if there is a transfer record, if the billing amount shown on the bill is different from the transfer record, the payer P may decide whether to make an advance payment. According to this embodiment, in such a case, an inquiry is made to the payer P, allowing the payer P to make a selection based on his / her judgment. Thus, according to this embodiment, the payer P can more suitably process multiple bills.

[0154] Furthermore, according to the above-described embodiment, the advance payment device 10, by being equipped with the billing information acquisition unit 11, acquires billing information BI regarding a bill issued by the biller C to the payer P, which includes at least information indicating the payment status to the biller C, and by being equipped with the advance payment device control unit 13, performs processing to prevent missed payments to the biller when the payment status to the biller is unpaid among the multiple billing information BI acquired by the billing information acquisition unit 11. Therefore, according to this embodiment, the payer P can easily avoid situations that result in missed payments and avoid losing credibility.

[0155] Furthermore, according to the above-described embodiment, the process performed by the advance device control unit 13 to prevent missed payments to the biller C includes at least notifying the payer P that there is an unpaid bill. Furthermore, by providing the output unit 14, the advance device 10 outputs to the payer P that there is an unpaid bill when the advance device control unit 13 decides to notify the payer P. Therefore, according to the present embodiment, the advance device 10 can notify the payer P that there is an unpaid bill, and when the payer P receives the notification, the payer P can easily avoid a situation in which a payment goes unpaid by carrying out payment processing for the bill, thereby avoiding loss of credibility.

[0156] Furthermore, according to the above-described embodiment, the process performed by the advance device control unit 13 to prevent missed payments to the claimant C includes the advance payer R making an advance payment to the claimant C on behalf of the payer P. Furthermore, by being equipped with the transfer execution unit 16, the advance device 10 executes a transfer process for an unpaid claim when the advance payment is decided by the advance device control unit 13. Therefore, according to the present embodiment, the advance device 10 makes payments to the claimant C on behalf of the payer P for unpaid invoices, so that the payer P can easily avoid a situation in which a payment goes unpaid and can avoid losing credibility.

[0157] Furthermore, according to the embodiment described above, after the fact that there is an unpaid invoice has been output to the payer, if the transfer execution unit 16 is unable to obtain information that payment has been made by the payment due date from the payer P, it executes the transfer process for the unpaid invoice. That is, according to this embodiment, first a notice is sent to the payer P, and if the payer P still fails to make the payment, the unpaid invoice is paid to the biller C on behalf of the payer P. According to this embodiment, by thus carrying out the process to prevent missed payments in two stages, it is possible to avoid a situation in which a payment is missed, and to avoid losing credibility, even in the case that the payer P defaults on a payment.

[0158] Furthermore, according to the above-mentioned embodiment, the advance payment device 10A includes the billing information acquisition unit 11 to acquire billing information BI related to the bill issued by the biller C to the payer P, includes the business status acquisition unit 18 to acquire information related to the business status of the payer P, includes the advance payment device control unit 13 to determine whether or not to propose to the payer P to make an advance payment among the multiple billing information BI acquired by the billing information acquisition unit 11 based on the information acquired by the business status acquisition unit 18, and includes the output unit 14 to output information proposing to the payer P to make an advance payment when the advance payment device control unit 13 determines to propose to the payer P to make an advance payment. That is, according to this embodiment, it is possible to propose to make an advance payment to the payer P who needs to make an advance payment according to the business status of the payer P. Thus, according to this embodiment, the payer P can receive a proposal to make an advance payment when he or she wants to make an advance payment, and can more suitably process multiple bills.

[0159] Also, according to the above-described embodiment, the information on the business status of the payer P acquired by the business status acquisition unit 18 includes the payer P's profit and loss statement, and the advance payment device control unit 13 determines to propose to the payer P to make an advance payment depending on the result of comparing the payer P's profit and loss statement with a predetermined threshold. More specifically, the advance payment device control unit 13 may determine to propose to the payer P to make an advance payment when the cost of sales, selling and general administrative expenses, etc. included in the payer P's profit and loss statement exceed a predetermined threshold ratio. That is, according to this embodiment, the advance payment device 10A proposes an advance payment to the payer P who is predicted to have a limited cash flow. Therefore, according to this embodiment, the payer P can receive a proposal to make an advance payment when he or she wants to make an advance payment, and can more suitably process multiple invoices.

[0160] Furthermore, according to the embodiment described above, the information on the business status of the payer P acquired by the business status acquisition unit 18 includes information on the payer P's balance, and the advance payment device control unit 13 determines to propose to make an advance payment to the payer P when the payer P's balance is less than a predetermined threshold. Therefore, according to the embodiment, the payer P can receive a proposal to make an advance payment when he or she wishes to make an advance payment, and can more appropriately process multiple invoices.

[0161] Also, according to the above-mentioned embodiment, the advance payment device 10A further includes the acquisition unit 15, and acquires information from the payer P indicating whether or not the payer P wishes to make an advance payment in response to the information output by the output unit 14, and further includes the transfer execution unit 16, and executes a transfer process based on the billing information BI indicating that an advance payment will be made. Also, when the advance payment device control unit 13 acquires information indicating a desire to make an advance payment from the payer P, it determines whether or not an advance payment is possible, and if an advance payment is possible, it associates the advance payment with the billing information BI. That is, according to this embodiment, after the advance payment device 10A proposes to make an advance payment, it determines whether or not the advance payment is possible based on the result of the judgment made by the payer P. Therefore, according to this embodiment, it is possible to make an advance payment only for payers P who are able to make an advance payment, and it becomes possible to reduce the risk of bad debt.

[0162] Furthermore, according to the embodiment described above, the advance payment device control unit 13 feeds back the result of the determination as to whether or not advance payment is possible to the business status visualization SaaS 40 (business status storage device) that stores information on the business status of the payer P. Therefore, according to the embodiment, the information of the business status visualization SaaS 40 can be updated according to the payment status of the payer P, making it possible to determine the business status of the payer P in more detail.

[0163] Furthermore, according to the above-described embodiment, the advance payment device 10B is provided with a set amount acquisition unit 19, which acquires set amount information SAI including at least one of the advance payment amount indicating the upper limit of the amount to be advanced payment and the regular payment amount indicating the upper limit of the amount to be advanced payment, which is a method other than the advance payment; the billing information acquisition unit 11 acquires billing information BI regarding a bill issued by the biller to the payer; the advance payment device control unit 13 determines the amount to be advanced payment and the amount to be regular payment based on the acquired set amount information SAI; and the advance payment device control unit 16 executes a transfer process for the bill for which the advance payment has been determined by the advance payment device control unit 13. The advancing device control unit 13 has the following criteria for judgment: (1) if the billing amount shown in the billing information BI is less than the advance payment amount, it decides to make the entire billing amount shown in the billing information BI an advance payment; (2) if the billing amount shown in the billing information BI is more than the advance payment amount, it decides to make the amount shown in the advance payment amount out of the billing amount shown in the billing information BI an advance payment and the remaining amount an ordinary payment; (3) if the billing amount shown in the billing information BI is less than the ordinary payment amount, it decides to make the entire billing amount shown in the billing information BI an ordinary payment; and (4) if the billing amount shown in the billing information BI is more than the ordinary payment amount, it decides to make the amount shown in the ordinary payment amount out of the billing amount shown in the billing information BI an ordinary payment and the remaining amount an advancing payment. According to the advancing device 10B having such a configuration, the payer P determines the upper limit of the amount to be advanced, and the advancing device 10B determines whether to make an advance payment or an ordinary payment for each billing information BI. In other words, the payer P does not need to determine whether to make an advance payment or a regular payment for each piece of billing information BI, and can more easily process multiple bills.

[0164] Furthermore, according to the embodiment described above, the set amount information SAI acquired by the set amount acquisition unit 19 includes either the advance payment amount or the regular payment amount. That is, according to this embodiment, the payer P can set either the advance payment amount or the regular payment amount. Therefore, according to this embodiment, the payer P is not required to make complicated settings and can more easily process multiple invoices.

[0165] Furthermore, according to the above-described embodiment, the set amount information SAI acquired by the set amount acquisition unit 19 includes both the advance payment amount and the regular payment amount. That is, according to this embodiment, the payer P can set both the advance payment amount and the regular payment amount. Therefore, according to this embodiment, the payer P can make more detailed settings and can more appropriately process multiple invoices.

[0166] According to the above-mentioned embodiment, the set amount acquisition unit 19 further acquires priority information for selecting whether the advance payment or the normal payment is to be prioritized, and the advance device control unit 13 decides to pay the excess amount by the payment method selected by the priority information when an excess amount occurs in which the billing amount shown in the billing information BI is an amount greater than the total amount of the advance payment amount and the normal payment amount. That is, according to this embodiment, even if both the advance payment amount and the normal payment amount are set and the billing amount exceeds the total amount of the advance payment amount and the normal payment amount, the payer P can make the payment by the payment method he / she desires. Note that, when the billing amount exceeds the total amount of the advance payment amount and the normal payment amount, an alert may be output to the payer P. The alert is output after the payment amount is determined. The alert enables the payer P to take measures such as re-planning his / her business. Thus, according to this embodiment, the payer P can more suitably process multiple bills.

[0167] In addition, all or part of the functions of each unit of the advance payment device 10 in the above-mentioned embodiment may be realized by recording a program for realizing these functions in a computer-readable recording medium, and reading and executing the program recorded in the recording medium into a computer system. Note that the "computer system" referred to here includes hardware such as the OS and peripheral devices.

[0168] In addition, the term "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs, and CD-ROMs, and storage units such as hard disks built into computer systems. Furthermore, the term "computer-readable recording medium" may also include those that dynamically hold a program for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, and those that hold a program for a certain period of time, such as a volatile memory inside a computer system that serves as a server or client in such cases. Furthermore, the above program may be one that realizes part of the above-mentioned functions, or may be one that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

[0169] Although an embodiment of the present invention has been described above, the present invention is not limited to the above embodiment, and various modifications can be made without departing from the spirit of the present invention. [Explanation of symbols]

[0170] 1...Advance payment system, C...Biller, P...Payer, R...Advance payment person, 10...Advance payment device, 11...Billing information acquisition unit, 12...Billing information storage unit, 13...Advance payment device control unit, 14...Output unit, 15...Acquisition unit, 16...Transfer execution unit, 17...Transfer record acquisition unit, 121...Transfer record storage unit, 20...Payer device, 21...Payer device control unit, 22...Presentation unit, 23...Operation reception unit, 30...Biller device, BI...Billing information, UPI...Update information, TI...Transfer information, TRI...Transfer record information, 40...Business status visualization SaaS, 18...Business status acquisition unit, BCI...Business status information, 19...Set amount acquisition unit, SAI...Set amount information

Claims

1. a set amount acquisition unit that acquires set amount information including at least one of an advance payment amount indicating an upper limit of an amount to be used for an advance payment and a regular payment amount indicating an upper limit of an amount to be used for a regular payment other than the advance payment; a claim information acquisition unit that acquires claim information relating to a claim issued by a claimant to a payer; a control unit which, based on the acquired set amount information, determines that if the billing amount shown in the billing information is less than the advance payment amount, the entire billing amount shown in the billing information is to be an advance payment, and if the billing amount shown in the billing information is more than the advance payment amount, determines that of the billing amount shown in the billing information, the amount shown in the advance payment amount is to be an advance payment and the remaining amount is to be a regular payment, if the billing amount shown in the billing information is less than the regular payment amount, determines that the entire billing amount shown in the billing information is to be a regular payment, and if the billing amount shown in the billing information is more than the regular payment amount, determines that of the billing amount shown in the regular payment amount is to be a regular payment and the remaining amount is to be an advance payment; a transfer execution unit that executes a transfer process for a bill for which an advance payment has been decided by the control unit; A payment device comprising:

2. The set amount information acquired by the set amount acquisition unit includes either the advance payment amount or the regular payment amount. The payment device according to claim 1.

3. The set amount information acquired by the set amount acquisition unit includes both the advance payment amount and the regular payment amount. The payment device according to claim 1.

4. The set amount acquisition unit further acquires priority information for selecting whether the advance payment or the regular payment is to be prioritized; The control unit determines, when an excess amount occurs in which the billing amount indicated in the billing information is greater than the total amount of the advance payment amount and the regular payment amount, to pay the excess amount by a payment method selected based on the priority information. The payment device according to claim 1.

5. a set amount acquisition step of acquiring set amount information including at least one of an advance payment amount indicating an upper limit of an amount to be used for an advance payment and a regular payment amount indicating an upper limit of an amount to be used for a regular payment other than the advance payment; a claim information acquisition step of acquiring claim information relating to a claim issued by a claimant to a payer; a control process for determining, based on the acquired set amount information, that if the billing amount shown in the billing information is less than the advance payment amount, to pay the entire billing amount shown in the billing information as an advance payment, and if the billing amount shown in the billing information is more than the advance payment amount, to pay the amount shown in the advance payment amount of the billing amount shown in the billing information as an advance payment and the remaining amount as a regular payment, and if the billing amount shown in the billing information is less than the regular payment amount, to pay the entire billing amount shown in the billing information as a regular payment, and if the billing amount shown in the billing information is more than the regular payment amount, to pay the amount shown in the regular payment amount of the billing amount shown in the billing information as a regular payment and the remaining amount as an advance payment; a transfer execution step of executing a transfer process for the invoice for which it has been decided to make an advance payment by the control step; A payment method having the above structure.

Images