Credit and Debt Management Device, Credit and Debt Management Method, and Credit and Debt Management Program

Abstract

To provide a debt and credit management device, debt and credit management method, and debt and credit management program which can reduce the work, prevent input errors and prevent incorrect cancel processing.SOLUTION: A debt and credit management device extracts corresponding data according to the payment planned date entered from the outside from each of payment plan data and cancel application data, compares the amount to be paid with the cancel amount for each payee on the basis of the corresponding data, and generates cancel result data in which the payee, payment planned date, billing destination, amount to be paid, cancel amount and balanced payment amount for each combination code on the basis of the comparison result.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an apparatus, a method, and a program for managing claims and obligations. [Background technology]

[0002] Patent Document 1 discloses a technology for efficient settlement using a distributed ledger and a platform system that can verify the validity of debt record information. This technology performs netting using payment information obtained from each financial institution's server to offset credits and debts to the same financial institution, calculate the amount of payment or remittance by the financial institution, and then stores the calculation result in the distributed ledger. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2020-67805 Summary of the Invention [Problem to be solved by the invention]

[0004] However, when offsetting accounts receivable and payable at trading companies, the accounting department, etc., cannot grasp the actual state of the offset, so they have to check with the sales department, etc. on-site each time, which is time-consuming. In this case, the accounting department has to manually process the offset based on the actual state of the offset confirmed by the sales department, etc., and also has to determine whether the content of the offsetting is correct, which creates the problem of requiring a huge amount of time and confirmation work.

[0005] The present invention has been made in consideration of the above, and aims to provide an asset / debt management device, asset / debt management method, and asset / debt management program that can reduce work, prevent input errors, and prevent incorrect offsetting processing. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems and achieve the objectives, the receivables and payables management device of the present invention is a receivables and payables management device equipped with a control unit, which is capable of accessing payment schedule data which associates, for each document number, payment category, transaction category, payment method, scheduled payment date, payment establishment, payment department, payee, scheduled payment amount, and payment notice number, and offset application data which associates, for each offset application number, the scheduled payment date, payee, receivable establishment, receivable department, receivable item, invoice, offset amount, and offset consumption tax amount, and the control unit is characterized by comprising: an extraction unit which extracts relevant data corresponding to the scheduled payment date input from outside from each of the payment schedule data and the offset application data; a comparison unit which compares the scheduled payment amount and the offset amount for each payee based on the relevant data; and a generation unit which generates offset result data which associates, for each combination code, the payee, scheduled payment date, invoice, scheduled payment amount, offset amount, and net payment amount based on the comparison results of the comparison unit.

[0007] In addition, the receivables and payables management method of the present invention is a receivables and payables management method executed by a receivables and payables management device equipped with a control unit, wherein the receivables and payables management device is capable of accessing payment schedule data in which, for each document number, payment category, transaction category, payment method, scheduled payment date, payment establishment, payment department, payee, scheduled payment amount, and payment notice number are associated, and offset application data in which, for each offset application number, the scheduled payment date, payee, receivables establishment, receivables department, receivables item, invoice, offset amount, and offset consumption tax amount are associated, and is characterized by including the following steps executed by the control unit: an extraction step of extracting relevant data corresponding to the scheduled payment date input from outside from each of the payment schedule data and the offset application data; a comparison step of comparing the scheduled payment amount and the offset amount for each payee based on the relevant data; and a generation step of generating offset result data in which, for each combination code, the payee, scheduled payment date, invoice, scheduled payment amount, offset amount, and net payment amount are associated, based on the comparison result of the comparison step.

[0008] In addition, the receivables and payables management program of the present invention is a receivables and payables management program to be executed by a receivables and payables management device equipped with a control unit, and the receivables and payables management device is capable of accessing payment schedule data in which, for each document number, payment category, transaction category, payment method, scheduled payment date, payment establishment, payment department, payee, scheduled payment amount, and payment notice number are associated, and for each offset application number, offset application data in which, for each offset application number, scheduled payment date, payee, receivables establishment, receivables department, receivables item, invoice, offset amount, and offset consumption tax amount are associated, and is characterized by including: an extraction step for extracting relevant data corresponding to the scheduled payment date input from outside from each of the payment schedule data and the offset application data, to be executed by the control unit; a comparison step for comparing the scheduled payment amount and the offset amount for each payee based on the relevant data; and a generation step for generating offset result data in which, for each combination code, payee, scheduled payment date, invoice, scheduled payment amount, offset amount, and net payment amount are associated, based on the comparison results of the comparison step. [Effects of the Invention]

[0009] According to the present invention, it is possible to reduce the workload, prevent input errors, and prevent erroneous offset processing. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a schematic diagram showing an overview in a block diagram of an example of the configuration of a credit and debt management device according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of a set-off counterpart setting master table in the set-off counterpart setting master of the credit and debt management apparatus according to the embodiment. [Figure 3] FIG. 3 is a diagram showing an example of a journal entry definition master table in the journal entry definition master of the receivables and payables management device according to the embodiment. [Figure 4] FIG. 4 is a flowchart showing an outline of the processing executed by the credit and debt management device according to the embodiment. [Figure 5]FIG. 5 is a diagram showing an example of a payment schedule data table in the payment schedule data of the credit and debt management apparatus according to the embodiment. [Figure 6] FIG. 6 is a diagram showing an example of a scheduled billing data table in the scheduled billing data of the credit and debt management device according to the embodiment. [Figure 7] FIG. 7 is a diagram showing an example of an offset application data table in the offset application data of the credit and debt management apparatus according to the embodiment. [Figure 8] FIG. 8 is a diagram showing an example of an offset application input screen displayed on the monitor of the credit and debt management apparatus according to the embodiment. [Figure 9] FIG. 9 is a diagram showing an example of an offset application data table in the offset application data inputted and accepted by the offset application input unit of the credit and debt management apparatus according to the embodiment. [Figure 10] FIG. 10 is a diagram showing an example of an offset application data import screen displayed on the monitor of the credit and debt management device according to the embodiment. [Figure 11] FIG. 11 is a diagram showing an example of a payment schedule data table in payment schedule data extracted by the payment schedule date by the extraction unit of the credit and debt management apparatus according to the embodiment. [Figure 12] FIG. 12 is a diagram showing an example of an offset application data table in the offset application data extracted by the scheduled payment date by the extraction unit of the credit and debt management apparatus according to the embodiment. [Figure 13] FIG. 13 is a diagram showing an example of a comparison result data table obtained by the comparison unit of the credit and debt management apparatus according to the embodiment. [Figure 14] FIG. 14 is a diagram showing an outline of offsetting processing between our company and business partner A. [Figure 15] FIG. 15 is a diagram showing an outline of the offsetting process results between our company and business partner A. [Figure 16] FIG. 16 is a diagram showing an outline of the offset process between the company, payee B, and invoiceee X. [Figure 17] FIG. 17 is a diagram showing an outline of the offsetting process results between the company and payee B, and the company and invoice recipient X. [Figure 18] FIG. 18 is a diagram showing an outline of correlation processing between the company and payee C, and between the company and invoice recipient Y. [Figure 19] FIG. 19 is a diagram showing an outline of the correlation processing results between the company and payee C, and between the company and invoice recipient Y. [Figure 20] FIG. 20 is a diagram showing an example of a deposit data table of deposit data generated by the generation unit of the credit and debt management apparatus according to the embodiment. [Figure 21] FIG. 21 is a diagram showing an example of a payment schedule data table of payment schedule data generated by the generation unit of the credit and debt management apparatus according to the embodiment. [Figure 22] FIG. 22 is a diagram showing an example of a deposit data table of deposit data generated by the generation unit of the credit and debt management apparatus according to the embodiment. [Figure 23] FIG. 23 is a diagram showing an example of a payment schedule data table of payment schedule data generated by the generation unit of the credit and debt management apparatus according to the embodiment. [Figure 24] FIG. 24 is a diagram showing an example of the offset result displayed on the monitor of the credit and debt management apparatus according to the embodiment. [Figure 25] FIG. 25 is a diagram showing an example of a journal data table on the credit side. [Figure 26] FIG. 26 is a diagram showing an example of a debt-side journal data table. [Figure 27] FIG. 27 is a diagram showing an example of a journal data table that has already been created by inputting purchases on the debtor side. [Figure 28] FIG. 28 is a diagram showing an example of a journal data table on the credit side. [Figure 29] FIG. 29 is a diagram showing an example of a journal data table that has already been created by inputting purchases on the creditor side. [Figure 30] FIG. 30 is a diagram showing an example of a debt-side journal data table. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments of an apparatus, a method, and a program for managing credits and debts according to the present invention will be described in detail with reference to the accompanying drawings. However, the present invention is not limited to these embodiments.

[0012] [1. Configuration] An example of the configuration of a receivables and payables management device according to this embodiment will be described with reference to Fig. 1 etc. Fig. 1 is a schematic diagram showing an overview in a block diagram of an example of the configuration of a receivables and payables management device.

[0013] The receivables and payables management device 100 shown in Fig. 1 is a commercially available desktop personal computer. Note that the receivables and payables management device 100 is not limited to a stationary information processing device such as a desktop personal computer, but may also be a portable information processing device such as a commercially available notebook personal computer, PDA (Personal Digital Assistant), smartphone, or tablet personal computer.

[0014] The receivables and payables management device 100 comprises a control unit 102, a communication interface unit 104, a memory unit 106, and an input / output interface unit 108. The units comprised in the receivables and payables management device 100 are connected to each other so as to be able to communicate with each other via any communication path.

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

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

[0017] The memory unit 106 stores various databases, tables, files, etc. The memory unit 106 stores computer programs that cooperate with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes. The memory unit 106 can be, for example, a memory device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, or an optical disk. The memory unit 106 stores an offsetting counterparty setting master 106a, a journal entry definition master 106b, scheduled payment data 106c, scheduled billing data 106d, and offsetting application data 106e.

[0018] The offsetting counterparty setting master 106a stores a payee and a billing destination in association with each combination CD (code).

[0019] 2 is a diagram showing an example of the offsetting counterparty setting master table in the offsetting counterparty setting master 106a. As shown in the first row of the offsetting counterparty setting master table T1 shown in Fig. 2, the payee "Customer A" and the invoice destination "Customer A" are stored in association with each other for the combination CD "1001."

[0020] The journal entry definition master 106b stores data, transaction classification, debit and credit in association with each other for each definition number.

[0021] 3 is a diagram showing an example of a journal entry definition master table in the journal entry definition master 106b. As shown in the first row of the journal entry definition master table T2 shown in Fig. 3, the definition number "1" is stored in association with the data "Deposit data", the transaction classification "Offset", the debit side "Offset suspense account", and the credit side "Accounts receivable".

[0022] The details of the payment schedule data 106c, the billing schedule data 106d, and the offset application data 106e will be described later.

[0023] Returning to FIG. 1, the description of the configuration of the claims and debts management apparatus 100 will continue. The control unit 102 is a CPU or the like that comprehensively controls the receivables and payables management device 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, required data, etc., and executes various information processing based on these stored programs. The control unit 102 includes a purchases input unit 102a, a sales input unit 102b, an offset content creation processing unit 102c, an offset application input unit 102d, an offset application data import unit 102e, an extraction unit 102f, a comparison unit 102g, a generation unit 102h, a display control unit 102i, and a journal data creation processing unit 102j.

[0024] The purchase input unit 102a executes a purchase input process for creating payment schedule data 106c in accordance with the operation content of the purchase input input entered via the input device 112 by a user in the field such as the sales department.

[0025] The sales input unit 102b executes a sales input process for creating scheduled billing data 106d in accordance with the operation content of sales input entered via the input device 112 by a user in the field such as a sales department.

[0026] The offset content creation processing unit 102c executes an offset content creation process for creating offset application data in accordance with the content of the offset application input via the input device 112 by a user in the field such as the sales department.

[0027] The offset application input unit 102d refers to the offset counterparty setting master 106a, displays on the monitor 114 an offset gaze input screen that allows the accounting department user to input offset payment information corresponding to the offset application data sent from the sales department via the input device 112 while looking at printed materials, and executes an offset application input process that accepts the input of offset application data.

[0028] The offset application data import unit 102e refers to the offset counterparty setting master 106a, displays an offset application data import screen on the monitor 114 so that the user of the accounting department can import the offset application data sent from the sales department via the input device 112, and executes an offset application data import process that specifies the import file.

[0029] The extraction unit 102f extracts the payment schedule data 106c and the offset application data 106e corresponding to the payment schedule date input via the input device 112 by the user of the accounting department from the payment schedule data 106c and the offset application data 106e.

[0030] The comparison unit 102g compares the amount to be paid with the amount to be offset (including the amount of offset consumption tax) for the payee extracted by the extraction unit 102f.

[0031] The generating unit 102h generates deposit data based on the comparison result of the magnitude comparison performed by the comparing unit 102g. Specifically, the generating unit 102h generates deposit data on the creditor side and payment schedule data on the debtor side.

[0032] The display control unit 102i executes a cancellation result confirmation output process for displaying the cancellation result on the monitor 114.

[0033] The journal data creation processing unit 102j executes a journal data creation process to create journal data resulting from offsetting processing based on the journal data of the deposit data and payment schedule data generated by the journal definition master 106b and the generation unit 102h.

[0034] [2. Processing performed by the receivables and payables management device] Next, there will be explained the processing executed by the credit and debt management apparatus 100. Fig. 4 is a flowchart showing an outline of the processing executed by the credit and debt management apparatus 100.

[0035] As shown in FIG. 4, first, the purchase input unit 102a executes a purchase input process to create payment schedule data 106c in accordance with the purchase input operation content input by a field user such as a sales department via the input device 112 (step S1).

[0036] Figure 5 is a diagram showing an example of a payment schedule data table in the payment schedule data 106c. The payment schedule data table T3 shown in Figure 5 stores a slip number in association with a row, payment category, transaction category, payment method, scheduled payment date, payment establishment, payment department, payee, scheduled payment amount, and payment notice number.

[0037] Specifically, the first row of the payment schedule data table T3 stores the document number "SIH0001" in association with row "1", payment category "Closing payment", transaction category "Purchase", payment method "Accounts receivable offset", scheduled payment date "2022 / 3 / 15", payment establishment "A01: Accounting Headquarters", payee "Customer A", scheduled payment amount "120,000", and payment notice number "A0LQ0111".

[0038] In the payment schedule data table T3 shown in Figure 5, a payment notification number is assigned to all data, but this is not limited to this, and a number is usually assigned to approved data, which becomes the target data for payment (including offset).

[0039] Returning to FIG. 4, the description of step S2 and subsequent steps will be continued. In step S2, the sales input unit 102b executes a sales input process to create scheduled billing data 106d in accordance with the operation details of the sales input entered via the input device 112 by a field user such as a sales department.

[0040] Fig. 6 is a diagram showing an example of a billing schedule data table in the billing schedule data 106d. In the billing schedule data table T4 shown in Fig. 6, the slip number is stored in association with the line, billing category, transaction category, collection method, scheduled collection date, deposit company, deposit department, billing destination, tax-excluded amount, and consumption tax amount.

[0041] Specifically, the first row of the billing schedule data table T4 shown in Figure 6 stores the document number "SEI0001" in association with row "1," billing category "billing," transaction category "billing accounting," collection method "bank transfer," scheduled collection date "3 / 31 / 2022," deposit company "B01: Utsunomiya Office," deposit department "B0100: Utsunomiya Section 1," billing destination "Customer A," amount excluding tax "100,000," and consumption tax amount "10,000."

[0042] Returning to FIG. 4, the description of step S3 and subsequent steps will be continued. In step S3, the offset content creation processing unit 102c executes an offset content creation process for creating offset application data in accordance with the content of the offset application input via the input device 112 by a user in the field such as the sales department.

[0043] Fig. 7 is a diagram showing an example of an offset application data table in the offset application data. The offset application data table T5 shown in Fig. 7 stores the expected payment date, the payee, the creditor business establishment, the creditor department, the creditor item, the billing destination, the offset amount, the offset consumption tax amount, and notes in association with each other.

[0044] Specifically, the first row of the offset application data table T5 shown in Figure 7 associates the expected payment date "2022 / 3 / 15" with the payee "Customer A," the creditor business office "Utsunomiya Sales Office," the creditor department "Utsunomiya Division 1," the creditor item "Accounts Receivable," the invoice recipient "Customer A," the offset amount "100,000," and the offset consumption tax amount "10,000." Similarly, the fourth row of the offset application data table T5 associates the expected payment date "2022 / 3 / 15" with the payee "Payee B," the creditor business office "Chugoku Branch," the creditor department "Hiroshima Division 1," the creditor item "Reward Received," the invoice recipient "Invoice X," the offset amount "3,000," the offset consumption tax amount "300," and the remark "Sale for China."

[0045] Returning to FIG. 4, the description of step S4 and subsequent steps will be continued. In step S4, the control unit 102 determines whether the operation content input by the accounting department user via the input device 112 is an offset application submitted from the field, such as the sales department. If the control unit 102 determines that the operation content input by the accounting department user via the input device 112 is an offset application submitted from the field, such as the sales department (step S4: Yes), the receivables and payables management device 100 proceeds to step S5. On the other hand, if the control unit 102 determines that the operation content input by the accounting department user via the input device 112 is not an offset application submitted from the field, such as the sales department (step S4: No), the receivables and payables management device 100 proceeds to step S6.

[0046] In step S5, the offset application input unit 102d refers to the offset counterparty setting master 106a, displays on the monitor 114 an offset gaze input screen that the accounting department user can use to input offset payment information corresponding to the offset application data sent from the sales department via the input device 112 while looking at printed materials, and executes an offset application input process to accept the input of offset application data.

[0047] Fig. 8 is a diagram showing an example of an offset application input screen displayed on the monitor 114. The offset application input screen P1 shown in Fig. 8 includes an input area B1 where a user of the accounting department inputs the details of the offset application via the input device 112, and a detail table B2 that reflects the input results.

[0048] As shown in Fig. 8, the offset application input unit 102d accepts the details of an offset application entered into the input area B1 via the input device 112, and reflects the accepted details in the details table B2. The following items are entered into the input area B1: scheduled payment date, payee, creditor business establishment, creditor department, creditor subject, billing destination, offset amount, offset consumption tax amount, and remarks. This allows the offset application input unit 102d to accept the input of the offset application data 106e.

[0049] Fig. 9 is a diagram showing an example of an offset application data table in the offset application data input accepted by the offset application input unit 102d. As shown in the offset application data table T6 shown in Fig. 9, the offset application input unit 102d inputs the same contents as those in the offset application data table T5 described in Fig. 7. After step S5, the credit and debt management device 100 proceeds to step S7 in Fig. 4.

[0050] Returning to FIG. 4, the explanation of step S6 and subsequent steps will be continued. In step S6, the offset application data import unit 102e refers to the offset counterparty setting master 106a, displays an offset application data import screen on the monitor 114 so that the user of the accounting department can import the offset application data sent from the sales department via the input device 112, and executes an offset application data import process that specifies the import file.

[0051] Fig. 10 is a diagram showing an example of an offset application data import screen displayed on the monitor 114. The offset application data import screen P2 shown in Fig. 10 includes an import file path cell B3 for specifying the path (address) of the import file, and an import button B4 for instructing import.

[0052] In the case shown in Figure 10, the offset application data import unit 102e imports the file specified in the import file path cell B3, for example, the offset application data of Figure 7 (see the offset application data table T6 in Figure 9 described above). In this case, the offset application data import unit 102e references the offset counterparty setting master 106a, and if the offset application data 106e is a combination in which the payee and the invoice are not linked, it halts the import of the offset application data 106e. At this time, the display control unit 102i may display on the monitor 114 a warning that the offset application data 106e cannot be imported or an error warning that the payee and the invoice are not linked. After step S6, the credit and debt management device 100 proceeds to step S7 in Figure 4.

[0053] Returning to FIG. 4, the description of step S7 and subsequent steps will be continued. In step S7, the credit and debt management apparatus 100 executes offset calculation processing for offsetting the payment schedule data 106c and the billing schedule data 106d based on the offset application data 106e.

[0054] [2.1 Extraction Overview] First, the content extracted by the extraction unit 102f in the offset calculation process will be described. The extraction unit 102f extracts, from the payment schedule data 106c and the offset application data 106e, the payment schedule data 106c and the offset application data 106e corresponding to the payment schedule date input by the accounting department user via the input device 112 as relevant data.

[0055] Fig. 11 is a diagram showing an example of a payment schedule data table in the payment schedule data extracted by the extraction unit 102f by the payment schedule date. Fig. 12 is a diagram showing an example of an offset application data table in the offset application data extracted by the extraction unit 102f by the payment schedule date.

[0056] As shown in the payment schedule data table T21 shown in Fig. 11 and the offset application data table T22 shown in Fig. 12, the extraction unit 102f extracts each item from the payment schedule data 106c and the offset application data 106e based on the specified scheduled payment date. Note that Figs. 11 and 12 are similar to the payment schedule data table T3 in Fig. 5 and the offset application data table T5 in Fig. 7 described above, and therefore detailed explanations will be omitted.

[0057] [2.2 Overview of size comparison] Next, the comparison content performed by the comparison unit 102g in the offset calculation process will be described. The comparison unit 102g compares the amount to be paid with the offset amount (including the offset consumption tax amount) for the payee extracted by the extraction unit 102f.

[0058] Fig. 13 is a diagram showing an example of a comparison result data table obtained by the comparison unit 102g. The comparison result data table T23 shown in Fig. 13 stores a combination CD (code) in association with a payee, a scheduled payment date, a billing destination, a scheduled payment amount, an offset amount, and a net payment amount.

[0059] Specifically, the first row of the comparison result data table T23 stores the combination CD "1001" in association with the payee "Customer A," the scheduled payment date "2022 / 3 / 15," the billing destination "Customer A," the scheduled payment amount "6,620,000," the offset amount "5,610,000," and the net payment amount "1,010,000" (hereinafter referred to as "Part 1").

[0060] In addition, in the second row of the comparison result data table T23, the combination CD "1002" is stored in association with the payee "Payee B", the scheduled payment date "2022 / 3 / 15", the billing recipient "Billing recipient X", the scheduled payment amount "5,000", the offset amount "3,300", and the net payment amount "1,700" (hereinafter referred to as "Part 2").

[0061] Furthermore, in the third row of the comparison result data table T23, the combination CD "1003" is stored in association with the payee "Payee C", the scheduled payment date "2022 / 3 / 15", the billing recipient "Billing recipient Y", the scheduled payment amount "10,500", the offset amount "22,440", and the net payment amount "-11,940" (hereinafter referred to as "Part 3").

[0062] In the offset calculation process, the comparison unit 102g compares the amount of the payee's scheduled payment amount with the invoiced amount (including tax) to determine which is larger.

[0063] Specifically, from the first row of the comparison result data table T23, the total amount of the planned payment for business partner A is 6,620.00 yen, and the total amount of the offset is 5,610,000 yen, so the planned payment amount > offset amount (6,620.00 yen > 5,610,000 yen), and therefore the purchase is a win.

[0064] Furthermore, from the second row of the comparison result data table T23, payee B's total planned payment amount is 5,000 yen and the total offset amount is 3,300 yen, so the planned payment amount > offset amount (5,000 yen > 3,300 yen) and therefore the buyer wins.

[0065] Furthermore, from the third row of the comparison result data table T23, the total amount of the planned payment for payee C is 10,500 yen, and the total amount of the offset is 22,440 yen, so the planned payment amount < the offset amount (10,500 yen < 22,440 yen), and therefore the sale is a win.

[0066] Here we will provide an overview of two-party offsetting and three-party offsetting. [2.2-1 Overview of Part 1] First, we will explain the outline of the offset process between our company and business partner A, which is "Part 1" of the comparison results. Fig. 14 is a diagram showing the outline of the offset process between our company and business partner A. Fig. 15 is a diagram showing the outline of the offset process result between our company and business partner A.

[0067] As shown in the transaction status between two companies in Figure 14, our company has a receivable of 5,610,000 yen from business partner A and a payable of 6,620,000 yen from business partner A. In other words, in the offsetting process between two companies, our company plans to pay 6,620,000 yen to business partner A and plans to collect 5,610,000 yen from business partner A. Therefore, in the offsetting process, by offsetting 5,610,000 yen, an offset can be automatically performed between our company and business partner A.

[0068] As a result, as shown in Figure 15, our company's receivables from business partner A will be 0 yen, our debt to business partner A will be 1,010,000 yen, the offset will be 5,610,000 yen, and we will be due to pay 1,010,000 yen to business partner A.

[0069] [2.2-2 Overview of Part 2] Next, we will explain the outline of the offsetting process between our company, payee B, and invoice X, which is "Part 2" of the comparison results. Figure 16 is a diagram showing an outline of the offsetting process between our company, payee B, and invoice X. Figure 17 is a diagram showing an outline of the offsetting process results between our company, payee B, and invoice X.

[0070] As shown in the transaction status between the three companies in Figure 16, the company has a receivable of 3,300 yen from invoice destination X and a debt of 5,000 yen from payee B. Furthermore, as shown in the transaction status between the three companies in Figure 16, there is a receivable / debt of 4,000 yen between invoice destination X (Company X) and payee B (Company B), but this cannot be grasped because it is not managed by the company's receivable / debt management device 100. In other words, the company has a planned payment of 5,000 yen to payee B (Company B) and a planned collection of 3,300 yen from invoice destination X (Company X). Furthermore, there is a receivable / debt of 4,000 yen between Company B and Company X, which is not managed by the receivable / debt management device 100. Therefore, the offset process offsets 3,300 yen.

[0071] As a result, as shown in Figure 17, the company's credit against billing destination X (Company X) becomes 0 yen, and its debt against payee B (Company B) becomes 1,700 yen. Furthermore, the credit and debt between the two companies, billing destination X (Company X) and payee B (Company B), is 700 yen, but this cannot be grasped because it is not managed by the company's credit and debt management device 100. This credit and debt of 700 yen is not important to the company.

[0072] [2.2-3 Overview of Part 3] Next, we will explain the outline of the correlation process between our company, payee C, and invoice Y, which is "part 3" of the comparison results. Figure 18 is a diagram showing an outline of the correlation process between our company, payee C, and invoice Y. Figure 19 is a diagram showing an outline of the correlation process results between our company, payee C, and invoice Y.

[0073] As shown in the transaction status between the three companies in Figure 18, the company's receivables to invoice recipient Y (Company Y) are 22,440 yen, and its payables to payee C (Company C) are 10,500 yen. Furthermore, as shown in the transaction status between the three companies in Figure 18, there is a receivable / payable of 15,000 yen between the two companies, invoice recipient Y (Company Y) and payee C (Company C), but this cannot be grasped because it is not managed by the company's receivable / payable management device 100. In other words, the company has a planned payment of 10,500 yen to payee C (Company C), and a planned collection of 22,440 yen from invoice recipient Y (Company Y). Furthermore, there is a receivable / payable of 15,000 yen between the two companies, Y Company and C Company, which is not managed by the receivable / payable management device 100. Therefore, the offsetting process offsets 10,500.

[0074] As a result, as shown in Figure 19, the company's receivables to payee C (Company C) will be 0 yen, and its receivables to invoiced party Y (Company Y) will be 11,940 yen. Furthermore, the receivables and payables between the two companies, invoiced party Y (Company Y) and payee C (Company C), will be 4,500 yen, but this cannot be grasped because it is not managed by the company's receivables and payables management device 100. This receivables and payables of 4,500 yen is not important to the company.

[0075] [2.3 Overview of deposit data] Next, the content of the deposit data generated by the generation unit 102h in the offset calculation process will be explained. The generation unit 102h generates the deposit data based on the comparison result of the magnitude comparison performed by the comparison unit 102g. Note that the following will be explained separately for the case of a winning buy and the case of a winning sell.

[0076] [2.3-1 In case of winning bid] First, we will explain the case where the comparison result of the comparison unit 102g is a winning purchase. In this case, the generation unit 102h generates the creditor's deposit data and the debtor's payment schedule data. Note that, as an example of a winning purchase, we will use payee B as an example, but the same processing is also performed for business partner A, as it is also a winning purchase.

[0077] [2.3-1-1 Creditor in case of winning bid] First, the credit side will be described. The generating unit 102h generates deposit data for the amount to be offset on the credit side. Fig. 20 is a diagram showing an example of a deposit data table of deposit data generated by the generating unit 102h.

[0078] As shown in Figure 20, the generation unit 102h generates deposit data that associates the billing address, creditor business office, creditor department, expected deposit date, transaction classification, and deposit amount with a combination CD (code) based on the comparison result data and offset application data compared by the comparison unit 102g.

[0079] Specifically, the deposit data table T31 stores the combination CD "1002" in association with the billing destination "Billing destination X," the creditor business office "Chugoku Branch," the creditor department "Hiroshima Division 1," the expected deposit date "3 / 31 / 2022," the transaction category "Offset," and the deposit amount "3,300." More specifically, the generation unit 102h sets the combination CD, billing destination, and deposit amount from the comparison result data, sets the creditor business office and creditor department from the offset application data, sets the expected deposit date from the scheduled billing data, and sets the transaction category to offset, thereby generating the deposit data table T31.

[0080] [2.3-1-2 Debtors in the case of a winning bid] Next, the debt side will be described. Based on the payment schedule data, the generation unit 102h generates payment schedule data for the debt side for each of the payment methods "offset" and "transfer." Figure 21 is a diagram showing an example of a payment schedule data table of the payment schedule data generated by the generation unit 102h.

[0081] As shown in Figure 21, the generation unit 102h uses the payment schedule data to change the payment method of the payment schedule data for the amount to be offset to "offset," and generates payment schedule data for the amount after deducting the amount to be offset, with the payment method set to "transfer."

[0082] Specifically, as shown in the first row of the payment schedule data table T32 in Figure 21, the voucher number "SIH0004" is stored in association with row "1," payment category "Closing payment," transaction category "Expense accounting," payment method "Offset," payment schedule section "2022 / 3 / 15," payment establishment "A01: Accounting Headquarters," payment department "A0100: Accounting Headquarters," payee "Payee B," scheduled payment amount "3,300," and payment notice number "A0LQ0114."

[0083] Similarly, as shown in the second row of the payment schedule data table T32 in Figure 21, the voucher number "SIH0004" is stored in association with row "2," payment category "Closing payment," transaction category "Expense accounting," payment method "Bank transfer," payment schedule section "2022 / 3 / 15," payment establishment "A01: Accounting Headquarters," payment department "A0100: Accounting Headquarters," payee "Payee B," scheduled payment amount "1,700," and payment notification number "A0LQ0114."

[0084] [2.4-1 Selling in the case of winning] Next, the case of a winning sale will be described. In this case, the generating unit 102h generates the creditor's deposit data and the debtor's scheduled payment data. Note that the case of a winning sale will be described using payee C as an example.

[0085] [2.4-1-1 Creditor in case of winning sale] First, the credit side will be described. The generation unit 102h generates deposit data for the amount to be offset on the credit side. Fig. 22 is a diagram showing an example of a deposit data table of deposit data generated by the generation unit 102h.

[0086] As shown in Figure 22, the generation unit 102h generates deposit data that associates the billing address, creditor business office, creditor department, expected deposit date, transaction classification, and deposit amount with a combination CD (code) based on the comparison result data and offset application data compared by the comparison unit 102g.

[0087] Specifically, the first row of the deposit data table T33 stores the combination CD "1003" in association with the billing destination "Billing destination Y," the creditor business office "Tohoku Branch," the creditor department "Tohoku Section 1," the expected deposit date "2022 / 3 / 31," the transaction category "offset," and the deposit amount "440." More specifically, the generation unit 102h sets the combination CD and billing destination from the comparison result data, and sets the creditor business office and creditor department from the offset application data, and also sets the expected deposit date from the billing schedule data and the deposit amount from the offset application data, and generates the deposit data table T33.

[0088] Similarly, the second row of the deposit data table T33 stores the combination CD "1003" in association with the billing destination "Billing destination Y," the creditor business office "North Tohoku Division 1," the creditor department "North Tohoku Division 1," the expected deposit date "2022 / 3 / 31," the transaction category "Offset," and the deposit amount "10,060." In this case, the generation unit 102h, like the first row, sets the combination CD and billing destination from the comparison result data, sets the creditor business office and the creditor department from the offset application data, and also sets the expected deposit date from the billing schedule data, sets the deposit amount from the offset application data, and sets the transaction category to offset, thereby generating the deposit data table T33.

[0089] Furthermore, in the third row of the deposit data table T33, the combination CD "1003" is stored in association with the billing destination "Billing destination Y," the creditor business office "North Tohoku Division 1," the creditor department "North Tohoku Division 1," the expected deposit date "2022 / 3 / 31," the transaction category "Transfer," and the deposit amount "11,940." In this case, as in the first row, the generation unit 102h sets the combination CD and billing destination from the comparison result data, and sets the creditor business office and creditor department from the offset application data, and the generation unit 102h sets the expected deposit date from the billing schedule data, sets the deposit amount from the offset application data, and sets the transaction category to offset, thereby generating the deposit data table T33.

[0090] [2.4-1-2 Debtor in case of winning sale] Next, the debt side will be described. Based on the payment schedule data, the generation unit 102h generates payment schedule data for the debt side by changing the payment method of the payment schedule data to "offset." Figure 23 is a diagram showing an example of a payment schedule data table of the payment schedule data generated by the generation unit 102h.

[0091] As shown in FIG. 23, the generating unit 102h generates payment schedule data in which the payment method of the original payment schedule data is changed to "offset."

[0092] Specifically, as shown in the first row of the payment schedule data table T34 in Figure 23, the voucher number "SIH0005" is stored in association with row "1," payment category "Closing payment," transaction category "Expense accounting," payment method "Offset," payment schedule section "2022 / 3 / 15," payment establishment "A01: Accounting Headquarters," payment department "A0100: Accounting Headquarters," payee "Payee C," scheduled payment amount "500," and payment notice number "A0LQ0115."

[0093] Similarly, as shown in the second row of the payment schedule data table T34 in Figure 23, the document number "SIH0006" is stored in association with row "1," payment category "Closing payment," transaction category "Expense accounting," payment method "Offset," payment schedule section "2022 / 3 / 15," payment establishment "A01: Accounting Headquarters," payment department "A0100: Accounting Headquarters," payee "Payee C," scheduled payment amount "10,000," and payment notice number "A0LQ0116."

[0094] In this way, the generating unit 102h generates the creditor's deposit data and the debtor's payment schedule data.

[0095] Returning to FIG. 4, the explanation of step S8 and subsequent steps will be continued. In step S8, the display control unit 102i executes a cancellation result confirmation output process for displaying the cancellation result on the monitor 114.

[0096] Figure 24 is a diagram showing an example of the offset result displayed on the monitor 114. The offset result table T35 shown in Figure 24 stores the combination CD in association with the payee, scheduled payment date, scheduled payment amount, offset amount, and net payment amount. This allows the accounting department user to intuitively understand the situation. After step S8, the receivables and payables management device 100 proceeds to step S9.

[0097] Returning to FIG. 4, the description of step S9 and subsequent steps will be continued. In step S9, the journal data creation processing unit 102j executes a journal data creation process to create journal data as a result of offset refinement processing based on the journal data of the deposit data and payment schedule data generated by the journal definition master 106b and the generation unit 102h.

[0098] [2.5-1 Overview of journal data for buying losses] First, the contents of the journal data created by the journal data creation processing unit 102j in the case of a winning purchase will be described. Note that, as an example of a winning purchase, the following description will be given using payee B as an example, but similar processing will be performed for business partner A as well, since it is also a winning purchase.

[0099] [2.5-1-1 Buying Wins] Fig. 25 is a diagram showing an example of a journal data table on the creditor's side, Fig. 26 is a diagram showing an example of a journal data table on the debtor's side, and Fig. 27 is a diagram showing an example of a journal data table already created by purchase input on the debtor's side.

[0100] As shown in FIG. 25, the journal data creation processing unit 102j refers to the journal definition master 106b and creates a journal data table H1 using definition number 1 as a pattern in which the transaction classification of the deposit data matches the transaction classification of the journal definition master 106b.

[0101] Also, as shown in Figure 26, the journal data creation processing unit 102j refers to the journal definition master 106b and generates journal data H2 using definition number 11 and definition number 12 as patterns in which the transaction classification of the payment schedule data matches the transaction classification of the journal definition master 106b.

[0102] Also, as shown in FIG. 27, the journal data creation processing unit 102j creates a journal data table H3 by reusing the slip number "SIH0004" of the payment schedule data.

[0103] [2.5-1-2 Selling in the case of a winning position] Fig. 28 is a diagram showing an example of a journal data table on the creditor's side. Fig. 29 is a diagram showing an example of a journal data table already created by inputting purchases on the creditor's side. Fig. 30 is a diagram showing an example of a journal data table on the debtor's side.

[0104] As shown in Figure 28, the journal data creation processing unit 102j refers to the journal definition master 106b and creates a journal data table H4 using definition number 1 and definition number 2 as patterns in which the transaction classification of the deposit data matches the transaction classification of the journal definition master 106b.

[0105] Furthermore, as shown in FIG. 29, the journal data creation processing unit 102j creates a journal data table H5 by using the sales input "22,440".

[0106] Furthermore, as shown in Figure 30, the journal data creation processing unit 102j creates a journal data table H6 using definition number 11 as a pattern in which the transaction classification in the payment schedule data table T34 shown in Figure 23 matches the transaction classification in the journal definition master 106b.

[0107] In this way, the journal data creation processing unit 102j creates journal data as a result of the offsetting process based on the journal data of the deposit data and the payment schedule data generated by the journal definition master 106b and the generation unit 102h. After step S8, the receivables and payables management device 100 terminates this process.

[0108] According to the embodiment described above, the generation unit 102h generates offset result data that associates the payee, scheduled payment date, billing destination, scheduled payment amount, offset amount, and net payment amount for each combination code based on the comparison results of the comparison unit 102g, thereby reducing the workload and preventing input errors and incorrect offset processing.

[0109] Furthermore, according to the embodiment, the display control unit 102i causes the monitor 114 to display the offset result data generated by the generation unit 102h, allowing the user to intuitively grasp the data.

[0110] In addition, according to the embodiment, the generation unit 102h automatically generates deposit data that associates the billing address, creditor business office, creditor department, expected deposit date, transaction category, and deposit amount with the combination code, thereby preventing manual input errors in the offset amount.

[0111] In addition, according to the embodiment, new payment schedule data is generated for the amount to be offset, while the payment method for the payment schedule data for the amount to be offset on the debtor side is changed to offset, thereby preventing erroneous offset processing.

[0112] Furthermore, according to the embodiment, the journal data creation processing unit 102j creates the journal data, which reduces the workload and prevents input errors and erroneous offsetting processes.

[0113] Furthermore, according to the embodiment, when offset application data is imported from outside or when offset application data is imported in response to external input, the offset application data import unit 102e refers to the offset counterparty setting master 106a, and when the offset application data is a combination in which the payee and the billing recipient are not linked, the import of the offset application data is stopped, thereby preventing the import of incorrect offset application data.

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

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

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

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

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

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

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

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

[0122] In addition, this computer program may be stored in an application program server connected to the claims and debts management apparatus 100 via any network, and it is also possible to download all or part of it as needed.

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

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

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

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

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

[0128] The present invention is useful in industries that perform credit and debit management. [Explanation of symbols]

[0129] 100 Credit and Debt Management Device 102 Control section 102a Purchase Input Section 102b Sales input section 102c Offsetting content creation processing unit 102d Offset application input section 102e Offset application data import unit 102f Extraction part 102g comparison section 102h generation part 102i Display Control Unit 102j Journal data creation processing unit 104 Communication interface unit 106 Storage section 106a Countervailing party setting master 106b Journal entry definition master 106c Payment schedule data 106d Billing schedule data 106e Offset application data 108 Input / Output Interface Section 112 Input Device 114 Output Device 200 servers 300 Network

Claims

1. A credit and debt management device having a control unit, Payment schedule data that associates payment classification, transaction classification, payment method, scheduled payment date, payment establishment, payment department, payment recipient, scheduled payment amount, and payment notice number for each slip number; For each offset application number, offset application data is associated with the scheduled payment date, payee, creditor business office, creditor department, creditor item, billing destination, offset amount, and offset consumption tax amount. is accessible to The control unit an extraction unit that extracts corresponding data corresponding to an externally input scheduled payment date from each of the scheduled payment data and the offset application data; a comparison unit that compares the amount of payment to be made and the amount of offset for each payee based on the corresponding data; a generating unit that generates offset result data that associates a payee, a scheduled payment date, a billing destination, a scheduled payment amount, an offset amount, and a net payment amount for each combination code based on the comparison result of the comparing unit; To have A credit and debt management device characterized by the above.

2. 2. The credit and debt management device according to claim 1, The control unit Further comprising a display control unit that displays the offset result data on a monitor; A credit and debt management device characterized by the above.

3. 3. The credit and debt management device according to claim 2, The generation unit If the comparison unit determines that the payment amount is greater than the offset amount, the comparison unit generates payment data for the amount to be offset on the creditor side, in which the billing address, creditor business office, creditor department, expected payment date, transaction classification, and payment amount are associated with a combination code; When the comparison unit determines that the amount to be paid is less than the offset amount and the sale is successful, the amount to be offset on the creditor side and the amount remaining after the amount to be offset are generated, and the combined code is associated with the billing destination, creditor business office, creditor department, expected date of payment, transaction classification, and payment amount. A credit and debt management device characterized by the above.

4. 4. The credit and debt management device according to claim 3, The generation unit When the comparison unit determines that the purchase is a winning purchase, the payment method of the payment schedule data for the amount to be offset on the debtor side is changed to offset, and new payment schedule data is generated by subtracting the amount to be offset, When the comparison unit determines that the sale is a winning transaction, the payment method of the payment schedule data for the amount to be offset on the debtor side is changed to offset. A credit and debt management device characterized by the above.

5. 5. The credit and debt management device according to claim 4, It is possible to further access a journal entry definition master in which data, transaction classification, debit and credit are associated with the definition number, The control unit Further comprising a journal data creation processing unit that references the journal definition master and creates journal data for each of the deposit data and the payment schedule data; A credit and debt management device characterized by the above.

6. 6. The credit and debt management device according to claim 5, The combination code can further access offsetting counterparty setting master data that associates a payee and a billing destination, The control unit Further provided is an offset application data acquisition unit that acquires the offset application data. The offset application data acquisition unit When the offset application data is imported from the outside or when the offset application data is imported in response to an external input, the offset application data is imported by referring to the offset counterparty setting master, and when the offset application data is a combination in which the payee and the billing destination are not linked, the import of the offset application data is stopped; A credit and debt management device characterized by the above.

7. A credit and debt management method executed by a credit and debt management device having a control unit, The credit and debt management device Payment schedule data that associates payment classification, transaction classification, payment method, scheduled payment date, payment establishment, payment department, payment recipient, scheduled payment amount, and payment notice number for each slip number; For each offset application number, offset application data is associated with the scheduled payment date, payee, creditor business office, creditor department, creditor item, billing destination, offset amount, and offset consumption tax amount. is accessible to Executed by the control unit, an extraction step of extracting corresponding data corresponding to an externally input scheduled payment date from each of the scheduled payment data and the offset application data; a comparison step of comparing the amount of payment to be made and the amount of offset for each payee based on the relevant data; a generating step of generating offset result data in which a payee, a scheduled payment date, a billing destination, a scheduled payment amount, an offset amount, and a net payment amount are associated with each combination code based on the comparison result of the comparing step; containing, A method for managing receivables and payables, characterized by:

8. A credit and debt management program to be executed by a credit and debt management device having a control unit, The credit and debt management device Payment schedule data that associates payment classification, transaction classification, payment method, scheduled payment date, payment establishment, payment department, payment recipient, scheduled payment amount, and payment notice number for each slip number; For each offset application number, offset application data is associated with the scheduled payment date, payee, creditor business office, creditor department, creditor item, billing destination, offset amount, and offset consumption tax amount. is accessible to The credit and debt management program causes the control unit to: an extraction step of extracting corresponding data corresponding to an externally input scheduled payment date from each of the scheduled payment data and the offset application data; a comparison step of comparing the amount of payment to be made and the amount of offset for each payee based on the relevant data; a generating step of generating offset result data in which a payee, a scheduled payment date, a billing destination, a scheduled payment amount, an offset amount, and a net payment amount are associated with each combination code based on the comparison result of the comparing step; To execute the A receivables and payables management program featuring:

Images