Debt collection device, debt collection method, and debt collection program

Abstract

To enable re-withdrawal on a trade date (withdrawal date) even if a predetermined amount of money cannot be withdrawn in the trade date.SOLUTION: A withdrawal request unit performs a withdrawal request of a predetermined prescribed amount, on a predetermined withdrawal date, for a deposit management device managing a bank account of each debtor. An acquisition unit acquires success or failure of the withdrawal based on the withdrawal request from the deposit management device. A re-withdrawal control unit, when an acquisition result indicating that the withdrawal of the prescribed amount cannot be performed is obtained, controls the withdrawal request unit so as to repeatedly perform the withdrawal request with respect to the bank account of the debtor in which the acquisition result indicating that the withdrawal of the prescribed amount cannot be performed has been obtained, at preset timing, with respect to the deposit management device, within the withdrawal date. Then, a data generation unit generates withdrawal data which includes information identifying the debtor, the withdrawal date, the number of times of the withdrawal, a billing amount and the withdrawal result, and in which the number of times of the withdrawal is incremented each time the withdrawal request within the withdrawal date is performed by the withdrawal request unit.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] Patent Document 1 (Japanese Patent No. 6989882) discloses a school payment collection support device that can support the efficient collection of school payment. This school payment collection support device includes a dialogue control unit that controls dialogue with the parent terminal device held by the parent who pays the school payment, a settlement control unit that controls the settlement of the school payment, and a re-withdrawal date determination unit that acquires the desired re-withdrawal date for the school payment from the parent terminal device and determines the re-withdrawal date.

[0003] The settlement control unit requests the financial institution terminal device to debit the school payment, and receives information indicating whether the financial institution has successfully debited the school payment in response to the request. Furthermore, if the financial institution fails to debit the school payment on a specified debit date, the dialogue control unit notifies the parent terminal device of the failure to debit the school payment through dialogue, and receives the parent terminal device's desired re-debit date. This makes it possible to support the efficient collection of school payment. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6989882 Summary of the Invention [Problem to be solved by the invention]

[0005] However, in the past, if the specified amount could not be debited on the contract date (withdrawal date) due to insufficient funds in the debtor's deposit account, it was difficult to make another withdrawal until the next contract date.

[0006] The present invention has been made in consideration of the above-mentioned problems, and aims to provide a debt collection device, a debt collection method, and a debt collection program that enable re-withdrawal on the contract date (withdrawal date) even if the specified amount cannot be withdrawn on the contract date. [Means for solving the problem]

[0007] In order to solve the above problems and achieve the object, the debt collection device of the present invention has a debit request unit that makes a debit request for a predetermined amount on a predetermined debit date to a deposit management device that manages the deposit account of each debtor; an acquisition unit that acquires from the deposit management device the success or failure of the debit request; a re-debit control unit that, if an acquisition result is obtained indicating that the predetermined amount cannot be debited, controls the debit request unit to repeatedly make debit requests to the deposit management device at predetermined timings during the debit date to the deposit account of a debtor for which an acquisition result is obtained indicating that the predetermined amount cannot be debited; and a data generation unit that generates debit data that includes information identifying the debtor, the debit date, the number of deductions, the amount requested, and the debit result, and increments the number of deductions each time a debit request is made by the debit request unit during a debit day.

[0008] In addition, in order to solve the above-mentioned problems and achieve the object, the debt collection method of the present invention includes a debit request step in which a debit request unit makes a debit request for a predetermined amount on a predetermined debit date to a deposit management device that manages the deposit account of each debtor; an acquisition step in which an acquisition unit acquires from the deposit management device whether the debit request was successful; a re-withdrawal control step in which, if an acquisition result indicating that the predetermined amount cannot be debited is obtained, a re-withdrawal control unit controls the debit request unit to repeatedly make debit requests to the deposit management device at predetermined timings during the debit date to the deposit account of the debtor for which an acquisition result indicating that the predetermined amount cannot be debited is obtained; and a data generation step in which a data generation unit generates debit data including information identifying the debtor, the debit date, the number of deductions, the amount claimed, and the debit result, and increments the number of deductions each time a debit request is made by the debit request unit during the debit day.

[0009] In addition, in order to solve the above-mentioned problems and achieve the object, the debt collection program of the present invention causes a computer to function as a debit request unit that makes a debit request for a predetermined amount on a predetermined debit date to a deposit management device that manages the deposit account of each debtor; an acquisition unit that acquires from the deposit management device the success or failure of the debit request; a re-debit control unit that, if an acquisition result indicating that the predetermined amount cannot be debited is obtained, controls the debit request unit to repeatedly make debit requests to the deposit management device at predetermined timings during the debit date to the deposit account of the debtor for which an acquisition result indicating that the predetermined amount cannot be debited is obtained; and a data generation unit that generates debit data that includes information identifying the debtor, the debit date, the number of deductions, the amount requested, and the debit result, and increments the number of deductions each time a debit request is made by the debit request unit during the debit date. [Effects of the Invention]

[0010] The present invention makes it possible to re-debit a specified amount on the contract date (withdrawal date) even if the specified amount cannot be debited on the contract date (withdrawal date). [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram showing the hardware configuration of a debt collection device according to an embodiment. [Figure 2] FIG. 2 is a flowchart showing the flow of a debt collection operation as a reference example. [Figure 3] FIG. 3 is a diagram showing an example of debit data handled in the reference example. [Figure 4] FIG. 4 is a diagram for explaining that, in the reference example, transaction data becomes overdue when the withdrawal cannot be made. [Figure 5] FIG. 5 shows how, when a withdrawal cannot be made on the contract date, the collection of the receivable is carried over until the contract date of the following month. [Figure 6] FIG. 6 is a flowchart showing the flow of the debt collection operation in the debt collection device according to the embodiment. [Figure 7] FIG. 7 is a diagram showing an example of a self-bank debit request data creation processing screen. [Figure 8] FIG. 8 is a diagram illustrating an example of debit data handled by the debt collection device according to the embodiment. [Figure 9] FIG. 9 is a diagram for explaining that transaction data becomes overdue when the withdrawal cannot be made in the debt collection device of the embodiment. [Figure 10] FIG. 10 is a diagram showing how a second withdrawal request is made during the contract date in the debt collection device according to the embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of the withdrawal history data generated by the debt collection apparatus according to the embodiment. [Figure 12] FIG. 12 shows debit data that is treated as a delinquent invoice when the payment cannot be debited on the contract date. [Figure 13] FIG. 13 is a diagram showing the withdrawal history data in the case where the withdrawal could not be made on the contract date. DETAILED DESCRIPTION OF THE INVENTION

[0012] A debt collection device according to an embodiment of the present invention will be described in detail below with reference to the drawings, although the present invention is not limited to such an embodiment.

[0013] (Hardware configuration) Figure 1 is a block diagram showing the hardware configuration of a debt collection device 1 according to an embodiment. The debt collection device 1 shown in Figure 1 comprises a memory unit 2, a control unit 3, a communication interface unit 4, and an input / output interface unit 5. An input device 6 and an output device 7 are connected to the input / output interface unit 5. The output device 7 may be a display unit such as a monitor device (including a home television). The input device 6 may be a keyboard device, a mouse device, a microphone device, or a monitor device that cooperates with a mouse device to provide a pointing device function.

[0014] The communication interface unit 4 is connected to the deposit management device 40 and the creditor terminal device 50 via a network 30, which may be a wide area network such as the Internet or a private network such as a local area network (LAN). The deposit management device 40 is a server device of a bank that manages the debtor's deposit account. The debtor terminal device 50 is a terminal device owned by the debtor, such as a mobile terminal device, tablet terminal device, or personal computer device.

[0015] The storage unit 2 may be, for example, a read-only memory (ROM), a random access memory (RAM), a hard disk drive (HDD), or a solid state drive (SSD). The storage unit 2 stores a debt collection program for debiting a specified amount from a debtor's deposit account on a specified contract date (debit date), such as the 10th of each month. The storage unit 2 also stores debit data, transaction data, and debit history data, which will be described later.

[0016] The memory unit 2 also stores a debtor master data 11. This debtor master data 11 stores debtor information such as the name of the bank from which each debtor is debited, the account number, the amount debited, and the contract date (debit date). A debit request unit 22 of the control unit 3, which will be described later, refers to this debtor master data 11 and performs the debit process for the amount debited from each debtor's account.

[0017] (Functional configuration of debt collection device) Next, the control unit 3 executes the debt collection program stored in the memory unit 2, and functions as a display control unit 21, a deduction request unit 22, an acquisition unit 23, a re-deduction control unit 24, a data generation unit 25, a notification processing unit 26, and a communication control unit 27, as shown in Figure 1.

[0018] The display control unit 21 inputs the withdrawal request date (= contract date) and displays a self-debit request data creation processing screen via the output device 7, which is an example of a display unit, for debiting the withdrawal amount from each debtor's deposit account.

[0019] The withdrawal request unit 22 requests the deposit management device 40, which manages the debtor's deposit account, to withdraw a predetermined amount on a predetermined withdrawal date. The acquisition unit 23 acquires from the deposit management device 40 information on the success or failure of the withdrawal request.

[0020] When the re-withdrawal control unit 24 obtains an acquisition result indicating that the specified amount cannot be withdrawn, it controls the withdrawal request unit 22 to repeatedly make a withdrawal request to the deposit management device 40 at a pre-set timing for the deposit account of the debtor from which the acquisition result indicating that the specified amount cannot be withdrawn has been obtained during the withdrawal day (contract day).

[0021] In addition, if the specified amount cannot be debited on the debit date, the re-debit control unit 24 controls the debit request unit 22 so that a late fee corresponding to the amount on the date after the debit date is added to the specified amount and a debit request is made.

[0022] The data generation unit 25 generates debit data that includes information identifying the debtor, the debit date, the number of debits, the amount claimed, and the debit result, and increments the number of debits each time the debit claim unit makes a debit claim on a debit date.

[0023] Furthermore, the data generating unit 25 sequentially generates debit history data including information identifying the debtor, the debit date, the number of debits, the amount claimed, and the debit result each time a debit request is made on a debit date.

[0024] When the notification processing unit 26 obtains an acquisition result indicating that the specified amount cannot be debited, it sends a notification to the terminal device of the debtor from which the acquisition result indicating that the specified amount cannot be debited, requesting that the deposit balance be increased, at least on the debit date.

[0025] The communication control unit 27 controls communication with the deposit management unit 40 and communication with the debtor terminal device 50 via the communication interface unit 4 and the network 30.

[0026] (Example of typical debt collection operations) Here, we will explain a normal debt collection operation as a reference example. Figure 2 is a flowchart showing the flow of a normal debt collection operation. The example shown in Figure 2 is an example where the contract date (withdrawal date) is the 1st of each month and a withdrawal for June is made. In this case, the business operator makes a withdrawal request to the deposit management device that manages the debtor's deposit account, for example, around June 28th (step S1). Figure 3 shows withdrawal data when withdrawals are made for "July 2022 (=June)" to three debtors with contract numbers "100000001-0," "100000002-0," and "100000003-0." Until the deposit management device makes a withdrawal from each debtor's deposit account, the withdrawal result of the withdrawal data will be "Z: Requesting."

[0027] Next, in response to this withdrawal request, the deposit management device will withdraw the invoice amount, for example, "10,000 yen," "20,000 yen," or "30,000 yen," from each debtor's deposit account on the contract date, for example, July 1. This allows the business operator to check the withdrawal results from, for example, around July 3 by accessing the deposit management device, and confirms the withdrawal results via the withdrawal data shown in Figure 4 (step S2).

[0028] The example in Figure 4 shows an example where the balance in the deposit account of the debtor with contract number "100000002-0" is insufficient, and the "20,000 yen" deduction could not be made. In this case, as shown in Figure 4(a), the deduction result for the deduction data of the debtor with contract number "100000002-0" is displayed as "1: Insufficient funds." If the deduction cannot be made, as shown in the example in Figure 4(b), the next contract date for the transaction data of the debtor with contract number "100000002-0" will remain as "July 1, 2022," the date on which the deduction could not be made, and the debtor will be in a delinquent state.

[0029] If the withdrawal cannot be made, for example, around July 4th, a payment request that can be used at convenience stores, etc., is issued along with a reminder letter, and a request for overdue payment is made to the debtor (step S3).

[0030] If the debtor does not transfer the amount even after this late payment request is made, as shown in Figure 5, the next contract date, August 2022, will be set as the debit date, and a debit request will be made for the amount of 21,000 yen, including a late payment penalty of 1,000 yen (step S4).

[0031] (Debt collection operation of the debt collection device according to the embodiment) Next, the debt collection operation of the debt collection device 1 of the embodiment will be described. Figure 6 is a flowchart showing the flow of the debt collection operation of the debt collection device 1 of the embodiment. The example shown in Figure 6 is an example where the agreement date (withdrawal date) is the 1st of each month and a withdrawal for June is made. In this case, the business operator specifies the display of the own bank debit request data creation screen via the input device 6. This causes the display control unit 21 to display the own bank debit request data creation screen shown in Figure 7 on the output device 7. The business operator inputs a debit request date, for example July 1, 2022, into this own bank debit request data creation screen.

[0032] When input is made to this self-bank withdrawal request data creation screen, the withdrawal request unit 22 references the debtor master data 11 to detect the deposit management device 40 that manages each debtor's deposit account. The withdrawal request unit 22 then makes a withdrawal request to the deposit management device 40 that manages the debtor's deposit account on July 1, the contract date (step S11). Figure 8 shows withdrawal data when a June withdrawal request is made on July 1, 2022, to three debtors with contract numbers "100000001-0," "100000002-0," and "100000003-0." Until the deposit management device 40 makes a withdrawal from each debtor's deposit account, the withdrawal result of the withdrawal data will be "Z: Requesting."

[0033] Next, in response to this withdrawal request, the deposit management device 40 withdraws the requested amount, for example, "10,000 yen," "20,000 yen," or "30,000 yen," from each debtor's deposit account on the contract date of July 1st. This allows the business operator to check the withdrawal results on the day, for example, July 1st, by accessing the deposit management device 40. The acquisition unit 22 accesses the deposit management device 40 and acquires the withdrawal results for each debtor (step S12). The data generation unit 25 generates withdrawal data that reflects the withdrawal results acquired by the acquisition unit 22, as exemplified in FIG. 9(a).

[0034] The example in Figure 9(a) shows that the balance in the deposit account of the debtor with contract number "100000002-0" is insufficient, and the deduction of "20,000 yen" could not be made. In this case, the data generation unit 25 generates deduction data showing the deduction result for the debtor with contract number "100000002-0" as "1: Insufficient funds," as shown in Figure 9(a).

[0035] Furthermore, when the withdrawal result is "1: Insufficient funds," the data generation unit 25 generates transaction data that maintains the date of the failure to withdraw, "July 1, 2022," as the next contract date for the transaction data of the debtor with contract number "100000002-0," as shown in Figure 9(b). As a result, the debt of the debtor with contract number "100000002-0" becomes overdue.

[0036] Next, if the withdrawal cannot be made, the notification processing unit 26 refers to the debtor master 11 and obtains the email address that is the contact address for the debtor. Then, since the withdrawal cannot be made due to insufficient balance, the notification processing unit 26 creates an email requesting an increase in the balance in the savings account and sends it to the debtor terminal device 50 via the communication control unit 27 (step S13). Upon receiving this reminder email, the debtor makes a deposit into their savings account to increase the balance.

[0037] In this example, an email is sent requesting an increase in the balance of the deposit account, but the notification processing unit 26 may detect the debtor's telephone number from the debtor master 11 and automatically send a voice message, or a business operator may call the debtor's telephone number.

[0038] Next, the re-withdrawal control unit 24 controls the withdrawal request unit 22 to repeatedly make withdrawal requests to the deposit management device 40 at pre-set times for the deposit account of the debtor for which an acquisition result indicating that the specified amount cannot be withdrawn has been obtained during the withdrawal date, "July 1, 2022" (step S14).

[0039] Specifically, the number of times that withdrawals will be repeated on a withdrawal day when withdrawals cannot be made and the withdrawal times are determined for each debtor and stored in the credit master 11. That is, the number of times that withdrawals will be repeated on a withdrawal day is determined for each debtor in the credit master 11 as "3 times," and the withdrawal times are determined as "9:00 AM," "1:00 PM," "5:00 PM," etc.

[0040] If the withdrawal result at "9:00 AM" is "1: Insufficient funds," the re-withdrawal control unit 24 controls the withdrawal request unit 22 to make another withdrawal request at "1:00 PM" to the debtor's deposit account that is now "1: Insufficient funds." Also, if the withdrawal result at "1:00 PM" is "1: Insufficient funds," the re-withdrawal control unit 24 controls the withdrawal request unit 22 to make another withdrawal request at "5:00 PM" to the debtor's deposit account that is now "1: Insufficient funds."

[0041] Furthermore, each time a new withdrawal request is made, the data generation unit 25 updates the sequence (SEQ = number of withdrawals) of the debtor's withdrawal data one by one, such as "1" → "2" → "3", as shown in Figure 10. Furthermore, the data generation unit 25 sets the withdrawal result of a debtor for which a withdrawal cannot be made to "Z: Requesting".

[0042] Furthermore, the data generation unit 25 generates withdrawal history data corresponding to the first withdrawal for each debtor, as shown in Figure 11. This withdrawal history data is composed of each debtor's contract number, withdrawal date, number of withdrawals (SEQ), invoice amount, and withdrawal result. As shown in the example of Figure 11, the withdrawal result for debtors with contract numbers "100000001-0" and "100000003-0" for which withdrawal was possible is set to "0: Transferred," and the withdrawal result for debtor with contract number "100000002-0" for which withdrawal was not possible is set to "1: Insufficient funds."

[0043] Furthermore, each time another withdrawal is made, the data generation unit 25 generates and adds a record (details) of withdrawal history data for that debtor, as shown in Figure 13. The example in Figure 13 is an example in which a record of withdrawal history data is generated in which the result of the first withdrawal for the debtor with contract number "100000002-0" is "1: Insufficient funds", and since the result of the second withdrawal on the same day was also insufficient due to an insufficient account balance, a new record is generated and added in which the number of withdrawals (SEQ) is "2", the claim is "20,000 yen", and the result of the withdrawal is "1: Insufficient funds".

[0044] As described above, the debt collection device 1 of the embodiment allows multiple withdrawals on the same day, which allows the creditor to obtain the effects of lowering the delinquency rate and reducing the cost of managing delinquent debts, etc. Also, the debtor can reduce the effort of carrying out transfer procedures at a convenience store, for example, and can also reduce the risk of paying late fees.

[0045] Next, if the acquisition unit 23 is unable to obtain a withdrawal result of "0: Transferred" from the deposit management device 40 even after multiple withdrawals are made on the same day, the invoice will be overdue from July 2, 2022 onwards, the day after this example, and the data generation unit 25 will generate withdrawal data with a withdrawal result of "Z: Requesting" for the invoice amount plus late payment penalties, as shown in Figure 12. Then, on August 1, 2022, another withdrawal will be made for the invoice amount including late payment penalties.

[0046] If the invoice amount cannot be debited even after a second debit on "August 1, 2022," the re-debit control unit 24 will make multiple debit requests "during August 1, 2022," as described above, and debit the debtor's deposit account (step S15).

[0047] (Effects of the embodiment) As is clear from the above explanation, the debt collection device 1 of the embodiment can attempt to make withdrawal requests and withdrawals multiple times on the same day, even if the withdrawal cannot be made on the scheduled date. Therefore, if the deposit balance in the customer's withdrawal account can be increased in time by the next request, for example by email or telephone, debt collection can be carried out at that time.

[0048] As a result, creditors can enjoy benefits such as a lower delinquency rate and reduced costs for managing delinquent loans. In addition, debtors can reduce the hassle of having to go through transfer procedures at convenience stores, for example, and also reduce the risk of paying late fees.

[0049] [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 Goals 8 and 9 of the SDGs.

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

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

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

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

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

[0055] Furthermore, with regard to the debt collection device 1, the components shown in the figures are functional concepts, and do not necessarily have to be physically configured as shown in the figures.

[0056] For example, all or any part of the processing functions of the debt collection device 1, particularly the control unit 3 and each processing function performed by the control unit 3, may be realized by a CPU (Central Processing Unit) and a program interpreted and executed by the CPU, or may be realized 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 debt collection device 1 as needed. That is, a storage unit such as a ROM or HDD stores a computer program for working with the OS to issue instructions to the CPU and perform various processing. This computer program is executed by being loaded into RAM, and works with the CPU to constitute the control unit 3.

[0057] In addition, the debt collection program of this debt collection device 1 may be stored in another server device connected to the debt collection device 1 via any network, and all or part of it may be downloaded as needed.

[0058] The debt collection program for executing the process described in this embodiment may be stored on 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.

[0059] Furthermore, a "program" is a data processing method written in any language or description method, and does not matter whether it is in the form of source code or binary code. 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 working together with a separate program, such as an OS. The specific structure and reading procedure for reading a recording medium in the debt collection device 1 shown in the embodiment, as well as the installation procedure after reading, can use well-known structures and procedures.

[0060] The memory unit 2 is a storage means such as a memory device such as RAM or ROM, a fixed disk device such as a hard disk, a flexible disk, or an optical disk, and stores various programs, tables, databases, and web page files used for various processes and providing websites.

[0061] The debt collection device 1 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as an information processing device connected to any peripheral device. The information processing device may be realized by installing software (including programs or data) that realizes the processing described in this embodiment.

[0062] 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 according to 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]

[0063] The present invention is suitable for application to debt collection operations in the financial industry and the like. [Explanation of symbols]

[0064] 1. Debt collection device 2 Storage section 3. Control Unit 4. Communication interface section 5 Input / output interface section 6 Input Devices 7 Output Devices 11 Debtor Master 21 Display control unit 22 Withdrawal Request Department 23 Acquisition Department 24 Re-withdrawal control unit 25 Data Generation Unit 26 Notification processing section 27 Communication control section 30 Network 40 Deposit Management Device 50 Debtor terminal device

Claims

1. a withdrawal request unit that requests a predetermined amount of money to be withdrawn on a predetermined withdrawal date from a deposit management device that manages the deposit account of each debtor; an acquisition unit that acquires from the deposit management device whether the withdrawal request has been successful; a re-withdrawal control unit that, when an acquisition result indicating that the predetermined amount cannot be withdrawn is obtained, controls the withdrawal request unit to repeatedly make a withdrawal request to the deposit management device at a preset timing during the withdrawal day for the deposit account of the debtor for which an acquisition result indicating that the predetermined amount cannot be withdrawn is obtained; a data generating unit that generates debit data including information identifying the debtor, a debit date, the number of debits, the amount claimed, and the result of the debit, and increments the number of debits each time the debit claim unit makes a debit claim on the debit date; A debt collection device having:

2. the data generation unit sequentially generates debit history data including information identifying the debtor, the debit date, the number of debits, the amount claimed, and the debit result each time a debit request is made during the debit date; 2. The debt collection device according to claim 1,

3. Further comprising a notification processing unit that, when an acquisition result indicating that the predetermined amount cannot be debited is obtained, sends a notification requesting an increase in the deposit balance to the terminal device of the debtor from which the acquisition result indicating that the predetermined amount cannot be debited is obtained, at least on the debit date; 3. The debt collection device according to claim 2,

4. the re-withdrawal control unit controls the deduction request unit so that, if the specified amount cannot be debited on the deduction date, a late fee corresponding to a date after the deduction date is added to the specified amount and a deduction request is made; 4. The debt collection device according to claim 1, wherein:

5. a debit request step in which the debit request unit requests a deposit management device that manages the deposit accounts of each debtor to debit a predetermined amount on a predetermined debit date; an acquisition step in which an acquisition unit acquires from the deposit management device whether or not the withdrawal request has been successful; a re-withdrawal control step of controlling the re-withdrawal request unit, when an acquisition result indicating that the predetermined amount cannot be debited is obtained, to make repeated withdrawal requests to the deposit management device at predetermined timings during the withdrawal day for the deposit account of the debtor for which an acquisition result indicating that the predetermined amount cannot be debited is obtained; a data generation step in which a data generation unit generates debit data including information identifying the debtor, a debit date, a number of debits, a billing amount, and a debit result, the number of debits being incremented each time a debit request is made by the debit request unit during the debit date; A debt collection method having the following.

6. Computer, a withdrawal request unit that requests a predetermined amount of money to be withdrawn on a predetermined withdrawal date from a deposit management device that manages the deposit account of each debtor; an acquisition unit that acquires from the deposit management device whether the withdrawal request has been successful; a re-withdrawal control unit that, when an acquisition result indicating that the predetermined amount cannot be withdrawn is obtained, controls the withdrawal request unit to repeatedly make a withdrawal request to the deposit management device at a preset timing during the withdrawal day for the deposit account of the debtor for which an acquisition result indicating that the predetermined amount cannot be withdrawn is obtained; functioning as a data generating unit that generates debit data including information identifying the debtor, the debit date, the number of debits, the amount claimed, and the result of the debit, and incrementing the number of debits each time the debit claim unit makes a debit claim on the debit date; A debt collection program featuring:

Images