Debt management device, debt management method, and debt management program

Abstract

To provide a credit management device, a credit management method, and a credit management program, which can process whether or not to return an overpayment with content that is agreed by a customer on a system and may reduce errors in business work when the overpayment is generated.SOLUTION: A credit management device comprises a control section. The credit management device can access: customer data including customer information containing a customer number and financial institution information used by a customer; claim data on credit including the customer information containing the customer number, a principal amount, an interest amount, a total amount, and claim date; and payment data including the customer information containing the customer number, a payment amount, and payment date. The control section includes: an overpayment calculation section that calculates the presence or absence of an overpayment and the amount of the overpayment by comparing the claim data with the payment data; and an overpayment processing receiving section that receives a method for processing the overpayment.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a claim management device, a claim management method, and a claim management program. [Background technology]

[0002] With the spread of smartphones and ATMs, various channels have become available for payments associated with installment purchases of goods, etc., making the payment routes from debtors more complicated and resulting in an increasing number of cases of overpayment.

[0003] Previously, when an overpayment occurred, the system would either refund the full amount, or the overpayment would be manually applied to the following month's bill, and the remaining amount would then be refunded in full. However, as overpayments are occurring more frequently, this process takes time and is prone to errors during work operations.

[0004] Patent Document 1 proposes a commodity trading information comprehensive management system that can achieve comprehensive and efficient management of electronic invoices, comprising a configuration including a claimant's computer device, a management headquarters on the claimant's side that conducts commodity trading with this claimant's computer device via a web page, and each computer device assigned common identification information and individual passwords for any number of departments or any number of registered companies under this management headquarters, and a communications network for communicating information between each computer device, and a method of sending electronic invoices in bulk from the claimant's computer device to the management headquarters' computer device.The system is equipped with a payment management means that manages deposits from the claimant on a monthly basis, and determines that if there is no excess or shortfall in the deposit, the deposit has been made and only the amount for the next month's invoice is invoiced, if there is no deposit or if the deposit amount is short, the deposit is automatically carried over to the next month's invoice and an additional invoice is charged for that month, if there is an excess deposit, the amount is offset against the amount for the next month's invoice and the excess deposit amount is charged off in the next month's invoice, and the system is equipped with a payment management means that reflects this in the creation of the individual or consolidated electronic invoices by the invoice creation means. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-9245 Summary of the Invention [Problem to be solved by the invention]

[0006] In the system of Patent Document 1, if an overpayment occurs, it is possible to offset it against the next month's billing amount and claim the overpayment amount against the next month's bill, but no consideration is given to refund processing, including when the overpayment amount is equal to or greater than the next month's billing amount.

[0007] The present invention has been made in consideration of the above-mentioned problems, and aims to provide a debt management device, a debt management method, and a debt management program that, in the event of an overpayment, can process on the system whether or not to return the overpayment based on the customer's agreement, thereby reducing errors in business operations. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems and achieve the objectives, the receivables management device of the present invention is a receivables management device equipped with a control unit, which is capable of accessing customer information including a customer number, customer data including information on the financial institution used by the customer, receivables billing data including customer information including the customer number, principal amount, interest amount, total amount, and billing date, and deposit data including customer information including the customer number, deposit amount, and deposit date, and the control unit is characterized by having an overdeposit calculation unit that calculates whether or not there is an overdeposit and the amount of the overdeposit by comparing the billing data with the deposit data, and an overdeposit processing acceptance unit that accepts a method for processing the overdeposit.

[0009] In addition, the debt management device of the present invention is characterized in that the control unit is equipped with an account transaction data creation unit that creates account transaction data for excess deposits based on the processing method accepted by the excess deposit processing acceptance unit.

[0010] In addition, the receivables management device of the present invention is characterized in that the control unit includes an accounting data creation unit that creates accounting data for overpayments, and a remittance data creation unit that creates remittance data including the amount to be returned to the customer, information about the financial institution that will make the return, and the return date.

[0011] In addition, the debt management device of the present invention is characterized in that, when the deposit date is later than the repayment date, the overpayment calculation unit compares the amount of the claim plus late payment penalties with the amount of the deposit to calculate whether or not there is an overpayment and the amount of the overpayment.

[0012] In addition, the debt management device of the present invention is characterized in that the excess deposit processing reception unit is capable of receiving the amount to be returned to the customer, and if the amount to be returned is less than the transfer fee, it is processed as miscellaneous income.

[0013] In addition, the receivables management method of the present invention is a receivables management method executed by a receivables management device equipped with a control unit, which is capable of accessing customer information including a customer number, customer data including information on the financial institution used by the customer, customer information including a customer number, receivables billing data including the principal amount, interest amount, total amount and billing date, and deposit data including customer information including a customer number, deposit amount and deposit date, and is characterized by including an overdeposit calculation step that calculates whether or not there is an overdeposit and the amount of the overdeposit by comparing the billing data with the deposit data, and an overdeposit processing acceptance step that accepts a method for processing the overdeposit.

[0014] In addition, the receivables management program of the present invention is a receivables management program executed by a receivables management device equipped with a control unit, and is capable of accessing customer information including a customer number, customer data including information on the financial institution used by the customer, receivables billing data including customer information including a customer number, principal amount, interest amount, total amount, and billing date, and receivables deposit data including customer information including a customer number, deposit amount, and deposit date, and is characterized by executing an overdeposit calculation step that calculates whether or not there is an overdeposit and the amount of the overdeposit by comparing the billing data with the deposit data, and an overdeposit processing acceptance step that accepts a method for processing the overdeposit. [Effects of the Invention]

[0015] According to the present invention, in the event of an overpayment, the system can accept the return or allocation of the overpayment in accordance with the customer's consent, thereby reducing errors in business operations. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a claim management apparatus 100 according to this embodiment. [Figure 2] FIG. 2 is a diagram showing an example of account transaction data created by a conventional credit management device. [Figure 3] FIG. 3 is a diagram showing an example of a reception screen MA for processing an overpayment (deposit) in a conventional credit management device. [Figure 4] FIG. 4 is a diagram showing an example of account transaction data created by a conventional credit management device. [Figure 5] FIG. 5 is a diagram showing a processing flow when a portion of an overpayment (deposit) is returned. [Figure 6] FIG. 6 is a diagram showing an example of account transaction data created when a portion of an overpayment (deposit) is returned by a conventional credit management device. [Figure 7] FIG. 7 is a diagram showing an example of journal data created when a part of an overpayment (deposit) is returned by a conventional credit management device. [Figure 8] FIG. 8 is a diagram showing an example of journal data created when a part of an overpayment (deposit) is returned by a conventional credit management device. [Figure 9] FIG. 9 is a diagram showing an example of account transaction data created by the claim management device according to this embodiment. [Figure 10] FIG. 10 is a diagram showing an example of a reception screen MB-1 for processing an overpayment (deposit) in the claim management device according to this embodiment. [Figure 11] FIG. 11 is a diagram showing an example of account transaction data created by the claim management device according to this embodiment. [Figure 12]FIG. 12 is a diagram showing an example of journal data created by the claim management device according to this embodiment. [Figure 13] FIG. 13 is a diagram showing an example of remittance data created by the claim management device according to this embodiment. [Figure 14] FIG. 14 is a diagram showing an example of account transaction data created by a conventional credit management device. [Figure 15] FIG. 15 is a diagram showing the processing flow when part of a deposit is treated as miscellaneous income. [Figure 16] FIG. 16 is a diagram showing an example of account transaction data created when a portion of a deposit is classified as miscellaneous income in a conventional credit management device. [Figure 17] FIG. 17 is a diagram showing an example of journal data created when a part of a deposit is classified as miscellaneous income in a conventional credit management device. [Figure 18] FIG. 18 is a diagram showing an example of journal data created when a part of a deposit is classified as miscellaneous income in a conventional credit management device. [Figure 19] FIG. 19 is a diagram showing an example of account transaction data created by the claim management apparatus according to this embodiment. [Figure 20] FIG. 20 is a diagram showing an example of a deposit processing reception screen MB-2 in the claim management device according to this embodiment. [Figure 21] FIG. 21 is a diagram showing an example of account transaction data created by the claim management apparatus according to the present embodiment. [Figure 22] FIG. 22 is a diagram showing an example of journal data created by the claim management apparatus according to this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0017] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of a claim management device, a claim management method, and a claim management program according to the present invention will be described in detail below with reference to the accompanying drawings. However, the present invention is not limited to these preferred embodiments.

[0018] [1. Configuration] An example of the configuration of a claim management device according to this embodiment will be described with reference to Fig. 1 etc. Fig. 1 is a diagram showing an example of the configuration of a claim management device 100 according to this embodiment.

[0019] The claim management device 100 is constructed based on a commercially available desktop personal computer. Note that the claim management device 100 is not limited to being constructed based on a stationary information processing device such as a desktop personal computer, but may also be constructed based on a portable information processing device such as a commercially available notebook personal computer, PDA (Personal Digital Assistant), smartphone, or tablet personal computer.

[0020] The bond management device 100 comprises a control unit 102, a communication interface unit 104, a memory unit 106, and an input / output interface unit 108. Each unit of the bond management device 100 is connected to each other so that they can communicate with each other via any communication path.

[0021] The communication interface unit 104 communicatively connects the claim management device 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with other devices via a communication line. Here, the network 300 has a function of connecting the claim management device 100 and the server device 200 so that they can communicate with each other, and is, for example, the Internet or a LAN (Local Area Network). The data stored in the memory unit 106 may also be stored in the server device 200, for example.

[0022] An input device 400 and an output device 500 are connected to the input / output interface unit 108. The output device 500 may be a monitor (including a home television), a speaker, or a printer. The input device 400 may be a keyboard, a mouse, a microphone, or a monitor that functions as a pointing device in cooperation with a mouse. In the following, the output device 500 may be referred to as the monitor 500, and the input device 400 may be referred to as the keyboard 400 or the mouse 400.

[0023] Various databases, tables, files, etc. are stored in the storage unit 106. Computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes are recorded in the storage unit 106. The storage unit 106 can be, for example, a memory device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, an optical disk, etc.

[0024] The storage unit 106 stores, for example, customer data 106a, billing data 106b, deposit data 106c, account transaction data 106d, journalization data 106e, remittance data 106f, and the like.

[0025] The customer data 106a is data related to customers who have entered into a credit contract. The customer data 106a stores customer information including the customer number, credit information such as the customer's credit amount, and information on the financial institution used by the customer.

[0026] The billing data 106b is data related to monthly billing for customers based on the credit agreement. The billing data 106b stores billing information including customer information including the customer number, the principal amount, the interest amount, the billing amount which is the sum of the principal and interest, and the billing date.

[0027] The deposit data 106c is data related to deposits from customers. The deposit data 106c stores customer information including a customer number, and money information including the deposit amount and the deposit date.

[0028] The account transaction data 106d is data created for each transaction, such as a deposit from a customer, a return of an overdeposit (deposit), etc. The account transaction data 106d stores account transaction information, such as customer information including the customer number, the transaction data category, the transaction date, the deposit amount, the principal amount, the interest amount, late payment charges, carried over deposits, accrued deposits, and the amount of the deposit returned.

[0029] The journal data 106e is data created when journalizing each transaction such as a deposit from a customer or an overpayment (deposit).

[0030] The remittance data 106f is data created to return excess funds to the customer. The remittance data 106f stores customer information including the customer number, the remittance date of the excess funds, the remittance bank code, the remittance destination bank code, the bank name, the branch name, account information, and other financial institution information, as well as remittance information such as the remittance amount.

[0031] The control unit 102 is a CPU or the like that performs overall control of the claim management device 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, required data, etc., and executes various information processing operations based on these stored programs.

[0032] The control unit 102 conceptually includes, in terms of functions, an excess deposit calculation unit 102a, an excess deposit processing reception unit 102b, an account transaction data creation unit 102c, a journal data creation unit 102d, a remittance data creation unit 102e, and the like.

[0033] The overpayment calculation unit 102a compares the billing data 106b with the deposit data 106c to calculate whether or not there is an overpayment and the amount of the overpayment.

[0034] When the overdeposit calculation unit 102a determines that an overdeposit has occurred, the overdeposit processing reception unit 102b receives a method for processing the overdeposit that has occurred. The method for processing the overdeposit is received, for example, via a reception screen MB-1 as shown in FIG.

[0035] The account transaction data creation unit 102c creates account transaction data 106d relating to deposits and withdrawals. The account transaction data creation unit 102c also creates account transaction data 106d for overdeposits based on the processing method accepted by the overdeposit processing acceptance unit 102b.

[0036] The journal data creation unit 102d creates journal data 106e when journalizing each transaction such as a deposit from a customer or an overpayment (deposit).

[0037] When an overpayment (deposit) occurs and the overpayment (deposit) is to be returned to the customer, the remittance data creation unit 102e creates remittance data 106f including the amount to be returned to the customer, information about the financial institution that will make the return, and the return date.

[0038] [2. Processing] Here, a specific example of the processing executed by the bond management device 100 will be described with reference to FIGS. 2 to 22, in comparison with a conventional bond management device.

[0039] For example, let's consider a case where a bill for 20,000 yen (principal 18,000 yen, interest 2,000 yen) is due on October 10, 2022, and a deposit of 42,000 yen is made on October 20, 2022. The contract with the customer is for installment payments of 20,000 yen with a due date of the 10th of each month, and another payment of 20,000 yen (principal 18,000 yen, interest 2,000 yen) is due on November 10, and if the payment is not made by the due date, a late payment charge of 1,000 yen will be incurred.

[0040] In conventional credit management systems, when an overpayment (deposit) occurred, the system would either return the entire amount or process the deposit manually.

[0041] Once the customer's deposit is confirmed, account transaction data 106d'-1 is created as shown in Figure 2. The account transaction data 106d'-1 is composed of, for example, the customer number, branch number, transaction sequence number, data category, transaction date, deposit amount, allocated principal, allocated interest, allocated late payment charges, carried over deposit, accrued deposit, and deposit refund amount.

[0042] In a conventional credit management device, when returning an overpayment (deposit) in full on the system, the return process for the deposit of 21,000 yen is accepted on the acceptance screen MA for processing the overpayment (deposit) as shown in Figure 3. The return process is confirmed by entering the return category, return date, and transfer amount on the acceptance screen MA. Return category 84 means a full return.

[0043] When the return process is accepted on the acceptance screen MA, the account transaction data 106d'-2 relating to the deposit return as shown in FIG. 4 is created.

[0044] On the other hand, if the overdeposit (deposit) was not returned in full, the deposit process had to be performed manually. For example, a partial return of an overdeposit (deposit) using the flow shown in Figure 5 will be described. Regarding a 21,000 yen overdeposit (deposit) out of a 42,000 yen deposit made on October 20, 2022, the customer was contacted on October 21, 2022, and it was agreed that 20,000 yen would be applied to the following month, November, and the remaining 1,000 yen would be returned on October 25, 2022. For the 20,000 yen deposit, account transaction data 106d''-1, as shown in Figure 6, is manually created. In the account transaction data 106d''-1, "accrued_deposit" is the deposit incurred by this deposit, and "carried_deposit" is the total deposit at this time.

[0045] After creating the account transaction data 106d''-1, if the journal data 106e''-1, an example of which is shown in FIG. 7, for the deposit of 20,000 yen is manually created and registered, the journal data 106e''-2 is automatically created.

[0046] Thereafter, to transfer the remaining 1,000 yen to the customer, the remittance data is manually registered using the remittance terminal, and journal data 106e''-3 shown in Figure 8 is manually created. As described above, with the conventional credit management device, if a user wanted to return a portion of an overpayment (deposit), the user had to manually process the deposit, etc., and as overpayments occurred frequently, errors in the process could occur.

[0047] In the claim management device 100 according to this embodiment, even if you want to return a part of the overpayment (deposit) to the customer, it is possible to process it on the system, which reduces operational errors. The processing in the claim management device 100 according to this embodiment for the above case will be explained below.

[0048] When the customer's deposit is confirmed, the excess deposit calculation unit 102a compares the billing data 106b with the deposit data 106c to calculate whether or not there is an excess deposit (deposit) and the amount of the excess deposit. If the deposit date is later than the repayment date, the excess deposit calculation unit 102a compares the billing amount plus late payment penalties with the deposit amount to calculate whether or not there is an excess deposit and the amount of the excess deposit. If a bill for 20,000 yen (principal 18,000 yen, interest 2,000 yen) is due on October 10, 2022, and 42,000 yen is deposited on October 20, 2022, because the deposit date is later than the repayment date, the billing amount will be 21,000 yen (principal 18,000 yen, interest 2,000 yen, late payment penalties 1,000 yen), and the excess deposit (deposit) will be 21,000 yen.

[0049] The account transaction data creation unit 102c creates account transaction data 106d-1, as shown in Figure 9, based on the billing data 106b, the deposit data 106c, and the amount of the excess deposit (deposit) calculated by the excess deposit calculation unit. The account transaction data 106d-1 is composed of, for example, the customer number, branch number, transaction sequence number, data category, transaction date, deposit amount, applied principal, applied interest, applied late payment penalties, carried over deposit, accrued deposit, and deposit return amount. Because the method for handling the excess deposit (deposit) has not yet been determined, the content is the same as the conventional account transaction data 106d'-1 (see Figure 2).

[0050] If a deposit of 42,000 yen is made on October 20, 2022, 18,000 yen and 2,000 yen will be appropriated as the principal and interest for the October invoice, and because the October deadline has passed, 1,000 yen will also be appropriated as late payment charges. The amount of 21,000 yen, calculated by subtracting the total of 21,000 yen above from the 42,000 yen deposit, will be the overpayment (deposit).

[0051] If an overpayment (deposit) occurs, the customer will be contacted about the overpayment (deposit) and a decision will be made as to when and how much of the overpayment (deposit) will be returned. Here, we will explain the case where the customer is contacted on October 21, 2022, and it is agreed that 20,000 yen will be applied to the following month of November, and the remaining 1,000 yen will be returned on October 25, 2022.

[0052] After determining the refund amount and return date, the overpayment processing acceptance unit 102b accepts the return of the carried-over deposit of 21,000 yen via the overpayment (deposit) processing acceptance screen MB-1, as shown in FIG. 10. The acceptance screen MB-1 allows the user to enter the return category, return date, and return amount to accept the overpayment (deposit). The other items are automatically entered from the customer data 102a and account transaction data 106d. The overpayment processing acceptance unit 102b accepts a partial return of the overpayment (deposit) on the system in accordance with the terms agreed upon with the customer, by the operator entering the return category 83 on the acceptance screen MB-1. The overpayment processing acceptance unit 102b can also accept a full return of the overpayment, as before, by selecting the return category 84.

[0053] When the overdeposit processing acceptance unit 102b accepts the processing of the overdeposit (deposit), the account transaction data creation unit 102c creates account transaction data 106d-2 for the overdeposit (deposit) as shown in FIG.

[0054] After creating the account transaction data 106d-2, the journal data creation unit 102d creates journal data 106e-1 as shown in FIG.

[0055] The remittance data creation unit 102e also creates remittance data 106f as shown in Fig. 13. Based on the customer data 106a and the journal data 106e, the remittance data creation unit 102e creates remittance data 106f including customer information including the customer number, the remittance date of the overdeposit, the remittance bank code, the remittance destination bank code, the bank name, the branch name, account information, and other financial institution information, the remittance amount, and the like.

[0056] In the debt management device 100 of this embodiment, excess deposits (deposits) can be returned via the system according to the terms agreed upon with the customer, thereby reducing errors caused by manual input and reducing the amount of work required.

[0057] In addition, we will explain how the claim management device 100 according to this embodiment processes an overpayment (deposit) when a bill for 20,000 yen (principal 18,000 yen, interest 2,000 yen) is due on October 10, 2022, and a deposit of 41,100 yen is made on October 20, 2022. This deposit was not made within the deadline, and a late payment penalty of 1,000 yen has been incurred, resulting in an overpayment (deposit) of 20,100 yen.

[0058] In conventional credit management devices, when an overpayment (deposit) occurs as described above, the system either returns the entire amount of the overpayment (deposit) or the deposit is processed manually.

[0059] When the customer's deposit is confirmed, account transaction data 106d'-3 is created as shown in Figure 14. The accrued deposit and carried over deposit are 20,100 yen.

[0060] In a conventional credit management device, when an overpayment (deposit) is returned in full on the system, the return process for the deposit of 20,100 is accepted on the acceptance screen MA for processing the overpayment (deposit) as shown in Figure 3, and account transaction data 106d'-2 as shown in Figure 4 is created. The only difference from the case described above is the amount to be returned (21,000 yen and 20,100 yen).

[0061] On the other hand, if the overdeposit (deposit) is not returned in full, the deposit process is performed manually. For example, we will explain a case where a portion of the overdeposit (deposit) is treated as miscellaneous income using the flow shown in Figure 15. We will explain a case where a deposit of 41,100 yen was made on October 20, 2022, and regarding the overdeposit (deposit) of 20,100 yen, the customer was contacted on October 21, 2022, and an agreement was reached to apply 20,000 yen to the following month, November, and the remaining 100 yen to miscellaneous income. A portion of the overdeposit (deposit) is treated as miscellaneous income when the refund (deposit, 100 yen) is less than the transfer fee. The operator manually creates account transaction data 106d''-2 as shown in Figure 16 for the 20,100 yen deposit.

[0062] After creating the account transaction data 106d''-2, when the journal data 106e''-4, an example of which is shown in FIG. 17, for the deposit of 20,000 yen is manually created and registered, the journal data 106e''-5 is automatically created.

[0063] Thereafter, in order to treat the remaining 100 yen as miscellaneous income, journal entry data 106e''-6 shown in Figure 18 is manually created. As described above, with conventional credit management devices, even when treating part of an overpayment (deposit) as miscellaneous income, it was necessary to manually process the deposit, etc., and as overpayments became more frequent, the occurrence of operational errors also increased.

[0064] In contrast, in the claim management device 100 according to this embodiment, when a customer's deposit is confirmed, the excess deposit calculation unit 102a compares the billing data 106b with the deposit data 106c to calculate whether or not there is an excess deposit (deposit) and the amount of the excess deposit (deposit). If the deposit date is after the repayment date, the excess deposit calculation unit 102a compares the billing amount plus late payment penalties with the deposit amount to calculate whether or not there is an excess deposit and the amount of the excess deposit. If a bill for 20,000 yen (principal 18,000 yen, interest 2,000 yen) is due on October 10, 2022, and 41,100 yen is deposited on October 20, 2022, the bill amount will be 21,000 yen (principal 18,000 yen, interest 2,000 yen, late payment penalty 1,000 yen) because the deposit date is after the repayment date, and the overpayment (deposit) will be 20,100 yen.

[0065] Account transaction data creation unit 102c creates account transaction data 106d-3 as shown in FIG. 19 based on billing data 106b, deposit data 106c, and the amount of excess deposit (deposit) calculated by the excess deposit calculation unit.

[0066] If a deposit of 41,100 yen is made on October 20, 2022, 18,000 yen and 2,000 yen will be appropriated as the principal and interest for the October bill, and because the October deadline has passed, 1,000 yen will also be appropriated as late payment charges. The amount of 20,100 yen, calculated by subtracting the total of 21,000 yen above from the deposit of 41,100 yen, will be the overpayment (deposit).

[0067] The overdeposit processing reception unit 102b receives the return processing of the carried-over deposit of 20,100 yen via the reception screen MB-2 for processing overdeposits (deposits) as shown in Fig. 20. On the reception screen MB-2, by selecting return category 81, processing of part of the deposit as miscellaneous income is received.

[0068] When the overdeposit processing acceptance unit 102b accepts the processing of the overdeposit (deposit), the account transaction data creation unit 102c creates account transaction data 106d-4 for the overdeposit (deposit) as shown in FIG.

[0069] After creating the account transaction data 106d-4, the journal data creation unit 102d creates journal data 106e-2 as shown in FIG. 22, thereby making it possible to treat a part of the excess deposit (deposit) as miscellaneous income.

[0070] [3. Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

[0071] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of SDGs Goals 12, 13, and 15.

[0072] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.

[0073] 4. Other Embodiments The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

[0074] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

[0075] Furthermore, the processing procedures, control procedures, specific names, information including parameters such as registered data and search conditions for each process, screen examples, and database configurations shown in this specification and drawings can be changed as desired unless otherwise specified.

[0076] Furthermore, with regard to the bond management device 100, the components shown in the figures are functional concepts, and do not necessarily have to be physically configured as shown in the figures.

[0077] For example, all or any part of the processing functions of the claim management device 100, particularly the processing functions performed by the control unit, may be implemented by a CPU and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processing described in this embodiment, and is mechanically read by the claim management device 100 as needed. That is, a computer program is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive) for working with the OS to issue instructions to the CPU and perform various processes. This computer program is executed by being loaded into RAM, and works with the CPU to form the control unit.

[0078] In addition, this computer program may be stored in an application program server connected to the claim management device 100 via any network, and all or part of it may be downloaded as needed.

[0079] Furthermore, the program for executing the processes described in this embodiment may be stored in a non-transitory computer-readable recording medium or configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) disc.

[0080] Furthermore, a "program" is a data processing method written in any language or description method, regardless of the format, such as source code or binary code. Note that a "program" is not necessarily limited to a single structure, but also includes a structure that is distributed as multiple modules or libraries, or a structure that achieves its function by cooperating with a separate program, such as an OS. Note that the specific configuration and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known configurations and procedures.

[0081] The various databases stored in the memory unit are storage means such as memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and providing websites.

[0082] The claim management device 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. The claim management device 100 may also be realized by installing software (including programs or data, etc.) that causes the device to perform the processing described in this embodiment.

[0083] Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit depending on various additions or functional loads. In other words, the above-described embodiments can be implemented in any combination, or embodiments can be implemented selectively. [Industrial Applicability]

[0084] The present invention can be used in the financial industry, such as non-banks, online banks, and banks. [Explanation of symbols]

[0085] 100 Debt management device 102 Control section 102a Overpayment Calculation Department 102b Overpayment Processing Department 102c Account Transaction Data Creation Department 102d Journal Data Creation Department 102e Remittance Data Creation Department 104 Communication interface unit 106 Storage section 106a Customer Data 106b Billing Data 106c deposit data 106d Account Transaction Data 106e Remittance Data 108 Input / Output Interface Section 200 servers 300 Network 400 Input Device 500 output devices

Claims

1. A debt management device having a control unit, Customer data including customer information, including customer numbers, and financial institution information used by the customer; customer information including customer number, principal amount, interest amount, total amount, and billing date of the receivable; Customer information including customer number, deposit amount, and deposit data including deposit date; is accessible to The control unit an overpayment calculation unit that calculates whether there is an overpayment and the amount of the overpayment by comparing the billing data with the deposit data; an overpayment processing reception unit that receives the overpayment processing method; an account transaction data creation unit that creates account transaction data for the overdeposit based on the processing method accepted by the overdeposit processing acceptance unit; A debt management device comprising:

2. A debt management device having a control unit, Customer data including customer information, including customer numbers, and financial institution information used by the customer; customer information including customer number, principal amount, interest amount, total amount, and billing date of the receivable; Customer information including customer number, deposit amount, and deposit data including deposit date; is accessible to The control unit an overpayment calculation unit that calculates whether there is an overpayment and the amount of the overpayment by comparing the billing data with the deposit data; an overpayment processing reception unit that receives the overpayment processing method; a journal data creation unit that creates journal data when returning overpayments to customers; a remittance data creation unit that creates remittance data including the amount to be returned to the customer, information on the financial institution that will make the return, and the return date; A debt management device comprising:

3. A debt management device having a control unit, Customer data including customer information, including customer numbers, and financial institution information used by the customer; customer information including customer number, principal amount, interest amount, total amount, and billing date of the receivable; Customer information including customer number, deposit amount, and deposit data including deposit date; is accessible to The control unit an overpayment calculation unit that calculates whether there is an overpayment and the amount of the overpayment by comparing the billing data with the deposit data; an overpayment processing reception unit that receives the overpayment processing method; Equipped with the overpayment processing reception unit is capable of receiving the amount to be returned to the customer, and if the amount to be returned is equal to or less than the transfer fee, it processes it as miscellaneous income; A debt management device characterized by:

4. The debt management device described in claim 1, characterized in that the overpayment calculation unit, when the deposit date is later than the repayment date, compares the amount of the claim plus late payment interest with the amount of the deposit to calculate whether or not there is an overpayment and the amount of the overpayment.

5. A claim management method executed by a claim management device having a control unit, Customer data including customer information, including customer numbers, and financial institution information used by the customer; customer information including customer number, principal amount, interest amount, total amount, and billing date of the receivable; Customer information including customer number, deposit amount, and deposit data including deposit date; is accessible to causing the control unit to execute an overpayment calculation step of calculating whether or not there is an overpayment and the amount of the overpayment by comparing the billing data with the payment data; an overdeposit processing reception step for receiving a method for processing the overdeposit; an account transaction data creation step for creating account transaction data of the overdeposit based on the processing method accepted in the overdeposit processing acceptance step; A receivables management method comprising:

6. A claim management program executed by a claim management device having a control unit, Customer data including customer information, including customer numbers, and financial institution information used by the customer; customer information including customer number, principal amount, interest amount, total amount, and billing date of the receivable; Customer information including customer number, deposit amount, and deposit data including deposit date; is accessible to The control unit an overpayment calculation step of calculating whether or not there is an overpayment and the amount of the overpayment by comparing the billing data with the payment data; an overdeposit processing reception step for receiving a method for processing the overdeposit; an account transaction data creation step for creating account transaction data of the overdeposit based on the processing method accepted in the overdeposit processing acceptance step; A receivables management program characterized by executing the above.

Images