JP7726856B2 - Debt collection device, debt collection method, and debt collection program - Google Patents

Description

The present invention relates to a debt collection device, a debt collection method, and a debt collection program.

Patent Document 1 (Patent Publication No. 6989882) discloses a school payment collection support device that can support the efficient collection of school payment fees. 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 payment 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.

The payment control unit requests the financial institution terminal device to debit the school payment, and receives information in response to the request indicating whether the financial institution successfully debited the school payment. 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 using dialogue, and receives a desired re-debit date from the parent terminal device. This makes it possible to support the efficient collection of school payment.

Patent No. 6989882

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.

The present invention was made in consideration of the above-mentioned problems, and aims to provide a debt collection device, debt collection method, and debt collection program that allows for re-withdrawal on the contract date (withdrawal date) even if the specified amount cannot be withdrawn on the contract date.

To solve the above problems and achieve the objectives, the debt collection device of the present invention comprises: 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 each debtor's deposit account; 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 times during the debit date for the debtor's deposit account 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 debits, the amount requested, and the debit result, and increments the number of debits each time a debit request is made by the debit request unit during the debit date.

In order to solve the above-mentioned problems and achieve the objectives, 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 each debtor's deposit account; an acquisition step in which an acquisition unit acquires from the deposit management device whether the debit request was successful; a re-debit control step in which, if the acquisition result indicates that the predetermined amount cannot be debited, the re-debit control unit controls the debit request unit to make repeated debit requests to the deposit management device at predetermined times during the debit date for the debtor's deposit account for which the acquisition result indicates that the predetermined amount cannot be debited; 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 debits, the amount requested, and the debit result, and incrementing the number of debits each time a debit request is made by the debit request unit during the debit date.

Furthermore, in order to solve the above-mentioned problems and achieve the objective, 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 each debtor's deposit account; 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 times during the debit date for the debtor's deposit account 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 debits, the amount requested, and the debit result, and increments the number of debits each time a debit request is made by the debit request unit during the debit date.

The present invention makes it possible to re-debit the specified amount on the contract date (withdrawal date) even if the specified amount cannot be debited on the contract date.

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

Below, a debt collection device according to an embodiment of the present invention will be described in detail with reference to the drawings. However, the present invention is not limited to such an embodiment.

(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.

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.

The memory unit 2 can be, for example, a storage device such as a ROM (Read Only Memory), RAM (Random Access Memory), HDD (Hard Disk Drive), or SSD (Solid State Drive). The memory unit 2 stores a debt collection program for debiting a specified amount from a debtor's deposit account on a specified contract date (withdrawal date), such as the 10th of each month. The memory unit 2 also stores deduction data, transaction data, and deduction history data, which will be described later.

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 debit amount, and the contract date (debit date). The debit request unit 22 of the control unit 3, which will be described later, references this debtor master data 11 and processes the debit amount from each debtor's deposit account.

(Functional configuration of the 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.

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

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 whether the withdrawal request was successful.

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 withdrawal requests to the deposit management device 40 at pre-set times during the withdrawal day (contract day) for the deposit account of the debtor for which the acquisition result indicating that the specified amount cannot be withdrawn has been obtained.

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 to add a late fee corresponding to the amount for the date after the debit date to the specified amount and make a debit request.

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.

In addition, the data generation unit 25 sequentially generates withdrawal history data including information identifying the debtor, the withdrawal date, the number of withdrawals, the amount claimed, and the withdrawal result each time a withdrawal request is made on a withdrawal date.

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.

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

(Example of typical debt collection operations)
Here, we will explain a typical debt collection operation as a reference example. Figure 2 is a flowchart showing the flow of a typical debt collection operation. The example shown in Figure 2 shows a case 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 for "July 2022 (=June)" withdrawals made to three debtors with contract numbers "100000001-0,""100000002-0," and "100000003-0." Until the deposit management device makes the withdrawal from each debtor's deposit account, the withdrawal result of the withdrawal data will be "Z: Requested."

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 agreed date, for example, July 1st. This allows the business operator to check the withdrawal results, for example, from around July 3rd, by accessing the deposit management device, and confirm the withdrawal results via the withdrawal data shown in Figure 4 (Step S2).

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 deduction of "20,000 yen" 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 is not possible, 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 "July 1, 2022," the date on which the deduction could not be made, and the debt will be in a delinquent state.

If the withdrawal cannot be made, for example around July 4th, a payment request form that can be used at convenience stores, etc., will be issued along with a reminder notice, and a delinquent payment request will be sent to the debtor (step S3).

If the debtor does not make a payment even after this overdue request, 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 claimed, totaling 21,000 yen, including a late payment penalty of 1,000 yen (Step S4).

(Debt collection operation of the debt collection device according to the embodiment)
Next, the debt collection operation of the debt collection device 1 of this embodiment will be described. Figure 6 is a flowchart showing the flow of the debt collection operation of the debt collection device 1 of this 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 withdrawal request date, for example, July 1, 2022, into this own bank debit request data creation screen.

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 the 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."

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 illustrated in Figure 9(a).

The example in Figure 9(a) shows that the balance in the savings 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).

Furthermore, when the withdrawal result is "1: Insufficient funds," the data generation unit 25 generates transaction data that maintains the date of the failed withdrawal, "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.

Next, if the withdrawal cannot be made, the notification processing unit 26 references the debtor master data 11 and obtains the email address that is the debtor's contact information. Since the withdrawal cannot be made due to insufficient funds, the notification processing unit 26 then creates an email requesting an increase in the deposit account balance 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 deposit account to increase the balance.

In this example, an email is sent requesting an increase in the balance of the savings account, but the notification processing unit 26 may also 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.

Next, the re-withdrawal control unit 24 controls the withdrawal request unit 22 to repeatedly, at pre-set times, request withdrawals from the debtor's deposit account for which the deposit management device 40 has obtained an acquisition result indicating that the specified amount cannot be withdrawn on the withdrawal date, July 1, 2022 (step S14).

Specifically, the receivables master 11 stores the number of times that deductions will be repeated on a deduction day if deductions cannot be made, and the deduction times, which are determined for each debtor. That is, the receivables master 11 stores the number of times that deductions will be repeated on a deduction day as "3 times," and the deduction times, such as "9:00 AM," "1:00 PM," and "5:00 PM," for each debtor.

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 in "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 in "1: Insufficient funds."

In addition, each time a new debit request is made, the data generation unit 25 updates the sequence (SEQ = number of debits) of the debtor's debit data by one, such as "1" → "2" → "3", as shown in Figure 10. In addition, the data generation unit 25 sets the debit result for debtors who cannot be debited to "Z: Requesting".

Furthermore, the data generation unit 25 generates withdrawal history data corresponding to each debtor's first withdrawal, 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 Figure 11, the withdrawal result for debtors with contract numbers "100000001-0" and "100000003-0" for whom withdrawals were successful is set to "0: Transferred," and the withdrawal result for debtor with contract number "100000002-0" for whom withdrawals were not successful is set to "1: Insufficient funds."

Furthermore, each time a new 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. In the example of Figure 13, a record of withdrawal history data was generated in which the result of the first withdrawal for the debtor with contract number "100000002-0" was "1: Insufficient funds." However, since the second withdrawal on the same day also failed due to an insufficient account balance, a new record was generated and added with the number of withdrawals (SEQ) set to "2," the claim set to "20,000 yen," and the result of the withdrawal set to "1: Insufficient funds."

As described above, the debt collection device 1 of this embodiment allows for multiple withdrawals on the same day, allowing creditors to enjoy benefits such as a lower delinquency rate and reduced delinquent debt management costs. Furthermore, debtors can reduce the effort required to carry out transfer procedures at, for example, a convenience store, and also reduce the risk of paying late fees.

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 following day in this example, "July 2, 2022," the invoice will be overdue, and the data generation unit 25 will generate withdrawal data with a withdrawal result of "Z: Requesting" for the invoice amount plus late fees, as shown in Figure 12. Then, on "August 1, 2022," another withdrawal will be made for the invoice amount including late fees.

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

(Effects of the embodiment)
As is clear from the above explanation, the debt collection device 1 of the embodiment can attempt to make withdrawals by making multiple withdrawal requests 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.

As a result, creditors can enjoy benefits such as a lower delinquency rate and reduced management costs for overdue debts. Debtors can also reduce the hassle of having to go through transfer procedures at convenience stores, for example, and reduce the risk of having to pay late fees.

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

Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to SDGs Goals 12, 13, and 15.

Furthermore, this embodiment can contribute to strengthening control and governance, thereby contributing to Goal 16 of the SDGs.

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.

For example, of 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.

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

Furthermore, with regard to the debt collection device 1, each component shown in the figure is a functional concept and does not necessarily have to be physically configured as shown.

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 implemented by a CPU (Central Processing Unit) 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 debt collection device 1 as needed. In other words, a computer program is recorded in a storage unit such as a ROM or HDD 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 3.

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

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

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. A "program" is not necessarily limited to a single structure, but also includes a distributed structure consisting of multiple modules or libraries, or a structure that achieves its function by working in conjunction 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.

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 website provision.

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

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional loads. In other words, the above-mentioned embodiments may be implemented in any combination, or embodiments may be implemented selectively.

This invention is suitable for use in debt collection operations in the financial industry, etc.

REFERENCE SIGNS LIST 1 Debt collection device 2 Memory unit 3 Control unit 4 Communication interface unit 5 Input/output interface unit 6 Input device 7 Output device 11 Debtor master 21 Display control unit 22 Withdrawal request unit 23 Acquisition unit 24 Re-withdrawal control unit 25 Data generation unit 26 Notification processing unit 27 Communication control unit 30 Network 40 Deposit management device 50 Debtor terminal device

Claims (6)

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: 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, 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, 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: 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. 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.