JP7723372B2 - Automatic journal entry program - Google Patents

Description

This embodiment relates to an automatic accounting program.

In recent years, automation of accounting work has been promoted as one way to improve the efficiency of accounting operations. For example, there are known devices that perform accounting work by inputting document data such as invoices to be accounted for. Known methods for this type of automated accounting work include rule-based methods and methods that use artificial intelligence.

International Publication No. 2018/179411

In automatic accounting, the details of various transactions listed on documents such as invoices are entered into account items in accordance with various pre-defined rules, such as tax rules and company rules. However, the way transaction details are recorded on invoices and other documents often varies greatly due to differences in various conditions, such as differences in industry and operations. If the details of transactions on invoices and other documents vary greatly, the automatic accounting process becomes more complicated, accounting processing takes more time, and there is a higher chance of errors in the resulting entries.

The present embodiment aims to provide an automatic accounting program that can reduce the complexity of accounting processing while improving the accuracy of accounting entries, even when there is a large variation in the description of transaction details.

According to one aspect, the automatic journalizing program is a file processing program that causes a processor to accept input of data on different items representing the contents of multiple transactions and amounts related to each item, aggregate the input different items into one item based on predetermined aggregation rules, calculate the total amount related to the aggregated items, and perform automatic journalizing for the aggregated items.

According to the embodiment, an automatic accounting program can be provided that can reduce the complexity of accounting processing while improving accounting accuracy, even when there is a large variation in the description of transaction details or in the types of expenses listed in the details.

FIG. 1 is a diagram illustrating an example of a configuration of a terminal according to an embodiment. FIG. 2 is a diagram illustrating an example of the aggregation rule. FIG. 3 is a flowchart showing the process of setting aggregation rules in a terminal. FIG. 4 is a diagram showing an example of an aggregation rule setting screen. FIG. 5 is a flowchart illustrating an example of the aggregation process and the journalization process. FIG. 6 is a flowchart illustrating an example of the aggregation process. FIG. 7 is a diagram showing an example of invoice data. FIG. 8 is a diagram illustrating an example of the aggregation result. FIG. 9 is a diagram showing an example of a journalization result.

Embodiments will be described below with reference to the drawings. Figure 1 is a diagram showing the configuration of an example of a terminal according to an embodiment. As shown in Figure 1, terminal 1 has a processor 11, memory 12, storage 13, input interface 14, display 15, and communication module 16. Processor 11, memory 12, storage 13, input interface 14, display 15, and communication module 16 are connected to bus 17 so that they can communicate with each other. Here, terminal 1 may be a terminal such as a smartphone, tablet terminal, or personal computer.

Processor 11 is a processor configured to control the operation of terminal 1. Processor 11 executes various processes in accordance with various programs stored in storage 13. Processor 11 is, for example, a CPU. Processor 11 may not be a CPU, but may instead be an MPU, GPU, etc. Furthermore, processor 11 does not have to be composed of a single CPU, etc., but may be composed of multiple CPUs, etc.

Memory 12 includes memory such as ROM and RAM. ROM is non-volatile memory. ROM stores the startup program for terminal 1, etc. RAM is volatile memory. RAM is used, for example, as working memory during processing by processor 11.

Storage 13 is a storage device such as a flash memory. Storage 13 stores various programs and data used by terminal 1. In the embodiment, storage 13 stores an OS (operating system) 131, an automatic journalizing program 132, and aggregation rules 133. Storage 13 may also store programs other than OS 131 and automatic journalizing program 132.

OS 131 is a program that realizes the basic functions of terminal 1. Various programs stored in storage 13 are executed under the control of the OS.

The automatic journalizing program 132 is a program that causes the processor 11 to execute automatic journalizing processing. Automatic journalizing processing is a process that classifies input transactions into appropriate account items according to their content and calculates the amount for each account item. The content of the transaction is entered in a document such as an invoice, or data containing content equivalent to a document. In this case, the automatic journalizing program 132 causes the processor 11 to execute processing that recognizes the content of the transaction from character strings in the document, etc., and classifies the recognized content of the transaction into account items. The automatic journalizing program 132 can be installed on the terminal 1 as needed. Note that the transactions in the embodiment are not particularly limited as long as they are transactions that can be subject to automatic journalizing.

In addition, in the embodiment, the automatic journalizing program 132 causes the processor 11 to execute an aggregation process prior to the actual automatic journalizing process. The aggregation process aggregates input transactions according to predetermined rules. The aggregation result here is the content of multiple transactions summarized under a single heading according to the aggregation rules 133. In the actual automatic journalizing process, journalizing to an account item is performed for each aggregation result. Here, journalizing to an account item may be performed using any method. For example, journalizing to an account item may be performed rule-based or using a trained model. When journalizing to an account item is performed rule-based, the journalizing rule is a journalizing rule between the aggregation result and the account item. Similarly, when journalizing to an account item is performed using a trained model, the model is configured to input the aggregation result and output the account item as the journalizing result. The model may use various classification models such as an SVM (support vector machine) or a neural network.

The aggregation rules 133 are rules for executing the aggregation process. Some aggregation rules 133 may be set, for example, when the automatic accounting program 132 is installed. Aggregation rules 133 may be added by the user of the terminal 1. Here, the aggregation rules 133 do not necessarily have to be stored in the storage 13, but may also be stored on a server or the like external to the terminal 1. In this case, the terminal 1 obtains the aggregation rules 133 from the external server or the like as needed.

Figure 2 is a diagram showing an example of an aggregation rule 133. The example aggregation rule 133 is a rule for determining partial matches of character strings. The example aggregation rule 133 shown in Figure 2 has three items: "Aggregation result," "Condition (includes)," and "Condition (does not include)."

The "aggregation result" is the name to which transactions are aggregated when the conditions are met. The names associated with the "aggregation result" include those that are pre-set when the automatic accounting program 132 is created. The names associated with the "aggregation result" also include those added by the user. In an embodiment, the contents of transactions aggregated into the same aggregation result are classified into the same account item.

"Condition (includes)" and "Condition (does not include)" are string conditions for aggregating into the corresponding aggregated results.

If the string to be aggregated contains a string set in the "Condition (includes)" field, the string to be aggregated will be aggregated into the corresponding "Aggregation Result." For example, in Figure 2, the "Condition (includes)" field for the aggregation result "Advertising/Promotion" is set to "Advertising," "Submission," and "Publication Fee." In this case, if the string to be aggregated contains any of "Advertising," "Submission," or "Publication Fee," the string to be aggregated will be aggregated into the aggregation result "Advertising/Promotion."

Furthermore, if a string set in "Condition (Excludes)" is included in the string to be aggregated, that string will not be aggregated into the corresponding "Aggregation Result," even if the string set in "Condition (Includes)" is also included in the string to be aggregated. For example, in Figure 2, "Advertising Production" is set as the "Condition (Excludes)" for the aggregation result "Advertising/Promotion." In this case, if the string to be aggregated is "Advertising Production," it will not be aggregated into the aggregation result "Advertising/Promotion," even though it contains "Advertising." By being able to set "Condition (Excludes)," situations in which transaction contents are aggregated based on simple partial matches, resulting in undesired journal entries by the user, can be prevented.

The aggregation rule 133 shown in Figure 2 is an example. The aggregation rule 133 may include conditions other than the partial string match condition shown in Figure 2. For example, in the case of donations, it may be better to journalize them into different sub-accounts depending on the organization or group to which they were donated. In addition, payments to important business partners may be listed separately and therefore not be aggregated with other payments. Also, invoices from a specific business partner may refer to rent as "office." While "office" would normally not be aggregated into the aggregation result "rent, etc.", it may be better for "office" to be aggregated into the aggregation result "rent, etc." for that particular business partner. If transactions with the same string that should be journalized into different account items are combined under a single heading, subsequent journalization processing may not be performed appropriately. For this reason, the aggregation rule 133 may also include a condition regarding the payee. The aggregation rule 133 may also include various other conditions, such as a condition regarding the amount. By including a monetary amount condition in the aggregation rule 133, for example, even if the string condition results in the same aggregation result, different amounts may result in different aggregation results. Furthermore, the aggregation rule 133 may be saved along with each aggregation result for evaluation and analysis of the aggregation results.

The input interface 14 includes input devices such as a touch panel, keyboard, and mouse. When the input interface 14 is operated, a signal corresponding to the operation is input to the processor 11 via the bus 17. The processor 11 performs various processes in response to this signal. Here, the input device may include a camera. The camera is used to capture an image of a document such as an invoice. The character string to be journalized can be recognized from the image of the document captured by the camera.

Display 15 is a display device such as a liquid crystal display or an organic EL display. Display 15 displays various images.

The communication module 16 is a module including an interface configured to process communication between the terminal 1 and various external devices. The communication module 16 is configured to connect to a network using a mobile phone line, a wireless LAN line, a wired LAN line, etc. Alternatively, the communication module 16 is configured to connect to devices near the terminal 1 using short-range wireless communication such as Bluetooth (registered trademark). Furthermore, by connecting a storage device storing specific aggregation rules to the communication module 16, it is possible to automatically set specific aggregation rules on the terminal 1. This makes it possible to automatically operate a general-purpose terminal as a dedicated terminal.

Next, the operation of the terminal 1 based on the automatic journalizing program 132 in this embodiment will be described. Figure 3 is a flowchart showing the process of setting aggregation rules for the automatic journalizing program 132 on the terminal 1. The process in Figure 3 is initiated, for example, when a user of the terminal 1 instructs the automatic journalizing program 132 to be started.

In step S1, the processor 11 of the terminal 1 determines whether or not an instruction to set an aggregation rule has been issued. For example, if the aggregation rule setting button is selected on an initial screen (not shown) that is displayed on the display 15 when the automatic journalizing program 132 is launched, it is determined that an instruction to set an aggregation rule has been issued. If it is determined in step S1 that an instruction to set an aggregation rule has been issued, the process proceeds to step S2. If it is not determined in step S1 that an instruction to set an aggregation rule has been issued, the process proceeds to step S7.

In step S2, the processor 11 displays an aggregation rule setting screen on the display 15.

Figure 4 shows an example of an aggregation rule setting screen. The aggregation rule setting screen 150 is a screen that includes, for example, an aggregation result input field 151, a condition (inclusive) input field 152, and a condition (exclusive) input field 153.

The aggregation result input field 151 is an input field for the name associated with the "aggregation result" of the aggregation rule 133. The user can directly input a string representing the name of the aggregation result into the aggregation result input field 151. Alternatively, the user can select the name of the desired aggregation result from a drop-down list displayed by selecting the pull-down button 151a provided in the aggregation result input field 151. The drop-down list displays a list of names set as default values and names newly added by the user.

The condition (including) input field 152 is an input field for the "condition (including)" of the aggregation rule 133. In the condition (including) input field 152, the user can enter a list of character strings representing the transaction details that the user wants to aggregate into the corresponding aggregation result. If only a partial character string of the transaction details is entered, the aggregation process will determine whether the character strings match. If the entire character string of the transaction details is entered, the aggregation process will determine whether the entire character string matches. Here, in Figure 4, each character string in the "condition (including)" is distinguished by starting a new line after each character string. However, each character string in the "condition (including)" may also be distinguished using other methods, such as entering character strings with commas between them.

The condition (excluding) input field 153 is an input field for the "condition (excluding)" of the aggregation rule 133. In the condition (excluding) input field 153, the user can enter a list of character strings representing transaction details that the user does not want aggregated into the corresponding aggregation results. If a partial character string of the transaction details is entered, the aggregation process will determine whether the character strings match. If the entire character string of the transaction details is entered, the aggregation process will determine whether the entire character string matches. Here, as with the condition (including) input field 152, the condition (excluding) input field 153 may also distinguish between the "condition (excluding)" character strings by starting each string on a new line or by inserting commas between strings.

Furthermore, the aggregation rule setting screen 150 may include a save button 154 and a back button 155. The save button 154 is a button selected by the user to save the content entered in each input field as an aggregation rule 133 and return to the initial screen. The back button 155 is a button selected by the user to return to the initial screen without saving the content entered in each input field as an aggregation rule 133.

Here, if the aggregation rule 133 includes other conditions such as amount, the aggregation rule setting screen 150 may also include input fields corresponding to each condition. Also, in Figure 4, two buttons, Save button 154 and Back button 155, are provided, but Save button 154 and Back button 155 may be omitted as long as the same processing as these buttons can be performed. Also, buttons other than Save button 154 and Back button 155 may be provided.

Returning to the description of Figure 3, in step S3, the processor 11 updates the display of the aggregation rule setting screen 150 in accordance with the user's input operation. For example, the processor 11 displays character strings in accordance with the input operation of character strings into each of the aggregation result input field 151, the condition (inclusive) input field 152, and the condition (exclusive) input field 153.

In step S4, processor 11 determines whether to save the aggregation rule. For example, if the save button 154 is selected, it is determined that the aggregation rule is to be saved. If it is determined in step S4 that the aggregation rule is to be saved, processing proceeds to step S6. If it is not determined in step S4 that the aggregation rule is to be saved, processing proceeds to step S5.

In step S5, the processor 11 determines whether to return from the aggregation rule setting screen 150. For example, if the back button 155 is selected, it is determined that the user should return. If it is not determined in step S5 that the user should return from the aggregation rule setting screen 150, the process returns to step S3. In this case, the aggregation rule can be subsequently set on the aggregation rule setting screen 150. If it is determined in step S5 that the user should return from the aggregation rule setting screen 150, the process proceeds to step S7. In this case, the processor 11 returns the display on the display 15 to the initial screen.

In step S6, processor 11 updates or adds aggregation rule 133 based on the content entered in each field of aggregation rule setting screen 150. When the name entered in aggregation result input field 151 is a name that is already registered in the "Aggregation result" field of aggregation rule 133, processor 11 updates the corresponding "Condition (included)" and "Condition (excluded)" fields based on the input content in condition (included) input field 152 and condition (excluded) input field 153. On the other hand, when the name entered in aggregation result input field 151 is a name that is not registered in the "Aggregation result" field of aggregation rule 133, processor 11 adds the "Aggregation result," "Condition (included)," and "Condition (excluded)" fields of aggregation rule 133. Then, processor 11 registers the name entered in aggregation result input field 151 in the newly added "Aggregation Result" field, while registering the input contents of condition (inclusive) input field 152 and condition (exclusive) input field 153 in the newly added "Condition (inclusive)" and "Condition (exclusive)" fields. After that, processor 11 returns the display on display 15 to the initial screen. Then, processing proceeds to step S7.

In step S7, the processor 11 determines whether or not to terminate the processing of the automatic journalizing program 132. For example, it determines that the processing is to be terminated when the end button displayed on the initial screen (not shown) is selected. If it is not determined in step S7 that the processing of the automatic journalizing program 132 is to be terminated, the processing returns to step S1. If it is determined in step S7 that the processing of the automatic journalizing program 132 is to be terminated, the processing of FIG. 3 ends.

Next, the aggregation process and journalizing process will be explained. Figure 5 is a flowchart showing the aggregation process and journalizing process. The process in Figure 5 is initiated, for example, when the user of terminal 1 inputs data to be journalized on an initial screen (not shown) that is displayed when the automatic journalizing program 132 is started. Here, the input data to be journalized may be data in various formats, such as text data representing the contents of a document such as an invoice, tabular data representing the contents of a document such as an invoice, or image data of a document such as an invoice. In addition, the data to be journalized may be a digital invoice in a specified format.

In step S11, processor 11 executes aggregation processing. After the aggregation processing, processing proceeds to step S12. The aggregation processing will be described below with reference to Figure 6. Figure 6 is a flowchart showing an example of the aggregation processing.

In step S101, processor 11 determines whether the input data is image data. If it is determined in step S101 that the input data is image data, processing proceeds to step S102. If it is determined in step S101 that the input data is not image data, processing proceeds to step S103.

In step S102, processor 11 performs character recognition on the input image data. Character recognition may be performed using any method.

In step S103, processor 11 obtains one name string from the input data. For example, if the input data is text data, processor 11 obtains the name strings in the order in which they were input. Also, for example, if the input data is tabular data, processor 11 obtains the name strings in order from the top row. Also, for example, if the input data is image data, processor 11 obtains the name strings in the order in which character recognition was performed.

In step S104, the processor 11 obtains an aggregation rule for one "aggregation result" from the aggregation rules 133. For example, the processor 11 obtains the aggregation rules in order from the top of Figure 2.

In step S105, processor 11 determines whether the acquired name string matches the acquired "condition (inclusive)." For example, if the acquired name string contains any of the strings listed in the corresponding "condition (inclusive)," it is determined that the acquired name string matches the acquired "condition (inclusive)." If it is determined in step S105 that the acquired name string matches the acquired "condition (inclusive)," processing proceeds to step S106. If it is not determined in step S105 that the acquired name string matches the acquired "condition (inclusive)," processing proceeds to step S108.

In step S106, processor 11 determines whether the acquired name string matches the "condition (excludes)" of the "aggregation result" that was previously determined to match the "condition (includes)." For example, if the acquired name string contains any of the strings listed in the corresponding "condition (excludes)," it is determined that the acquired name string matches the acquired "condition (excludes)." If in step S106 it is not determined that the acquired name string matches the acquired "condition (excludes)," processing proceeds to step S107. If in step S106 it is determined that the acquired name string matches the acquired "condition (excludes)," processing proceeds to step S108.

In step S107, processor 11 aggregates the acquired names into the acquired "aggregated result." When aggregating, processor 11 adds the amount of the corresponding name to the amount of the corresponding aggregated result. Processing then proceeds to step S109. That is, in this embodiment, when the "condition (includes)" is met but the "condition (does not include)" is not met, the corresponding name is aggregated into the corresponding "aggregated result."

In step S108, processor 11 determines whether all aggregation rules have been acquired, i.e., whether a judgment based on all aggregation rules has been performed on the acquired nominal string. If it is determined in step S108 that all aggregation rules have not been acquired, processing returns to step S104. In this case, processor 11 acquires the next aggregation rule. If it is determined in step S108 that all aggregation rules have been acquired, processing proceeds to step S109.

In step S109, processor 11 determines whether all name strings have been acquired, i.e., whether all name strings have been judged based on all aggregation rules. If it is determined in step S109 that all name strings have not been acquired, processing returns to step S103. In this case, processor 11 acquires the next name string. If it is determined in step S109 that all name strings have been acquired, processing proceeds to step S110.

In step S110, the processor 11 displays the aggregation results on the display 15. The user can edit the aggregation results on the aggregation result display screen. After editing is complete, the processing in Figure 6 ends.

The processing in Figure 6 will be explained in detail below. The following explanation uses the aggregation process for the invoice data shown in Figure 7 as an example. The transaction in this case is payment for various products. The invoice data shown in Figure 7 has the following fields: "No.", "Product Name," "Quantity," "Unit Price," and "Amount." "No." is a serial number assigned to each product. "Product Name" is the name of the corresponding product. "Quantity" is the number of corresponding products. "Unit Price" is the price of one unit of the corresponding product. "Amount" is the total payment amount for the corresponding product, i.e., the product of "Quantity" and "Unit Price." Note that each field of the invoice data shown in Figure 7 is set appropriately based on business operations, etc., and is not particularly limited.

As part of the aggregation process, processor 11 sequentially retrieves the nominal strings from the input data. For example, in the case of the invoice data shown in Figure 7, processor 11 retrieves the strings "rent," "management fee," "waste disposal fee," "electricity fee," and "after-hours air conditioning fee" in that order.

Then, processor 11 sequentially acquires the aggregation rules. For example, in the case of the aggregation rules shown in Figure 2, the aggregation rules would be acquired in the following order: "Advertising/Promotion," "Commissions," "Miscellaneous Membership Fees," "Donations," "Transportation," "Rent, etc.", "Parking Fees," "Utility Fees," etc.

The processor 11 then determines whether the character string of the acquired title matches the acquired "conditions (including)." For example, the character string "Rent" in the product name shown in Figure 7 does not contain any of the character strings listed in the aggregation results "Advertising/Promotion," "Commission," "Miscellaneous Membership Fees," "Donations," or "Shipping." Therefore, it is determined that the character string "Rent" does not match any of the "conditions (including)" of the aggregation results "Advertising/Promotion," "Commission," "Miscellaneous Membership Fees," "Donations," or "Shipping." On the other hand, the character string "Rent" contains the character string "Rent" listed in the "Conditions (including)" of the aggregation result "Rent, etc." Therefore, it is determined that the character string "Rent" matches the "conditions (including)" of the aggregation result "Rent, etc."

If there is a "condition (includes)" that matches the acquired name string, processor 11 determines whether the name string matches the corresponding "condition (excludes)." For example, the string "rent" contains the string "rent" listed in the "condition (includes)" of the aggregation result "rent, etc." On the other hand, the string "rent" does not contain any of the strings listed in the "condition (excludes)" of the aggregation result "rent, etc." Therefore, it is determined that the string "rent" does not match the "condition (excludes)" of the aggregation result "rent, etc."

As a result, the string "Rent" is aggregated into the aggregation result "Rent, etc." A similar determination is made for each product name string. Here, strings that do not match any of the "Conditions (including)" will remain without being aggregated.

As a result of the above, the aggregation result for the invoice data shown in Figure 7 is as shown in Figure 8. In the example of Figure 8, the aggregation result has the fields "Original No.", "Item," and "Amount." "Original No." is a field that indicates the "No." of each product name aggregated in the corresponding aggregation result. "Item" is the nominal item associated with the aggregation result. Here, it is written as "item" because it is an aggregation result for invoice data. "Amount" is the total "Amount" of each product aggregated in the corresponding aggregation result. In other words, the "Amount" in Figure 8 is the total "Amount" of the "Number" indicated by the "Original No.". Therefore, for example, when the "Original No." is 1 or 2, the "Amount" in Figure 8 is 2,500,000 + 500,000 = 3,000,000 yen.

The processor 11 displays the aggregation result shown in FIG. 8 on the display 15. The user can edit the aggregation result displayed on the display 15. After editing is complete, the processing of FIG. 6 ends.

Now, returning to the explanation of Figure 5, in step S12 after the aggregation process, processor 11 executes journalization processing. As described above, journalization processing is executed on the aggregation results. After journalization processing, processing proceeds to step S13. Figure 9 is a diagram showing an example of the journalization results. As shown in Figure 9, the journalization processing journalizes the transaction details shown in Figure 7 into predetermined account items.

In step S13, the processor 11 displays the journal entry results on the display 15. The user can edit the journal entry results on the journal entry result display screen. After editing is complete, the screen transitions to the initial screen, and processing proceeds to step S14.

In step S14, the processor 11 determines whether or not to terminate the processing of the automatic journalizing program 132. For example, it determines that the processing is to be terminated when the end button displayed on the initial screen (not shown) is selected. If it is not determined in step S14 that the processing of the automatic journalizing program 132 is to be terminated, the processing returns to step S11. If it is determined in step S14 that the processing of the automatic journalizing program 132 is to be terminated, the processing of FIG. 5 ends.

As described above, according to the embodiment, in automatic journal entry processing, the contents of transactions entered before the actual journal entry processing is performed are aggregated according to predetermined aggregation rules. This reduces the complexity of the processing, whether the journal entry processing for invoices and other documents with various contents is performed rule-based or using a trained model. Furthermore, as the complexity of the processing is reduced, the accuracy of the journal entry processing is expected to improve. Furthermore, it is expected that the number of rules set in the journal entry processing and the amount of training data required to train the trained model will also be reduced.

In addition, in the embodiment, aggregation processing is performed based on rules that involve partial string matching. This is expected to reduce the processing load. Furthermore, because the rules can be defined by the user, it is expected that appropriate aggregation will be performed based on operations, etc. Furthermore, partial string matching rules can be set not only for conditions that include specific strings, but also for conditions that do not include specific conditions. This is expected to prevent journal entries that the user does not intend to make.

(Modification)
Modifications of the embodiment are described below. As described above, in the embodiment, rule-based aggregation processing is performed. Therefore, it is possible that appropriate aggregation will not be performed if the number of defined rules is small or if the input data contains many deviations from the rules. On the other hand, depending on the content of the journal entry, detailed journal entry for each transaction may not be necessary in the first place; for example, the entire invoice may be combined into a single journal entry. Taking this into consideration, the processor 11 may aggregate the contents of all input data into a single aggregated result when the following conditions are met. Furthermore, the progress of the aggregation processing can be monitored, and the aggregation rules can be changed even during processing, enabling more efficient derivation of optimal aggregation rules.
1) The total amount of the input data is the same as the amount of the aggregation result.
2) The aggregated results are consolidated into one.
3) It has been aggregated in the same way a certain number of times in succession.

Here, it is desirable that the determinations in 1), 2), and 3) be made based on the aggregation results edited by the user. For example, if a user has edited the aggregation results based on partial matches a certain number of times in the past to aggregate the aggregation results for the same combination under a specific name, and the amount of the data entered in each edited result is the same as the amount of the aggregation result, the post-edit aggregation result is learned. Then, from the next time onwards, the same combination of names for the same payee is entered, those names may be aggregated under the learned name. By adding this type of modified processing, the number of times partial string matches are determined is reduced, and it is expected that the load on the aggregation process will be further reduced.

In addition, in the embodiment, the aggregation process and journalizing process by the automatic journalizing program 132 are both performed on terminal 1. However, the aggregation process and journalizing process may also be performed on a device other than terminal 1, such as a server with which terminal 1 can communicate. In this case, the aggregation rules 133 are stored in storage on the server or the like. Furthermore, the results of aggregation processes performed on multiple terminals 1, the results of journalizing processes, and the aggregation rules may be sent to a server or the like, and the results may be analyzed and evaluated on the server or the like. Then, the optimal aggregation rule may be derived based on the results of the analysis and evaluation of the multiple results. Needless to say, if the data before aggregation is also sent at this time, more detailed analysis and evaluation is possible.

In addition, in the embodiment, the aggregation process is performed on a rule-based basis. However, the aggregation process may also be performed using a trained model that has learned the relationship between transaction content and aggregation results.

Furthermore, each process according to the above-described embodiment can be stored as a program that can be executed by processor 11, which is a computer. Alternatively, the program can be stored and distributed on a storage medium of an external storage device such as a magnetic disk, optical disk, or semiconductor memory. Processor 11 can then load the program stored on the storage medium of this external storage device, and its operation can be controlled by the loaded program, thereby executing the above-described process.

The present invention is not limited to the above-described embodiments, and various modifications can be made in the implementation stage without departing from the spirit of the invention. Furthermore, the various embodiments may be implemented in appropriate combinations, in which case the combined effects can be obtained. Furthermore, the above-described embodiments include various inventions, and various inventions can be extracted by combining selected elements from the multiple elements disclosed. For example, if the problem can be solved and the desired effect can be obtained even if some elements are deleted from all elements shown in the embodiments, the configuration from which these elements are deleted can be extracted as an invention.

1 terminal, 11 processor, 12 memory, 13 storage, 14 input interface, 15 display, 16 communication module, 17 bus, 132 automatic sorting program, 133 aggregation rule.

Claims (4)

Accepting input of data on a plurality of different items representing the contents of a plurality of transactions and amounts related to each item;
Aggregating the input different names into one name based on a predetermined aggregation rule;
calculating the total amount of money related to the aggregated items;
Performing automatic journal entries for aggregated items;
An automatic journal entry program for causing a processor to execute the above. The aggregation rule is a partial match rule for the character string of the name,
aggregating the plurality of names includes, when the input name string includes a first string associated with a name predetermined for each aggregation result, aggregating the input name string into a corresponding aggregation result;
The automatic journalizing program according to claim 1. Aggregating the plurality of names includes causing the processor to execute the following: when the input name string includes a second character string associated with a name predetermined for each aggregation result, the input name string is not aggregated into a corresponding aggregation result even when the input name string includes a first character string associated with a name predetermined for each aggregation result.
The automatic journalizing program according to claim 2. The automatic journalizing program of claim 1 further causes the processor to execute the following steps: The automatic journalizing program of claim 1 further causes the processor to prompt the user to set the aggregation rules.