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

The debt management device addresses the issue of processing unapproved applications by displaying a warning image, enhancing operational efficiency through accurate approval status checks.

JP7869272B2Active Publication Date: 2026-06-02OBIC CO LTD

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
OBIC CO LTD
Filing Date
2024-08-20
Publication Date
2026-06-02

AI Technical Summary

Technical Problem

Existing claim management systems risk processing applications in an unapproved state, leading to confusion and unnecessary confirmation work, reducing operational efficiency.

Method used

A debt management device and method that includes a control unit to display a warning image on a management screen if an application is unapproved, using application and contract data associated with an approval flag to prevent processing until approval is confirmed.

Benefits of technology

Reduces the risk of processing unapproved applications, improving operational efficiency by preventing unnecessary tasks and ensuring accurate approval status checks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007869272000001
    Figure 0007869272000001
  • Figure 0007869272000002
    Figure 0007869272000002
  • Figure 0007869272000003
    Figure 0007869272000003
Patent Text Reader

Abstract

This reduces the risk of processing receivables management without an application being approved, thereby improving operational efficiency. [Solution] A claims management device comprising a control unit that executes application processing for a workflow related to claims management, and a display unit, which is capable of accessing application data registered in the application processing and claims management contract data, the application data being associated with information including an application ID that identifies the application, a contract ID that identifies the claims management contract, and an approval flag that indicates the approval status of the application, and the contract data being associated with information including the contract ID and the name of the contract subject, the control unit displays a claims management management screen on the display unit, and when processing based on the management screen is executed, acquires the application data and determines whether the application is in an unapproved state based on the approval flag in the application data, and if it is determined that the application is in an unapproved state, displays a warning image on the management screen indicating that the application is unapproved, associated with the contract data.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

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

Background Art

[0002] Conventionally, when a request for approval is made in a workflow, a request for approval confirmation device that displays a message on a monitor is known (see, for example, Patent Document 1). In this request for approval confirmation device, the application content and the approval status such as approved or unapproved are stored in association with each other. When the request for approval confirmation device is inputting expenses in the request for approval in the workflow, if the request for approval is unapproved, a warning is displayed on the monitor.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] There are cases where processing related to claim management, such as issuing a demand notice or issuing a repayment schedule, is performed while the application in the workflow is in an unapproved state. When processing related to claim management is performed while the application is in an unapproved state, it may cause confusion in the claim management business or unnecessary confirmation work related to the application may occur. For example, if a demand notice is issued while the registration content of offsetting a payment is unapproved, the demand notice may be issued even though the payment has been made. In order to reduce the issuance of demand notices, it is necessary to check the approval status of the application on a separate screen, which lowers the work efficiency.

[0005] The present invention has been made in view of the above problems, and aims to provide a debt management device, a debt management method, and a debt management program that can reduce the risk of debt management processing being carried out while an application is not yet approved, and improve operational efficiency. [Means for solving the problem]

[0006] To solve the above-mentioned problems and achieve the objective, the debt management device according to the present invention is a debt management device comprising a control unit that executes application processing for a debt management workflow and a display unit, wherein it is able to access application data, which is data registered in the application processing, and contract data, which is data relating to the debt management contract, wherein the application data is associated with information including an application ID that identifies the application, a contract ID that identifies the debt management contract, and an approval flag that indicates the approval status of the application, and the contract data is associated with information including the contract ID and the name of the contract subject, wherein the control unit displays the debt management management screen on the display unit, and when processing based on the management screen is executed, it acquires the application data, determines whether the application is in an unapproved state based on the approval flag of the application data, and if it determines that the application is in an unapproved state, it displays a warning image indicating that the application is unapproved on the management screen, associated with the contract data.

[0007] Furthermore, in the debt management device according to the present invention, a plurality of management screens are provided, and it is possible to access a screen type master, which is information about the type of management screen, and a check master, which is information about the transaction details to be checked. The screen type master is associated with information including a screen type ID that identifies the type of management screen and the name of the management screen, and the check master is associated with information including the screen type ID and a transaction details code, which is a code that identifies the transaction details. The application data further includes the transaction details code information, and the control unit may identify the type of management screen displayed on the display unit based on the screen type master, acquire the transaction details corresponding to the identified type of management screen based on the check master, and determine the approval status of the application corresponding to the acquired transaction details based on the application data.

[0008] Furthermore, in the debt management device according to the present invention, the management screen may include a screen relating to the processing of issuing dunning notices and a screen relating to the processing of issuing repayment schedules.

[0009] Furthermore, the debt management method according to the present invention is a debt management method that executes an application process for a debt management workflow, and uses application data, which is data registered in the application process, and contract data, which is data relating to the debt management contract, wherein the application data is associated with information including an application ID that identifies the application, a contract ID that identifies the debt management contract, and an approval flag that indicates the approval status of the application, and the contract data is associated with information including the contract ID and the name of the contract subject, and the debt management device equipped with a control unit displays the debt management management screen on a display unit, and when executing a process based on the management screen, it acquires the application data, determines whether the application is in an unapproved state based on the approval flag of the application data, and if it is determined that the application is in an unapproved state, it displays a warning image indicating that the application is unapproved on the management screen, associated with the contract data.

[0010] Furthermore, the debt management program according to the present invention is a debt management program that causes a debt management device equipped with a control unit to execute a debt management method that executes an application processing of a workflow related to debt management, wherein the application processing uses application data which is data registered in the application and contract data which is data related to the debt management contract, the application data is associated with information including an application ID that identifies the application, a contract ID that identifies the debt management contract and an approval flag that indicates the approval status of the application, the contract data is associated with information including the contract ID and the name of the contract subject, the debt management device is caused to display the debt management management screen on a display unit, and when processing based on the management screen is executed, it retrieves the application data, determines whether the application is in an unapproved state based on the approval flag of the application data, and if it is determined that the application is in an unapproved state, it displays a warning image indicating that the application is unapproved on the management screen, associated with the contract data. [Effects of the Invention]

[0011] This invention reduces the risk of debt management processing being carried out while applications are still unapproved, thereby improving operational efficiency. [Brief explanation of the drawing]

[0012] [Figure 1] Figure 1 shows an example of the configuration of a debt management system. [Figure 2] Figure 2 shows an example of a screen type master. [Figure 3] Figure 3 shows an example of a check master. [Figure 4] Figure 4 shows an example of application data. [Figure 5] Figure 5 shows an example of contract data. [Figure 6] Figure 6 shows an example of a workflow application. [Figure 7] Figure 7 shows an example of the process for issuing a demand letter. [Figure 8]FIG. 8 is a diagram showing an example of the process of issuing a repayment schedule. [Figure 9] FIG. 9 is a flowchart showing an example of the claim management process. MODE FOR CARRYING OUT THE INVENTION

[0013] Hereinafter, embodiments of the claim management apparatus, the claim management method, and the claim management program according to the present invention will be described in detail based on the drawings. Note that the present invention is not limited to the present embodiment.

[0014] [1. Configuration] An example of the configuration of the claim management apparatus 100 according to the present embodiment will be described with reference to FIG. 1 and the like. FIG. 1 is a diagram showing an example of the configuration of the claim management apparatus.

[0015] The claim management apparatus 100 is an apparatus that executes processes related to claim management. Specifically, the claim management apparatus 100 executes, for example, an application process for a workflow related to claim management, an issuance process for a demand notice, or an issuance process for a repayment schedule.

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

[0017] The claim management apparatus 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each unit included in the claim management apparatus 100 is communicably connected via an arbitrary communication path.

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

[0019] An input device 112 and an output device 114 are connected to the input / output interface unit 108. As the output device 114, in addition to a monitor (including a home television), a speaker or a printer can be used. As the input device 112, in addition to a keyboard, a mouse, and a microphone, a monitor that cooperates with the mouse to realize a pointing device function can be used. In the following, the output device 114 may be described as the monitor (display unit) 114, and the input device 112 may be described as the keyboard 112 or the mouse 112.

[0020] Various databases, tables, files, etc. are stored in the storage unit 106. A computer program for giving commands to the CPU (Central Processing Unit) to perform various processes in cooperation with the OS (Operating System) is recorded in the storage unit 106. As the storage unit 106, for example, a memory device such as a RAM (Random Access Memory)·ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, and an optical disk can be used.

[0021] The storage unit 106 stores various master data and various other data. Specifically, the storage unit 106 stores screen type master data 121, check master data 122, application data 123, and contract data, etc. The various master data and various other data will be described below. Note that if there are duplicate items in the various master data and various other data, the explanation for the duplicate items will be partially omitted.

[0022] Figure 2 shows an example of a screen type master. The screen type master 121 is data used to identify the type of management screen related to debt management that is displayed on the display unit 114. Examples of management screens include screens related to the processing of issuing dunning notices and screens related to the processing of issuing repayment schedules, but it is not limited to these screens, and any screen related to debt management may be used. As shown in Figure 2, the screen type master 121 includes items for screen type ID and screen type name, and these items are associated with each other. The screen type ID is a number used to identify the type of management screen. The screen type name is the name of the management screen.

[0023] Figure 3 shows an example of a check master. Check master 122 contains data on transaction details to be checked according to the type of management screen. Check master 122 includes fields for screen type ID and transaction details code, and these fields are associated with each other. The screen type ID is the same as that of screen type master 121. The transaction details code is a code used to identify the transaction details. The name of the transaction details is also included with the transaction details code.

[0024] Figure 4 shows an example of application data. Application data 123 is data registered in the workflow application process. Application data 123 is generated in the workflow application described later. Application data 123 includes the fields Application ID, Transaction Content Code, Contract ID, and Approval Status, and these fields are associated with each other. The Transaction Content Code is the same as that of Check Master 122. The Application ID is a number used to identify the application. The Contract ID is a number used to identify the contract. The Approval Status is an approval flag that determines whether the application has been approved or not. When the approval flag is "0", the application is not approved, and when the approval flag is "1", it is approved. Note that the approval status will also show either the not approved or approved status.

[0025] Figure 5 shows an example of contract data. Contract data 124 is data related to a debt management contract. Contract data 124 includes the fields Contract ID and Contractor Name, and these fields are associated with each other. The Contract ID is the same as that of Application Data 123. The Contractor Name is the name of the contractor.

[0026] Next, referring again to Figure 1, the control unit 102 will be described. The control unit 102 is a CPU, etc., that comprehensively controls the debt management device 100. The control unit 102 has an internal memory for storing control programs such as the OS, programs that define various processing procedures, required data, etc., and executes various information processing based on these stored programs.

[0027] The control unit 102 performs information processing, specifically, credit management processing, based on the various master data and other data stored in the storage unit 106.

[0028] The following section, [2. Specific Examples of Processing], will provide a detailed explanation of specific examples of processing performed by the control unit 102.

[0029] [2. Specific examples of processing] Here, specific examples of processes performed by the debt management device 100 will be explained with reference to Figures 6 to 9. Figure 6 is a diagram showing an example of a workflow application. Figure 7 is a diagram showing an example of the process for issuing a dunning letter. Figure 8 is a diagram showing an example of the process for issuing a repayment schedule. Figure 9 is a flowchart showing an example of a debt management process.

[0030] As shown in Figure 6, in the workflow application process, the debt management device 100 generates application data 123 after inputting information based on a predetermined input screen and then registering it. Specifically, in Figure 6, the workflow applications are, for example, applications for payment reconciliation, applications for early repayment, and applications for partial prepayment, in that order.

[0031] When the accounts receivable management device 100 executes an application for processing related to payment reconciliation, it displays a payment reconciliation input screen on the display unit 114. The payment reconciliation input screen includes fields for entering the temporary receipt ID, the amount of the temporary receipt, the contract ID, and the reconciliation amount. The temporary receipt ID is a number used to identify the temporary receipt. When each item is entered via the input device 112 on the payment reconciliation input screen and the registration button on the screen is operated, the control unit 102 of the accounts receivable management device 100 generates application data 123 based on each entered item. For example, the generated application data 123 may have an application ID of "1", a transaction content code of "100: payment reconciliation", a contract ID of "10001", and an approval status of "0: not approved", with these elements associated together.

[0032] Next, when the debt management device 100 executes an application for processing related to early repayment, it displays an early repayment input screen on the display unit 114. The early repayment input screen includes fields for entering the contract ID and a field for entering the early repayment date. When each item is entered via the input device 112 on the early repayment input screen and the registration button on the screen is operated, the control unit 102 of the debt management device 100 generates application data 123 based on each entered item. In this case, the generated application data 123 is added to the application data 123 generated in the payment reconciliation application processing. For example, the generated application data 123 may have an application ID of "2", a transaction content code of "200: Early Repayment", a contract ID of "10002", and an approval status of "0: Unapproved", with these associated data.

[0033] After this, when the debt management device 100 executes an application for processing related to partial prepayment, it displays the partial prepayment input screen on the display unit 114. The partial prepayment input screen includes fields for entering the contract ID, entering the prepayment date, and entering the amount of the prepayment. When each item is entered via the input device 112 on the partial prepayment input screen and the registration button on the screen is operated, the control unit 102 of the debt management device 100 generates application data 123 based on each entered item. In this case, the generated application data 123 is added to the application data 123 generated in the application processing for payment reconciliation and early full repayment. For example, the generated application data 123 may have an application ID of "3", a transaction content code of "300: Partial Prepayment", a contract ID of "10003", and an approval status of "0: Unapproved", with these associated data.

[0034] In this way, the debt management device 100 generates application data 123 as shown in Figure 4 by executing the application process for the debt management workflow.

[0035] Next, referring to Figures 7 and 8, the processing based on the management screen will be described. When the debt management device 100 executes the process of issuing a demand letter as shown in Figure 7, for example, it displays the demand letter issuance screen as the management screen. The demand letter issuance screen includes input fields for entering predetermined extraction conditions and display fields for displaying contract data. The control unit 102 of the debt management device 100 extracts contract data 124 using the input fields of the demand letter issuance screen as extraction conditions, and displays the extracted contract data 124 in the display fields of the demand letter issuance screen. Then, when the execution button on the screen is operated, the control unit 102 of the debt management device 100 displays a warning image on the demand letter issuance screen if there is contract data 124 for which the application has not been approved. The warning image includes a display indicating that there is a contract for which the application has not been approved, and a display of the contract ID and transaction content code of the corresponding contract data 124.

[0036] When the debt management device 100 executes the repayment schedule issuance process shown in Figure 8, for example, it displays the repayment schedule issuance screen as a management screen. The repayment schedule issuance screen includes input fields for entering predetermined extraction conditions and display fields for displaying contract data. The control unit 102 of the debt management device 100 extracts contract data 124 using the input fields on the repayment schedule issuance screen as extraction conditions, and displays the extracted contract data 124 in the display fields of the repayment schedule issuance screen. When the execution button on the screen is operated, the control unit 102 of the debt management device 100 displays a warning image on the repayment schedule issuance screen if there is contract data 124 for which the application has not been approved. The warning image includes a display indicating that there is a contract for which the application has not been approved, and a display of the contract ID and transaction content code of the corresponding contract data 124.

[0037] Next, with reference to Figure 9, an example of processing based on the management screens shown in Figures 7 and 8 will be explained. When the control unit 102 of the debt management device 100 displays the management screen on the display unit 114, it acquires the contract data 124 and the check master 122 (step S1). Subsequently, the control unit 102 determines whether or not there are any details (contract IDs of contract data 124) to be processed (step S2). Specifically, in step S2, the control unit 102 acquires the contract IDs of the contract data 124 that match the extraction conditions entered on the management screen and makes them the items to be processed. For example, using the contract data 124 shown in Figures 7 and 8, the contract IDs to be processed are "10001", "10002", and "10003".

[0038] If the control unit 102 determines that there is a contract ID to be processed (Step S2: Yes), it determines whether there is a transaction content code corresponding to the management screen based on the acquired check master 122 (Step S3). In Step S3, for example, if the management screen is the repayment schedule issuance screen, the control unit 102 determines that the transaction content codes in the check master 122 are "200: Early repayment" and "300: Partial prepayment" (Step S3: Yes).

[0039] If the control unit 102 determines that there is a transaction content code, it determines, based on the application data 123, whether there is an application data 123 with a transaction content code corresponding to the contract ID and an approval status of "unapproved" (step S4). If the control unit 102 determines in step S4 that there is an application data 123 (step S4: Yes), it obtains the corresponding application data 123 (step S5). In step S5, for example, if the management screen is the repayment schedule issuance screen, the control unit 102 obtains application IDs "2" and "3" whose transaction content codes are "200: Early repayment" and "300: Partial advance payment" and whose approval status is "0: Unapproved". Also, in step S5, the control unit 102 counts the number of obtained application IDs as the number of obtained items.

[0040] After step S5 is executed, the control unit 102 adds the contract ID and transaction details code displayed in the warning image as message details (step S6). After step S6 is executed, the control unit 102 marks the contract ID to be processed as processed and proceeds to step S2 again. The control unit 1023 repeatedly executes steps S2 to S7 until there are no more contract IDs to be processed. Through the processing from step S2 to step S7, the control unit 102 can determine the approval status of the application for six combination patterns, for example, if the management screen is the repayment schedule issuance screen, by multiplying the three contract IDs by the two transaction details codes.

[0041] Furthermore, if the control unit 102 determines in step S3 that there is no transaction content code (step S3: No), and if it determines in step S4 that there is no application data 123 (step S4: No), it proceeds to step S7.

[0042] In step S2, if the control unit 102 determines that there are no contract IDs to be processed (step S2: No), it determines whether the number of application IDs obtained in the application data 123 is 1 or more (step S8). If the control unit 102 determines that the number of obtained items is 1 or more (step S8: Yes), it displays a warning image on the management screen along with the message details (step S9) and terminates the processing based on the management screen. On the other hand, if the control unit 102 determines that the number of obtained items is not 1 or more (step S8: No), it terminates the processing based on the management screen without displaying a warning image.

[0043] As described above, this embodiment allows a warning image to be displayed on the management screen if a workflow application is not approved. Therefore, by displaying a warning image, the risk of debt management processing being carried out while the application is still unapproved can be reduced. In addition, unnecessary tasks such as checking the approval status of applications can be reduced, thereby improving operational efficiency.

[0044] Furthermore, according to this embodiment, the approval status of an application can be determined according to the type of management screen and the transaction content, so it is possible to select transactions that require checking and determine the approval status of the application.

[0045] Furthermore, according to this embodiment, the management screen can be applied to the screen related to the processing of issuing dunning notices (due diligence notice issuance screen) and the screen related to the processing of issuing repayment schedules (repayment schedule issuance screen), so warning images can be displayed on these screens.

[0046] [3. Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This embodiment can contribute to improving operational efficiency and promoting appropriate management decisions within companies, thereby enabling contributions to SDGs Goals 8 and 9.

[0047] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and digital processes, thereby contributing to SDGs Goals 12, 13, and 15.

[0048] Furthermore, this embodiment can contribute to strengthening control and governance, thereby enabling contributions to SDG Goal 16.

[0049] [4. Other Embodiments] In addition to the embodiments described above, the present invention may be implemented in various different embodiments within the scope of the technical idea described in the claims.

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

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

[0052] Furthermore, with respect to the debt management device 100, each component shown in the diagram is a functional concept and does not necessarily need to be physically configured as shown.

[0053] For example, the processing functions of the debt management device 100, particularly those performed in the control unit, may be implemented in whole or in part by a CPU and a program interpreted and executed by the CPU, or they may be implemented as wired logic hardware. The program is recorded on a non-temporary computer-readable recording medium containing programmed instructions for the information processing device to execute the processing described in this embodiment, and is mechanically read by the debt management device 100 as needed. That is, a storage unit such as ROM or HDD (Hard Disk Drive) contains a computer program that works in cooperation with the OS to give instructions to the CPU and perform various processing tasks. This computer program is executed by being loaded into RAM and works in cooperation with the CPU to constitute the control unit.

[0054] Furthermore, this computer program may be stored on an application program server connected to the debt management device 100 via any network, and it is possible to download all or part of it as needed.

[0055] Furthermore, the program for executing the processing described in this embodiment may be stored on a non-temporary computer-readable recording medium, or it may be configured as a program product. Here, "recording medium" includes any "portable physical 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.

[0056] Furthermore, "program" refers to a data processing method described in any language or writing method, regardless of its format, such as source code or binary code. Note that "program" is not necessarily limited to a single, monolithic structure; it also includes distributed structures consisting of multiple modules or libraries, and those that work in cooperation with other programs, such as an operating system, to achieve their functions. Regarding the specific configuration and reading procedures for reading the recording medium in each device shown in the embodiments, as well as the installation procedures after reading, well-known configurations and procedures can be used.

[0057] The various databases stored in the memory unit are storage means such as RAM, ROM, other memory devices, hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and website provision.

[0058] Furthermore, the debt management device 100 may be configured as a known personal computer or workstation or other information processing device, or as an information processing device to which any peripheral devices are connected. Alternatively, the debt management device 100 may be implemented by installing software (including programs or data, etc.) on the device that enables the processing described in this embodiment.

[0059] 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 and integrating them in any unit according to various additions or functional loads. In other words, the embodiments described above may be implemented in any combination, or the embodiments may be implemented selectively. [Industrial applicability]

[0060] This invention is useful in the debt management industry. [Explanation of symbols]

[0061] 100 Debt Management System 102 Control Unit 104 Communication Interface Section 106 Storage section 108 Input / Output Interface Section 112 Input device 114 Output device (display section) 121 Screen Type Master 122 Check Master 123 Application Data 124 Contract Data 200 servers 300 Networks

Claims

1. A debt management device comprising a control unit that executes application processing for a debt management workflow and a display unit, In the aforementioned application process, it is possible to access application data, which is the data registered in the application, and contract data, which is the data relating to the debt management contract. The aforementioned application data is associated with information including an application ID that identifies the application, a contract ID that identifies the debt management contract, and an approval flag that indicates the approval status of the application. The aforementioned contract data is associated with information including the contract ID and the name of the contracted item. The control unit, The debt management screen is displayed on the display unit. When executing the process based on the aforementioned management screen, the application data is acquired, Based on the approval flag in the application data, it is determined whether the application is in an unapproved state. If the system determines that an application is in an unapproved state, it displays a warning image indicating that the application is unapproved on the management screen, in association with the contract data.

2. Multiple management screens are available. It is also possible to access the screen type master, which contains information about the types of the aforementioned management screens, and the check master, which contains information about the transaction details to be checked. The aforementioned screen type master has information associated with it, including a screen type ID that identifies the type of the management screen and the name of the management screen. The aforementioned check master has information associated with the screen type ID and the transaction content code, which is a code that identifies the transaction content. The aforementioned application data further includes the information of the transaction details code, The control unit, Based on the aforementioned screen type master, the type of the management screen displayed on the display unit is identified. Based on the aforementioned check master, the transaction details corresponding to the identified type of management screen are obtained. The debt management device according to claim 1, which determines the approval status of an application corresponding to the acquired transaction details based on the aforementioned application data.

3. The debt management device according to claim 2, wherein the management screen includes a screen for processing the issuance of dunning notices and a screen for processing the issuance of repayment schedules.

4. A debt management method that executes application processing for a debt management workflow, In the aforementioned application process, application data, which is the data registered in the application, and contract data, which is the data relating to the debt management contract, are used. The aforementioned application data is associated with information including an application ID that identifies the application, a contract ID that identifies the debt management contract, and an approval flag that indicates the approval status of the application. The aforementioned contract data is associated with information including the contract ID and the name of the contracted item. The aforementioned debt management screen is displayed on the display unit. When executing the process based on the aforementioned management screen, the application data is acquired, Based on the approval flag in the application data, it is determined whether the application is in an unapproved state. A debt management method in which a debt management device equipped with a control unit performs the following actions: if it determines that an application is in an unapproved state, it displays a warning image indicating that the application is unapproved on the management screen, in association with the contract data.

5. A debt management program for causing a debt management device equipped with a control unit to execute a debt management method that performs application processing for a workflow related to debt management, In the aforementioned application process, application data, which is the data registered in the application, and contract data, which is the data relating to the debt management contract, are used. The aforementioned application data is associated with information including an application ID that identifies the application, a contract ID that identifies the debt management contract, and an approval flag that indicates the approval status of the application. The aforementioned contract data is associated with information including the contract ID and the name of the contracted item. The aforementioned debt management screen is displayed on the display unit. When executing the process based on the aforementioned management screen, the application data is acquired, Based on the approval flag in the application data, it is determined whether the application is in an unapproved state. A debt management program that causes the debt management device to display a warning image indicating that an application is unapproved on the management screen, in association with the contract data, if it determines that the application is in an unapproved state.