Deposit reconciliation device, deposit reconciliation method, and deposit reconciliation program

Abstract

To realize payment settlement with high accuracy and low workload even when the source of payment for receivables changes each time. [Solution] According to this embodiment, the deposit reconciliation device comprises: a deposit input means for creating deposit data including the deposit date, specific information, deposit amount, reconciled deposit amount, and customer classification obtained from the billing master using the specific information as a key; and a reconciliation means for aggregating the scheduled collection amounts of the collection schedule data by scheduled collection date in the receivables master, in order of customer granularity specified in the customer classification of the deposit data to customer granularity decreasing, excluding records other than the customer classification of the receivables origination reason master linked to the reason for the receivable of the collection schedule data, creating reconciliation candidate pattern list data, and comparing the scheduled collection amounts and deposit amounts in the reconciliation candidate pattern list data in order of customer granularity decreasing, and performing automatic reconciliation.

Description

Technical Field

[0006] ,

[0001] The present invention relates to a payment offsetting device, a payment offsetting method, and a payment offsetting program.

Background Art

[0002] For example, when a gaming manufacturer newly installs or replaces a gaming machine in a hall (store), the payment offsetting operation is performed when there is a payment from the payer for the claim. For example, there is Patent Document 1 as a conventional payment offsetting system.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the sending of the claim form is sent to the destination determined at the time of each hall or contract. However, since the payer changes due to reasons such as new installation or replacement of a hall, corporation, affiliated corporation, etc., each time the payer changes, there is a problem that the workload of the person in charge of the payment offsetting operation increases and the load is large.

[0005] The present invention has been made in view of the above, and an object thereof is to provide a payment offsetting device, a payment offsetting method, and a payment offsetting program capable of realizing high-precision payment offsetting with a low workload even when the payer for the claim changes each time.

Means for Solving the Problems

[0006] To solve the above-mentioned problems and achieve the objective, the present invention provides a payment reconciliation device equipped with a control unit, wherein the control unit is configured to access a billing master registered by associating specific information for identifying the customer from whom a payment is made for a receivable, one or more customers, and customer classifications for specifying the granularity of the customer; a receivable creation reason master registered by associating the reason for the creation of the receivable with the customer classification; and collection schedule data including multiple customers, collection schedule date, collection schedule amount, collected amount, and reason for the creation of the receivable, and the payment date, specific information, payment amount, and collected amount are used as keys for the payment reconciliation. The system is characterized by comprising: a payment input means that creates payment data including a customer classification obtained from a customer request master; and a reconciliation means that, in the accounts receivable master, aggregates the planned collection amount of the planned collection data by the planned collection date, in order from the customer classification of the customer specified in the payment data to the customer with the smallest granularity, and at that time excludes records other than the customer classification of the account receivable reason master that are linked to the reason for the creation of the planned collection data, to create a list of reconciliation candidate patterns data, and performs automatic reconciliation by comparing the planned collection amount and the payment amount of the reconciliation candidate pattern list data in order of the smallest granularity of the customer.

[0007] Furthermore, according to one aspect of the present invention, the automatic reconciliation process may also update the amount of the scheduled collection data that has been collected and the amount of the payment data that has been reconciled.

[0008] Furthermore, according to one aspect of the present invention, the trading partners and trading partner classifications may include affiliated corporate groups, corporations, area groups, and stores, the granularity of the trading partners may be in the order of affiliated corporate groups > corporations > area groups > stores, and the recipient of the claims may be the stores.

[0009] Furthermore, according to one aspect of the present invention, the claim may be a claim relating to the installation or replacement of gaming machines or game machines in a store.

[0010] Furthermore, in order to solve the above-mentioned problems and achieve the objectives, the present invention provides a payment reconciliation method executed by an information processing device equipped with a control unit, wherein the control unit is configured to access a billing master registered by associating specific information for identifying the paying customer for the receivable, one or more customers, and customer classifications for specifying the granularity of the customers, a receivable creation reason master registered by associating the reason for the creation of the receivable with the customer classification, and collection schedule data including multiple customers, a collection schedule date, a collection schedule amount, a collected amount, and a receivable creation reason, and the payment date, specific information, payment amount, and payment reconciliation amount are executed by the control unit, and the payment date, specific information, payment amount, and payment reconciliation amount are The method is characterized by including: a payment input step that creates payment data including a customer classification obtained from the billing master using specific information as a key; and a reconciliation step that aggregates the planned collection amount of the planned collection data by the planned collection date in the billing master, in order from the customer classification of the customer specified in the payment data to the customer with the smallest granularity, and at that time excludes records other than the customer classification of the reason for the occurrence of the receivable in the reason for the planned collection data, to create a list of reconciliation candidate patterns, and then compares the planned collection amount and the payment amount in the list of reconciliation candidate patterns in order of the smallest granularity of the customer to perform automatic reconciliation.

[0011] Furthermore, in order to solve the above-mentioned problems and achieve the objective, the present invention provides a payment reconciliation program to be executed by an information processing device equipped with a control unit, wherein the control unit is configured to access a billing master registered by associating specific information for identifying the paying customer for the receivable, one or more customers, and customer classifications for specifying the granularity of the customers, a receivable creation reason master registered by associating the reason for the creation of the receivable with the customer classification, and collection schedule data including multiple customers, collection schedule date, collection schedule amount, collected amount, and reason for the creation of the receivable, and the control unit is configured to access the payment date, specific information, payment amount, collected amount, and specific information as keys. The payment reconciliation program is characterized by performing the following steps: a payment input step of creating payment data including a customer classification obtained from the customer master; and a reconciliation step of aggregating the planned collection amount of the planned collection data by the planned collection date in the customer master, in order from the customer with the smallest granularity of the customer specified by the customer classification of the payment data to the customer with the smallest granularity, and at that time excluding records other than the customer classification of the reason for the occurrence of the receivable linked to the reason for the occurrence of the planned collection data, creating a list of reconciliation candidate patterns data, and matching the planned collection amount and the payment amount of the reconciliation candidate pattern list data in order of the smallest granularity of the customer to perform automatic reconciliation. [Effects of the Invention]

[0012] According to the present invention, even when the source of payment for receivables changes each time, it becomes possible to achieve payment reconciliation with high accuracy and low workload. [Brief explanation of the drawing]

[0013] [Figure 1] Figure 1 is a block diagram showing an example of the configuration of a deposit reconciliation device according to this embodiment. [Figure 2] Figure 2 is a diagram illustrating the overall processing flow of the control unit of the deposit reconciliation device according to this embodiment. [Figure 3] Figure 3 is a diagram illustrating a specific example of the processing performed by the control unit of the deposit reconciliation device according to this embodiment. [Figure 4] FIG. 4 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 5] FIG. 5 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 6] FIG. 6 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 7] FIG. 7 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 8] FIG. 8 is a diagram showing a flow for explaining the overall processing flow of the control unit of the payment offsetting device according to the present embodiment. [Figure 9] FIG. 9 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 10] FIG. 10 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 11] FIG. 11 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 12] FIG. 12 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 13] FIG. 13 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 14] FIG. 14 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 15] FIG. 15 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 16] FIG. 16 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 17] FIG. 17 is a diagram for explaining a specific example of the processing of the control unit of the payment offsetting device according to the present embodiment. [Figure 18]FIG. 18 is a diagram for explaining a specific example of the processing of the control unit of the deposit offsetting device according to the present embodiment. [Figure 19] FIG. 19 is a diagram for explaining a specific example of the processing of the control unit of the deposit offsetting device according to the present embodiment. [Figure 20] FIG. 20 is a diagram for explaining a specific example of the processing of the control unit of the deposit offsetting device according to the present embodiment. [Figure 21] FIG. 21 is a diagram for explaining a specific example of the processing of the control unit of the deposit offsetting device according to the present embodiment. [Figure 22] FIG. 22 is a diagram for explaining a specific example of the processing of the control unit of the deposit offsetting device according to the present embodiment. [Figure 23] FIG. 23 is a diagram for explaining a specific example of the processing of the control unit of the deposit offsetting device according to the present embodiment. [Figure 24] FIG. 24 is a diagram for explaining a specific example of the processing of the control unit of the deposit offsetting device according to the present embodiment.

Embodiments for Carrying Out the Invention

[0014] Hereinafter, embodiments of the deposit offsetting device, deposit offsetting method, and deposit offsetting program according to the present invention will be described in detail based on the drawings. Note that the present invention is not limited by this embodiment.

[0015] [1. Overview] The overview of the present invention will be described in the order of [Background], [Problems], and "Solution".

[0016] [Background] [[ID=3S]]For example, when a game machine manufacturer installs or replaces a game machine in a hall, there are various reasons such as the judgment of the store, the judgment of the company, and the judgment of the affiliated company. Depending on the reason for the installation or replacement, the source of the payment after the claim may change. The invoice is sent to the destination determined at the time of each store or contract, but the source of the payment received changes due to reasons such as installation or replacement of the store, company, affiliated company, etc.

[0017] [Problems] When an invoice is sent and payment is received from the billing party, it is possible to reconcile the amount of the outstanding debt with that party. However, when payments are made in a consolidated manner, such as by the hall alone, by the corporation as a whole, or by affiliated corporations as a whole, it is difficult to determine which outstanding debt the payment corresponds to, requiring the person in charge to make a judgment, which increases the burden on the payment reconciliation work.

[0018] [Solution] Therefore, in this embodiment, the system checks the amount of outstanding receivables and the amount received in the order of the granularity (hierarchy) of trading partners (for example, affiliated companies > companies > areas > stores) and automatically reconciles them. Furthermore, by focusing on the fact that the source of payment after invoice issuance changes depending on the reason for the creation of the receivable, and by excluding cases where the reason for the creation of the receivable is clear from the list of reconciliation targets, automatic reconciliation is enabled, thereby improving reconciliation accuracy and reducing the workload of reconciliation operations.

[0019] The following example illustrates a case where a gaming machine manufacturer notifies a store of an invoice, and payment is received from a different supplier (source of payment). However, the present invention is not limited to this example. It is also applicable to manufacturers of game machines installed in stores, manufacturers of ticket vending machines installed in stores, and manufacturers of payment machines installed in coin-operated parking lots, etc., where the source of payment after invoicing may change due to reasons such as new installation or replacement. The invention is broadly applicable when the source of payment for receivables changes each time.

[0020] [2. Structure] An example of the configuration of the payment reconciliation device 100 according to this embodiment will be described with reference to Figure 1. Figure 1 is a block diagram showing an example of the configuration of the payment reconciliation device 100. In the following, the case in which the payment reconciliation device 100 is applied to a gaming machine manufacturer will be described as an example. The gaming machine manufacturer will be described as an example in which a gaming machine manufacturer installs or replaces gaming machines in a store, notifies the store of an invoice, and receives payments from different trading partners (payers).

[0021] The deposit reconciliation device 100 is, for example, a commercially available desktop personal computer or workstation.

[0022] The deposit reconciliation device 100 comprises a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each part of the deposit reconciliation device 100 is connected to communicate via any communication path.

[0023] The communication interface unit 104 connects the deposit reconciliation 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 the function of communicating data with other devices via a communication line. Here, the network 300 has the function of connecting the deposit reconciliation device 100 with the server 200 and the bank's system (not shown) so that they can communicate with each other, and is, for example, the internet or a LAN (Local Area Network). Data such as various masters, which will be described later, may be stored in the server 200, for example.

[0024] The input / output interface unit 108 is connected to an input device 112 and an output device 114. The output device 114 can be a monitor (including a home television), a speaker, or a printer. The input device 112 can be a keyboard, mouse, microphone, or a monitor that works in conjunction with a mouse to provide pointing device functionality. 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 mouse 112.

[0025] The memory unit 106 stores various databases, tables, and files. The memory unit 106 also stores computer programs that work in cooperation with the OS (Operating System) to give instructions to the CPU (Central Processing Unit) to perform various processes. As the memory unit 106, for example, memory devices such as RAM (Random Access Memory) and ROM (Read Only Memory), fixed disk devices such as hard disks, flexible disks, and optical disks can be used.

[0026] The memory unit (memory area) 106 stores, for example, a billing address master 106a, a debt creation reason master 106b, collection schedule data, payment data, etc.

[0027] The billing master 106a is a master for setting specific information to identify the customer from whom payments are made regarding receivables, one or more customers, and customer classifications to specify the granularity of the customers. The billing master 106a can consist of tables that associate and register specific information (store code, store name), affiliated corporate group code, affiliated corporate group name, corporate code, corporate name, area group code, area group name, and customer classification (see Figure 3).

[0028] The Accounts Receivable Reason Master 106b is a master database that sets up customer categories for each reason for the occurrence of an account receivable. In the case of a particular reason, only that customer category becomes the customer (source of payment). The Accounts Receivable Reason Master 106b can be composed of tables that associate and register the reasons for the occurrence of an account receivable (accounts receivable reason code, accounts receivable reason name) and the transaction account categories (customer category code, customer category name) (see Figure 4).

[0029] The data to be collected may include the invoice number, store (store code and / or store name), affiliated corporate group (affiliated corporate group code and / or corporate group name), corporation (corporation code and / or corporation name), area group (area group code and / or area group name), scheduled collection date, scheduled collection amount, collected amount, and reason for debt creation (see Figure 5).

[0030] The payment data may include payment number, payment date, specific information (store code, store name), payment method, payment amount, amount reconciled, and customer category (see Figure 6).

[0031] The control unit 102 is a CPU or similar component that comprehensively controls the deposit reconciliation device 100. The control unit 102 has internal memory for storing control programs such as the OS, programs that define various processing procedures, and required data, and executes various information processing based on these stored programs.

[0032] The control unit 102 is configured to access the billing address master 106a, the debt creation reason master 106b, collection schedule data, payment data, etc., which are stored in the storage unit 106. The billing address master 106a, the debt creation reason master 106b, collection schedule data, payment data, etc., may be stored in another location (for example, server 200), as long as the control unit 102 can access them.

[0033] Functionally, the control unit 102 comprises a master maintenance unit 102a, a collection schedule data creation unit 102b, a payment processing unit 102c, a reconciliation processing unit 102d, and a screen display control unit 102e.

[0034] The master maintenance unit 102a performs editing such as inputting, adding, and changing data in the billing address master 106a and the debt generation reason master 106b, for example, in response to operator operations on the master maintenance screen (not shown) displayed on the monitor 114.

[0035] The collection schedule data creation unit 102b creates collection schedule data, including multiple trading partners, collection schedule dates, collection schedule amounts, collected amounts, and reasons for debt generation, in response to operator operations on an input screen (not shown) displayed on the monitor 114, for example, and stores it in the storage unit 106.

[0036] The deposit processing unit 102c downloads and imports transfer data from the bank's system (e.g., EB system or internet banking system), identifies the source of the deposit, and Using the payment source (specific information) as the key, the customer classification is retrieved from the billing master 106a, and payment data is created including the payment date, specific information (e.g., store), payment amount, payment reconciliation amount, and retrieved customer classification, and stored in the storage unit 106.

[0037] The reconciliation processing unit 102d aggregates the planned collection amounts of the collection schedule data by the collection schedule date, starting from the smallest granularity of the customer specified in the customer category of the payment data in the billing master 106a. At the same time, it excludes records other than the customer category in the receivables reason master 106b that are linked to the reason for the creation of the receivables in the collection schedule data, and creates a list of reconciliation candidate patterns. The reconciliation processing unit then compares the planned collection amounts and payment amounts in the list of reconciliation candidate patterns in order of the smallest granularity of the customer to perform automatic reconciliation. In automatic reconciliation, the collected amounts of the collection schedule data and the settled payment amounts of the payment data are updated.

[0038] The screen display control unit 102e controls the display and acceptance of input for various screens (for example, the master maintenance screen, the data collection schedule input screen, etc.) to be displayed on the monitor 114.

[0039] [3. Specific examples] Referring to Figures 1 to 24, a specific example of the processing of the control unit 102 of the deposit reconciliation device 100 in this embodiment will be explained. Figures 2 to 24 are diagrams illustrating a specific example of the processing of the control unit 102 of the deposit reconciliation device 100 in this embodiment.

[0040] [3-1. Processing Flow] Figure 2 is a diagram illustrating the overall processing flow of the control unit 102 of the payment reconciliation device 100 in this embodiment. The overall processing flow of the control unit 102 of the payment reconciliation device 100 in this embodiment will be explained with reference to Figure 2.

[0041] The collection schedule data creation unit 102b creates collection schedule data, including multiple trading partners, collection schedule dates, collection schedule amounts, collected amounts, and reasons for debt generation, in response to operator operations on an input screen (not shown) displayed on the monitor 114, for example, and stores it in the storage unit 106.

[0042] The deposit processing unit 102c downloads and imports transfer data from the bank's system (e.g., EB system or internet banking system), identifies the source of the deposit, and Using the payment source (specific information) as the key, the customer classification is retrieved from the billing master 106a, and payment data is created including the payment date, specific information (e.g., store), payment amount, payment reconciliation amount, and retrieved customer classification, and stored in the storage unit 106. For example, the customer classifications are 0: affiliated corporate group, 1: corporation, 2: area group, and 3: store.

[0043] The reconciliation processing unit 102d aggregates the planned collection amounts of the collection schedule data by the collection schedule date, starting from the smallest granularity (hierarchy) of the customer specified in the customer category of the payment data in the billing master 106a. At that time, it excludes records other than the customer category in the receivables reason master 106b that are linked to the reason for the creation of the receivables in the collection schedule data, and creates a list of reconciliation candidate patterns. The reconciliation processing unit then compares the planned collection amounts and payment amounts in the list of reconciliation candidate patterns in descending order of customer granularity and performs automatic reconciliation. For example, the granularity of customers is in the order of affiliated corporate group > corporation > area group > store. For example, if the customer category is "0: Affiliated Corporate Group," the reconciliation is performed in the order of Affiliated Corporate Group > Corporate > Area Group > Store; if the customer category is "1: Corporate," the reconciliation is performed in the order of Corporate > Area Group > Store; if the customer category is "2: Area Group," the reconciliation is performed in the order of Area Group > Store; and if the customer category is "3: Store" (where the billing address is the same as the payment source), the reconciliation is performed for the store.

[0044] [3-2. Sample Data] Figures 3 to 24 are diagrams showing sample data to illustrate a specific example of the processing performed by the control unit 102 of the payment reconciliation device 100 in this embodiment. A specific example of the processing performed by the control unit 102 of the payment reconciliation device 100 in this embodiment will be explained with reference to Figures 3 to 24.

[0045] (Assumption data) In the following explanation, the master data shown in Figures 3 to 5 will be described assuming that it is already stored in the storage unit 106.

[0046] Figure 3 shows an example of data in the billing master 106a. The billing master 106a is a master for setting specific information to identify the customer from whom payments are made for receivables, one or more customers, and customer categories to specify the granularity of the customers. The billing master 106a can consist of tables that associate and register store codes, store names, affiliated corporate group codes, affiliated corporate group names, corporate codes, corporate names, area group codes, area group names, and customer categories. The "customer category" is used to specify the granularity (hierarchy) of the customer (billing destination), with 0: affiliated corporate group, 1: corporate, 2: area group, and 3: store. The granularity is in the order of 0: affiliated corporate group > 1: corporate > 2: area group > 3: store.

[0047] In this example, lines 1-8 show cases where a subsidiary corporate group, corporation, or area group is the source of payment for receivables, and the specific information used to identify the customer that is the source of payment for receivables is a hypothetical store (store = subsidiary corporate group, corporation, or area group that is the source of payment). For example, line 1 has store code "SE1000", store name "○○ Holdings", subsidiary corporate group code "SE1000", corporate group name "○○ Holdings", and customer category "0: subsidiary corporate group". Store = subsidiary corporate group. When creating payment data, if the source of payment is the subsidiary corporate group ○○ Holdings, store = ○○ Holdings Group (specific information) and customer category "0: subsidiary corporate group" is obtained from billing master 106a.

[0048] Lines 9-17 show cases where the source of payment is the store (physical store) where the receivable actually arises. For each store, the affiliated corporate group, corporation, area group, and customer category are set. In this case, the customer category will be set to "3: Store".

[0049] Figure 4 shows an example of data in the Accounts Receivable Reason Master 106b. The Accounts Receivable Reason Master 106b is a master that sets up customer categories for each reason for the occurrence of an account receivable, and in the case of a given reason, only that customer category becomes the customer (source of payment). The Accounts Receivable Reason Master 106b can be composed of tables that register and associate the reasons for the occurrence of an account receivable (accounts receivable reason code, accounts receivable reason name) and the account receivable category (customer category code, customer category name). In the example shown in the figure, for example, the third row has the accounts receivable reason code "300", the accounts receivable reason name "New Corporation Establishment", the customer category code "1", and the customer category name "Corporation". In the case of a new corporation establishment, "Corporation" becomes the source of payment (customer). Also, the fifth row has the accounts receivable reason code "500", the accounts receivable reason name "New Area G Establishment", the customer category code "2", and the customer category name "Area Group". In the case of "New Area G Establishment", "Area Group" becomes the source of payment (customer).

[0050] Figure 5 shows an example of collection schedule data. Collection schedule data may include billing number, store (store code and / or store name), affiliated corporate group (affiliated corporate group code and / or corporate group name), corporation (corporation code and / or corporation name), area group (area group code and / or area group name), collection date, collection amount, collected amount, and reason for debt creation. Collection schedule data is created each time a debt is created. It is created for each affiliated corporate group, corporation, area group, and store linked in billing master 105a.

[0051] In the example shown in the diagram, the first row contains the following information: Invoice No. "SNO1000", Store Code "SE1111", Store Name "Sapporo Store", Affiliated Corporate Group Code "SE1000", Affiliated Corporate Group Name "○○ Holdings", Corporate Code "SE1100", Corporate Name "□□ Co., Ltd.", Area Group Code "SE1110", Area Group Name "Hokkaido / Tohoku", Scheduled Collection Date "2024 / 5 / 31", Scheduled Collection Amount "¥12,000", Amount Collected "¥0", and Reason for Debt Creation "".

[0052] Next, we will explain examples of cases where a lump-sum payment is made from an affiliated corporate group, from a single corporation, and from an area group, in that order.

[0053] (When a lump-sum payment is made from an affiliated corporate group) Refer to Figures 6 to 12 to explain the case where a lump-sum payment is made from an affiliated corporate group. Figure 6 shows an example of payment data. The payment data may include payment number, payment date, store code, store name, payment method, payment amount, payment reconciled amount, and customer category. The customer category is obtained from the billing master 106a using the store from which the payment originates as the key. In the example shown in the figure, the first row is: Payment No. "N1000", Payment Date "2024 / 6 / 30", Store Code "SE1000", Store Name "○○ Holdings", Payment Method "Bank Transfer", Payment Amount "¥54,000", Payment Reconciled Amount "¥0", Customer Category "0: Affiliated Corporate Group". The outstanding receivables subject to reconciliation are aggregated for the payment from the affiliated corporate group.

[0054] In the billing master 106a, the expected collection amount of the collection data is aggregated by the collection date, starting from the smallest granularity of the customer specified in the customer category of the payment data (0: affiliated corporate group > 1: corporate > 2: area group > 3: store). At that time, records other than the customer category in the receivables reason master 106b, which is linked to the reason for the creation of the receivable in the collection data, are excluded to create a list of reconciliation candidate patterns. The expected collection amount and payment amount in the list of reconciliation candidate patterns are then compared in descending order of customer granularity to perform automatic reconciliation.

[0055] The following processes (1) to (4) are used to create a list of candidate pattern data for removal.

[0056] Process (1) As shown in Figure 7(A), the collection schedule data is aggregated by affiliated corporate group > collection schedule date, and items whose reason for generating the receivable is not affiliated with an affiliated corporate group (receivable generation reasons "300" to "800" in the receivable generation reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0057] In this example, for the affiliated company group code "SE1000" and the company "XX Holdings," the planned collection date "2024 / 5 / 31" will result in a planned collection amount of "¥12,000," and the planned collection date "2024 / 6 / 30" will result in a planned collection amount of "¥54,000 (=13,000 + 17,000 + 3,000 + 21,000)."

[0058] Processing (2) As shown in Figure 7(B), the collection schedule data is aggregated by affiliated corporate group > corporation > collection schedule date, and items where the reason for the debt is not a corporation (debt origination reasons "100", "200", "500" to "800" in the debt origination reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0059] Processing (3) As shown in Figure 7(C), the collection schedule data is aggregated by affiliated corporate group > corporate > area group > collection schedule date, and items whose reason for debt generation is not an area group (debt generation reasons "100" to "400", "700", and "800" in the debt generation reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0060] Processing (4) As shown in Figure 8, the collection schedule data is aggregated by affiliated corporate group > corporation > area group > store > collection schedule date, and items where the reason for debt generation is other than stores (debt generation reason "100" to "600" in debt generation reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0061] Processing (5) The above list of reconciliation candidate patterns created in processes (1) to (4) is checked for matching or mismatching of amounts, starting with the largest granularity candidates, and automatic reconciliation is performed. Figure 9(A) shows an example of payment data (same as Figure 6), and Figure 9(B) shows an example of the list of reconciliation candidate patterns (same as Figure 8). As shown in Figures 9(A) and (B), for the affiliated corporate group: SE1000 (○○ Holdings), scheduled collection date: 2024 / 06 / 30, scheduled collection amount: ¥54,000, the amount matches the payment amount and becomes eligible for reconciliation.

[0062] Processing (6) For the reconciliation candidates identified in process (5), automatic reconciliation is performed, updating the recovered amount in the planned recovery data and updating the reconciled amount in the payment data. Figure 10(A) shows an example of planned recovery data after automatic reconciliation, and Figure 10(B) shows an example of payment data after automatic reconciliation. As shown in Figure 10(A), for the affiliated corporate group: SE1000 (XX Holdings), planned recovery date: 2024 / 06 / 30, planned recovery amount: ¥54,000, the recovered amounts (¥13,000, ¥17,000, ¥3,000, ¥21,000) are updated all at once and treated as recovered. In addition, the reconciled amount in the payment data is updated to "¥54,000".

[0063] Next, we will explain the case where the deposit amount in the deposit data is different from the example above, referring to processes (5)' and (6)'.

[0064] Process (5)' Figure 11(A) shows another example of deposit data. As shown in Figure 11(A), the deposit amount is "¥13,000", and the other items are the same as in Figure 6.

[0065] The above list of reconciliation candidate patterns created in processes (1) to (4) is checked for matching or mismatching of amounts, starting with the largest granularity of candidates, and automatic reconciliation is performed. Figure 11(B) shows an example of the reconciliation candidate pattern list data (same as Figure 8). As shown in Figures 11(A) and (B), for the affiliated corporate group: SE1000 (XX Holdings), scheduled collection date: 2024 / 06 / 30, scheduled collection amount: ¥13,000, the amount matches the received amount and becomes eligible for reconciliation.

[0066] Process (6)' For the reconciliation candidates identified in process (5)', automatic reconciliation is performed, updating the recovered amount in the planned recovery data and updating the reconciled amount in the payment data. Figure 12(A) shows an example of planned recovery data after automatic reconciliation, and Figure 12(B) shows an example of payment data after automatic reconciliation. As shown in Figure 12(A), for the affiliated corporate group: SE1000 (XX Holdings), planned recovery date: 2024 / 06 / 30, planned recovery amount: ¥13,000, the recovered amount: ¥13,000 is updated in bulk and treated as recovered. In addition, the reconciled amount in the payment data is updated to "¥13,000".

[0067] (When a lump-sum payment is made by a corporation) Refer to Figures 13 to 18 to explain the case where a lump-sum payment is made from a corporation. Figure 13 shows an example of payment data. In the example shown in this figure, the first row contains: Payment No. "N1000", Payment Date "2024 / 6 / 30", Store Code "SE2100", Store Name "△△ Co., Ltd.", Payment Method "Bank Transfer", Payment Amount "¥17,000", Payment Reconciled Amount "¥0", and Customer Category "1: Corporation". For payments from corporations, the outstanding receivables to be reconciled are aggregated.

[0068] Process (1) As shown in Figure 14(A), the collection schedule data is aggregated by corporation > collection schedule date, and items where the reason for debt generation is not a corporation (debt generation reasons "100", "200", "500" to "800" in the debt generation reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0069] Processing (2) As shown in Figure 14(B), the collection schedule data is aggregated by corporation > area group > collection schedule date, and items whose reason for debt is outside the area group (debt origination reasons "100" to "400", "700", and "800" in the debt origination reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0070] Processing (3) As shown in Figure 14(C), the collection schedule data is aggregated by corporation > area group > store > collection schedule date, and items where the reason for debt generation is other than store (debt generation reason "100" to "600" in the debt generation reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0071] Processing (4) The above list of reconciliation candidate patterns created in processes (1) to (3) is checked for matching or mismatching of amounts, starting with the candidates with the largest granularity, and automatic reconciliation is performed. Figure 15(A) shows an example of payment data (same as Figure 13), and Figure 15(B) shows an example of the list of reconciliation candidate patterns data (same as Figure 14(C)). As shown in Figures 15(A) and (B), for company: SE2100 (△△ Corporation), scheduled collection date: 2024 / 06 / 30, scheduled collection amount: ¥17,000, the amount matches the payment amount and becomes eligible for reconciliation.

[0072] Processing (5) For the reconciliation candidates identified in process (4), automatic reconciliation is performed, updating the recovered amount in the planned recovery data and updating the reconciled amount in the payment data. Figure 16(A) shows an example of planned recovery data after automatic reconciliation, and Figure 16(B) shows an example of payment data after automatic reconciliation. As shown in Figure 16(A), for company: SE2100 (△△ Holdings), planned recovery date: 2024 / 06 / 30, planned recovery amount: ¥17,000, the recovered amount: ¥17,000 is updated in bulk and treated as recovered. In addition, the reconciled amount in the payment data is updated to "¥17,000".

[0073] Next, we will explain the case where the deposit amount in the deposit data is different from the example above, referring to processes (4)' and (5)'.

[0074] Process (4)' Figure 17(A) shows another example of deposit data. As shown in Figure 17(A), the deposit amount is "¥31,000", and the other items are the same as in Figure 13.

[0075] The above list of reconciliation candidate patterns created in processes (1) to (3) is checked for matching or mismatching of amounts, starting with the candidates with the largest granularity, and automatic reconciliation is performed. Figure 17(B) shows an example of the list of reconciliation candidate patterns (same as Figure 15(B)). As shown in Figures 17(A) and (B), for the company: SE2100 (△△ Corporation), scheduled collection date: 2024 / 06 / 30, scheduled collection amount: ¥31,000, the amount matches the received amount and becomes eligible for reconciliation.

[0076] Process (5)' For the reconciliation candidates identified in process (4)', automatic reconciliation is performed, updating the recovered amount in the planned recovery data and updating the reconciled amount in the payment data. Figure 18(A) shows an example of planned recovery data after automatic reconciliation, and Figure 18(B) shows an example of payment data after automatic reconciliation. As shown in Figure 18(A), for company: SE2100 (△△ Corporation), planned recovery date: 2024 / 06 / 30, planned recovery amount: ¥31,000, the recovered amounts of ¥14,000 and ¥17,000 are updated together and treated as recovered. In addition, the reconciled amount in the payment data is updated to "¥31,000".

[0077] (When a lump-sum payment is made from the area group) Refer to Figures 19 to 24 to explain the case where a lump-sum payment is made from an area group. Figure 19 shows an example of payment data. In the example shown in the figure, the first row contains: Payment No. "N1000", Payment Date "2024 / 6 / 30", Store Code "SE3110", Store Name "Chubu / Kansai Area", Payment Method "Bank Transfer", Payment Amount "¥25,000", Payment Reconciled Amount "¥0", and Customer Classification "2: Area Group". For payments from area groups, the outstanding receivables to be reconciled are aggregated.

[0078] Process (1) As shown in Figure 20(A), the collection schedule data is aggregated by area group > collection schedule date, and items whose reason for debt generation is outside the area group (debt generation reasons "100" to "400", "700", and "800" in the debt generation reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0079] Processing (2) As shown in Figure 20(B), the collection schedule data is aggregated by area group > store > collection schedule date, and items where the reason for debt generation is other than store (debt generation reason "100" to "600" in debt generation reason master 106b) are excluded to calculate the candidate amount for reconciliation.

[0080] Processing (3) The above list of reconciliation candidate patterns created in processes (1) and (2) are checked for matching or mismatching of amounts, starting with the largest granularity of candidates, and automatic reconciliation is performed. Figure 21(A) shows an example of payment data (same as Figure 19), and Figure 21(B) shows an example of the list of reconciliation candidate patterns (same as Figure 20(B)). As shown in Figures 21(A) and (B), for area group: SE3110 (Chubu / Kansai region), scheduled collection date: 2024 / 06 / 30, scheduled collection amount: ¥25,000, the amount matches the payment amount and becomes eligible for reconciliation.

[0081] Processing (4) For the reconciliation candidates identified in process (3), automatic reconciliation is performed, updating the recovered amount in the planned recovery data and updating the reconciled amount in the payment data. Figure 22(A) shows an example of planned recovery data after automatic reconciliation, and Figure 22(B) shows an example of payment data after automatic reconciliation. As shown in Figure 22(A), for area group: SE3110 (Chubu / Kansai area), planned recovery date: 2024 / 06 / 30, planned recovery amount: ¥25,000, the recovered amounts of ¥3,000 and ¥22,000 are updated together and treated as recovered. In addition, the reconciled amount in the payment data is updated to "¥25,000".

[0082] Next, we will explain the case where the deposit amount in the deposit data is different from the example above, referring to processes (3)' and (4)'.

[0083] Process (3)' Figure 23(A) shows another example of deposit data. As shown in Figure 23(A), the deposit amount is "¥3,000", and the other items are the same as in Figure 19.

[0084] The above list of reconciliation candidate patterns created in processes (1) and (2) is checked for matching or mismatching of amounts, starting with the largest granularity of candidates, and automatic reconciliation is performed. Figure 23(B) shows an example of the list of reconciliation candidate patterns (same as Figure 21(B)). As shown in Figures 23(A) and (B), for area group: SE3110 (Chubu / Kansai area), scheduled collection date: 2024 / 06 / 30, and scheduled collection amount: ¥3,000, the amount matches the received amount and becomes eligible for reconciliation.

[0085] Process (4)' For the reconciliation candidates identified in process (3)', automatic reconciliation is performed, updating the recovered amount in the planned recovery data and updating the reconciled amount in the payment data. Figure 24(A) shows an example of planned recovery data after automatic reconciliation, and Figure 24(B) shows an example of payment data after automatic reconciliation. As shown in Figure 24(A), for area group: SE3110 (Chubu / Kansai area), planned recovery date: 2024 / 06 / 30, planned recovery amount: ¥3,000, the recovered amount: ¥3,000 is updated in bulk and treated as recovered. In addition, the reconciled amount in the payment data is updated to "¥3,000".

[0086] As described above, according to this embodiment, a billing address master 106a is registered by associating specific information for identifying the customer from whom the receivable is received, one or more customers, and a customer classification for specifying the granularity of the customer; a receivable origination reason master 106b is registered by associating the reason for the receivable with the customer classification; a collection schedule data creation unit 102b creates collection schedule data including multiple customers, a collection schedule date, a collection schedule amount, a collected amount, and the reason for the receivable; and a payment processing unit creates payment data including the payment date, specific information, payment amount, a payment settlement amount, and a customer classification obtained from the billing address master 106a using the specific information as a key. 102c and the billing master 106a are provided, and the reconciliation processing unit 102d aggregates the planned collection amount of the collection schedule data by the collection schedule date, in order from the smallest granularity of the customer specified in the customer category of the payment data to the smallest granularity of the customer, and at that time excludes records other than the customer category of the receivable reason master 106b that are linked to the reason for the creation of the receivable in the collection schedule data, and creates a list of reconciliation candidate patterns data, and then compares the planned collection amount and the payment amount in the list of reconciliation candidate patterns in order of the smallest granularity of the customer to perform automatic reconciliation. As such, even if the source of payment for the receivable changes each time, it is possible to achieve payment reconciliation with high accuracy and low workload.

[0087] [4. 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.

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

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

[0090] [5. 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.

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

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

[0093] Furthermore, with respect to the deposit reconciliation device 100, each component shown in the illustration is a functional concept and does not necessarily need to be physically configured as shown.

[0094] For example, the processing functions of the deposit reconciliation 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 deposit reconciliation 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.

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

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

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

[0098] The various databases stored in the memory unit are 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 website provision.

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

[0100] 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. [Explanation of Symbols]

[0101] 100 Deposit Reconciliation Device 102 Control Unit 102a Master Maintenance Department 102b Data Collection Department 102c Deposit Processing Unit 102d Removal Processing Unit 102e Screen display control unit 104 Communication Interface Section 106 Storage section 106a Billing Address Master 106b Master of Reasons for Debt Generation 108 Input / Output Interface Section 112 Input device 114 Output device 300 Networks 400 devices

Claims

1. A deposit reconciliation device equipped with a control unit, The control unit, A billing master registers a list of specific information for identifying the customer from whom the payment is received for the receivable, one or more customers, and customer classifications for specifying the granularity of the customers. The receivables generation reason master, which is registered by associating the reason for receivable generation with the customer category, Collection schedule data including multiple business partners, scheduled collection dates, scheduled collection amounts, collected amounts, and reasons for debt generation, It is configured to be accessible, A payment entry means for creating payment data that includes the payment date, specific information, payment amount, payment reconciled amount, and customer classification obtained from the aforementioned billing master using the specific information as a key. In the aforementioned billing master, the planned collection amount of the collection schedule data is aggregated by the collection schedule date, starting from the smallest granularity of the customer specified in the customer category of the payment data, and records other than the customer category of the reason for the occurrence of the collection data linked to the reason for the occurrence of the collection schedule data are excluded to create a list of reconciliation candidate patterns, and the planned collection amount and payment amount in the list of reconciliation candidate patterns are compared in order of the smallest granularity of the customer to perform automatic reconciliation. A deposit reconciliation device characterized by being equipped with the following features.

2. The payment reconciliation device according to claim 1, characterized in that the automatic reconciliation updates the amount of the scheduled collection data that has been collected and the amount of the payment data that has been reconciled.

3. The aforementioned business partners and business partner categories include affiliated corporate groups, corporations, area groups, and stores. The granularity of the aforementioned business partners is in the following order: affiliated corporate group > corporation > area group > store. The payment reconciliation device according to claim 1, characterized in that the recipient of the aforementioned claim is a store.

4. The deposit reconciliation device according to any one of claims 1 to 3, characterized in that the aforementioned claim is a claim relating to the installation or replacement of amusement machines or game machines in a store.

5. A deposit reconciliation method performed by an information processing device equipped with a control unit, The control unit, A billing master registers a list of specific information for identifying the customer from whom the payment is received for the receivable, one or more customers, and customer classifications for specifying the granularity of the customers. The receivables generation reason master, which is registered by associating the reason for receivable generation with the customer category, Collection schedule data including multiple business partners, scheduled collection dates, scheduled collection amounts, collected amounts, and reasons for debt generation, It is configured to be accessible, The control unit is executed as follows: A payment entry process that creates payment data including the payment date, specific information, payment amount, payment reconciled amount, and customer classification obtained from the aforementioned billing master using the specific information as a key. In the aforementioned billing master, the planned collection amount of the collection schedule data is aggregated by the collection schedule date, starting from the smallest granularity of the customer specified in the customer category of the payment data, and records other than the customer category of the reason for the occurrence of the collection data linked to the reason for the occurrence of the collection schedule data are excluded to create a list of reconciliation candidate patterns, and the planned collection amount and payment amount in the list of reconciliation candidate patterns are compared in order of the smallest granularity of the customer to perform automatic reconciliation. A method for reconciling payments, characterized by including the following:

6. A deposit reconciliation program to be executed by an information processing device equipped with a control unit, The control unit, A billing master registers a list of specific information for identifying the customer from whom the payment is received for the receivable, one or more customers, and customer classifications for specifying the granularity of the customers. The receivables generation reason master, which is registered by associating the reason for receivable generation with the customer category, Collection schedule data including multiple business partners, scheduled collection dates, scheduled collection amounts, collected amounts, and reasons for debt generation, It is configured to be accessible, The control unit, A payment entry process that creates payment data including the payment date, specific information, payment amount, payment reconciled amount, and customer classification obtained from the aforementioned billing master using the specific information as a key. In the aforementioned billing master, the planned collection amount of the collection schedule data is aggregated by the collection schedule date, starting from the smallest granularity of the customer specified in the customer category of the payment data, and records other than the customer category of the reason for the occurrence of the collection data linked to the reason for the occurrence of the collection schedule data are excluded to create a list of reconciliation candidate patterns, and the planned collection amount and payment amount in the list of reconciliation candidate patterns are compared in order of the smallest granularity of the customer to perform automatic reconciliation. A payment reconciliation program to execute this.

Images