Advance payment apparatus and advance payment method

Abstract

To properly process a plurality of bills.SOLUTION: An advance payment apparatus includes: an advance payment accepting unit which accepts, from an applicant, an application for advance payment for a bill; a deduction amount acquisition unit which acquires deduction amount which is the amount to be deducted from the amount billed received by the advance payment accepting unit, the amount being generated by sales of the applicant; a balance calculation unit which calculates the balance, which is the amount obtained by subtracting the deduction amount from the amount billed received by the advance payment accepting unit; and a billing unit which bills the applicant for the balance calculated by the balance calculation unit when a predetermined condition is met.SELECTED DRAWING: Figure 2

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, an advance payment system, and an advance payment method that are capable of suitably processing a plurality of invoices. [Means for solving the problem]

[0006] (1) One aspect of the present invention is an advance payment device that includes an advance payment acceptance unit that accepts an application from an applicant to make an advance payment for a claim, a deduction amount acquisition unit that acquires a deduction amount, which is an amount generated through a sale made by the applicant and is an amount to be deducted from the claim amount of the claim accepted by the advance payment acceptance unit, a balance calculation unit that calculates a balance, which is the amount obtained by subtracting the deduction amount from the claim amount of the claim accepted by the advance payment acceptance unit, and a billing unit that bills the applicant for the balance calculated by the balance calculation unit when certain conditions are met.

[0007] (2) In one aspect of the present invention, in the advance payment device described in (1) above, the specified condition is whether or not a preset period of time has elapsed since the advance payment acceptance unit accepted the application.

[0008] (3) In one aspect of the present invention, in the advance payment device described in (1) above, the deduction amount is an amount paid to the applicant at a predetermined timing, and the predetermined condition is whether or not the number of times the predetermined timing has passed has reached a preset number.

[0009] (4) In one aspect of the present invention, in the advance payment device described in any of (1) to (3) above, if the balance calculated by the balance calculation unit is zero, the billing unit does not bill the applicant, and the amount by which the deduction amount exceeds the billing amount is paid to the applicant.

[0010] (5) In one aspect of the present invention, in the advance payment device described in any of (1) to (3) above, a maximum amount or percentage to be deducted from the billing amount is predetermined, and the balance calculation unit calculates the balance so that the amount or percentage to be deducted from the billing amount does not exceed the predetermined maximum amount.

[0011] (6) One aspect of the present invention is an advance payment method having an advance payment receiving step of receiving an application from an applicant to make an advance payment for an invoice; a deduction amount acquisition step of acquiring a deduction amount, which is an amount generated through a sale made by the applicant and is an amount to be deducted from the invoice amount of the invoice accepted by the advance payment receiving step; a balance calculation step of calculating a balance, which is the amount obtained by subtracting the deduction amount from the invoice amount of the invoice accepted by the advance payment receiving step; and a billing step of billing the balance calculated by the balance calculation step when predetermined conditions are met. Effect of the Invention

[0012] 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]

[0013] [Figure 1] FIG. 1 is a diagram for explaining an overview of a payment-on-reimbursement system according to a first embodiment. [Diagram 2] 3 is a functional configuration diagram showing an example of the functional configuration of the payment-advancing device according to the first embodiment. FIG. [Diagram 3] 10 is a flowchart showing a series of processes according to a first method of applying for an advance payment in accordance with the second embodiment. [Figure 4] FIG. 11 is a functional configuration diagram showing a first example of the functional configuration of the payment-advancing device according to the second embodiment. [Diagram 5] 10 is a flowchart showing a series of processes according to a second method for applying for an advance payment in accordance with the second embodiment. [Figure 6] FIG. 11 is a functional configuration diagram showing a second example of the functional configuration of the payment-advancing device according to the second embodiment. [Figure 7] 13 is a flowchart showing a series of processes for advance payment according to the third embodiment. [Figure 8] FIG. 11 is a functional configuration diagram showing an example of the functional configuration of a payment-advancing device according to a third embodiment. [Figure 9]FIG. 11 is a diagram for explaining an overview of a payment management system according to a fourth embodiment. [Figure 10] FIG. 13 is a diagram for explaining a modified example of the payment management system according to the fourth embodiment. [Figure 11] FIG. 11 is a functional configuration diagram showing an example of the functional configuration of a payment management device according to a fourth embodiment. [Figure 12] FIG. 13 is a functional configuration diagram showing an example of the functional configuration of a debt management device according to a fifth embodiment. [Figure 13] FIG. 13 is a diagram showing an example of payment information according to the fifth embodiment. [Figure 14] 13 is a first flowchart showing the processing of a debt management method according to a fifth embodiment. [Figure 15] 20 is a second flowchart showing the process of the debt management method according to the fifth embodiment. [Figure 16] 13 is a third flowchart showing the process of the debt management method according to the fifth embodiment. [Figure 17] 2 is a block diagram showing an example of the internal configuration of the advance payment device, the payment management device, or the debt management device according to the embodiment. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] [Embodiment] Hereinafter, preferred embodiments of the advance payment device, advance payment system, advance payment method, payment management device, payment management system, payment management method, debt management device, debt management system, and debt management method according to the aspects of the present invention will be described in detail with reference to the accompanying drawings. Note that the aspects of the present invention are not limited to these embodiments, and include those with 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. In addition, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the present invention. In addition, in the drawings below, 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.

[0015] [Embodiment 1] First, a first embodiment will be described with reference to FIGS.

[0016] FIG. 1 is a diagram for explaining an overview of the advance payment system according to the first embodiment. First, an overview of the advance payment system 1 will be explained with reference to the diagram. The advance payment system 1 includes, as components, a consumer 2, an applicant 3, an ISS (issuer) 4, an ACQ (acquirer) 5, an ACQ / receiving agent 6, a comprehensive affiliated store 7, and a transfer destination 8. Each component shown in the diagram constitutes the advance payment system 1. It is preferable that the exchange of information and money between each of the parties constituting the advance payment system 1 is performed using a device controlled by a processor (not shown). In the following description, the exchange of information and money performed by the device may be described as an exchange performed by each of the parties.

[0017] The consumer 2 is a general consumer who purchases goods and receives services. The consumer 2 purchases goods from the applicant 3 or receives services provided by the applicant 3. Here, the consumer 2 may pay the price for the goods or services directly to the applicant 3 in cash, or indirectly through electronic payment such as credit card payment or electronic money. The diagram omits the case where the price is paid directly in cash, and shows only an example of the case where the price is paid indirectly through electronic payment.

[0018] The applicant 3 sells a product to the consumer 2 or provides a service to the consumer 2. The applicant 3 receives payment for the sale of the product or the provision of the service from the consumer 2. The applicant 3 receives payment from the consumer 2, for example, by electronic payment such as credit card payment. When electronic payment is made, money is not transferred directly from the consumer 2 to the applicant 3, but is transferred from the consumer 2 to the ISS 4.

[0019] The ISS 4 is an issuer, or the issuer of an electronic payment service. Specifically, the ISS 4 may be a credit card issuing company. The ISS 4 enters into a contract with the consumer 2 and provides the electronic payment service. If the electronic payment service is credit card payment, the ISS 4 issues a credit card to the consumer 2. If the ISS 4 is a credit card issuing company, the ISS 4 may be an international credit card brand. When the consumer 2 makes an electronic payment, money is transferred from the consumer 2 to the ISS 4.

[0020] ACQ5 is an acquirer and an issuer of electronic payment services or an affiliated store management company of ISS4, which is an issuer. ACQ5 obtains a license from ISS4 and is responsible for developing new affiliated stores, screening and managing affiliated stores, and billing ISS4 for purchases. When consumer 2 makes an electronic payment, the money transferred from consumer 2 to ISS4 is further transferred from ISS4 to ACQ5.

[0021] Here, various electronic payment services have become widespread in recent years. The advance payment system 1 may be configured to be able to use multiple types of electronic payment services. In the example shown in the figure, an example is shown in which the advance payment system 1 includes one type of electronic payment service. Note that if the advance payment system 1 is compatible with multiple types of electronic payment services, multiple ISS4 and ACQ5 will be included depending on the number of electronic payment services included in the advance payment system 1.

[0022] ACQ / collection agent 6 has an affiliated store contract with one or more ACQ5. ACQ / collection agent 6 preferably has an affiliated store contract with multiple ACQ5. Money is transferred from ACQ5 to ACQ / collection agent 6 in response to electronic payment by consumer 2. The money transferred to ACQ / collection agent 6 is not paid to applicant 3 immediately, but is temporarily stored. The stored money is paid to applicant 3 at a predetermined timing, such as once a month or twice a month (for example, the last day if once a month, or the 15th and last day if twice a month). The predetermined timing at which money is paid from ACQ / collection agent 6 to applicant 3 may be set individually for each applicant 3. In this embodiment, ACQ / collection agent 6 is preferably an affiliated company of general affiliated store 7. Specifically, ACQ / collection agent 6 may be a subsidiary of general affiliated store 7.

[0023] The general affiliated store 7 is a business operator that operates the advance payment system 1 according to this embodiment. The general affiliated store 7 is able to make an advance payment for the applicant 3 by entering into a contract with the applicant 3. Advance payment is a method in which the general affiliated store 7 makes a payment on behalf of the applicant 3 for an invoice issued to the applicant 3. Here, the applicant 3 may receive multiple (large volume) invoices from multiple billing companies, and processing all of them is very time-consuming. Furthermore, the multiple invoices are different from one another for each billing company, and processing them is very time-consuming. Therefore, the general affiliated store 7 advances and pays the multiple invoices issued to the applicant 3, and issues a single invoice to the applicant 3 for the total amount of the multiple invoices, thereby reducing the applicant 3's workload. In the example shown in the figure, the payee 8 issues an invoice to the consumer 2, and the general affiliated store 7 makes an advance payment. Note that although only one payee 8 is shown in the figure, there may be multiple payees 8.

[0024] Next, the flow of the advance payment according to this embodiment will be described. First, an invoice is issued from the transfer destination 8 to the applicant 3. The invoice issued from the transfer destination 8 to the applicant 3 may be issued as payment for something purchased by the applicant 3 to carry out its business, or as payment for a service used by the applicant 3 to carry out its business. The number of invoices issued from the transfer destination 8 to the applicant 3 may be one or more. The applicant 3 selects one or more arbitrary invoices that he or she wishes to make an advance payment from among the one or more invoices issued to him or her, and submits an application for making an advance payment to the comprehensive affiliated store 7. The application may be made for each invoice, or may be made for multiple invoices at once.

[0025] The blanket affiliated store 7 checks the invoices that the applicant 3 wishes to pay on behalf of, and transfers the invoice amount to the transfer destination 8 by the payment due date shown on the invoice. If there are multiple invoices for which payment on behalf of the applicant 3 has been requested, the blanket affiliated store 7 transfers the invoice amount for each of the multiple invoices by the payment due date. Note that an application for payment on behalf of the applicant 3 does not need to be made for each invoice, and it may be preset to make payment on behalf of all invoices issued to the applicant 3. In other words, it may be set to make automatic payment on behalf of the applicant 3.

[0026] Here, the general affiliated store 7 may issue an invoice to the applicant 3 for the total amount of the invoices for which it has made advance payments (i.e., the amount paid in advance by the general affiliated store 7 on behalf of the applicant 3), and, if necessary, for the fee. According to this embodiment, instead of issuing an invoice for the entire total amount of the invoices for which it has made advance payments, part or all of the invoice amount, and, if necessary, the fee, are collected from the ACQ / collection agent 6. In other words, if there is an amount to be paid by the ACQ / collection agent 6 to the applicant 3, this amount is first deducted (offset) from the invoice amount, and if there is a remaining amount of the invoice amount, an invoice for the remaining amount is issued to the applicant 3.

[0027] Specifically, the amount to be paid by ACQ / Collection Agent 6 to Applicant 3 until a certain period of time has elapsed since the applicant 3 applied for an advance payment to the general affiliated store 7 (or since it was decided to automatically make an advance payment) may be deducted. The certain period of time may be, for example, about two months. The certain period of time may be the period from the application for an advance payment to the time when the applicant 3 is billed, and may be determined, for example, based on the provisions of the Money Lending Business Act or other laws.

[0028] Furthermore, from the time when an application for an advance payment is made by the applicant 3 to the general affiliated store 7 (or from the time when it is decided to make an automatic advance payment) until the timing when payments are made from ACQ / collection agent 6 to the applicant 3 reaches a predetermined number, an amount to be paid by ACQ / collection agent 6 to the applicant 3 may be deducted. The predetermined number may be, for example, three times (effectively about one and a half months). The predetermined number may be a number equivalent to the period from when an application for an advance payment is made to when a bill is made to the applicant 3, and may be determined, for example, based on the provisions of law such as the Money Lending Business Act.

[0029] In other words, the bill from the general affiliated store 7 to the applicant 3 resulting from the advance payment can be offset by the amount paid by ACQ / collection agency 6 to the applicant 3. In order to achieve this offset, it is preferable that ACQ / collection agency 6 and the general affiliated store 7 are part of the same group of companies. By performing this offset, it is possible to reduce the number of deposits and withdrawals at the applicant 3 and prevent the need for the cumbersome process of processing invoices.

[0030] In addition, if there is a balance in the invoice from the general affiliated store 7 to the applicant 3 after the amount invoiced by the general affiliated store 7 to the applicant 3 is offset by the amount paid by ACQ / Collection Agent 6 to the applicant 3, the general affiliated store 7 will issue an invoice for that balance to the applicant 3. The applicant 3 will carry out payment processing according to the payment due date, invoice amount, etc. stated on the invoice from the general affiliated store 7.

[0031] In addition, if the amount billed by the blanket affiliated store 7 to the applicant 3 is offset by the amount paid by ACQ / Collection Agency 6 to the applicant 3 and the amount billed by the blanket affiliated store 7 to the applicant 3 becomes zero or negative, the blanket affiliated store 7 will not issue an invoice to the applicant 3. In addition, if the amount billed by the blanket affiliated store 7 to the applicant 3 becomes negative after the offset, in other words, if there is a balance in the amount paid by ACQ / Collection Agency 6 to the applicant 3, that balance will be paid by ACQ / Collection Agency 6 to the applicant 3.

[0032] FIG. 2 is a functional configuration diagram showing an example of the functional configuration of the advance device according to the first embodiment. The functional configuration of the advance device 10 will be described with reference to the diagram. The advance device 10 is a device used by the comprehensive affiliated store 7. The advance device 10 is configured to include an advance payment acceptance unit 11, a deduction amount acquisition unit 12, a balance calculation unit 13, and a billing unit 14 as functional units. Each of these functional units 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.

[0033] The advance payment receiving unit 11 receives an application for advance payment of a bill from the applicant 3. The applicant 3 may perform operations such as application for advance payment by operating an applicant device (not shown), for example.

[0034] The deduction amount acquisition unit 12 acquires information on the deduction amount from the ACQ / collection agent 6. The deduction amount is an amount generated by sales made by the applicant 3, and is an amount that has not yet been paid to the applicant 3 by the ACQ / collection agent 6. The deduction amount is an amount scheduled to be paid to the applicant 3 by the ACQ / collection agent 6 at a predetermined timing (e.g., the end of the month, etc.). The amount indicated in the deduction amount is deducted from the invoice amount of the invoice accepted by the advance payment acceptance unit 11. The information on the deduction amount may be acquired from a comprehensive affiliated store device (not shown) operated by the ACQ / collection agent 6, or may be acquired from a storage device (not shown) in which information output from the comprehensive affiliated store device is stored. The storage device may be present on the cloud.

[0035] The balance calculation unit 13 acquires information on the billing amount of the claim accepted by the advance payment acceptance unit 11 (the billing amount shown on the invoice that is the subject of the advance payment) from the advance payment acceptance unit 11, and acquires information on the deduction amount from the deduction amount acquisition unit 12. The balance calculation unit 13 subtracts the deduction amount from the acquired billing amount to calculate the balance that is the subject of the claim. The balance may be positive, negative, or zero. When there are multiple invoices that are the subject of the advance payment, the balance calculation unit 13 subtracts the deduction amount from the total amount of the multiple invoices to calculate the balance.

[0036] The billing unit 14 bills the applicant 3 for the balance calculated by the balance calculation unit 13. The bill issued by the billing unit 14 to the applicant 3 will be made in a single bill even if there are multiple invoices for which advance payment is to be made. The billing unit 14 bills the applicant 3 when certain conditions defined for each applicant 3 are met. The billing unit 14 may bill the applicant 3 an amount equal to the amount billed to the applicant 3 plus a handling fee.

[0037] Here, the predetermined condition for the billing unit 14 to make a billing may be based on a period of time. When the predetermined condition is based on a period of time, for example, when a preset period of time has elapsed since the advance payment acceptance unit 11 accepted the application, the billing unit 14 makes a billing to the applicant 3. The preset period of time may be set for each applicant 3, and may be, for example, about two months.

[0038] Furthermore, the predetermined condition under which the billing unit 14 makes a billing may depend on the number of payments made from ACQ / collection agent 6 to the applicant 3. If the predetermined condition depends on the number of payments made from ACQ / collection agent 6 to the applicant 3, for example, when the number of payments made from ACQ / collection agent 6 to the applicant 3 after the advance payment acceptance unit 11 accepts the application reaches a preset number, the billing unit 14 makes a billing to the applicant 3. The preset number of times may be set for each applicant 3, and may be, for example, about two or three times.

[0039] It should be noted that when the balance is calculated by the balance calculation unit 13, the billing amount subject to advance payment may be entirely offset by the deduction amount. In that case, the amount by which the deduction amount exceeds the billing amount subject to advance payment (the difference) is paid to the applicant 3. The payment of the difference may usually be made at the same time that the ACQ / collection agent 6 makes a payment to the applicant 3. If the balance calculated by the balance calculation unit 13 is zero (or negative), the billing unit 14 may not bill the applicant 3.

[0040] According to the advance payment system 1 of this embodiment, the applicant 3 may be configured to be able to set the maximum deduction amount in advance. The maximum deduction amount may be set by the amount, or by a percentage of the amount to be advanced payment. In other words, when the balance calculation unit 13 calculates the balance, the maximum amount or percentage to be deducted from the billing amount may be predetermined. In this case, the balance calculation unit 13 calculates the balance so that the amount to be deducted from the billing amount, or the percentage of the deduction amount to the amount to be advanced payment, does not exceed the predetermined maximum value.

[0041] [Summary of embodiment 1] As described above, the advance payment device 10 includes the advance payment receiving unit 11, which receives an application from the applicant 3 to make an advance payment for a bill, the deduction amount acquisition unit 12, which acquires a deduction amount that is an amount generated by a sale made by the applicant 3 and is to be deducted from the billing amount of the billing received by the advance payment receiving unit 11, the balance calculation unit 13, which calculates a balance that is the amount obtained by subtracting the deduction amount from the billing amount of the billing received by the advance payment receiving unit 11, and the billing unit 14, which bills the applicant 3 for the balance calculated by the balance calculation unit 13 when a predetermined condition is met. By adopting such a configuration, the advance payment device 10 can collect a part or all of the billing amount for the applicant 3 from the ACQ / receiving agent 6. Therefore, the business that has made the advance payment (in this case, the comprehensive affiliated store 7) can more reliably collect the amount that has been advanced. Furthermore, the applicant 3 can process multiple bills in an appropriate manner by making advance payments for multiple bills.

[0042] Furthermore, according to the embodiment described above, the predetermined condition for the billing unit 14 to bill the applicant 3 is based on a period of time. That is, the predetermined condition is whether or not a preset period of time has passed since the advance payment acceptance unit 11 accepted the application. In this way, by making a bill based on a period of time, it is possible to prevent violation of laws such as the Money Lending Business Act.

[0043] Furthermore, according to the embodiment described above, the predetermined condition under which the billing unit 14 bills the applicant 3 corresponds to the number of times that the timing for making a payment from ACQ / collection agency 6 to the applicant 3 has passed. In other words, the predetermined condition is whether or not the number of times that the predetermined timing for making a payment from ACQ / collection agency 6 to the applicant 3 has passed has reached a preset number. In this way, by making a billing according to the period, it is possible to prevent violation of laws such as the Money Lending Business Act.

[0044] Furthermore, according to the above-described embodiment, there are cases where all claims for which an advance payment has been applied for are offset by the deduction amount. That is, there are cases where the balance calculated by the balance calculation unit 13 is zero or negative. In such cases, the billing unit 14 does not bill the applicant 3. In other words, if the balance calculated by the balance calculation unit 13 is zero or negative, the applicant 3 does not receive an invoice for the claim for which an advance payment has been made, and the effort required for processing the invoice is reduced. Therefore, according to this embodiment, the applicant 3 can suitably process multiple invoices. Any amount in which the deduction amount exceeds the amount claimed is paid to the applicant 3.

[0045] Furthermore, according to the above-described embodiment, the applicant 3 can set the maximum amount of deduction to any value. That is, according to this embodiment, the maximum amount or percentage to be deducted from the billing amount is predetermined, and the balance calculation unit 13 calculates the balance so that the amount or percentage to be deducted from the billing amount does not exceed the predetermined maximum amount. By adopting such a configuration, the applicant 3 can prevent his / her financial plan from being disrupted.

[0046] [Embodiment 2] Next, the second embodiment will be described with reference to FIG. 3 to FIG. 6. In the above-mentioned embodiment, the applicant 3 applies for an advance payment to the advance device 10. Here, when applying for an advance payment, information on the payment method after the advance payment is selected. The information on the payment method after the advance payment may broadly include a payment agency, 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, and the like. Examples of an external transfer include a transfer at a bank counter, a transfer using an automated teller machine (ATM), and the like. When there are multiple invoices issued to the applicant 3 (especially when there are many), it may be troublesome for the applicant 3 to even apply for an advance payment. Therefore, one of the objectives of the second embodiment described below is to reduce the trouble of the applicant 3 in selecting an invoice to be paid on the advance payment.

[0047] In the following explanation, two methods, a first method and a second method, will be explained as examples. The first method is a method in which the comprehensive affiliated store 7 proposes a payment method after advance payment for a plurality of invoices for which an advance payment application has been made. The second method is a method in which the applicant 3 determines the payment method after advance payment. First, a series of processes related to the first method will be explained with reference to Figures 3 and 4, and then a series of processes related to the second method will be explained with reference to Figures 5 and 6. Note that the methods according to this embodiment are not limited to these two methods.

[0048] Fig. 3 is a flow chart showing a series of processes related to the first method, which is an application method for advance payment according to the second embodiment. First, the series of processes related to the first method will be described with reference to the same figure. In the following description, the device that executes the first method in the second embodiment may be referred to as an advance device 10A.

[0049] (Step S11) First, the applicant 3 uploads to the advance payment device 10A the invoices that he / she wishes to pay on behalf of, among the multiple invoices issued to him / her. Multiple items can be uploaded to the advance payment device 10A at the same time. After uploading, the applicant 3 clicks the advance payment application button.

[0050] (Step S12) Next, the advance payment device 10A arranges, on behalf of the applicant 3, which scheme will be the post-advance payment method for each of the multiple invoices that have been uploaded. The post-advance payment method may be, for example, either BPSP or bank transfer. The advance payment device 10A presents the payment method obtained as a result of the arrangement to the applicant 3. The presentation to the applicant 3 may be made for each of the multiple invoices, or may be made for the multiple invoices all at once.

[0051] (Step S13) Next, the applicant 3 checks the information (arrangement details) presented by the advance payment device 10A, and if there are no problems, clicks the application confirmation button to confirm the payment method after the advance payment. If there is a problem (i.e., if a payment method not desired by the applicant 3 has been selected), the applicant 3 may correct the information presented by the advance payment device 10A.

[0052] (Step S14) Next, the advance payment device 10A judges whether or not a BPSP application amount exists in the confirmed payment method after advance payment. If a BPSP application amount exists in the confirmed payment method after advance payment (i.e., Step S14; YES), the advance payment device 10A proceeds to step S15. If a BPSP application amount does not exist in the confirmed payment method after advance payment (i.e., Step S14; NO), the advance payment device 10A does not perform card settlement and proceeds to step S16.

[0053] (Step S15) If the confirmed payment method after advance payment includes a BPSP application, the advance payment device 10A performs card payment. In card payment, the invoice for which the BPSP application was selected is referenced, and processing is performed based on the payee, the amount claimed, etc.

[0054] (Step S16) After the card payment has been made, or if the payment method after the confirmed advance payment does not include the BPSP application amount, the advance payment application is completed as is.

[0055] (Step S17) Next, the advancing device 10A processes the advancing payment for the invoice for which the payment has been made by bank transfer. Specifically, first, the advancing device 10A transfers the invoice amount to the transfer destination 8 by the payment due date. Next, after the transfer, the advancing device 10A issues an invoice to the applicant 3. Note that when issuing the invoice, deductions such as those referred to in the first embodiment may be applied.

[0056] FIG. 4 is a functional configuration diagram showing a first example of the functional configuration of the advance payment device according to the second embodiment. The first method as described above can be realized by the advance payment device 10A shown in FIG. 4. The functional configuration of the advance payment device 10A will be described with reference to the same figure. In the description of the advance payment device 10A, the components already described may be denoted by the same reference numerals as those of the advance payment device 10 and the description may be omitted. The advance payment device 10A differs from the advance payment device 10 in that it further comprises a multiple claim processing unit 110. The multiple claim processing unit 110 is provided between the applicant 3 and the advance payment receiving unit 11. The multiple claim processing unit 110 comprises a payment data acquisition unit 111, an advance payment application receiving unit 112, a payment method determination unit 113, a presentation unit 114, an application confirmation unit 115, and a card payment implementation unit 116.

[0057] The payment data acquisition unit 111 acquires payment data from the applicant 3. The payment data includes information related to billing. The payment data may be the invoice itself, or may be information in lieu of the invoice. The payment data acquisition unit 111 acquires multiple payment data for one or more transfer destinations 8. The payment data acquisition unit 111 may acquire payment data entered by the applicant 3, or may acquire payment data accumulated in a specified database in an existing platform. Note that integration with systems such as other platforms may be performed, for example, via an API (Application Programming Interface).

[0058] The advance payment application receiving unit 112 receives an application for advance payment from the applicant 3. The applicant 3 applies for advance payment for a bill that is to be paid in advance from among the payment data acquired by the payment data acquisition unit 111. An application for advance payment may be made, for example, by the applicant 3 clicking an advance payment application button. The advance payment device 10A may present the applicant 3 with payment data that can be used as an advance payment, and the applicant 3 may apply for advance payment by selecting from the presented payment data.

[0059] The payment method determination unit 113 determines the payment method for each of the multiple payment data for which an application for advance payment has been made. The payment method is determined by a predetermined algorithm. It is preferable that the payment method includes at least card payment and bank transfer. The payment method may include a wide range of other payment methods.

[0060] The presentation unit 114 presents the information determined by the payment method determination unit 113, i.e., the payment method for each piece of payment data, to the applicant 3. The applicant 3 checks the presented information and, if there are no problems, confirms the application. If the applicant 3 wishes to make payment by a method other than the presented payment method, he or she can change to a payment method of their choice. Changing to a payment method of their choice may be done for each payment data.

[0061] The application confirmation unit 115 confirms the application for advance payment based on the operation of the applicant 3 in accordance with the result presented by the presentation unit 114. Confirmation of the application for advance payment can also be said to be confirmation of the payment method of the applicant 3 after the advance payment.

[0062] The card payment execution unit 116 performs card payment for the payment data determined as card payment by the payment method determination unit 113 and confirmed by the application confirmation unit 115. Card payment is performed based on the payment due date, transfer destination, billing amount, etc. indicated in the payment data. Pre-set credit card information of the applicant 3 may be used for card payment.

[0063] The advance payment receiving unit 11 receives an application for making an advance payment by bank transfer for payment data that has been determined to be bank transfer by the payment method determining unit 113 and confirmed by the application confirming unit 115. After the advance payment receiving unit 11 has accepted the advance payment, the processing described in the first embodiment may be performed.

[0064] Fig. 5 is a flow chart showing a series of processes related to the second method, which is an application method for advance payment according to the second embodiment. Next, the series of processes related to the second method will be described with reference to the same figure. In the following description, the device that executes the second method in the second embodiment may be referred to as the advance device 10B.

[0065] (Step S21) First, the applicant 3 uploads, from among multiple invoices issued to him / her, the invoice that he / she wishes to pay on behalf of, to the advance payment device 10A. Multiple items can be uploaded to the advance payment device 10A at the same time.

[0066] (Step S22) Next, the applicant 3 sets which scheme will be the post-advance payment method for each of the multiple invoices that have been uploaded. Information regarding the multiple uploaded invoices is presented to the applicant 3 by the advance payment device 10B, and the applicant 3 may select a scheme for each of the presented invoices. After setting the post-advance payment method for each of the multiple invoices, the applicant 3 clicks the advance payment application button. Note that the payment method assigned by the above-mentioned first method may be preset as the initial setting.

[0067] (Step S23) Next, the advance payment device 10B judges whether or not a BPSP application amount exists in the confirmed payment method after advance payment. If a BPSP application amount exists in the confirmed payment method after advance payment (i.e., step S23; YES), the advance payment device 10B proceeds to step S24. If a BPSP application amount does not exist in the confirmed payment method after advance payment (i.e., step S23; NO), the advance payment device 10B does not perform card settlement and proceeds to step S25.

[0068] (Step S24) If the confirmed post-payment payment method includes a BPSP application amount, the advancing device 10B performs card payment.

[0069] (Step S25) After the card payment has been made, or if the payment method after the confirmed advance payment does not include the BPSP application amount, the advance payment application is completed as is.

[0070] (Step S26) Next, the advancing device 10B processes the advance payment for the invoice for which the payment has been made by bank transfer. Specifically, the advancing device 10B transfers the invoice amount to the transfer destination 8 by the payment due date. After the transfer, the advancing device 10B issues an invoice to the applicant 3. When issuing the invoice, deductions such as those referred to in the first embodiment may be applied.

[0071] FIG. 6 is a functional configuration diagram showing a second example of the functional configuration of the advance payment device according to the second embodiment. The above-mentioned second method can be realized by the advance payment device 10B shown in FIG. 6. The functional configuration of the advance payment device 10B will be described with reference to the same figure. In the description of the advance payment device 10B, the description of the components already described may be omitted by assigning the same reference numerals as those of the advance payment device 10 or the advance payment device 10A. The advance payment device 10B differs from the advance payment device 10 or the advance payment device 10A in that it further comprises a multiple claim processing unit 110B. The multiple claim processing unit 110B is provided between the applicant 3 and the advance payment acceptance unit 11, like the multiple claim processing unit 110. The multiple claim processing unit 110B comprises a payment data acquisition unit 111, a payment method determination unit 113B, a presentation unit 114B, an application confirmation unit 115B, and a card payment implementation unit 116.

[0072] The presentation unit 114B presents the applicant 3 with multiple payment data acquired by the payment data acquisition unit 111. The applicant 3 determines a payment method for each of the multiple payment data presented. The payment methods selectable by the applicant 3 may be presented to the applicant 3 by the presentation unit 114B, for example, together with check boxes. Nothing may be selected by default in the check boxes, but for example, the payment methods determined by the payment method determination unit 113 described in the first method may be preset.

[0073] The payment method determination unit 113B acquires the payment method for each of the multiple payment data presented by the presentation unit 114B from the applicant 3. The payment method determination unit 113B determines the payment method for each of the multiple payment data based on the operation of the applicant 3.

[0074] The application confirmation unit 115B detects that the application confirmation button has been pressed after the applicant 3 has determined the payment method for each of the multiple payment data. When the application confirmation button is pressed by the applicant 3, the application confirmation unit 115B confirms the application for advance payment. The application confirmation button may be in an inactive state if the applicant 3 has not selected a payment method for all of the payment data presented by the presentation unit 114B. In other words, the application confirmation button may be configured to be in an active state and to be operable when the applicant 3 has selected a payment method for all of the payment data presented by the presentation unit 114B.

[0075] When the application for advance payment is confirmed, the card payment execution unit 116 refers to the payment method confirmed by the payment method determination unit 113B and performs card payment for the payment data for which card payment has been selected. Card payment is performed based on the payment due date, transfer destination, billing amount, etc., indicated in the payment data. Pre-set credit card information of the applicant 3 may be used for card payment.

[0076] The advance payment receiving unit 11 receives an application for making an advance payment by bank transfer for payment data that has been determined to be bank transfer by the payment method determining unit 113 and confirmed by the application confirming unit 115. After the advance payment receiving unit 11 has accepted the advance payment, the processing described in the first embodiment may be performed.

[0077] [Summary of embodiment 2] As described above, the advance payment device 10A and the advance payment device 10B are provided with the payment data acquisition unit 111, thereby acquiring multiple payment data for one or more transfer destinations, the payment method determination unit 113 or the payment method determination unit 113B, thereby determining a payment method including card payment and bank transfer for each of the multiple payment data, the card payment execution unit 116, thereby performing card payment for payment data determined to be card payment by the payment method determination unit 113 or the payment method determination unit 113B, and the advance payment acceptance unit 11, thereby accepting an application for advance payment by bank transfer for payment data determined to be bank transfer by the payment method determination unit 113 or the payment method determination unit 113B. That is, according to this embodiment, the applicant 3 does not need to upload invoices one by one and select a payment method one by one, but can upload multiple invoices at the same time and apply for advance payment. Therefore, according to this embodiment, multiple invoices can be processed appropriately.

[0078] Moreover, according to the embodiment described above, the payment method is determined by the person making the advance payment (specifically, the comprehensive affiliated store 7). Specifically, the advance payment device 10A is provided with a presentation unit 114, which presents a payment method for each payment data determined by the payment method determination unit 113, and is provided with an application confirmation unit 115, which confirms the advance payment application according to the results presented by the presentation unit 114. Therefore, according to this embodiment, the applicant 3 can reduce the effort required to determine the payment method.

[0079] Furthermore, according to the above-described embodiment, the payment method is determined by the applicant 3. Specifically, by including the presentation unit 114, the advance payment device 10B first presents multiple payment data acquired by the payment data acquisition unit 111, and the payment method determination unit 113B acquires from the applicant 3 the payment method for each of the multiple payment data presented by the presentation unit 114B, thereby determining the payment method for each of the multiple payment data. Thus, according to this embodiment, the applicant 3 can select the payment method he or she desires for each invoice.

[0080] [Embodiment 3] Next, a third embodiment will be described with reference to Figures 7 and 8. In the above-mentioned embodiments, the advance payment device 10, the advance payment device 10A, and the advance payment device 10B process invoices to be paid on behalf of others. However, the third embodiment differs from the above-mentioned embodiments in that it includes invoices other than invoices to be paid on behalf of others, and broadly includes those to be subject to debt management.

[0081] Fig. 7 is a flowchart showing a series of processes of an advance payment according to embodiment 3. A series of processes of an advance payment according to embodiment 3 will be described with reference to the same figure. In the following description, the device that executes the processes in embodiment 3 may be referred to as an advance payment device 10C.

[0082] (Step S31) First, the user of the advance payment device 10C (i.e., the applicant 3) uploads payment data. The applicant 3 can also upload multiple pieces of payment data at the same time. The advance payment device 10C acquires the multiple pieces of payment data uploaded by the applicant 3.

[0083] (Step S32) Next, the advance payment device 10C checks the payment due date written in each of the one or more pieces of payment data obtained. If the payment due date written in the payment data has arrived, i.e., if the number of days until the payment due date is less than a predetermined number of days (Step S32; YES), the advance payment device 10C advances the process to Step S33. If the payment due date written in the payment data has not arrived, i.e., if the number of days until the payment due date is more than a predetermined number of days (Step S32; NO), the advance payment device 10C ends the process. That is, in this case, it can be said that there is no movement until the payment due date.

[0084] (Step S33) Next, the advance payment device 10C automatically performs an advance payment transfer for invoices whose payment due date has arrived. Note that the process from step S33 onwards may be carried out individually for each payment data, but if there are multiple invoices whose payment due date has arrived, the process may be carried out for the multiple invoices all at once.

[0085] (Step S34) Next, the advance payment device 10C compares the balance of the payment management account registered in advance by the user with the billing amount of the invoice that is the subject of the advance payment. If the balance of the payment management account is equal to or greater than the billing amount of the invoice that is the subject of the advance payment (i.e., Step S34; YES), the advance payment device 10C proceeds to step S35. If the balance of the payment management account is less than the billing amount of the invoice that is the subject of the advance payment (i.e., Step S34; NO), the advance payment device 10C proceeds to step S36.

[0086] (Step S35) Next, the advancing device 10C debits the remaining amount of the advance payment from the payment management account registered in advance by the user. Note that, when the advancing device 10C executes advance payments for multiple invoices, it debits the total amount of the multiple invoices collectively.

[0087] (Step S36) If the balance in the payment management account is insufficient, the advance payment device 10C issues an invoice to the applicant 3 for the amount obtained by subtracting the invoice amount that is the subject of the advance payment from the balance in the payment management account (which can also be called the shortfall).

[0088] The series of processes described with reference to Fig. 7 may be used in combination with the offset process described in embodiment 1. The offset process described in embodiment 1 may be performed before or after the debit process from the payment management account in steps S34 to S36.

[0089] FIG. 8 is a functional configuration diagram showing an example of the functional configuration of the advance payment device according to the third embodiment. A series of processes of the advance payment according to the third embodiment can be realized by the advance payment device 10C shown in FIG. 8. The functional configuration of the advance payment device 10C will be described with reference to the same figure. In the description of the advance payment device 10C, the description of the components already described may be omitted by assigning the same reference numerals as those of the advance payment devices 10 to 10B. The advance payment device 10C differs from the advance payment devices 10 to 10B in that it includes a payment data acquisition unit 121, a payment due date determination unit 122, an advance payment determination unit 123, a withdrawal processing unit 124, and a billing unit 125. The advance payment device 10C may include these components in addition to the components of the advance payment devices 10 to 10B, or may include these components instead of the components of the advance payment devices 10 to 10B.

[0090] The payment data acquisition unit 121 acquires payment data from the applicant 3 to the transfer destination 8. The payment data from the applicant 3 to the transfer destination 8 may be information about an invoice issued by the transfer destination 8 to the applicant 3.

[0091] The payment due date determination unit 122 determines the payment due date of the payment data acquired by the payment data acquisition unit 121. The payment due date determination unit 122 determines the payment due date for each of the multiple payment data acquired by the payment data acquisition unit 121. The payment due date is determined based on whether the number of days from the determination date to the payment due date is within a predetermined number of days.

[0092] The advance payment determination unit 123 determines whether or not to automatically make an advance payment depending on the result determined by the payment due date determination unit 122 (i.e., the number of days until the payment due date of the payment data). An automatic advance payment is determined to be made when the number of days until the payment due date of the payment data is within a predetermined number of days and the payment due date will pass if left as is. In other words, by having the advance payment determination unit 123 automatically make an advance payment, the applicant 3 can prevent the payment due date from passing.

[0093] It should be noted that some applicants 3 may make payments themselves for some of the multiple payment data acquired by the payment data acquisition unit 121. For claims that have been paid by the applicants 3 by the payment due date, the advance payment determination unit 123 excludes them from the judgment of whether or not to make an advance payment. In other words, the advance payment determination unit 123 will decide to make an advance payment for payment data for which transfer has not been made by a specified due date based on the payment due date of the payment data.

[0094] The withdrawal processing unit 124 performs a process of withdrawing the amount indicated by the payment data for which the advance payment determination unit 123 has determined that an advance payment should be made from the payment management account 35. Here, the applicant 3 deposits money into the payment management account 35 in advance in order to withdraw the invoice for which an advance payment has been made. By making a deposit in advance in this manner, the withdrawal can be made smoothly. Note that the payment management account 35 does not need to be a dedicated account prepared for the withdrawal of invoices for which an advance payment has been made, but may be an account managed by the applicant 3 (an account to which the applicant 3 can deposit money), and the applicant may also deposit money himself.

[0095] Here, depending on the applicant 3, there may be cases where there is no remaining balance in the payment management account 35. In such cases, the advance payment device 10C cannot perform the debit process for the amount advanced from the payment management account 35. The advance payment device 10C is provided with a billing unit 125, and thereby bills the applicant 3 for the shortfall.

[0096] If the amount indicated by the payment data for which the advance payment determination unit 123 has determined that an advance payment should be made is greater than the balance in the payment management account 35, the billing unit 125 issues an invoice for the shortfall to the applicant 3. The billing unit 125 may invoice the applicant 3 for the shortfall amount plus a handling fee. Note that if the amount indicated by the payment data for which the advance payment determination unit 123 has determined that an advance payment should be made is less than the balance in the payment management account 35, the billing unit 125 does not have to issue an invoice to the applicant 3.

[0097] The process according to the third embodiment may be combined with the process according to the first embodiment. In this case, the advance payment device 10C further includes a deduction amount acquisition unit 12 as shown in FIG. 2. The deduction amount acquisition unit 12 acquires a deduction amount, which is an amount generated by a sale made by the applicant 3 and is an amount to be deducted from the billing amount indicated in the payment data. When the amount indicated in the payment data for which the advance payment determination unit 123 has determined to make an advance payment is greater than the balance of the payment management account 35, the billing unit 125 may bill the applicant 3 for the amount obtained by deducting the deduction amount from the shortfall. In addition, the applicant 3 may arbitrarily decide whether to give priority to appropriation from the payment management account 35 or from the deduction amount.

[0098] [Summary of embodiment 3] As described above, the advance payment device 10C includes the payment data acquisition unit 121 to acquire payment data from the applicant 3 to the transfer destination 8, the advance payment determination unit 123 to determine whether to automatically make an advance payment depending on the number of days until the payment due date of the acquired payment data, the debit processing unit 124 to perform debit processing to debit the amount indicated by the payment data for which the advance payment determination unit 123 has determined that an advance payment should be made from the payment management account 35, and the billing unit 125 to issue an invoice for the shortfall to the applicant 3 when the amount indicated by the payment data for which the advance payment determination unit 123 has determined that an advance payment should be made is greater than the balance of the payment management account 35. That is, according to this embodiment, the advance payment device 10C broadly manages invoices other than those to be paid in advance, and can automatically make an advance payment for invoices whose due date is approaching. Therefore, according to this embodiment, the applicant 3 can suitably process multiple invoices.

[0099] Furthermore, according to the above-described embodiment, there may be a plurality of payment data, including data for which applicant 3 does not wish to make an advance payment. Therefore, payment data acquisition unit 121 acquires a plurality of payment data, and advance payment decision unit 123 decides to make an advance payment for payment data for which transfer has not been made by a specified due date based on the payment due date of the payment data. By adopting such a configuration, applicant 3 can avoid making an advance payment by making the payment himself if he becomes able to make the payment just before the payment due date.

[0100] Also, according to the above-mentioned embodiment, the process according to the third embodiment and the process according to the first embodiment can be used in combination. For example, the advance payment device 10C further includes a deduction amount acquisition unit 12, and thereby acquires a deduction amount, which is an amount generated by a sale made by the applicant 3 and is an amount to be deducted from the billing amount indicated in the payment data. Furthermore, when the amount indicated in the payment data for which the advance payment decision unit 123 has decided to make an advance payment is greater than the balance of the payment management account 35, the billing unit 125 bills the applicant 3 for the amount obtained by deducting the deduction amount from the shortfall. By adopting such a configuration, the advance payment device 10C can more reliably collect the amount advanced from the applicant 3, and the applicant 3 can reduce cumbersome processes such as processing of bills.

[0101] [Embodiment 4] Next, a fourth embodiment will be described with reference to Figures 9 to 11. The fourth embodiment is not limited to an example in which the applicant 3 makes an advance payment, but can be applied to a wide range of payment cases. Therefore, the system provided in the fourth embodiment may be referred to as a payment management system 20.

[0102] Figure 9 is a diagram for explaining an overview of the payment management system according to embodiment 4. First, an overview of the payment management system 20 will be explained with reference to the figure. The payment management system 20 is similar to the advance payment system 1 in that it is configured to include a consumer 2, an applicant 3, an ISS (issuer) 4, an ACQ (acquirer) 5, and an ACQ / collection agent 6. Items that have already been explained with reference to the advance payment system 1 will be denoted by the same reference symbols and explanations may be omitted.

[0103] The payment management system 20 differs from the advance payment system 1 in that it is further configured to include a payee 81. The payee 81 is a party that issues an invoice to the applicant 3 as a result of the applicant 3 using the payee 81's services or purchasing goods from the payee 81. The payee 81 may include one or both of the comprehensive affiliated stores 7 and the transfer destinations 8 in the advance payment system 1.

[0104] Here, this embodiment differs from the above-mentioned embodiment in that the amount to be paid by ACQ / collection agent 6 to applicant 3 is temporarily accumulated (pooled). The amount to be accumulated can be set by applicant 3. There are various possible specific setting methods, but for example, it may be configured so that a maximum accumulated amount can be set. It may also be configured so that a monthly accumulated amount (which can also be called a savings amount) can be set. It may also be configured so that the monthly deposit amount from ACQ / collection agent 6 to applicant 3 is set, and the remaining amount is accumulated.

[0105] Next, the flow of payment management according to this embodiment will be described. First, money is accumulated in ACQ / collection agency 6 according to the settings of applicant 3. The amount accumulated in ACQ / collection agency 6 is also referred to as the accumulated amount. Meanwhile, applicant 3 is obligated to make a payment to payee 81 by using a service or purchasing a product. Normally, payment to payee 81 is made by applicant 3 making a payment to payee 81 or by making an advance payment as in the above-mentioned embodiment. However, according to this embodiment, payment to payee 81 is appropriated from the accumulated amount accumulated in ACQ / collection agency 6. Applicant 3, ACQ / collection agency 6, and payee 81 may be configured to be associated with each other by IDs used in payment management system 20.

[0106] FIG. 10 is a diagram for explaining a variation of the payment management system according to the fourth embodiment. With reference to the same figure, an overview of the payment management system 20A, which is a variation of the payment management system 20 according to the fourth embodiment, will be explained. In the example explained with reference to FIG. 9, a case was explained in which the entire payment amount to the payee 81 was covered by the accumulated amount and no shortfall occurred. However, there are cases in which the accumulated amount cannot cover the entire amount (i.e., a shortfall occurs) when the payment amount to the payee 81 is large or the accumulated amount is small. The payment management system 20A is configured to carry out processing when such a shortfall occurs.

[0107] Payment management system 20A differs from payment management system 20 in that it is configured to include payee 82 instead of payee 81. Payee 82 is a payee that does not include a comprehensive affiliated store 7. Payment management system 20A also differs from payment management system 20 in that it is configured to further include a comprehensive affiliated store 7 as a component different from payee 82. In explaining payment management system 20A, components that have already been explained in payment management system 20 may be omitted by assigning similar reference symbols.

[0108] First, an accumulated amount is stored in ACQ / collection agency 6 according to the settings of applicant 3. Meanwhile, applicant 3 incurs an obligation to make payments to payee 82 by using a service or purchasing a product. Here, according to this embodiment, payments to payee 82 are appropriated from the accumulated amount stored in ACQ / collection agency 6. However, in the example shown in payment management system 20A, unlike payment management system 20, it is not possible to appropriate the entire payment, and a shortfall occurs.

[0109] In this embodiment, the shortfall is paid on behalf of the comprehensive affiliated store 7. The comprehensive affiliated store 7 pays the shortfall on behalf of the payee 82 and issues an invoice to the applicant 3 for the shortfall (and a fee, if necessary).

[0110] FIG. 11 is a functional configuration diagram showing an example of the functional configuration of a payment management device according to the fourth embodiment. A series of processes for payment management according to the fourth embodiment can be realized by a payment management device 21 shown in FIG. 11. The payment management device 21 is a device used by a comprehensive affiliated store 7 included in the payee 81, or a comprehensive affiliated store 7 not included in the payee 81. The functional configurations of the payment management system 20 and the payment management device 21 will be described with reference to the same figure. The payment management device 21 may be configured as a part of the above-mentioned advance payment device 10 to advance payment device 10C, or may be a device separate and independent from the advance payment device 10 to advance payment device 10C. In the following description, when there is no need to distinguish between the payee 81 and the payee 82, they may simply be referred to as the payee 81.

[0111] The payment management device 21 includes, as functional units, a payment data acquisition unit 131, an accumulated amount acquisition unit 132, a balance calculation unit 133, and a billing unit 134. Each of these functional units is realized, for example, by using electronic circuits. Each functional unit may also include internal storage means such as a semiconductor memory or a magnetic hard disk drive, as necessary. Each function may also be realized by a computer having a CPU and software. All or part of each functional unit may also be realized by using hardware such as an ASIC, PLD, or FPGA. All or part of each functional unit may also be realized by a combination of software and hardware.

[0112] The payment data acquisition unit 131 acquires payment data from the applicant 3. The payment data includes information related to billing. The payment data may be the invoice itself, or may be information in lieu of the invoice. The payment data acquisition unit 131 acquires multiple payment data for one or more payees 81. The payment data acquisition unit 131 may acquire payment data entered by the applicant 3, or may acquire payment data accumulated in a predetermined database in an existing platform. Note that linkage with systems such as other platforms may be performed, for example, via an API.

[0113] The accumulated amount acquisition unit 132 acquires the accumulated amount from the accumulation device 61. The accumulated amount is the amount generated by sales made by the applicant 3, and is the amount that the applicant 3 can receive, i.e., the amount of accounts receivable that has been temporarily accumulated without being received by the applicant 3. A portion of the accounts receivable may be accumulated in the accumulation device 61, and the other portion may be paid to the applicant 3. The amount accumulated in the accumulation device 61 is appropriated for payment to the payee 81. Note that the payment to the payee 81 may be, for example, the amount used for recruiting staff in the business of the applicant 3.

[0114] It should be noted that the storage device 61 does not need to physically store actual money, but only needs to store information about the amount of money stored. In other words, the storage device 61 may exist as a storage unit.

[0115] Here, the maximum accumulated amount that can be accumulated in the accumulation device 61 may be arbitrarily predetermined by the setting of the applicant 3. In this case, the amount generated by the sales made by the applicant 3 is accumulated in the accumulation device 61 until it reaches the maximum accumulated amount, and any amount exceeding the maximum accumulated amount is paid to the applicant 3.

[0116] Furthermore, the amount of money accumulated in the accumulation device 61 during a predetermined period (for example, monthly or semi-monthly) may be determined in advance. In this case, the amount of money generated as a result of sales made by the applicant 3 is accumulated in the accumulation device 61 at a predetermined timing up to a predetermined amount, and any amount exceeding the predetermined amount is paid to the applicant 3.

[0117] The balance calculation unit 133 acquires payment data from the payment data acquisition unit 131, and acquires the accumulated amount from the accumulated amount acquisition unit 132. The balance calculation unit 133 calculates the balance by subtracting the accumulated amount from the amount indicated by the payment data. The balance calculated by the balance calculation unit 133 is, in other words, the amount that needs to be further billed from the applicant 3 after deducting the accumulated amount from the payment amount. The balance may be zero, a positive amount, or a negative amount.

[0118] If the amount indicated by the payment data is greater than the accumulated amount, the billing unit 134 issues an invoice for the shortfall to the applicant 3. The billing unit 134 may invoice the applicant 3 for the shortfall amount plus a handling fee.

[0119] The accumulated amount stored in ACQ / collection agent 6 may be configured to be refunded (deposited) to applicant 3 by the operation of applicant 3. In this case, storage device 61 transfers the accumulated amount to applicant 3 at the request of applicant 3.

[0120] In this embodiment, it is preferable that ACQ / collection agency 6 and payee 81 are the same business operator or a business operator that can be considered to be the same. If payee 81 is neither the same business operator as ACQ / collection agency 6 nor a business operator that can be considered to be the same, the amount of the payment amount appropriated from the accumulated amount will be paid to payee 81 by ACQ / collection agency 6 (or comprehensive affiliated store 7 that conducts business using payment management system 20).

[0121] [Summary of the fourth embodiment] As explained above, the payment management device 21 is provided with a payment data acquisition unit 131 to acquire payment data from the applicant 3 to the payee 81, is provided with an accumulated amount acquisition unit 132 to acquire the accumulated amount temporarily accumulated in the accumulation device 61, is provided with a balance calculation unit 133 to calculate the balance by subtracting the accumulated amount from the amount indicated by the payment data, and is provided with a billing unit 134 to issue an invoice for the shortfall to the applicant 3 when the amount indicated by the payment data is greater than the accumulated amount. According to this embodiment, by adopting such a configuration, it is possible for the applicant 3 to reduce the trouble of processing multiple invoices for payment to the payee 81. Therefore, according to this embodiment, it is possible to preferably process multiple invoices.

[0122] Also, according to the above-mentioned embodiment, the payment management system 20 includes the storage device 61 to store the accumulated amount, and includes the payment management device 21 to acquire the accumulated amount stored in the storage device 61. Here, the maximum accumulated amount stored in the storage device 61 is determined in advance, and the amount generated by the applicant 3's sales is stored in the storage device 61 until it reaches the maximum accumulated amount, and the amount exceeding the maximum accumulated amount is paid to the applicant 3. That is, according to this embodiment, the maximum amount that the applicant 3 can store is determined. By adopting such a configuration, the applicant 3 can store the amount that is considered necessary for payment, and receive any amount above that. Therefore, the applicant 3 can easily make a business plan.

[0123] Furthermore, according to the above-described embodiment, the accumulated amount accumulated in the accumulation device 61 is predetermined, and the amount generated as a result of sales made by the applicant 3 is accumulated in the accumulation device 61 for the predetermined amount at a predetermined timing, and any amount exceeding the predetermined amount is paid to the applicant 3. In other words, according to this embodiment, the amount that the applicant 3 can accumulate each month (or every two weeks) is determined. By adopting such a configuration, the applicant 3 can further easily make a business plan.

[0124] Furthermore, according to the above-described embodiment, in the payment management system 20, the accumulation device 61 transfers the accumulated accumulation amount to the applicant 3 at the request of the applicant 3. In other words, the applicant 3 can obtain the accumulation amount as needed. Therefore, according to this embodiment, the applicant 3 can further easily create a business plan.

[0125] [Embodiment 5] Next, a fifth embodiment will be described with reference to Figs. 12 to 16. The fifth embodiment is not limited to an example in which the applicant 3 makes an advance payment or manages payments, but is broadly applicable to managing the debts of the applicant 3. Therefore, the system provided in the fifth embodiment may be referred to as a debt management system 30. The debt management system 30 has functions such as centralized management of invoices, a notification function for the applicant 3, and automatic payment.

[0126] Fig. 12 is a functional configuration diagram showing an example of the functional configuration of a debt management device according to embodiment 5. With reference to the same figure, an overview of a debt management system 30 and a debt management device 31 according to embodiment 5 will be described. Note that the debt management device 31 may be configured as a part of the above-mentioned advance payment devices 10 to 10C and payment management device 21, or may be a device separate and independent from the advance payment devices 10 to 10C and payment management device 21.

[0127] The debt management device 31 includes a payment data acquisition unit 141, a payment data storage unit 142, a presentation unit 143, a payment method determination unit 144, a payment agent processing unit 145, and an advance payment processing unit 146 as functional units. Each of these functional units is realized, for example, by using electronic circuits. Each functional unit may have internal storage means such as a semiconductor memory or a magnetic hard disk device, as necessary. Each function may be realized by a computer having a CPU and software. All or a part of each functional unit may be realized by hardware such as an ASIC, PLD, or FPGA. All or a part of each functional unit may be realized by a combination of software and hardware.

[0128] The payment data acquisition unit 141 acquires multiple pieces of payment data. The payment data is information related to a bill issued to the applicant 3. The bill broadly includes information used for debt management of the applicant 3, and may include, for example, an invoice issued to the applicant 3 by the transfer destination 8.

[0129] The payment data storage unit 142 stores multiple payment data acquired by the payment data acquisition unit 141. The payment data storage unit 142 may store payment data for multiple applicants 3 who use the debt management system 30. In this case, the payment data may be associated with identification information capable of identifying the applicant 3. Note that the payment data storage unit 142 does not necessarily need to be included in the debt management device 31 and may exist on a cloud, for example.

[0130] The presentation unit 143 presents a list of invoices issued to a specific applicant 3 from among the multiple payment data acquired by the payment data acquisition unit 141 and stored in the payment data storage unit 142. For example, when the presentation unit 143 receives a request from the applicant 3 to present a list of invoices, it may search the payment data storage unit 142 using the identification information of the applicant 3 included in the request as a key, and present the found information to the applicant 3.

[0131] Here, the applicant 3 checks the list of bills presented by the presentation unit 143 and selects a payment method for each bill. Payment methods may include direct transfer, payment agency, advance payment, and other methods. Direct transfer means that the applicant 3 transfers money directly to the payee (i.e., without going through the general affiliated store 7, etc.). Payment agency means that the general affiliated store 7 withdraws money from the applicant 3's payment management account and makes the payment to the payee's account. Advance payment means that the general affiliated store 7 makes a payment to the payee's account and issues an invoice to the applicant 3 for the bills for which it has made an advance payment. The invoice issued to the applicant 3 after the general affiliated store 7 has made an advance payment may be one in which multiple bills are consolidated into one.

[0132] Here, an example of the screen configuration of the display screen presented to the applicant 3 and operated by the applicant 3 will be described. FIG. 13 is a diagram showing an example of payment information according to the fifth embodiment. For example, information as shown in the figure may be presented to the applicant 3. The figure shows multiple payment information BI for which the applicant 3 has a payment obligation. The payment information BI is associated with "billing identification information", "payee", "billing amount", "payment due date", and "payment method".

[0133] Specifically, the figure shows payment information BI1, payment information BI2, and payment information BI3. For payment information BI1, the "billing identification information" is billing A, the "payee" is A Commercial Corporation, the "billing amount" is 100,000 yen, the "payment date" is 2023 / 07 / 31, and the "payment method" is direct transfer. For payment information BI2, the "billing identification information" is billing B, the "payee" is B Commercial Corporation, the "billing amount" is 200,000 yen, the "payment date" is 2023 / 07 / 31, and the "payment method" is payment agency. For payment information BI3, the "billing identification information" is billing C, the "payee" is C Commercial Corporation, the "billing amount" is 300,000 yen, the "payment date" is 2023 / 07 / 31, and the "payment method" is advance payment.

[0134] As shown in the figure, the payment method column lists direct transfer, payment agency, and advance payment, each with a check box. The applicant 3 can select a payment method by selecting one of the check boxes. Note that one of the payment methods may be pre-selected (pre-set) in the check boxes. The preset payment method may be determined by a predetermined algorithm, taking into consideration the applicant 3's past selections, the applicant 3's financial situation, etc. Returning to FIG. 12, we will continue to explain the functional configuration of the debt management device 31.

[0135] The payment method determination unit 144 selects either payment agency or advance payment for each of the multiple bills included in the list of bills presented by the presentation unit 143, based on the operation of the applicant 3. Specifically, the payment method determination unit 144 acquires information on which of the above-mentioned checkboxes was selected by the applicant 3. The payment method determination unit 144 associates the acquired payment method with payment information BI stored in the payment data storage unit 142. The associated information may be stored in the payment data storage unit 142 (i.e., the payment data may be updated).

[0136] The payment agent processing unit 145 debits the invoice amount from the payment management account of the applicant 3 and issues a payment instruction to the transfer destination account for invoices for which payment agent has been selected from the payment methods determined by the payment method determination unit 144. The processing performed by the payment agent processing unit 145 may be referred to as payment agent processing.

[0137] The advance payment processing unit 146 issues a payment instruction to the transfer account for invoices for which advance payment has been selected from among the payment methods determined by the payment method determination unit 144, and issues an invoice to the applicant 3. When issuing an invoice, various processes described in the above embodiments, such as the offset process in embodiment 1, may be used.

[0138] Next, the process flow of the debt management method according to this embodiment will be described with reference to FIGS.

[0139] 14 is a first flowchart showing the process of the debt management method according to embodiment 5. First, with reference to the drawing, the billing data linkage to the debt management system and the payment function will be described.

[0140] (Step S41) First, payment data (billing data) is linked from an invoice issuing system (not shown) to the debt management system 30 of the comprehensive affiliated store 7. The payment data is linked by the payment data acquisition unit 141 acquiring the payment data. The invoice issuing systems may include those operated by the comprehensive affiliated store 7, and may also include those operated by systems other than the comprehensive affiliated store 7. After linkage, the applicant 3 is able to view a list of payment data in the debt management system 30.

[0141] (Step S42) Next, the applicant 3 (i.e., a user of the debt management system 30) selects payment data collectively on the debt management system 30, and selects a payment method for each payment data. As described above, payment methods include payment agency, advance payment, etc. If advance payment is selected, the system may be configured to also allow the selection of whether the payment after advance payment will be made by BPSP or bank transfer. In this case, the payment method determination unit 144 will further determine, based on the operation of the applicant 3, whether the method of advance payment by the applicant 3 will be card payment or bank transfer for the invoice for which advance payment has been selected.

[0142] As described above, the system may be configured so that direct transfer can be selected as one of the payment methods. In the following explanation, the case where the payment method is either a payment agent or an advance payment will be explained.

[0143] (Step S43) Next, the debt management device 31 determines the payment method for each payment data. If payment agency is selected (i.e., step S43; YES), the process proceeds to step S44. If a payment method other than payment agency (in this example, advance payment) is selected (i.e., step S43; NO), the process proceeds to step S45.

[0144] (Step S44) For payment data for which payment agency has been selected, the comprehensive affiliated store 7 withdraws the money from the applicant 3's payment management account and issues a payment instruction to the transfer account.

[0145] (Step S45) For those payment data for which advance payment has been selected, the comprehensive affiliated store 7 makes an advance payment to the payee, and the comprehensive affiliated store 7 issues an invoice to the applicant 3. By carrying out such processing, the applicant 3 is able to manage multiple invoices collectively.

[0146] 15 is a second flowchart showing the process of the debt management method according to embodiment 5. Next, the payment forgetting prevention function will be described with reference to the same figure.

[0147] (Step S51) First, payment data (billing data) is linked from an invoice issuing system (not shown) to the debt management system 30 of the comprehensive affiliated store 7. The payment data is linked by the payment data acquisition unit 141 acquiring the payment data. The invoice issuing systems may include those operated by the comprehensive affiliated store 7, and may also include those operated by systems other than the comprehensive affiliated store 7. After linkage, the applicant 3 is able to view a list of payment data in the debt management system 30.

[0148] (Step S52) Next, the debt management device 31 checks the payment due date of the payment data acquired by the payment data acquisition unit 141. If the payment due date of the payment data acquired by the payment data acquisition unit 141 is less than the preset number of days (i.e., step S52; YES), the debt management device 31 proceeds to the process at step S53. If the payment due date of the payment data acquired by the payment data acquisition unit 141 is not less than the preset number of days (i.e., step S52; NO), the debt management device 31 ends the process. In this case, the process is not performed until step S52 becomes YES. The preset number of days may be, for example, about 2 to 5 days.

[0149] (Step S53) Next, if the due date of the payment data acquired by the payment data acquisition unit 141 falls within a preset number of days, the debt management device 31 issues a warning (alert) to the applicant 3. The warning is issued to prevent forgetting to pay or preventing late payment. The warning may be issued by the presenting unit 143 described above. In this case, the presenting unit 143 may also issue a warning to the applicant 3 about invoices issued to a specific applicant 3, among the multiple payment data acquired by the payment data acquisition unit 141, that are within a predetermined number of days until the due date.

[0150] The type of warning may be set to be different depending on the payment method. For example, if the applicant 3 has set the payment method to "direct transfer" but has not made the payment several days before the payment due date, the applicant 3 may have forgotten to make the payment. In this case, the presenting unit 143 may warn the applicant 3 by issuing a visually different warning depending on the payment method determined by the payment method determination unit 144. A visually different warning may be a warning with a different color frame on the alert screen or a warning with a different color for the text. In addition, a message may be sent to a specified email address or the like as an important warning.

[0151] In addition, even if the payment method was set to "direct transfer", if the payment has not been made even several days before the payment due date, the applicant 3 may not have sufficient funds and may be unable to make the payment even if he or she actually wants to. Therefore, the warning output by the presentation unit 143 may have a screen configuration that guides the user to make an advance payment. Examples of screen configurations that guide the user to make an advance payment include a button to change to an advance payment and the display of a check box that allows the user to select the payment method as described above.

[0152] 16 is a third flowchart showing the process of the debt management method according to embodiment 5. Next, the automatic advance payment function will be described with reference to the same figure.

[0153] (Step S61) First, payment data (billing data) is linked from an invoice issuing system (not shown) to the debt management system 30 of the comprehensive affiliated store 7. The payment data is linked by the payment data acquisition unit 141 acquiring the payment data. The invoice issuing systems may include those operated by the comprehensive affiliated store 7, and may also include those operated by systems other than the comprehensive affiliated store 7. After linkage, the applicant 3 is able to view a list of payment data in the debt management system 30.

[0154] (Step S62) Here, according to this embodiment, the user of the debt management system 30 (i.e., applicant 3) can set in advance how much the automatic advance payment function will be used. Furthermore, when using the automatic advance payment function, it is also possible to set how much will be used for each of the BPSP and bank transfer schemes. Such advance settings may be performed by a pre-setting unit (not shown) provided in the debt management device 31. The pre-setting unit presents a specified display screen to the applicant 3 and performs the pre-setting based on the operation of the applicant 3.

[0155] In addition, instead of setting the amount for which the automatic advance payment function is to be used, the pre-setting unit may set the function to be used when the total payment amount for a specified period (i.e., the total payment amount indicated in the payment data that becomes due within the specified period) exceeds the set amount.

[0156] (Step S63) Next, the debt management device 31 checks the payment due date of the payment data acquired by the payment data acquisition unit 141. If the payment due date of the payment data acquired by the payment data acquisition unit 141 is less than the preset number of days (i.e., step S63; YES), the debt management device 31 proceeds to the process at step S53. If the payment due date of the payment data acquired by the payment data acquisition unit 141 is not less than the preset number of days (i.e., step S63; NO), the debt management device 31 ends the process. In this case, the process is not performed until step S63; YES is obtained. The preset number of days may be, for example, about 2 to 5 days.

[0157] (Step S64) Next, when the payment due date of the payment data acquired by the payment data acquisition unit 141 falls within a preset number of days, the debt management device 31 performs an advance payment within the automatic advance payment usage amount set in advance by the applicant 3. By adopting such a configuration, it is possible to prevent a payment from being left unpaid even if the due date shown in the payment data has passed.

[0158] [Summary of embodiment 5] As described above, the debt management device 31 includes the payment data acquisition unit 141, which acquires multiple payment data, which are payment data related to bills issued to the applicant 3 from the transfer destination 8, and includes the presentation unit 143, which presents a list of bills issued to a specific applicant 3 from the multiple payment data acquired by the payment data acquisition unit 141, and selects either payment agency or advance payment for each of the multiple bills included in the list of bills presented by the presentation unit 143 based on the operation of the applicant 3, and includes the payment agency processing unit 145, which debits the billing amount from the payment management account of the applicant 3 for bills for which payment agency is selected and issues a payment instruction to the account of the transfer destination 8, and includes the advance payment processing unit 146, which issues a payment instruction to the account of the transfer destination 8 for bills for which advance payment is selected, and issues an invoice to the applicant 3. By adopting such a configuration, the debt management device 31 allows the applicant 3 to collectively manage multiple invoices.

[0159] Furthermore, according to the above-described embodiment, when advance payment is selected, it is possible to select either the BPSP or bank transfer payment method. Specifically, the payment method determination unit 144 further determines whether the method of advance payment by the applicant 3 will be card payment or bank transfer for an invoice for which advance payment has been selected, based on the operation of the applicant 3. By adopting such a configuration, the applicant 3 can easily manage multiple invoices collectively.

[0160] Furthermore, according to the embodiment described above, the debt management device 31 issues a warning to the applicant 3 in accordance with the payment due date of the payment data. Specifically, the presenting unit 143 issues a warning to the applicant 3 for invoices issued to a specific applicant 3, among the multiple payment data acquired by the payment data acquisition unit 141, and for which the payment due date is within a predetermined number of days. Therefore, the applicant 3 can carry out payment processing based on the warning, and can prevent a decline in credit due to unpaid invoices.

[0161] Furthermore, according to the above-described embodiment, the type of warning issued by the presenting unit 143 differs depending on the payment method setting. Specifically, the presenting unit 143 issues visually different warnings depending on the payment method determined by the payment method determination unit 144. By employing such a configuration, even if there are a large number of warnings, the applicant 3 can be prevented from overlooking truly important warnings. Therefore, the applicant 3 can prevent a decline in credit due to unpaid invoices.

[0162] Furthermore, according to the above-described embodiment, when the applicant 3 is about to make a direct transfer but the payment is not made by the due date, the debt management device 31 induces the applicant 3 to change to an advance payment. Specifically, the warning issued by the presentation unit 143 includes an inducement to make an advance payment. Therefore, according to this embodiment, even an applicant 3 who is short of funds and has difficulty making a payment can easily make an advance payment, and can continue the business.

[0163] FIG. 17 is a block diagram showing an example of the internal configuration of the advance payment device 10, the payment management device 21, or the debt management device 31 according to this embodiment. At least a part of the functions of the advance payment device 10, the payment management device 21, or the debt management device 31 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 an external input / output device or the like. 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 a part of each functional unit provided in the advance payment device 10, the payment management device 21, or the debt management device 31 may be realized using hardware such as an ASIC, a PLD, or an FPGA. Also, all or a part of each functional unit may be realized by a combination of software and hardware.

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

[0165] 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.

[0166] 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]

[0167] 1...Advance payment system, 2...Consumer, 3...Applicant, 4...ISS, 5...ACQ, 6...ACQ / Collection agent, 7...General affiliated store, 8...Payee destination, 10...Advance payment device, 11...Advance payment acceptance unit, 12...Deduction amount acquisition unit, 13...Balance calculation unit, 14...Billing unit, 110...Multiple billing processing unit, 111...Payment data acquisition unit, 112...Advance payment application acceptance unit, 113...Payment method determination unit, 114...Presentation unit, 115...Application confirmation unit, 116...Card settlement execution unit, 121...payment data acquisition unit, 122...payment due date determination unit, 123...advance payment determination unit, 124...withdrawal processing unit, 125...billing unit, 81...payee, 61...storage device, 131...payment data acquisition unit, 132...accumulated amount acquisition unit, 133...balance calculation unit, 134...billing unit, 20...payment management system, 21...payment management device, 30...debt management system, 31...debt management device, BI...payment information

Claims

1. an advance payment receiving unit that receives an application for advance payment of a bill from an applicant; a deduction amount acquisition unit that acquires a deduction amount, which is an amount generated by the sale made by the applicant and is to be deducted from the invoice amount of the invoice accepted by the advance payment acceptance unit; a balance calculation unit that calculates a balance obtained by subtracting the deduction amount from the billing amount of the bill accepted by the advance payment acceptance unit; a claim unit that claims the applicant the balance calculated by the balance calculation unit when a predetermined condition is met; A payment device comprising:

2. The predetermined condition is whether or not a preset period of time has elapsed since the advance payment acceptance unit accepted the application. The payment device according to claim 1.

3. The deduction amount is an amount to be paid to the applicant at a predetermined time, The predetermined condition is whether or not the number of times the predetermined timing has elapsed has reached a preset number. The payment device according to claim 1.

4. the billing unit does not bill the applicant if the balance calculated by the balance calculation unit is zero, Any excess of the deduction amount over the amount claimed will be paid to the applicant. The payment device according to claim 1.

5. The maximum amount or percentage to be deducted from the invoice amount is predetermined; The balance calculation unit calculates the balance so that the amount or percentage to be deducted from the billing amount does not exceed a predetermined maximum value. The advance payment device according to any one of claims 1 to 4.

6. an advance payment receiving step of receiving an application for making the invoice an advance payment from an applicant; a deduction amount acquisition step for acquiring a deduction amount, which is an amount generated by the sale made by the applicant and is to be deducted from the invoice amount of the invoice accepted by the advance payment acceptance step; a balance calculation step of calculating a balance obtained by subtracting the deduction amount from the billing amount of the bill accepted by the advance payment acceptance step; a billing step of billing the balance calculated by the balance calculation step when a predetermined condition is met; A payment method having the above structure.

Images