Business support device, business support method, and business support program

Abstract

To support accurate and efficient payment reconciliation operations. [Solution] When installment payments are received after the due date, the calculation unit calculates the billed amount, which is the amount obtained by adding a predetermined late payment penalty to the installment payment amount scheduled to be received on the due date, and the deficit amount, which is the difference obtained by subtracting the installment payment amount received after the due date from the billed amount. The determination unit determines whether all three conditions are met: the first condition "deficit amount > 0 yen", the second condition "deficit amount ≤ late payment penalty", and the third condition "deficit amount ≤ base amount". If the payment reconciliation target data generation unit determines that all of the above conditions are met, it generates payment reconciliation target data that has undergone a predetermined process from among abandonment processing and carry-over processing. This payment reconciliation target data can be used to support payment reconciliation operations for payments in which late payment penalties have been incurred.

Description

Technical Field

[0006] , ,

[0001] The present invention relates to a business support apparatus, a business support method, and a business support program.

Background Art

[0002] The payment reconciliation device disclosed in Patent Document 1 (Japanese Patent Application Laid-Open No. 2006-040114) stores, in storage means (reconciliation result DB), reconciliation result information including debtor identification information and surplus or deficit information. The payment information acquisition means acquires payment information including debtor identification information and transfer amount information, and the claim information acquisition means acquires claim information indicating the amount claimed against the debtor based on the debtor identification information in the payment information. Then, the result writing means compares the transfer amount indicated by the payment information with the claim amount indicated by the claim information, and when the claim amount and the payment amount do not match, calculates a surplus or deficit and generates reconciliation result information, and writes it to the storage means.

[0003] [[ID=十六]]Thus, even when the claim amount fluctuates at any time, it is possible to calculate an accurate surplus or deficit when there is a payment from the debtor and perform payment reconciliation.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Here, for example, in the business of collecting financial claims such as loans, credits, and leases, there are cases where a customer such as a creditor makes a payment after the scheduled collection date. In this case, a claim is made with a late payment penalty added according to the number of days of delay.

[0006] However, delays in payment can result in a shortfall between the actual amount received and the invoiced amount, which may include late payment penalties.

[0007] In this case, the operations operator manually decided whether to forfeit the deficit or carry it over to the next claim based on the operating regulations and the amount of the deficit, and then manually processed the payment reconciliation. As a result, the payment reconciliation process was inefficient and prone to problems such as work errors or judgment errors.

[0008] This invention has been made in view of the above-mentioned problems, and aims to provide a business support device, a business support method, and a business support program that support accurate and efficient payment reconciliation operations. [Means for solving the problem]

[0009] The business support device according to the present invention is a business support device that supports the payment reconciliation of installment payments received when the price of a commercial transaction is divided into predetermined installment payments and repaid on predetermined repayment dates, and in order to solve the above problems and achieve the objective, when an installment payment is made after the repayment date, it includes a calculation unit that calculates the billed amount, which is the amount obtained by adding a predetermined late payment penalty to the installment payment that was scheduled to be paid on the repayment date, and the deficit amount, which is the difference obtained by subtracting the installment payment received after the repayment date from the billed amount, and a first condition of whether the deficit amount is greater than 0 yen, and whether the deficit amount is greater than 0 yen The system includes a determination unit that determines whether all of the following conditions are met: a second condition whether the amount is less than or equal to a certain amount, and a third condition whether the deficit is less than or equal to a certain threshold amount that serves as a criterion for determining whether to execute a predetermined processing method, which includes a waiver process to forfeit the deficit and a carry-forward process to add the deficit to the next installment payment amount. If the determination unit determines that all of the first, second, and third conditions are met, a payment reconciliation target data generation unit generates payment reconciliation target data to which a predetermined processing method, such as a waiver process or a carry-forward process, has been applied.

[0010] Furthermore, the business support method according to the present invention is a business support method in a business support device that supports the payment reconciliation of installment repayment amounts received when the price of a commercial transaction is divided into predetermined installment repayment amounts and repaid on predetermined repayment dates, and in order to solve the above problems and achieve the objective, the calculation unit calculates the billed amount, which is the amount obtained by adding a predetermined late payment penalty to the installment repayment amount scheduled to be paid on the repayment date when the installment repayment amount is paid after the repayment date, and the deficit amount, which is the difference obtained by subtracting the installment repayment amount paid after the repayment date from the billed amount, and the determination unit determines whether the deficit amount is greater than 0 yen, and whether the deficit amount is greater than 0 yen. The system includes a determination step to determine whether all of the following conditions are met: a second condition whether the amount is less than or equal to the amount of damages, and a third condition whether the deficit is less than or equal to a threshold amount that serves as a criterion for determining whether to execute a predetermined processing method, which includes a waiver process to forfeit the deficit and a carry-forward process to add the deficit to the next installment payment amount; and a payment reconciliation target data generation step in which, if the determination step determines that all of the first, second, and third conditions are met, the payment reconciliation target data generation unit generates payment reconciliation target data that has undergone a predetermined processing method, which includes a waiver process and a carry-forward process, which is stored in the storage unit.

[0011] Furthermore, the business support program according to the present invention is a business support program that enables the operation of a computer in a business support device that supports the payment reconciliation of installment payments received when the price of a commercial transaction is divided into predetermined installment payments and repaid on predetermined repayment dates. In order to solve the above-mentioned problems and achieve the objective, the computer includes a calculation unit that calculates the billed amount, which is the amount obtained by adding a predetermined late payment penalty to the installment payment amount scheduled to be paid on the repayment date, when the installment payment amount is paid after the repayment date, and the deficit amount, which is the difference obtained by subtracting the installment payment amount received after the repayment date from the billed amount, and whether the deficit amount is greater than 0 yen. A determination unit determines whether all of the following conditions are met: the first condition is whether or not, the second condition is whether or not the deficit is less than or equal to the late payment penalty, and the third condition is whether or not the deficit is less than or equal to a threshold amount that serves as a criterion for determining whether or not to execute a predetermined processing method, which includes a waiver process that waives the deficit and a carry-forward process that adds the deficit to the next installment payment scheduled for billing. If the determination unit determines that all of the first, second, and third conditions are met, it functions as a payment reconciliation target data generation unit that generates payment reconciliation target data to which a predetermined processing method, such as a waiver process or a carry-forward process, has been applied and which is stored in the memory unit. [Effects of the Invention]

[0012] This invention can support accurate and efficient payment reconciliation operations. [Brief explanation of the drawing]

[0013] [Figure 1] Figure 1 is a block diagram showing the hardware configuration of the business support device according to the embodiment. [Figure 2] Figure 2 shows an example of a contract information input screen. [Figure 3] Figure 3 shows an example of a processing code master table. [Figure 4] Figure 4 shows an example of contract data. [Figure 5] Figure 5 shows an example of the screen for importing bank transfer deposit files. [Figure 6] FIG. 6 is a diagram showing an example of deposit detail data. [Figure 7] FIG. 7 is a diagram showing an example of provisional receipt data and deposit write-off target data. [Figure 8] FIG. 8 is a diagram for explaining how to calculate the total claim amount including late damages. [Figure 9] FIG. 9 is a diagram showing an example of deposit write-off target data generated when a processing code of "0 (none)" indicating that no abandonment or carry-over processing is performed is set. [Figure 10] FIG. 10 is a diagram showing an example of the first to third conditions used to determine whether to create deposit write-off target data for abandonment or carry-over when the deposit amount is less than the claim amount. [Figure 11] FIG. 11 is a diagram showing an example of the determination result of whether the first to third conditions are satisfied. [Figure 12] FIG. 12 is a diagram showing an example of a deposit write-off screen. [Figure 13] FIG. 13 is a diagram for explaining the generation operation of collection performance data when "1 (abandonment)" is set as the processing code. [Figure 14] FIG. 14 is a diagram for explaining the generation operation of collection performance data when "0 (none)" is set as the processing code. [Figure 15] FIG. 15 is a diagram for explaining the generation operation of collection performance data when "1 (abandonment)" is set as the processing code. [Figure 16] FIG. 16 is a diagram for explaining the generation operation of collection performance data when "2 (carry-over)" is set as the processing code. [Figure 17] FIG. 17 is a diagram for explaining the generation operation of deposit write-off target data when the previous carry-over amount is added to the repayment amount and deposited on the next repayment date. [Figure 18] FIG. 18 is another diagram for explaining the generation operation of deposit write-off target data when the previous carry-over amount is added to the repayment amount and deposited on the next repayment date.

Best Mode for Carrying Out the Invention

[0014] Hereinafter, as an embodiment to which the present invention is applied, a business support device for assisting in the deposit offset processing business of loan repayment funds in the financial industry will be described in detail based on the drawings. Note that the present invention is not limited to the following embodiments, and can also be applied to a business support device or the like that assists in deposit offset operations such as loan repayment funds for physical goods or loan repayment funds for provided services. In any case, the same effects as those described later can be obtained. For details, refer to the following description.

[0015] (Overview) For example, in the collection business of financial claims such as loans, credits, and leases, customers such as creditors may make deposits after the scheduled collection date. In this case, a claim is made with a late payment penalty added according to the number of days of delay.

[0016] However, the amount actually deposited may be insufficient for the claim amount with a late payment penalty added due to a late deposit.

[0017] In this case, the business operator manually judged and performed the deposit offset processing, such as waiving the shortage amount or carrying forward the claim to the next time, based on the operation regulations and the amount of the shortage. As a result, the deposit offset business became inefficient, and there were problems such as work mistakes or judgment mistakes.

[0018] Here, the treatment of "waiving" or "carrying forward" late payment penalties is often applied to credit products or products dealing with small amounts and large volumes of debt. In other words, late payment penalties for credit products are often applied to consumers (individuals) as the customers, and are often applied to "waive" or "carry forward" from the perspective of customer satisfaction or securing repeat customers, and to increase the motivation of merchants or debtors to use the service (as a service). Also, for late payment penalties for products dealing with small amounts and large volumes of debt, the treatment of "waiving" or "carrying forward" is often applied to reduce the cost of responding to delinquent debt collection.

[0019] Whether or not to "waive" or "carry over" the outstanding amount of a payment for which late payment penalties have been incurred depends on the product (contract) and also on the amount. For this reason, the business support device of this embodiment automatically determines whether or not to perform the "waiver" or "carry over" process for each product (contract) and the amount of the payment shortage, and generates payment reconciliation target data to support the payment reconciliation process.

[0020] This enables the automation of the payment reconciliation process for payments with shortfalls, thereby improving operational efficiency and reducing errors in work or judgment.

[0021] (Hardware configuration) The business support device of this embodiment is operated by a business operator in the financial industry. The business support device 1 of the embodiment shown in Figure 1 has a hardware configuration similar to that of a so-called personal computer device, and mainly comprises a storage unit 2, a control unit 3, a communication interface unit 4, and an input / output interface unit 5.

[0022] An input / output interface unit 5 is connected to an input device 6 and an output device 7. The output device 7 can be a display unit such as a monitor device (including a home television), a printing device, or a speaker device. The input device 6 can be a keyboard device, a mouse device, a microphone device, or a monitor device that works in conjunction with the mouse device to provide a pointing device function.

[0023] The communication interface unit 4 is connected to a network 50, such as a wide-area network like the Internet or a private network like a LAN (Local Area Network). In addition to the business support device 1 of this embodiment, a bank terminal device 51 and a customer terminal device 52 are connected to this network 50 for customers to make deposit requests.

[0024] The customer accesses the bank terminal 51 via the customer terminal 52 and performs a deposit operation corresponding to the monthly loan payment. This causes the bank terminal 51 to generate deposit detail data in a format specified by the Japanese Bankers Association, corresponding to the customer's deposit operation. In response to a transmission request from the business support device 1, the bank terminal 51 transmits the deposit detail data corresponding to the customer's deposit to the business support device 1.

[0025] For the memory unit 2, a storage device such as ROM (Read Only Memory), RAM (Random Access Memory), HDD (Hard Disk Drive), or SSD (Solid State Drive) can be used.

[0026] Memory unit 2 stores a business support program designed to assist in accurate and efficient payment reconciliation operations.

[0027] Furthermore, the memory unit 2 is equipped with the following memory areas: a processing code master table 11, a customer data storage unit 12, a contract data storage unit 13, a collection schedule data storage unit 14, a payment details data storage unit 15, and a provisional receipt data storage unit 16. Additionally, the memory unit 2 is equipped with the following memory areas: a payment reconciliation target data storage unit 17, a work data storage unit 18, and a collection results data storage unit 19. More details will be provided later.

[0028] (Functional configuration of business support equipment) Next, the control unit 3 executes the business support program stored in the memory unit 2, and functions as a calculation unit 21, discrimination unit 22, data generation unit 23, display control unit 24, communication control unit 25, and update processing unit 26, as shown in Figure 1. The data generation unit 23 includes the functions of a payment reconciliation target data generation unit 27 and a collection performance data generation unit 28.

[0029] Such a business support device 1 aims to support the payment reconciliation process for installment payments received when the price of a commercial transaction (physical goods, loan products, or services, etc.) is divided into predetermined installment payments and repaid on predetermined repayment dates.

[0030] Specifically, the calculation unit 21 calculates the invoice amount, which is the amount obtained by adding a predetermined late payment penalty to the installment payment amount scheduled to be paid on the due date, and the deficit amount, which is the difference obtained by subtracting the installment payment amount received after the due date from the invoice amount, when the installment payment amount is paid after the due date.

[0031] The discrimination unit 22 determines whether all of the following conditions are met: a first condition whether the deficit is greater than 0 yen; a second condition whether the deficit is less than or equal to a predetermined late payment penalty, such as 500 yen; and a third condition whether the deficit is less than or equal to a predetermined threshold amount that serves as a criterion for deciding whether or not to execute a processing method, which includes at least a waiver process to forfeit the deficit and a carry-over process to add the deficit to the next installment payment amount (see Figure 10).

[0032] Furthermore, if the determination unit 22 determines that all of the first, second, and third conditions are met, the payment reconciliation target data generation unit 27 generates payment reconciliation target data that has undergone a predetermined process, either abandonment processing or carry-over processing, which is stored in the storage unit (processing code master table 11) (see Figure 9).

[0033] Furthermore, the payment reconciliation target data generation unit 27 generates payment reconciliation target data that includes the appropriation amount, which is the installment repayment amount received after the repayment due date, the late payment penalty appropriation amount, which is the amount obtained by subtracting the shortfall from the late payment penalty, and one of the processing methods (see Figure 9).

[0034] The collection performance data generation unit 28 generates collection performance data at the time of payment reconciliation, based at least on the payment reconciliation target data, with the payment date after the repayment due date as the collection performance date, and includes the amount of the principal, interest, fees, and late payment penalties applied by the payment made after the repayment due date, the amount of the late payment penalties that was applied by the payment, the amount of the installment repayment amount paid after the repayment due date which was deducted from the billed amount and is the amount to be forfeited based on the standard amount at the time of forfeiture processing or the amount that was not carried forward based on the standard amount at the time of carry-forward processing, and a collection completion flag indicating whether or not the collection of the installment repayment amount on the repayment due date has been completed (see Figure 13(c)).

[0035] When calculating the above-mentioned billing amount, the calculation unit 21 refers to the planned collection data (see Figure 17(c)) and the actual collection data (see Figure 17(d)) ​​which store the principal, interest, and fees corresponding to the installment repayment amount for each repayment due date. It calculates the principal billing amount by subtracting the principal amount allocated from the actual collection data from the principal amount for the previous (last month's) repayment due date and adding the principal amount for the current (current month's) repayment due date (see Figure 18(a)).

[0036] In this example, we will assume that the previous repayment due date was "last month's repayment due date" and the current repayment due date is "this month's repayment due date." However, if the repayment due date occurs every three months, the previous repayment due date would be "three months ago's repayment due date," and the current repayment due date would be "three months after the previous repayment due date, this month's repayment due date." Thus, the "repayment due date" can be set freely.

[0037] Furthermore, when calculating the above-mentioned billing amount, the calculation unit 21 calculates the billing amount for interest by subtracting the applicable interest from the collection performance data from the interest on the previous (last month's) repayment due date and adding the interest on the current (current month's) repayment due date (see Figure 18(a)).

[0038] Furthermore, the calculation unit 21 calculates the amount of the fee to be charged by subtracting the fee applied to the collection performance data from the fee for the previous (last month's) repayment due date and adding the fee for the current (current month's) repayment due date (see Figure 18(a)).

[0039] The calculation unit 21 then calculates the total amount of the invoiced principal, interest, and fees, plus the late payment penalty from the collection performance data, as the invoiced amount (see Figure 18(a)).

[0040] (Operation of the embodiment) In this embodiment, the business support device 1 performs the input of contract information in step S1, and in step S2, it acquires deposit details data from the bank terminal device 51 to generate deposit reconciliation target data. Then, in step S3, it performs deposit reconciliation processing based on this deposit reconciliation target data.

[0041] (Step S1: Entering contract information) First, once a loan agreement is concluded with the customer, the business operator of the business support device 1 specifies the display of the contract information input screen. As a result, the display control unit 24 displays the contract information input screen, as illustrated in Figure 2, via the output device 7.

[0042] As shown in Figure 2, the business operator enters the customer number (customer ID), contract identification number (contract ID), customer name, product code, contract date, and contract number into this contract information input screen.

[0043] When this various information is entered, the display control unit 24 refers to the processing code master table 11 shown in Figure 3 based on the entered product code. The processing code master table 11 has a processing code and a base amount set for each product code of each product.

[0044] In the example shown in Figure 3, for the product with product code "S01", a processing code of "0 (none)" is set, which means that if the installment payment is made after the due date, no processing is performed for any shortfall in the invoiced amount. In this case, the base amount is not set (NULL).

[0045] Furthermore, in the example shown in Figure 3, for the product code "S02," if there is a shortfall in the installment payment amount received after the due date, a processing code of "1 (forfeit)" is set to indicate that this shortfall will be forfeited. A threshold amount of "250 yen" is also set. This threshold amount indicates that if the shortfall is "250 yen or less," the shortfall will be forfeited and the payment reconciliation process will be performed automatically, and if the shortfall is "greater than 250 yen," the business operator will perform the payment reconciliation process manually.

[0046] Furthermore, in the example shown in Figure 3, for the product with product code "S03," if there is a shortfall in the installment payment received after the due date, a processing code of "2 (carryover)" is set to indicate that this shortfall will be carried over and billed in the next month. A threshold amount of "250 yen" is also set. This threshold amount indicates that if the shortfall is "250 yen or less," the shortfall will be carried over to the next billing cycle, and if the shortfall is "greater than 250 yen," the business operator will manually process the payment reconciliation.

[0047] The example in Figure 2 shows a case where a loan agreement for the product "Individual Credit Purchase Arrangement" with product code "S02" was concluded for a customer named "Yamada XX". The contract date is "April 1, 2024". Also, in the example in Figure 2, the product code is "S02". Therefore, the display control unit 24 refers to the processing code master table 11 shown in Figure 3 based on this product code "S02" and obtains the processing code "1 (abandonment)" and the base amount "250 yen". Then, as shown in Figure 2, the display control unit 24 automatically inputs the processing code "1 (abandonment)" and the base amount "250 yen" into the contract information input screen.

[0048] Furthermore, the processing method and standard amount are set for each customer, as shown in Figure 2. Therefore, it can be said that the business support device 1 of this embodiment allows for the setting of processing methods and standard amounts on a customer-by-customer and product-by-product basis.

[0049] When various contract information is entered into the contract information input screen and the "Register" button on the contract information input screen is operated, the data generation unit 23 generates contract data including contract ID, contract date, contract number, customer ID, product code, processing code, and base amount based on the input content on the contract information input screen, as shown in Figure 4, and stores it in the contract data storage unit 13.

[0050] (Step S2: Generation of data to be reconciled with payments) Next, the business operator specifies the display of the bank transfer deposit file import screen via the input device 6. As a result, the display control unit 24 displays the bank transfer deposit file import screen, as illustrated in Figure 5, via the output device 7. The business operator then inputs the import file path to this bank transfer deposit file import screen, specifying the storage location on the deposit details data storage unit 15 of the storage unit 2 where the bank transfer deposit details file is stored.

[0051] In other words, on a predetermined date after the repayment due date, the communication control unit 25 retrieves the transfer deposit details file from the bank terminal device 51 and stores it as deposit details data in the deposit details data storage unit 15 of the storage unit 2. This transfer deposit details file is generated based on a format specified by the so-called Federation of Japanese Bankers Associations, as shown in Figure 6(d), and is transferred from the bank terminal device 51.

[0052] The business operator enters the import file path, which specifies the storage location on the deposit details data storage unit 15 where this deposit details data is stored, into the transfer deposit file import screen and operates the "Execute" button.

[0053] This allows the deposit details data storage unit 15 to read the deposit details data exemplified in Figure 6(d). This example in Figure 6(d) shows that on the deposit date of "June 20, 2024", a deposit of "16,300 yen" was made by a customer with customer ID "U001" and customer name "Yamada XX".

[0054] Furthermore, the communication control unit 25 may, at a timing specified by the business operator, communicate with the bank terminal device 51, for example, via a web application interface, to obtain the transfer deposit file.

[0055] When a contract is concluded with a customer, in addition to the contract data shown in Figure 6(b), customer data including the customer ID and customer name shown in Figure 6(a) is generated by the data generation unit 23 and stored in the customer data storage unit 12. Furthermore, the collection schedule data shown in Figure 6(c) is generated by the data generation unit 23 and stored in the collection schedule data storage unit 14.

[0056] As shown in Figure 6(c), the collection schedule data includes the contract ID, line number, collection date, principal, interest, and fees to be collected on the collection date, and the "total amount of principal, interest, and fees." This example in Figure 6(c) shows that the principal, interest, and fees are scheduled to be collected on the "15th" of each month.

[0057] On the other hand, the example shown in Figure 6(d) has a deposit date of "June 20, 2024". This indicates that the deposit was made on a date later than the originally scheduled deposit date of "June 15, 2024".

[0058] Furthermore, the example shown in Figure 6(d) shows that the amount deposited was "16,300 yen". As shown in Figure 6(c), the amount scheduled to be deposited on "June 15, 2024" was "16,000 yen," but the customer was aware that late payment penalties would be incurred due to the missed repayment deadline. The customer estimated that these late payment penalties would be around "300 yen," and therefore added this "300 yen" to arrive, resulting in the deposit of "16,300 yen."

[0059] Furthermore, in this example, the actual late payment penalty is ¥500, as will be explained later. Therefore, although a payment of ¥16,500 was originally required due to the delay, ¥16,300 was received, which is ¥200 less. Whether this shortfall of ¥200 is forfeited or carried over to the next payment is determined based on the processing code of the contract data shown in Figure 6(b).

[0060] Next, based on the payment details data shown in Figure 6(d), the payment reconciliation target data is generated according to the following flow.

[0061] (Generating temporary receipt data) First, the data generation unit 23 generates temporary receipt data, including the temporary receipt ID, receipt date, and receipt amount, based on the receipt details data shown in Figure 6(d), as shown in Figure 7(a), and stores it in the temporary receipt data storage unit 16. The temporary receipt ID is automatically assigned and added by the control unit 3. In this example, the receipt date is "June 20, 2024," and the receipt amount is "16,300 yen," which is short by "200 yen" as described above.

[0062] (Customer identification) Next, the payment reconciliation target data generation unit 27 identifies the customer by referring to the payment details data shown in Figure 6(d). Specifically, the payment reconciliation target data generation unit 27 considers identification successful if there is one customer where "customer name (Katakana) in the customer data = remitter name (Katakana) in the payment details file". Alternatively, the payment reconciliation target data generation unit 27 considers identification successful if there is one customer where "customer ID (Katakana) in the customer data = remitter code (Katakana) in the payment details file". In all other cases, the payment reconciliation target data generation unit 27 considers customer identification unsuccessful.

[0063] (Calculation of the amount to be billed to the identified customer) Next, the payment reconciliation target data generation unit 27 refers to the contract data shown in Figure 6(b) based on the identified customer ID and identifies the contract ID. The calculation unit 21 refers to the collection schedule data of the identified customer shown in Figure 6(c) where "Collection schedule date of collection schedule data ≤ Payment date of provisional receipt data" and calculates the invoice amount on the payment date.

[0064] Specifically, in this example, since the payment was made on "June 20, 2024," the calculation unit 21 reads the principal (10,000 yen), interest (5,000 yen), and handling fee (1,000 yen) set for the scheduled payment date of "June 15, 2024," which is earlier than "June 20, 2024," from the scheduled payment data shown in Figure 6(c), and expands it into the work data storage unit 18. Then, the calculation unit 21 adds these up as shown in Figure 8 (totaling 16,000 yen). In addition, the calculation unit 21 adds a late payment penalty that will be incurred at the time of payment, such as "500 yen," to the sum of the principal, interest, and handling fee, to calculate a total invoice amount of "16,500 yen."

[0065] (Determination of items to be reconciled and generation of data to be reconciled) Next, the discrimination unit 22 determines whether the payment amount is equal to or greater than the invoiced amount, and if the payment amount is equal to or greater than the invoiced amount, whether all of the first to third conditions described later are met. The payment reconciliation target data generation unit 27 generates payment reconciliation target data corresponding to this discrimination result.

[0066] In other words, the discrimination unit 22 determines whether the amount received is equal to or greater than the invoiced amount. For example, if the invoiced amount with the late payment penalty added as described above is "16,500 yen", and the amount received by the customer on a late payment date is "16,500 yen", then the amount to be applied is "16,500 yen", and there is no shortfall in payment. In this case, as shown in Figure 9(a), the payment reconciliation target data generation unit 27 sets the applied amount to "16,500 yen", generates payment reconciliation target data including the provisional receipt ID, contract ID, processing code, and late payment penalty application amount, and stores it in the payment reconciliation target data storage unit 17.

[0067] The example shown in Figure 9(a) is an example of payment reconciliation data generated when the processing code "0 (none)" is set, indicating that no abandonment or carry-over processing will be performed.

[0068] In contrast, if the payment amount is less than the invoiced amount, the discrimination unit 22 determines whether all of the first to third conditions shown in Figure 10 are met.

[0069] Condition 1: Deficit > 0 Second condition: Deficit amount ≤ Late payment damages calculated as the invoice amount. Third condition: Deficit amount ≤ Base amount of contract data

[0070] The first condition is for determining whether or not a deficit has occurred. The second condition is for determining whether or not the deficit is less than or equal to the late payment penalty. The third condition is for determining whether or not the deficit is less than or equal to the threshold amount set as the criterion for deciding whether or not to waive or carry forward the deficit.

[0071] For example, if the total invoice amount is "16,500 yen," and the customer makes a payment of "16,300 yen" on "June 20, 2024 (= 5 days late)," and the processing code is set to "1 (abandoned)," the determination made by the discrimination unit 22 based on the first to third conditions will be as shown in Figure 11 and below. The deficit of 200 yen is the amount obtained by subtracting the payment amount of 16,300 yen from the invoice amount of 16,500 yen (the difference).

[0072] Condition 1: Deficit of 200 yen > 0 ← Condition 1 is met Second condition: Deficit of 200 yen ≤ Late payment penalty of 500 yen ← Second condition is met Third condition: Deficit of 200 yen ≤ Base amount of 250 yen ← Third condition is met

[0073] In this example, all of the first to third conditions are met. Therefore, as shown in Figure 9(b), the payment reconciliation target data generation unit 27 generates payment reconciliation target data with the allocation amount set to the payment amount, "16,300 yen", the processing code set to "1 (abandoned)", and the late payment damage allocation amount (amount of late payment damage already paid) set to "300 yen", which is obtained by subtracting a deficit of 200 yen from the late payment damage of 500 yen, and stores this data in the payment reconciliation target data storage unit 17.

[0074] Furthermore, for example, if the total invoice amount is "16,500 yen," but the customer pays "16,300 yen" on "June 20, 2024 (= 5 days late)," and the processing code is set to "2 (carryover)," the determination of the discrimination unit 22 based on the first to third conditions will be as follows.

[0075] Condition 1: Deficit of 200 yen > 0 ← Condition 1 is met Second condition: Deficit of 200 yen ≤ Late payment penalty of 500 yen ← Second condition is met Third condition: Deficit of 200 yen ≤ Base amount of 250 yen ← Third condition is met

[0076] In this example, all of the first to third conditions are met. Therefore, as shown in Figure 9(c), the payment reconciliation target data generation unit 27 generates payment reconciliation target data with the allocation amount set to the payment amount, "16,300 yen", the processing code set to "2 (carryover)", and the late payment penalty allocation amount (amount of late payment penalty already paid) set to "300 yen", which is obtained by subtracting a deficit of 200 yen from the late payment penalty of 500 yen, and stores this data in the payment reconciliation target data storage unit 17.

[0077] (Step S3: Payment reconciliation process) Next, assuming that a customer made a payment of 16,300 yen on June 20, 2024, with a shortfall of 200 yen, the collection performance data generation unit 28 generates the collection performance data shown in Figure 13(c) based on the provisional receipt data shown in Figure 13(a) and the payment reconciliation target data shown in Figure 13(b), and stores it in the collection performance data storage unit 19.

[0078] As shown in Figure 13(c), this recovery performance data is generated including the contract ID, line number, recovery date, principal amount applied, interest amount applied, fees applied, late payment penalties applied, total amount applied, waived late payment penalties, carried-over late payment penalties, and a recovery completion flag.

[0079] In this example, the collection date is "June 20, 2024," and the principal amount applied from the "16,300 yen" deposit is "10,000 yen," the applied interest is "5,000 yen," the applied fee is "1,000 yen," and the applied late payment penalty for the "500 yen" is "300 yen." Also, since "1 (abandoned)" is set as the processing code, the remaining "200 yen" for the "500 yen" late payment penalty is entered as abandoned late payment penalty.

[0080] Additionally, the collection completion flag is set to "0 (not collected)" by default, but when collection is completed through payment from the customer, it is updated to "1 (collected)" by the update processing unit 26.

[0081] In this situation, when performing payment reconciliation processing, the business operator specifies the display of the payment reconciliation screen. The display control unit 24 displays the payment reconciliation screen illustrated in Figure 12 via the output device 7, and also displays the above-mentioned payment reconciliation target data stored in the payment reconciliation target data storage unit 17 as a list on the payment reconciliation screen.

[0082] The business operator selects the payment reconciliation target data from this list via the input device 6 and operates the "Execute" button provided on the payment reconciliation screen.

[0083] When the "Execute" button is pressed, the calculation unit 21 calculates the invoice amount on the payment date of the provisional receipt data shown in Figure 13(a). Specifically, the calculation unit 21 refers to the collection schedule data shown in Figure 6(c) and reads the principal, interest, and fees on the payment date of the provisional receipt data as shown in Figure 14(a), and expands them into the work data storage unit 18 along with the late payment penalty corresponding to the delayed payment date, such as "500 yen".

[0084] The calculation unit 21 adds up the principal, interest, and fees that have been expanded in the work data storage unit 18, and also adds a late payment penalty corresponding to the delayed payment date, such as "500 yen," to this added amount to calculate the total billing amount (16,500 yen). Note that the example in Figure 14(a) is an example where the deficit becomes "0 yen" because the customer pays the principal, interest, late payment penalty, and fees, including a late payment penalty of "500 yen."

[0085] Next, as shown in Figure 14(b), the collection performance data generation unit 28 expands the principal, interest, late payment penalties, and fees from this payment into the work data storage unit 18 as the amount to be allocated. The collection performance data generation unit 28 also refers to the processing code of the payment reconciliation target data shown in Figure 13(b) and expands the deficit amount, which is the difference between the total billing amount and the amount received, into the work data storage unit 18 as the amount to be forfeited or carried forward, corresponding to the processing code, as shown in Figure 14(b).

[0086] The examples in Figures 14(a) and 14(b) show cases where the deficit, which is the difference between the total invoiced amount and the received amount, is "0 yen". Furthermore, the examples in Figures 14(a) and 14(b) show cases where "0 (none)" is set as the processing code for the payment reconciliation target data. Therefore, as shown in Figure 14(b), the collection performance data generation unit 28 sets the abandoned amount and the carried-over amount to "0 yen" and expands them to the work data storage unit 18.

[0087] If the processing code is set to "0 (none)" and the total invoice amount of "16,500 yen" is paid without any shortfall, the collection performance data will show "0 yen" for both the waived late payment penalty and the carried-over late payment penalty, as shown in Figure 14(c). In addition, the collection completion flag is updated from "0 (not collected)" to "1 (collected)" by the update processing unit 26.

[0088] (In case of abandonment) Next, we will explain a case where, against a total invoice amount of "16,500 yen," the customer paid "16,300 yen" on "June 20, 2024 (= 5 days late)," resulting in a deficit of "200 yen," and the processing code is set to "1 (abandon)" as shown in Figure 15(b).

[0089] In this case as well, the recovery performance data generation unit 28 expands the amount to be claimed, along with the amount to be forfeited, the amount to be waived, and the amount to be carried over, to the work data storage unit 18, as shown in Figure 15(a). In this example, since 300 yen, which is 200 yen less than the customer's amount, was applied to a late payment penalty of 500 yen, the amount to be applied to the late payment penalty is 300 yen.

[0090] Furthermore, although a deposit of "16,300 yen" results in a deficit of "200 yen," as shown in Figure 3, in the case of processing code "1 (abandonment)," the base amount is set to "250 yen." The deficit of "200 yen" is less than the base amount of "250 yen." Therefore, the collection performance data generation unit 28 treats this deficit of "200 yen" as "abandonment" and, as shown in Figure 15(a), deploys the "200 yen" late payment penalty as the abandoned amount to the work data storage unit 18.

[0091] In this example, since the processing code is set to "1 (abandonment)," the amount of carried-over late payment penalties is "0 yen." Also, if the deficit amount is greater than or equal to the standard amount, the payment reconciliation process will be performed manually by the business operator.

[0092] The update processing unit 26 updates the recovery performance data as shown in Figure 15(c), based on the billed amount, allocated amount, forfeited amount, and carried-over amount that have been expanded in the work data storage unit 18 in this manner.

[0093] In other words, in this example, the "200 yen" that is the shortfall in payment has a processing code of "1 (abandoned)," and its collection is abandoned. Therefore, the update processing unit 26 inputs "200 yen" as abandoned late payment penalty, as shown in Figure 15(c).

[0094] Furthermore, since the outstanding amount due to customer payments has been waived, the receivables for the current month have been collected. Therefore, the update processing unit 26 updates the collection completion flag in the collection performance data to "1 (Collected)" as shown in Figure 15(c).

[0095] (In case of carryover) Next, we will explain a case where, against a total invoice amount of "16,500 yen," the customer paid "16,300 yen" on "June 20, 2024 (= 5 days late)," resulting in a deficit of "200 yen," and the processing code is set to "2 (carryover)" as shown in Figure 16(b).

[0096] In this case as well, the collection performance data generation unit 28 expands the amount to be claimed, along with the amount to be forfeited, the amount to be waived, and the amount to be carried over, to the work data storage unit 18, as shown in Figure 16(a). In this example, since 300 yen, which is 200 yen less than the customer's amount, was applied to the 500 yen late payment penalty, the amount applied to the late payment penalty becomes 300 yen.

[0097] Furthermore, although a deposit of "16,300 yen" results in a deficit of "200 yen," as shown in Figure 3, in the case of processing code "2 (carryover)," the base amount is set to "250 yen." The deficit of "200 yen" is less than the base amount of "250 yen." Therefore, the collection performance data generation unit 28 treats this deficit of "200 yen" as a "carryover" and expands the "200 yen" of late payment penalty as a carryover amount to the work data storage unit 18, as shown in Figure 16(a).

[0098] In this example, since the processing code is set to "2 (carryover)," the amount of waived late payment penalties is "0 yen." Also, if the deficit amount is greater than or equal to the standard amount, the payment reconciliation process will be performed manually by the business operator.

[0099] The update processing unit 26 updates the recovery performance data as shown in Figure 16(c), based on the billed amount, allocated amount, forfeited amount, and carried-over amount that have been expanded in the work data storage unit 18 in this manner.

[0100] In other words, in this example, the "200 yen" that is the shortfall in payment has a processing code of "2 (carryover)" and will be carried over and collected next time. For this reason, the update processing unit 26 inputs "200 yen" as the carryover late payment penalty, as shown in Figure 16(c).

[0101] Furthermore, since the outstanding amount due to customer payments is carried over to the next collection, the accounts receivable for the current month remain uncollected. Therefore, as shown in Figure 16(c), the update processing unit 26 maintains the collection completion flag in the collection performance data as "0 (uncollected)".

[0102] (If the carried-over amount is received on the next repayment due date) Next, we will explain the process of generating the payment reconciliation data when, on the next repayment due date in this example, "July 15, 2024," the carried-over late payment penalty of "200 yen" from the previous payment is added to the repayment amount of "15,000 yen" and deposited.

[0103] Specifically, as shown in the customer data in Figure 17(a) and the contract data in Figure 17(b), suppose a customer with contract ID "K001" and customer ID "U001" was assigned the processing code "2 (carryover)". In this case, a payment was made on "June 20, 2024", five days after "June 15, 2024", as shown in the collection schedule data in Figure 17(c), but the payment amount was "200 yen" short. Therefore, the shortfall of "200 yen" was added to the repayment amount scheduled to be collected on "July 15, 2024", and the invoice was sent. As a result, on "July 15, 2024", the repayment due date, the customer paid the amount calculated by adding the shortfall of "200 yen" to the repayment amount scheduled to be collected, and the system generates the payment reconciliation data corresponding to this payment amount.

[0104] In this example, as shown in Figure 17(c), the fee is assumed to have been paid on "June 15, 2024". Therefore, the fee for the payment on "July 15, 2024" will be "0 yen". Also, as shown in Figure 17(d), the collection performance data generated based on the previous payment on "June 20, 2024" shows a collection completion flag of "0 (not collected)" because the shortfall of "200 yen" has been carried over to the next scheduled collection date of "July 15, 2024".

[0105] In this state, the calculation unit 21 refers to the collection schedule data shown in Figure 17(c) and the collection results data shown in Figure 17(d), and calculates the billing amount as shown in Figure 18(a). At this time, the calculation unit 21 refers to the collection schedule data where the collection schedule date ≤ the payment date. The calculation unit 21 also refers to the collection results data based on the contract ID and line number of the collection schedule data.

[0106] The calculation unit 21 does not refer to the collection completion flag which is set to "1 (collected)" or to the collection schedule data associated with this collection completion data based on the contract ID and line number.

[0107] As shown in Figures 17(c), 17(d), and 18(a), the calculation unit 21 sets the principal, interest, and fees for a scheduled collection date of "June 15, 2024" as (a), (b), and (c), respectively. The principal, interest, and fees for a scheduled collection date of "July 15, 2024" as (d), (e), and (f), respectively. The principal, interest, fees, and carried-over late payment penalties based on the payment received on "June 15, 2024" are set as (g), (h), (i), and (j), respectively.

[0108] The calculation unit 21 then performs the following calculation to calculate the total invoice amount corresponding to the scheduled collection date of "July 15, 2024".

[0109] Principal = (a) - (g) + (d) = 10,000 yen - 10,000 yen + 11,000 yen = 11,000 yen Interest = (b) - (h) + (e) = 5,000 yen - 5,000 yen + 4,000 yen = 4,000 yen Late payment penalty = (j) = 200 yen Fee = (c) - (i) + (f) = 1,000 yen - 1,000 yen + 0 yen = 0 yen Total amount due = Principal + Interest + Late payment penalty + Fees = 11,000 yen + 4,000 yen + 200 yen + 0 yen = 15,200 yen

[0110] In this example, since the payment is due on the scheduled collection date of "July 15, 2024," no new late payment penalties will be incurred. Therefore, the only late payment penalty will be the carried-over late payment penalty of "200 yen" from the previous payment.

[0111] Based on this calculation result, the data generation unit 23 generates provisional receipt data as shown in Figure 18(b), with the receipt date set to "July 15, 2024" and the receipt amount set to "15,200 yen," which includes the carried-over late payment penalty of "200 yen" that represents the previous shortfall, and stores this data in the provisional receipt data storage unit 16.

[0112] Furthermore, based on the calculation results described above, the payment reconciliation target data generation unit 27 generates payment reconciliation target data as shown in Figure 18(c), with the allocated amount set to "15,200 yen", the processing code set to "0 (none)", and the amount allocated for late payment penalties set to "0 yen (NULL)", and stores it in the payment reconciliation target data storage unit 17.

[0113] (Effects of the embodiment) As is clear from the above description, the business support device 1 of the embodiment automatically determines whether to perform a "forfeit" or "carry-over" process for each product (contract) and the amount of the payment shortage, and generates payment reconciliation target data to support the payment reconciliation process.

[0114] This enables the automation of the payment reconciliation process for payments with shortfalls. Furthermore, it can improve operational efficiency and reduce errors in work or judgment. Therefore, it can support accurate and efficient payment reconciliation operations.

[0115] [Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This invention can contribute to improving operational efficiency and promoting appropriate management decisions by companies, and therefore can contribute to SDGs Goals 8 and 9.

[0116] Furthermore, this invention can contribute to reducing waste and promoting paperless and electronic processes, thereby contributing to SDGs Goals 12, 13, and 15.

[0117] Furthermore, this invention can contribute to strengthening control and governance, and therefore can contribute to achieving the 16 goals of the SDGs.

[0118] [Other embodiments] The present invention can be implemented in various different forms within the scope of the technical idea described in the claims, even in embodiments other than those described above.

[0119] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically may be performed manually. Alternatively, all or part of the processes described as being performed manually may be performed automatically by known methods or the like.

[0120] Furthermore, unless otherwise specified, the processing procedures, control procedures, specific names, registration data for each process, information including parameters such as search conditions, screen examples, and database configuration shown in the specification or drawings can be arbitrarily changed.

[0121] Furthermore, with respect to the business support device 1, each component shown in the diagram is a functional concept and does not necessarily have to have the physical configuration shown. For example, the processing functions of the business support device 1, particularly the processing functions performed by the control unit 3, may be implemented in whole or in any part by a program interpreted and executed by the control unit 3 (CPU: Central Processing Unit), or by hardware using wired logic.

[0122] The program is recorded on a non-temporary, computer-readable recording medium containing programmed instructions for the information processing device to execute the processes described in the embodiment, and is mechanically read by the business support device 1 as needed. In other words, the storage unit 2, such as ROM or HDD, records a computer program that works in cooperation with the OS (Operating System) to give instructions to the control unit 3 (CPU) and perform various processes. This computer program is loaded into RAM, unpacked, and executed by the control unit 3 as appropriate.

[0123] Furthermore, the business support program for this business support device 1 may be stored on another server device connected to the business support device 1 via any network, and all or part of it may be downloaded and executed as needed.

[0124] Furthermore, the business support program for executing the processes described in the embodiment may be stored on a non-temporary computer-readable recording medium, or it may be configured as a program product.

[0125] Here, any "portable physical medium" can be used as the "recording medium," such as memory cards, USB (Universal Serial Bus) memory, SD (Secure Digital) cards, flexible disks, magneto-optical disks, ROMs, EPROMs (Erasable Programmable Read Only Memory), EEPROMs (Registered Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROMs (Compact Disk Read Only Memory), MOs (Magneto-Optical Disks), DVDs (Digital Versatile Disks), and Blu-ray (Registered Trademark) Discs.

[0126] Furthermore, "program" refers to a data processing method written in any language or writing method, regardless of whether it is source code or binary code.

[0127] Furthermore, the term "program" is not necessarily limited to a single, monolithic entity, but also includes those that are distributed as multiple modules or libraries, and those that work in cooperation with other programs, such as an operating system, to achieve their functions.

[0128] Furthermore, for the specific configuration, reading procedure, and post-reading installation procedure for the business support device 1 of the embodiment, well-known configurations or procedures can be used.

[0129] The storage unit 2 is a storage means such as memory devices like RAM and ROM, fixed disk devices like hard disks, flexible disks, and optical disks, and stores various programs, tables, databases, and web page files used for various processing or website provision.

[0130] Furthermore, the business support device 1 may be composed of a known personal computer device or an information processing device such as a workstation, or it may be composed of an information processing device to which any peripheral devices are connected. In addition, the information processing device may be implemented by implementing software (including programs or data, etc.) that realizes the processing described in the embodiment.

[0131] Furthermore, the specific forms of distribution and integration of the devices are not limited to those shown in the figures, and all or part of them can be configured by functionally or physically distributing or integrating them in any unit according to various additions or functional loads. In other words, the embodiments described above can be selectively implemented by arbitrarily combining the embodiments described above. [Industrial applicability]

[0132] This invention is particularly suitable for supporting the reconciliation of payments for physical goods, services provided, loan products, and other installment payments. [Explanation of Symbols]

[0133] 1 Business support equipment 2 Storage section 3. Control Unit 4. Communication Interface Section 5 Input / Output Interface Section 6 Input devices 7 Output device 11 Processing Code Master Table 12 Customer data storage unit 13 Contract Data Storage Unit 14 Data storage unit scheduled for retrieval 15. Deposit details data storage unit 16 Temporary receipt data storage unit 17. Data storage unit for deposit reconciliation target 18 Work Data Storage Unit 19. Data storage unit for recovery results 21 Calculation Section 22 Discrimination part 23 Data Generation Unit 24 Display Control Unit 25 Communication Control Unit 26 Update Processing Unit 27. Data generation unit for payment reconciliation 28. Data Generation Department for Collection Results 50 Networks 51 Bank terminal equipment 52 Customer terminal equipment

Claims

1. A business support device that assists in the payment reconciliation process for installment payments received when the price of a commercial transaction is divided into predetermined installment payments and repaid on predetermined repayment dates, A calculation unit that calculates the invoice amount, which is the amount obtained by adding a predetermined late payment penalty to the installment payment amount scheduled to be paid on the repayment due date, and the deficit amount, which is the difference obtained by subtracting the installment payment amount received after the repayment due date from the invoice amount, when the installment payment amount is paid after the repayment due date. A determination unit that determines whether all of the following conditions are met: a first condition whether the deficit is greater than 0 yen; a second condition whether the deficit is less than or equal to the late payment penalty; and a third condition whether the deficit is less than or equal to a predetermined threshold amount that serves as a criterion for determining whether or not to execute a processing method that includes at least a waiver process for forfeiting the deficit and a carry-over process for adding the deficit to the next installment payment scheduled for billing; If the discrimination unit determines that all of the first, second, and third conditions are met, the payment reconciliation target data generation unit generates payment reconciliation target data that has undergone the abandonment process and the carry-over process, which are predetermined and stored in the storage unit. A business support device having the following features.

2. The payment reconciliation target data generation unit generates payment reconciliation target data that includes the appropriation amount, which is the installment repayment amount received after the repayment due date; the late payment penalty appropriation amount, which is the amount obtained by subtracting the shortfall from the late payment penalty; and any of the processing methods. The business support device according to claim 1, characterized by the following:

3. The system further comprises a collection performance data generation unit that, at the time of payment reconciliation, generates collection performance data that includes, at least based on the payment reconciliation target data, sets the payment date after the repayment due date as the collection performance date, the principal amount, interest, and fees applied by the payment after the repayment due date, the amount of the late payment penalty that is applied by the payment, the shortfall amount obtained by subtracting the installment repayment amount paid after the repayment due date from the invoice amount, the amount of the late payment penalty that is forfeited based on the standard amount at the time of forfeiture processing or the amount that is not carried forward based on the standard amount at the time of carry-forward processing, and a collection completion flag indicating whether or not the collection of the installment repayment amount on the repayment due date has been completed. A business support device according to claim 1 or claim 2, characterized by the above.

4. The calculation unit described above, When calculating the aforementioned invoice amount, the principal, interest, and fees corresponding to the installment repayment amount for each repayment due date are stored in the collection schedule data and the collection performance data, and the principal amount for the current repayment due date is calculated by subtracting the allocated principal amount from the principal amount for the previous repayment due date from the principal amount for the previous repayment due date and adding the principal amount for the current repayment due date to this amount. The amount of interest to be charged is calculated by subtracting the amount of interest applied from the collection performance data from the interest on the previous repayment due date, and then adding the interest on the current repayment due date. The amount of the fee to be charged is calculated by subtracting the amount of the fee applied to the collection performance data from the fee for the previous repayment due date, and then adding the fee for the current repayment due date. The amount to be claimed is calculated by adding the aforementioned late payment penalty from the collection performance data to the aforementioned principal amount, the aforementioned interest amount, and the aforementioned fee amount. The business support device according to claim 3, characterized by the following:

5. A business support method in a business support device that supports the payment reconciliation of installment payments received when the price of a commercial transaction is divided into predetermined installment payments and repaid on predetermined repayment dates, The calculation unit performs a calculation step in which, if the installment payment is made after the repayment due date, it calculates the billed amount, which is the amount obtained by adding a predetermined late payment penalty to the installment payment that was scheduled to be paid on the repayment due date, and the shortfall, which is the difference obtained by subtracting the installment payment received after the repayment due date from the billed amount. A determination step in which a determination unit determines whether all of the following conditions are met: a first condition whether the deficit amount is greater than 0 yen; a second condition whether the deficit amount is less than or equal to the late payment penalty; and a third condition whether the deficit amount is less than or equal to a predetermined threshold amount that serves as a criterion for determining whether or not to execute a processing method that includes at least a waiver process for forfeiting the deficit amount and a carry-over process for adding the deficit amount to the next installment payment amount to be billed; If the determination step determines that all of the first, second, and third conditions are met, the payment reconciliation target data generation unit generates payment reconciliation target data that has undergone the abandonment process and the carry-over process, which are predetermined and stored in the storage unit, in a payment reconciliation target data generation step. A business support method that has the following characteristics.

6. A business support program that enables the operation of a computer in a business support device that assists in the payment reconciliation process of installment payments received when the price of a commercial transaction is divided into predetermined installment payments and repaid on predetermined repayment dates, The aforementioned computer, A calculation unit that calculates the invoice amount, which is the amount obtained by adding a predetermined late payment penalty to the installment payment amount scheduled to be paid on the repayment due date, and the deficit amount, which is the difference obtained by subtracting the installment payment amount received after the repayment due date from the invoice amount, when the installment payment amount is paid after the repayment due date. A determination unit that determines whether all of the following conditions are met: a first condition whether the deficit is greater than 0 yen; a second condition whether the deficit is less than or equal to the late payment penalty; and a third condition whether the deficit is less than or equal to a predetermined threshold amount that serves as a criterion for determining whether or not to execute a processing method that includes at least a waiver process for forfeiting the deficit and a carry-over process for adding the deficit to the next installment payment scheduled for billing; If the discrimination unit determines that all of the first, second, and third conditions are met, the payment reconciliation target data generation unit generates payment reconciliation target data that has undergone the processing of the abandonment processing and the carry-over processing, which are predetermined and stored in the storage unit. A business support program designed to function as such.

Images