A method of an automatic matching tool for associated transactions, dealings, and cash flows
Patent Information
- Application Number
- CN202611146717.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-30
- Publication Date
- 2026-10-09
AI Technical Summary
然而实务中财务人员仅在会计摘要中记录交易对手单位名称，未规范维护辅助核算字段，软件无法识别该类内部交易、往来，从而造成大量交易、往来数据遗漏，抵销数据源不完整
[0019]第三方面，本发明提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如第一方面所述的关联交易、往来、现金流自动匹配工具方法的步骤。
Smart Images
Figure CN122887623A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of matching tool technology, specifically relating to an automatic matching tool and method for related transactions, intercompany transactions, and cash flows. Background Technology
[0002] As conglomerates continue to expand their operations, numerous internal purchase and sale transactions, internal receivables and payables, and internal cash flow transfers arise between parent and subsidiary companies and sister companies within the group. In accordance with the standards for preparing consolidated financial statements, auditors must eliminate all internal transactions, balances, and cash flows item by item. Simultaneously, they must verify any abnormal transactions, balances, and cash flows with unilateral outstanding balances to eliminate duplicate data within the group, improve data quality, and meet the compliance requirements for financial reporting disclosure and audit verification.
[0003] Currently, the industry mainly uses two solutions to handle intra-group related transactions, accounts receivable and payable, and cash flow offsetting: manual verification and automated processing by commercial financial and auditing software. However, both solutions have insurmountable technical flaws. First, commercial financial and auditing software has limitations in its data identification logic and insufficient data extraction completeness. Commercial financial systems such as SAP and Oracle, and auditing software like AuditEasy and Cloud Audit, rely heavily on dedicated auxiliary accounting fields in their consolidation and elimination modules to mark related parties, lacking a data cleaning process. However, in practice, finance personnel only record the names of counterparty entities in the accounting summary, failing to maintain the auxiliary accounting fields properly. The software cannot identify these internal transactions, resulting in significant omissions of transaction data and incomplete elimination data sources. Furthermore, existing software relies solely on balance sheets and chronological ledgers for elimination, making it incompatible with independently stored cash flow statements. This means that internal cash flow elimination within the group still requires manual processing, resulting in incomplete automation coverage.
[0004] Second, the current software's summary display of offsetting results makes audit tracing difficult. Traditional software only outputs vertically summarized offsetting entries and displays only the final offsetting amount for each standard accounting item, failing to show the matching details of individual transactions, accounts receivable / payable, and cash flows. When discrepancies appear in consolidated financial statements, finance and audit personnel cannot quickly locate the source of the discrepancy, making it difficult to distinguish which specific transaction, account receivable / payable, or cash flow has issues such as unilateral recording, inconsistent amounts, or matching errors, resulting in extremely low verification and tracing efficiency.
[0005] Third, existing software lacks standardized data cleaning and hierarchical matching algorithms, resulting in low matching accuracy. Various commercial tools lack a unified mechanism for converting company names and standard accounting subjects. For company names with the same core keywords (often omitted or simplified due to different input habits of bookkeepers, leading to multiple abbreviation variations for the same entity in accounts) and non-standard company accounting subjects, they cannot be uniformly standardized. The matching logic simply compares the entities and amounts involved in transactions, receivables / payables, and cash flows, without fixed hierarchical verification rules. Mismatches easily occur when multiple transactions, receivables / payables, and cash flows are cross-matched. It is impossible to optimize matched data, and there is no mechanism for secondary verification of unmatched records.
[0006] Fourth, the fully manual verification model is characterized by high labor costs, significant error risks, and poor traceability. For internal transaction records, balances, and cash flows numbering in the thousands, manual matching requires multiple finance and audit personnel to spend several days screening and comparing each line, resulting in high labor costs. Manual operations are susceptible to fatigue and negligence, making it easy to miss or mismatch issues, leading to financial statement misstatements and audit adjustment risks. Furthermore, manual verification lacks standardized operational records, making it extremely labor-intensive to fully trace and correct all corresponding transactions, balances, and cash flow records when matching errors are subsequently discovered.
[0007] In addition, existing mainstream offsetting tools lack a targeted, visual error correction and sorting mechanism. The unmatched transactions generated after a round of matching are arranged in a disordered manner, and can only rely on manual screening and retrieval of corresponding reverse transactions, accounts receivable and payable, and cash flow records, which is time-consuming and cannot quickly locate abnormal data such as unilateral outstanding accounts and inter-period transactions.
[0008] In summary, current manual matching and traditional software-based offsetting solutions suffer from multiple drawbacks, including incomplete data extraction, incomplete functional coverage, low matching accuracy, difficulty in auditing and tracing, high labor costs, and low efficiency in anomaly detection. These shortcomings make it difficult to meet the actual business needs of large groups to efficiently and accurately complete internal offsetting and audit verification of consolidated financial statements. Summary of the Invention
[0009] The core concept of this invention is to construct an integrated, automated, closed-loop offsetting system that adapts to three types of heterogeneous financial data: related-party transactions, receivables and payables, and internal cash flow within a group. This system unifies the underlying company names and standardized coding of company accounting items with unidirectional graphical carriers, and is equipped with a four-level linkage matching mechanism (three-level priority hierarchical matching + bidirectional retrieval and error correction and dynamic adjustment + secondary matching + visual grouping). It outputs a visually grouped ledger, combining technical means with manual error correction, enabling data to be processed once and reused throughout the entire process. This simultaneously addresses the complex pain points of traditional software, such as fragmented modules, lag in outputting massive amounts of data, inability to form one-to-one matching ledgers, the need for manual offsetting of cash flow, and low efficiency in verifying abnormal data.
[0010] This invention provides a tool and method for automatically matching related-party transactions, intercompany transactions, and cash flows, comprising: S1 cleans, encodes, and constructs unidirectional graph elements from the transaction chronological ledger, intercompany balance sheet, and raw cash flow data. Starting from the first row and proceeding downwards, it performs a three-level priority hierarchical matching for each unidirectional graph element. During the matching process, it continuously corrects and dynamically adjusts the matched graph elements to ensure that each group is the best matching pair. After traversing the entire table, it performs a second matching on all unmatched unidirectional graph elements. After the two matchings, the results are grouped according to transaction, intercompany, and cash flow direction before being output. S2 Data Preprocessing and Standardized Modeling Steps: The process of cleaning, encoding, and constructing unidirectional graph elements from the original transaction chronological ledger, intercompany supplementary balance sheet, and cash flow data includes: obtaining a list of entities within the group's consolidated scope to construct a related party graph, establishing a one-to-one correspondence between corporate accounting items and standard accounting items, and pre-configuring an account relationship table; reading the original transaction chronological ledger, intercompany supplementary balance sheet, and cash flow data, filtering and removing irrelevant external transactions, intercompany transactions, and cash flow data based on the company's abbreviation to obtain a basic data table of internal transactions, intercompany transactions, and cash flow data; and standardizing the encoding of the reporting entities, counterparty entities, and corporate accounting items in the basic data table. Based on standardized enterprise codes, standard accounting subjects, and transaction, receivables and payables and cash flow amounts, attributed one-way transaction, receivables and payables and cash flow elements are constructed with the two parties involved in the transaction, receivables and payables and cash flow as vertices and the reporting unit pointing to the other unit as the flow direction. Each one-way transaction, receivables and payables and cash flow element is bound to the corresponding standard accounting subject and business amount attribute. The one-way element code is cleaned once and called throughout the entire process. S3 three-level priority hierarchical matching steps: The process of performing a three-level priority hierarchical matching for each unmatched unidirectional element, starting from the first row and proceeding downwards, includes: selecting one element from all unmatched unidirectional transaction, inflow and outflow, and cash flow elements as the element to be matched, and performing a three-level verification on the remaining elements. Level 1 verification: Based on the pre-configured account relationship table, filter out one-way transaction, intercompany and cash flow elements that are related to the standard accounting account to be matched, and form an account compliance candidate set; Second-level verification: Select graph elements whose transaction, payment, and cash flow direction is completely opposite to the graph element to be matched from the subject compliance candidate set, and generate a reverse subject candidate subset; if there is no reverse subject candidate subset, the current graph element to be matched is added to the candidate dataset. Third-level verification: Calculate the absolute value of the amount difference between the element to be matched and each candidate element, and select the element with the smallest absolute value of the difference as the optimal matching object; S4 bidirectional retrieval error correction and dynamic adjustment steps: During the matching process, the matched graphic elements are continuously corrected and dynamically adjusted to ensure that each pair is the best match. This includes: when searching for a single graphic element to be matched, first traversing all candidate graphic elements downwards from the row where the graphic element to be matched is located; if no qualified candidate graphic element is found when searching downwards, automatically switching to backtracking upwards to achieve a full table search; at the same time, checking the matched graphic elements in real time, and adjusting in real time if a better candidate graphic element appears. S5 secondary matching steps: After traversing the entire table, all unmatched unidirectional primitives are subjected to secondary matching; this includes: after completing one round of global matching, all unmatched primitives are collected to form an independent secondary candidate dataset, and the complete matching logic of S1-S4 is reused to re-loop the matching; primitives that still cannot be matched after two rounds of matching are regarded as problem primitives for auditing verification. S6 Visual Grouping Steps: After the two matching processes, the results are grouped and output according to the transaction, exchange, and cash flow direction. This includes: the grouping and sorting is based on the unified enterprise memory encoding generated in S2, which shares the same set of primitives with the matching and retrieval in S3-S6. The primitives are classified and grouped according to the direction of all unidirectional transactions, exchanges, and cash flows. Within the same pairing group, all positive flow primitives are arranged first, and all reverse flow primitives in the adjacent rows are arranged. At the same time, the reporting unit, the counterparty unit, and the enterprise accounting subject are reverse decoded to restore the full name of the standard enterprise and the full name of the standard accounting subject, generating an ordered and visually sorted ledger.
[0011] Furthermore, the unidirectional primitive encoding is cleaned once and called throughout the entire process. S1 data preprocessing and standardized modeling are provided throughout the process, S3 three-level priority hierarchical matching, S4 bidirectional retrieval error correction and dynamic adjustment, S5 secondary matching, and S6 visual grouping reuse. There is no need to repeat the data cleaning and encoding conversion throughout the process. The three types of business share the same matching operation carrier, realizing the integrated synchronous offsetting of multiple types of financial data.
[0012] Furthermore, the process of reading the original transaction chronological ledger, intercompany auxiliary balance sheet, and cash flow, and using streaming reading to remove irrelevant external transactions, intercompany transactions, and cash flow, includes: cleaning the massive amount of original chronological ledger data, retaining only internal group transactions, intercompany transactions, and cash flow, and encoding the company name and company accounting subject into the basic data table to reduce system memory usage.
[0013] Furthermore, based on the company abbreviation, external irrelevant transactions, current accounts receivable and payable, and cash flow are filtered and eliminated to obtain the basic data table of internal transactions, current accounts receivable and payable, and cash flow. The standardization process of company abbreviations includes: mapping company names containing the same abbreviation to the same memory code, for example, A Limited Company, A Company, and A Limited Liability Company are uniformly coded with the same numerical code; and uniformly collecting abbreviations not in the related party map into a mismatch list for manual supplementation and improvement of the related party map.
[0014] Furthermore, one element is selected from all unmatched one-way transactions, inter-transactions, and cash flow elements as a candidate element. When one element is selected as the element to be matched, the remaining elements automatically become candidate elements.
[0015] Furthermore, the element with the smallest absolute difference is selected as the optimal matching object. The key feature is that the selection rule for equal absolute difference in amount in the third-level priority hierarchical matching is as follows: compare the absolute value of the difference between the candidate amount and the amount of the element to be matched, and select the element with the smaller absolute difference as the matching object. If the absolute differences are equal, then the candidate element with a negative difference after removing the absolute value is selected first, so as to avoid the offset amount exceeding the amount of the element to be matched and forming a large one-sided offset.
[0016] Furthermore, during the entire process of traversing and retrieving candidate primitives, the already bound matching pairs are verified in real time. If a reverse candidate primitive with a smaller absolute value of the difference in amount with the current primitive to be matched is found, the original matching combination is automatically disassembled, the old paired primitive is returned to the candidate dataset, and a new matching relationship is established with the better candidate, thereby realizing global dynamic optimization of all offsetting pairs.
[0017] Furthermore, an orderly and visually sorted ledger is generated. The completed list can record related transactions, related parties and related cash flow entities, standard accounting subjects, and transaction amounts for each item. This is used for manual verification of unilateral entries, cross-period transactions, long-term outstanding accounts, off-book funds, accounting omissions, and amount discrepancies.
[0018] In a second aspect, the present invention provides an electronic device, characterized in that it includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the related party transaction, intercompany transaction, and cash flow automatic matching tool method as described in the first aspect.
[0019] Thirdly, the present invention provides a computer-readable storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the related party transaction, intercompany transaction, and cash flow automatic matching tool method as described in the first aspect.
[0020] The beneficial effects of this invention include: The technical aspects of this invention are not simply an aggregation of existing financial processing functions; the integrated and interconnected architecture delivers technical effects that cannot be achieved through a single improvement method. Compared to existing traditional financial offsetting software and purely manual matching solutions, the quantitative improvements of this invention are as follows: ① Data processing efficiency: This invention uses streaming batch reading to achieve unified loading of three types of data. Only one standardized coding is required for full-process reuse. The memory usage of hundreds of thousands of accounting transactions is reduced by more than 60%, completely solving the problems of program lag and memory overflow. The manual time spent on pre-processing is reduced by 90% compared with traditional solutions. ② Matching accuracy: Traditional software uses transaction, accounts receivable / payable, and cash flow auxiliary accounting fields for offsetting, lacking data cleaning, two-way retrieval, and secondary fallback mechanisms, resulting in a mismatch rate of over 30%. This invention relies on standardized coding of enterprise names and enterprise accounting subject names, three-level priority hierarchical matching, two-way retrieval error correction and dynamic adjustment, a two-round matching linkage mechanism, and dynamic adjustments during the matching process to improve the overall matching completeness of transactions, accounts receivable / payable, and cash flow, reducing the probability of mismatches and omissions. At the same time, it adds a global dynamic decomposition and rematching error correction mechanism, which can iteratively update the optimal pairing, significantly reducing the anomalies in the end-of-period closing of reports.
[0021] ③ Efficiency of manual review: In traditional tools without a visual grouping mechanism, manual location requires filtering from massive amounts of data to locate a single unmatched reverse transaction, which takes an average of 3 minutes per transaction; This invention generates a grouped visual sorting ledger based on unified coding, which makes it easier for audits to find abnormal transactions, accounts receivable and payable and cash flow, and locate accounting discrepancies; ④ Full business coverage capability: Existing software on the market only has separate offsetting modules for transactions and intercompany transactions, which require manual processing of cash flow offsetting; This invention is the first to share a set of unidirectional primitives for three types of data, unify the computing architecture, and use a single dataset to simultaneously complete the automatic netting offsetting of the three types of business, greatly expanding the scope of automation in consolidated report preparation; ⑤ Audit traceability capability: This invention maintains a unified offsetting detail ledger for each complete and matching transaction, receivables and payables, and cash flow retention, which makes it easy for auditors to locate single records with one-sided accounts or mismatches. This integrated unified ledger traceability capability and one-to-one corresponding offsetting details are unique advantages that existing software does not have. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 This is a flowchart illustrating an automatic matching tool method for related transactions, intercompany transactions, and cash flows according to an embodiment of the present invention. Figure 2 for Figure 1 First enlarged view of the area; Figure 3 for Figure 1 Second enlarged view of the area; Figure 4 for Figure 1 The third enlarged view. Detailed Implementation
[0024] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention. The following data are all illustrated using related-party transactions as examples. Related-party transactions and related-party cash flows differ only in their data sources; the remaining steps are the same as in related-party transactions.
[0025] Pre-set related party diagrams and account relationship tables. Obtain transaction chronological ledgers; Data cleaning: The original data from the transaction chronological ledger, accounts receivable / payable supplementary balance sheet, and cash flow statements are cleaned, coded, and used to construct unidirectional graph elements, including: ① Clean the original transaction chronological ledger The original transaction chronological ledger before filtering (containing a large amount of external redundant data) is shown in Table 1.
[0026] Table 1 The filtered transaction chronological ledger is shown in Table 2 (only internal related transactions are retained).
[0027] Table 2 Note: Read and load the full data, and remove irrelevant external streams.
[0028] ② Standardize the company names in the chronological ledger, standardize and map the company accounting items, and construct a one-way transaction primitive. General instructions for the preceding data source: The program synchronously preloads the related party graph (as shown in Table 3) and the standard accounting subject list (as shown in Table 4): storing the standard enterprise name, standard accounting subject, matching keywords, and assigning unique operation codes for each subsidiary.
[0029]
[0030] b. Filter and remove irrelevant external transactions, current accounts receivable and payable and cash flow based on the company abbreviation to obtain the basic data table of internal transactions, current accounts receivable and payable and cash flow, including: the reporting unit and the counterparty unit in the basic data are unorganized text, and the fuzzy matching logic of the company abbreviation is used: extract the core abbreviation in the current unit text and compare it with the abbreviation contained in each entity in the related party map. Only when the abbreviations of the two parties overlap, a one-to-one mapping relationship is established. Example 1: For example, if the basic data text is "Group Headquarters" and the abbreviation is "Group", then the full name of the matching related party graph standard is "XX Group Co., Ltd.", and the corresponding memory operation code of this unit is 1. At the same time, the accounting subject is matched according to the enterprise accounting subject standard. Example 2: For example, the basic data text is Daxi Squadron (formerly Taihe), abbreviated as "Daxi". The full name of the matching related party graph standard is XX Daxi Co., Ltd. The corresponding memory operation code of this unit is 2. At the same time, the accounting subject is matched according to the enterprise accounting subject standard. And so on... The standardized chronological ledger is shown in Table 5:
[0031] Table 5 c extracts the required information from each row of the chronological ledger sequentially and writes it into the basic data table according to a fixed format to prepare for data matching, as shown in Table 6:
[0032] Table 6 d. Standardize the coding of the reporting units, counterparties, and standard accounting subjects in the basic data table, including: coding each row of data in Table 6, as shown in Table 7:
[0033] Table 7 If, when using a company abbreviation to perform fuzzy matching with the related party map, it is found that none of the entries in the related party map contain the abbreviation, then the abbreviations of the unmatched units will be uniformly collected into the list of inconsistent matches. At the same time, the corresponding chronological ledger text will be completely retained. After manual review, if it is a unit within the group, it will be added to the related party map. Using the two parties involved in a transaction, exchange, and cash flow as vertices and the direction from the reporting unit to the other unit as the flow direction, construct attributed one-way transaction, exchange, and cash flow primitives, including: constructing one-way transaction primitives based on cleaned standardized codes. ① The program generates a unidirectional dataset of primitives to be matched for batch matching, based on the enterprise operation codes and standard accounting subject operation codes temporarily stored in memory: ② Vertex definition: The unit memory code of the reported vertex is the starting vertex, and the unit memory code of the other vertex is the ending vertex; ③ One-way rule: The flow of a single transaction is uniformly defined as "reporting unit → counterparty unit"; ④ Edge-mounted operation attributes: Bind the standardized accounting subject name and transaction amount of the bank to the one-way edge for subsequent two-level matching and verification; Each filtered business transaction corresponds to an independent one-way transaction element. These elements are aggregated to form a complete dataset to be matched, which is then used by subsequent matching algorithms, as shown in Table 8.
[0034]
[0035] Table 8 Select one from all unmatched one-way transactions, inflows and outflows and cash flow elements as the element to be matched, and perform three-level priority hierarchical matching on the remaining candidate elements, including: each transaction after enterprise name standardization and account standardization is packaged into an independent one-way element, and the program matches according to the pre-set account relationship table and the three-level priority hierarchical matching steps.
[0036] ① The program loads the pre-defined subject association table, as shown in Table 9:
[0037] Table 9 Note: The account relationship table is configured in advance by the auditors. The "This Account" column in the table is for revenue accounts, and the "Related Accounts" column is for corresponding offset cost accounts. Any "This Account - Related Account" combination in the table represents an account relationship that can be offset.
[0038] ② Match according to the matching rules set by this program: Subject constraint: Only subject relationships that exist in the subject relationship table can be matched; b. Unidirectional element flow constraint: If the flow direction of the element to be matched is A → B, the candidate element must satisfy the flow direction as B → A. c. Preferred Matching Constraint: Prioritize selecting two elements with an absolute difference of 0 as the binding matching pair. After full-amount equal-amount matching is completed, the matched elements are removed from the left-hand matching pool and written to the right-hand matching completion ledger. If the amount is not zero, the element with the smaller difference is selected for matching. The following details the steps for implementing preferred matching: Step 1: Lock the current row T0 of the primitives to be matched, as shown in Table 10.
[0039] Table 10 Step 2: First-level filtering: The program traverses all unmatched transactions in the basic data, verifies the standard accounting subject for each graphic element, and searches for the standard accounting subject that matches the main business revenue of the graphic element T0 to be matched according to the subject association table. The corresponding row number is then used to generate a compliance candidate pool, as shown in Table 11.
[0040]
[0041] Table 11 Step 3: Second-level filtering: From the compliant candidate pool, filter candidate primitives whose main flow is completely opposite to that of the target subject T0, and classify them into the reverse subject candidate subset, as shown in Table 12.
[0042] Table 12 Step 4: Third-level preferential matching: Calculate the absolute value of the difference between each item and the reverse candidate item T0 to be matched, and prioritize matching combinations with a difference of 0, as shown in Table 13.
[0043] Table 13 Since there is a candidate T1 within the subset whose absolute difference is equal to 0, the matching primitive T0 and the candidate primitive T1 are directly determined to be the optimal matching pair. The information of the candidate primitive T1 is written to the right side of the matching primitive T0 to form a complete cancellation detail, as shown in Table 14. At this point, the matching of the matching primitive T0 row is completed. Proceed to the next primitive matching.
[0044]
[0045] Table 14 Calculate the absolute value of the difference between the amount of the element to be matched and each candidate element, and select the element with the smallest absolute difference as the optimal matching object. This includes the matching logic for multiple candidate elements with equal absolute differences: Taking the matching primitive T2 in Table 10 as an example, repeat the above three-layer matching logic and calculate the absolute value of the difference between each candidate primitive (T3, T7) that meets the requirements and the matching primitive T2, as shown in Table 15.
[0046]
[0047] Table 15 Since the absolute values of the differences between the two candidate primitives are exactly the same, based on auditing practice, the unidirectional primitives corresponding to the negative difference after removing the absolute value are selected for matching, as shown in Table 16.
[0048] Table 16 Based on auditing practice, if candidate element T7 (main business revenue 14,000, difference 2,000) is selected for offsetting: after the full offsetting of the book management expenses of 12,000, there is no corresponding management expense amount for the remaining 2,000 of main business revenue. This will result in the offsetting entry reducing the amount greater than the actual book revenue, leading to abnormal financial statements and a high risk of audit adjustment. Therefore, when encountering situations where the absolute values of the differences are equal, candidate element T3 (other business revenue 10000, difference -2000) should be selected for offsetting: only the 10000 equivalent to the management expenses is offset, and the remaining management expenses of 2000 are retained in the books. There will be no abnormal situation where the offset amount exceeds the amount recorded in the other party's books, which complies with the audit verification standards for group consolidation offsetting.
[0049] Following this process, the matching results are shown in Table 17:
[0050] Table 17 During the matching process, the matched primitives are continuously corrected and dynamically adjusted to ensure that each pair is the best match. This includes designing a dynamic iterative error correction and optimal pairing reorganization mechanism during the matching process. The purpose of this mechanism is that, due to the aforementioned equal-priority and differential-priority matching logic, the default search range is to traverse all unmatched flows downwards from the row containing the primitive to be matched. However, in the practical scenario of massive unordered basic data business flows, there may be situations where there are no candidate primitives below the primitive to be matched, or candidate primitives that meet the conditions are stored in the unmatched area above the current row. Simply searching downwards will result in missed matches, causing missing matches and distortion of the offsetting ledger. To address this, the program of this invention has a built-in bidirectional search and error correction mechanism: it first traverses downwards for search, and automatically switches to upward backtracking search when no qualified candidates are found.
[0051] As shown in Table 17, when the program reaches the primitive T6 to be matched, the program first defaults to matching downwards and will automatically match the candidate primitive T7. The matching results are shown in Table 18.
[0052] Table 18 Since the current row is not the first row, the program searches downwards and then upwards for each matched unidirectional primitive. When a better primitive is found, it is dynamically disassembled and re-matched (the core error correction mechanism). For example, candidate primitive T3 is found to be a better match for the primitive T6 to be matched. However, since candidate primitive T3 has already been matched, the system first releases the original matching pair and then matches the primitive T6 to be matched with candidate primitive T3. The results are shown in Table 19.
[0053] Table 19 Existing financial matching tools all adopt a static locking pairing mode. Once a matching pair is formed, it cannot be adjusted, which easily leaves large offsetting differences and cannot generate one-to-one offsetting details. This invention dynamically iterates and adjusts all matching combinations throughout the process, continuously screening the globally optimal offsetting pairing, and significantly reducing the netting differences in consolidated financial statements.
[0054] After traversing the entire table, all unmatched unidirectional primitives undergo a secondary matching process. This includes: after completing the first round of top-down, bidirectional matching of the entire table, due to the dynamic adjustment mechanism, matched primitives may be released (for example, primitive T2, which was originally matched by candidate primitive T3, may be released and rematched due to a better matching pair, leaving primitive T2 without matching). This results in some primitives that should have been matched but were not after the first round of matching. At this point, they are divided into two categories: first, successfully matched primitives, which have been removed from the left-side matching pool and written in pairs to the right-side to complete the match; second, unmatched primitives, which remain on the left-side, with the corresponding matching column on the right-side empty. This means that the primitive may have cross-period accounting, unilateral accounting, or inconsistent accounting standards, resulting in the inability to match in the first round of retrieval, as shown in Table 20.
[0055] To maximize the coverage of internal transaction offsetting and avoid missing matchable primitives, this invention sets up a secondary matching process. All unmatched primitives from the first round are reassembled into a new, independent primitive set, and the entire matching logic described above is reused for a new, iterative matching process. Newly matched transactions in the secondary matching are merged with the results of the first round of matching and output, with each row containing complete offsetting details.
[0056] Residual elements that still cannot be matched after two rounds of full-process matching are retained on the right side of the matching ledger, with complete records of the unit, standard accounting subject, and amount, for manual auditing to check for accounting issues such as unilateral entries, amount discrepancies, cross-period entries, and omissions. As shown in Table 21: After one round of matching, the results are shown in Table 20:
[0057] Table 20 As can be seen in the table above, there are still unmatched primitives (such as T2, T4, T5, and T7). After repeating the matching process from 1 to 6, it was found that primitive T2 and candidate primitive T7 are the best matching pair, as shown in Table 21.
[0058] Table 21 After two matchings, the results are grouped and output according to transaction, exchange and cash flow direction. This includes: after the two rounds of matching, all unidirectional graph elements are grouped and visually sorted. That is: when outputting the results, each unidirectional graph element is grouped according to its flow direction. Graph elements with the same flow direction are grouped together. All rows with the opposite flow direction to the previous group are written to the current group. Then, the next group is switched, as shown in Tables 22 and 23.
[0059] The output before sorting is shown in Table 22:
[0060] Table 22 The sorted output is shown in Table 23:
[0061] Table 23 Simultaneously, the system reverse-decodes the reporting unit, the counterparty unit, and the standard accounting subject to restore the full name of the standard enterprise and the full name of the standard accounting subject. This is because the enterprise calculation code is only used temporarily in the program's memory and is not written to the system. When exporting the final matching results, the system retrieves the mapping ledger and reverse-decodes the memory code to restore the full name of the standard enterprise, as shown in Table 24.
[0062]
[0063] Table 24 The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.
Claims
1. A tool and method for automatically matching related-party transactions, intercompany transactions, and cash flows, characterized in that, include: S1 cleans, encodes, and constructs unidirectional graph elements from the transaction chronological ledger, intercompany balance sheet, and raw cash flow data. Starting from the first row and proceeding downwards, it performs a three-level priority hierarchical matching for each unidirectional graph element. During the matching process, it continuously corrects and dynamically adjusts the matched graph elements to ensure that each group is the best matching pair. After traversing the entire table, it performs a second matching on all unmatched unidirectional graph elements. After the two matchings, the results are grouped according to transaction, intercompany, and cash flow direction before being output. S2 Data Preprocessing and Standardized Modeling Steps: The process of cleaning, encoding, and constructing unidirectional graph elements from the original transaction chronological ledger, intercompany supplementary balance sheet, and cash flow data includes: obtaining a list of entities within the group's consolidated scope to construct a related party graph, establishing a one-to-one correspondence between corporate accounting items and standard accounting items, and pre-configuring an account relationship table; reading the original transaction chronological ledger, intercompany supplementary balance sheet, and cash flow data, filtering and removing irrelevant external transactions, intercompany transactions, and cash flow data based on the company's abbreviation to obtain a basic data table of internal transactions, intercompany transactions, and cash flow data; and standardizing the encoding of the reporting entities, counterparty entities, and corporate accounting items in the basic data table. Based on standardized enterprise codes, standard accounting subjects, and transaction, receivables and payables and cash flow amounts, attributed one-way transaction, receivables and payables and cash flow elements are constructed with the two parties involved in the transaction, receivables and payables and cash flow as vertices and the reporting unit pointing to the other unit as the flow direction. Each one-way transaction, receivables and payables and cash flow element is bound to the corresponding standard accounting subject and business amount attribute. The one-way element code is cleaned once and called throughout the entire process. S3 three-level priority hierarchical matching steps: The process of performing a three-level priority hierarchical matching for each unmatched unidirectional element, starting from the first row and proceeding downwards, includes: selecting one element from all unmatched unidirectional transaction, inflow and outflow, and cash flow elements as the element to be matched, and performing a three-level verification on the remaining elements. Level 1 verification: Based on the pre-configured account relationship table, filter out one-way transaction, intercompany and cash flow elements that are related to the standard accounting account to be matched, and form an account compliance candidate set; Second-level verification: Select graph elements whose transaction, payment, and cash flow direction is completely opposite to the graph element to be matched from the subject compliance candidate set, and generate a reverse subject candidate subset; if there is no reverse subject candidate subset, the current graph element to be matched is added to the candidate dataset. Third-level verification: Calculate the absolute value of the amount difference between the element to be matched and each candidate element, and select the element with the smallest absolute value of the difference as the optimal matching object; S4 bidirectional retrieval error correction and dynamic adjustment steps: During the matching process, the matched graphic elements are continuously corrected and dynamically adjusted to ensure that each pair is the best match. This includes: when searching for a single graphic element to be matched, first traversing all candidate graphic elements downwards from the row where the graphic element to be matched is located; if no qualified candidate graphic element is found when searching downwards, automatically switching to backtracking upwards to achieve a full table search; at the same time, checking the matched graphic elements in real time, and adjusting in real time if a better candidate graphic element appears. S5 secondary matching steps: After traversing the entire table, all unmatched unidirectional primitives are subjected to secondary matching; this includes: after completing one round of global matching, all unmatched primitives are collected to form an independent secondary candidate dataset, and the complete matching logic of S1-S4 is reused to re-loop the matching; primitives that still cannot be matched after two rounds of matching are regarded as problem primitives for auditing verification. S6 Visual Grouping Steps: After the two matching processes, the results are grouped and output according to the transaction, exchange, and cash flow direction. This includes: the grouping and sorting is based on the unified enterprise memory encoding generated in S2, which shares the same set of primitives with the matching and retrieval in S3-S6. The primitives are classified and grouped according to the direction of all unidirectional transactions, exchanges, and cash flows. Within the same pairing group, all positive flow primitives are arranged first, and all reverse flow primitives in the adjacent rows are arranged. At the same time, the reporting unit, the counterparty unit, and the enterprise accounting subject are reverse decoded to restore the full name of the standard enterprise and the full name of the standard accounting subject, generating an ordered and visually sorted ledger.
2. The automatic matching tool and method for related party transactions, intercompany transactions, and cash flows as described in claim 1, characterized in that, The unidirectional primitive encoding is cleaned once and called throughout the entire process. S1 data preprocessing and standardized modeling are provided throughout the process, S3 three-level priority hierarchical matching, S4 bidirectional retrieval error correction and dynamic adjustment, S5 secondary matching, and S6 visual grouping reuse. There is no need to repeat the data cleaning and encoding conversion throughout the process. The three types of business share the same matching operation carrier to realize the integrated synchronous offsetting of multiple types of financial data.
3. The automatic matching tool and method for related party transactions, intercompany transactions, and cash flows as described in claim 1, characterized in that, The process of reading the original transaction chronological ledger, intercompany auxiliary balance sheet, and cash flow, and using streaming reading to remove irrelevant external transactions, intercompany transactions, and cash flow, includes: cleaning the massive amount of original chronological ledger data, retaining only internal group transactions, intercompany transactions, and cash flow, and encoding the company name and company accounting subject into the basic data table to reduce system memory usage.
4. The automatic matching tool and method for related party transactions, intercompany transactions, and cash flows as described in claim 1, characterized in that, Based on the company abbreviation, external irrelevant transactions, current accounts receivable and payable, and cash flow are filtered and eliminated to obtain the basic data table of internal transactions, current accounts receivable and payable, and cash flow. The standardization process of company abbreviations includes: mapping company names containing the same abbreviation to the same memory code, for example, A Limited Company, A Company, and A Limited Liability Company are uniformly coded with the same numerical code; and uniformly collecting abbreviations that are not in the related party map into a mismatch list for manual supplementation and improvement of the related party map.
5. The automatic matching tool and method for related party transactions, intercompany transactions, and cash flows as described in claim 4, characterized in that, Select one as a candidate element from all unmatched one-way transactions, inflows and outflows and cash flow elements. When one data element is selected as the element to be matched, the remaining data automatically become candidate elements.
6. The automatic matching tool and method for related party transactions, intercompany transactions, and cash flows as described in claim 4, characterized in that, The element with the smallest absolute difference is selected as the optimal matching object. The characteristic is that the selection rule for equal absolute difference in amount in the third-level priority hierarchical matching is: compare the absolute value of the difference between the candidate amount and the amount of the element to be matched, and select the element with the smaller absolute difference as the matching object. If the absolute difference is equal, the candidate element with a negative difference after removing the absolute value is selected first to avoid the offset amount exceeding the amount of the element to be matched, thus avoiding a large one-sided offset.
7. The automatic matching tool and method for related party transactions, intercompany transactions, and cash flows as described in claim 4, characterized in that, The system verifies the bound matching pairs in real time throughout the traversal and retrieval of candidate primitives. If a reverse candidate primitive with a smaller absolute value of the difference in amount with the current primitive to be matched is found, the original matching combination is automatically disassembled, the old paired primitive is returned to the candidate dataset, and a new matching relationship is established with the better candidate, thereby achieving global dynamic optimization of all offsetting pairs.
8. The automatic matching tool and method for related party transactions, intercompany transactions, and cash flows as described in claim 4, characterized in that, Generate an ordered and visually sorted ledger. The matched list can record each related transaction, related party transactions and related cash flow entities, standard accounting subjects, and transaction amounts in a complete manner. It is used for manual verification of unilateral entries, cross-period transactions, long-term outstanding accounts, off-book funds, accounting omissions, and amount discrepancies.
9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the related party transaction, intercompany, and cash flow automatic matching tool method as described in any one of claims 1 to 6.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the automatic matching tool method for related transactions, intercompany transactions, and cash flows as described in any one of claims 1 to 6.