A financial data processing method, device, equipment, medium and product

Abstract

This invention provides a method, apparatus, device, medium, and product for processing financial data, applied in the field of data processing technology. The method includes: acquiring a chronological ledger file; preprocessing the chronological ledger file to obtain a standard chronological ledger data table; acquiring a monthly report of R&D projects; extracting features from the monthly report of R&D projects to obtain project feature vectors; and extracting features from the standard chronological ledger data table to obtain chronological ledger feature vectors; obtaining matching results based on the project feature vectors and chronological ledger feature vectors; determining the project dimension amount and the consolidated deduction amount for each project object based on the successfully matched chronological ledger records; generating multiple functional reports based on the matching results, thus standardizing the chronological ledger file; improving the matching success rate of financial data through feature vector-based matching; and enhancing the traceability of financial data through hierarchical display of functional reports.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, equipment, medium, and product for processing financial data. Background Technology

[0002] Currently, when calculating taxable income, companies can enjoy additional deductions based on actual R&D expenses incurred, and companies can internally collect and compile statistics on the expenses of each R&D project.

[0003] In existing technologies, finance personnel can export chronological ledgers from the financial accounting system and, in conjunction with monthly reports of R&D projects, manually calculate R&D expenses.

[0004] However, when using the above method, manual processing is inefficient due to the different file formats of chronological ledgers and monthly reports. Secondly, chronological ledgers contain a large amount of unstructured or semi-structured text descriptions, which may contain redundant information or special characters, non-standard formats or missing tags, and outliers in fields. This can easily lead to omissions during manual statistics, resulting in errors in R&D expense statistics. Furthermore, manual statistics generally only retain the final statistical results, making it difficult to trace the statistical process. This makes it impossible to verify the correctness of the statistical results when traceability is required, and it is also difficult to meet the requirements of tax audits for tracing the statistical process. Summary of the Invention

[0005] In view of the above problems, a method, apparatus, equipment, medium, and product for processing financial data are proposed to overcome or at least partially solve the above problems, including: In a first aspect, the present invention provides a method for processing financial data, the method comprising: Obtain a chronological ledger file, preprocess the chronological ledger file to obtain a standard chronological ledger data table; wherein the standard chronological ledger data table includes multiple chronological ledger records; Obtain the monthly report of R&D projects, extract features from the monthly report of R&D projects to obtain project feature vectors corresponding to multiple project objects, and extract features from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records. Based on the project feature vector and the chronological ledger feature vector, the matching results between the multiple project objects and the multiple chronological ledger records are obtained; Based on the amount corresponding to the successfully matched chronological ledger records, determine the project dimension amount corresponding to each project object, and determine the internal chronological ledger record in the successfully matched chronological ledger records. Based on the amount corresponding to the internal chronological ledger record, determine the consolidated deduction amount corresponding to each project object. Based on the matching results, multiple functional reports are generated; wherein, the multiple functional reports include a project summary table, a matching details table, and a remaining details table. The project summary table includes the project dimension amount, the consolidated deduction amount, and the net amount. The matching details table includes traceability information of successfully matched chronological ledger records. The remaining details table includes traceability information of unmatched chronological ledger records and traceability information of excluded chronological ledger records.

[0006] Optionally, the chronological ledger file is preprocessed to obtain a standard chronological ledger data table, including: The multi-level column headers in the chronological ledger file are detected, and the multi-level column headers are merged into a single-level column header required by the standard chronological ledger data table; wherein, the column name of the single-level column header is a single identifier that connects the multi-level column names through a concatenation operator; Determine the matching score between the column name of the single-level column header and the keywords in the preset column name semantic feature library, and determine the target column required for the standard chronological ledger data table based on the matching score; The data in the target column is cleaned to improve its quality, and a standard chronological ledger data table is generated based on the single-level column header, the target column, and the cleaned data.

[0007] Optionally, determine the matching score between the column name of the single-level column header and keywords in a preset column name semantic feature library, and determine the target column required for the standard chronological ledger data table based on the matching score, including: Obtain a column name semantic feature library, which contains the correspondence between target semantics and keyword set, as well as the weight of each keyword in the keyword set; For each column name in the single-level column header, a weighted matching score of the target semantics corresponding to the keyword is determined based on the keyword that matches the column name and the weight of the keyword. Select the column with the highest weighted matching score as the target column corresponding to the target semantics; When the weighted matching score is lower than a preset threshold, the column corresponding to the preset position is taken as the target column corresponding to the target semantics.

[0008] Optionally, feature extraction is performed on the monthly report of the R&D project to obtain project feature vectors corresponding to multiple project objects, and feature extraction is performed on the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records, including: Obtain the project name of each project object in the monthly report of the R&D project, extract features from the project name using regular expression groups, and generate a project feature vector corresponding to each project object based on the extracted features; Obtain the auxiliary item text for each chronological ledger record in the standard chronological ledger data table. The auxiliary item text contains a tag structure consisting of pairs of tag names and tag content. Use a regular expression that matches each tag name and tag content to extract features from the auxiliary item text, and generate a chronological ledger feature vector corresponding to each chronological ledger record based on the extracted features.

[0009] Optionally, the project feature vector includes any one or more of the following: a list of project files, the current name, the topic name, and the original full name; The chronological account feature vector includes one or more of the following: budget code, customer file, project file, department file, and personnel file.

[0010] Optionally, based on the project feature vector and the chronological ledger feature vector, a matching result is obtained between the plurality of project objects and the plurality of chronological ledger records, including: The semantic components in the project feature vector are compared with the budget coding components in the chronological account feature vector to determine their inclusion relationship, which is then used as the first matching channel. The inclusion relationship between each semantic component in the project feature vector and the project file component in the chronological ledger feature vector is determined and used as the second matching channel. According to the preset priority order, the inclusion relationship judgment in the first matching channel and the second matching channel are executed sequentially. When any inclusion relationship judgment is successful, the chronological ledger record corresponding to the chronological ledger feature vector is matched with the project object corresponding to the project feature vector.

[0011] Optionally, the inclusion relationship judgment in the first matching channel and the second matching channel is performed sequentially according to a preset priority order, including: In the first matching channel, the inclusion relationship judgment is performed sequentially according to the following priority order: First priority: Determine whether the original complete name in the project feature vector is a substring of the budget code in the chronological ledger feature vector; Second priority: Determine whether the current name in the project feature vector is a substring of the budget code in the chronological account feature vector; Third priority: Determine whether the topic name in the project feature vector is a substring of the budget code in the chronological account feature vector; Fourth priority: Determine whether any element in the project file list of the project feature vector is a substring of the budget code in the chronological ledger feature vector; If all priority inclusion relationship checks in the first matching channel fail, then the inclusion relationship checks in the second matching channel will be performed sequentially according to the following priority order: Fifth priority: Determine whether the original complete name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Sixth priority: Determine whether the current name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Seventh priority: Determine whether the topic name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Eighth priority: Determine whether any element in the project file list of the project feature vector is a substring of the project file in the chronological ledger feature vector.

[0012] Optionally, internal chronological ledger records are identified from the successfully matched chronological ledger records. Based on the amounts corresponding to these internal chronological ledger records, the consolidated deduction amount for each project object is determined, including: Obtain an external configuration file and read the list of internal units from the external configuration file; Extract customer profiles from successfully matched chronological ledger records; The customer files are matched with the internal unit list, and the matching chronological records are identified as internal chronological records.

[0013] Optional, also includes: Based on the matching details table and the remaining details table, a bidirectional index structure is constructed; the bidirectional index structure includes a forward index and a reverse index. The forward index uses the project name as the key and the list of all successfully matched chronological ledger records corresponding to the project name as the value; the reverse index uses the original table row number as the key and the processing result of the chronological ledger record corresponding to the original table row number as the value.

[0014] Optional, also includes: Provides an interface for querying by project name, which, in response to the input project name, returns a list of matching details and statistical information corresponding to the project name; It provides an interface for querying by the original table row number, and in response to the input original table row number, returns the processing result of the chronological ledger record corresponding to the original table row number; Provides an interface for querying by amount range, and in response to the input amount range, returns a sample of matching records within the amount range; In response to an audit request for a specified project, an audit report for the specified project is generated; wherein the audit report includes: total project amount, distribution of matching types, percentage of internal transactions, number of low-confidence matches, and sampling details.

[0015] In a second aspect, the present invention provides a financial data processing apparatus, the apparatus comprising: The standard chronological ledger data table acquisition module is used to obtain a chronological ledger file, preprocess the chronological ledger file, and obtain a standard chronological ledger data table; wherein, the standard chronological ledger data table includes multiple chronological ledger records; The feature vector extraction module is used to obtain the monthly report of R&D projects, extract features from the monthly report of R&D projects to obtain project feature vectors corresponding to multiple project objects, and extract features from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records. The matching result obtaining module is used to obtain the matching result between the multiple project objects and the multiple chronological ledger records based on the project feature vector and the chronological ledger feature vector; The amount determination module is used to determine the project dimension amount corresponding to each project object based on the amount corresponding to the successfully matched chronological ledger records, and to determine the internal chronological ledger records in the successfully matched chronological ledger records, and to determine the consolidated deduction amount corresponding to each project object based on the amount corresponding to the internal chronological ledger records. The functional report generation module is used to generate multiple functional reports based on the matching results. The multiple functional reports include a project summary table, a matching detail table, and a remaining detail table. The project summary table includes the project dimension amount, the consolidated deduction amount, and the net amount. The matching detail table includes traceability information of successfully matched chronological ledger records. The remaining detail table includes traceability information of unmatched chronological ledger records and traceability information of excluded chronological ledger records.

[0016] Thirdly, the present invention provides an electronic device including a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method described above.

[0017] Fourthly, the present invention provides a computer-readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the method described above.

[0018] Fifthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0019] The embodiments of the present invention have the following advantages: In this embodiment of the invention, a chronological ledger file is obtained and preprocessed to obtain a standard chronological ledger data table; a monthly report of R&D projects is obtained and features are extracted from the report to obtain project feature vectors corresponding to multiple project objects; similarly, features are extracted from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records; based on the project feature vectors and chronological ledger feature vectors, matching results between multiple project objects and multiple chronological ledger records are obtained; based on the amounts corresponding to the successfully matched chronological ledger records, the project dimension amount corresponding to each project object is determined, and internal chronological ledger records are identified from the successfully matched records; based on the amounts corresponding to the internal chronological ledger records, the merging amount corresponding to each project object is determined. The system optimizes the deduction amount based on the matching results. It generates multiple functional reports, enabling standardized conversion of different format chronological ledger files by obtaining and preprocessing chronological ledger files to obtain a standard chronological ledger data table. By extracting project feature vectors and chronological ledger feature vectors from the monthly R&D project reports and the standard chronological ledger data table, and performing matching based on these feature vectors, the system improves matching coverage and success rate. It determines the project dimension amount and consolidated deduction amount for each project object based on successfully matched chronological ledger records, reducing the manpower and time costs of manual calculation. Furthermore, by generating project summary tables, matching detail tables, and remaining detail tables based on the matching results, the system enables hierarchical display of financial data based on the matching results and improves the traceability of financial data. Attached Figure Description

[0020] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description of the present invention will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart of the steps of a financial data processing method provided in some embodiments of the present invention; Figure 2 This is a flowchart illustrating a method for processing financial data provided in some embodiments of the present invention; Figure 3 This is a flowchart illustrating a financial data matching method provided in some embodiments of the present invention; Figure 4 This is a flowchart of the steps of a second method for processing financial data provided in some embodiments of the present invention; Figure 5 This is a structural block diagram of a financial data processing device provided in some embodiments of the present invention. Detailed Implementation

[0022] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0023] Currently, when calculating corporate income tax payable, companies can deduct actual R&D expenses to reduce their taxable income. Companies need to collect and compile statistics on the expenses incurred for each R&D project in order to enjoy the corresponding tax benefits.

[0024] In related technologies, the research and development expenses generated by the research and development projects are usually calculated manually by exporting chronological accounts from the financial accounting system and combining them with the monthly reports of the research and development projects.

[0025] However, the following problems exist when using the above method: 1. There is data heterogeneity between the chronological ledger and the monthly report of R&D projects.

[0026] For example, the formats are heterogeneous: chronological ledgers typically use a multi-level column header structure, while monthly reports use a flat structure, resulting in a mismatch in structure; the semantics are heterogeneous: the same R&D project is presented as the project name in the monthly report, but may be stored in various forms such as budget code, project file, and customer file in the auxiliary items of the chronological ledger, resulting in inconsistent semantic representation; the granularity is heterogeneous: the chronological ledger contains detailed data (single vouchers), while the monthly report contains project-level summary data, resulting in a mismatch in data granularity.

[0027] 2. Insufficient fault tolerance in data quality.

[0028] The chronological ledger contains a large amount of unstructured or semi-structured text descriptions, which may have problems such as redundant information or special characters in the item name, non-standard format of auxiliary items or missing labels, and abnormal values ​​in the amount field, which can easily lead to matching failures or incorrect amount calculations.

[0029] 3. The matching results lack interpretability.

[0030] Manually compiling the R&D expenses generated by R&D projects only retains the statistical results, making it difficult to trace the statistical process. This makes it difficult to verify the accuracy of the statistical results and also fails to meet the tax audit requirements for tracing the statistical process.

[0031] Based on this, embodiments of the present invention propose to obtain a standard chronological ledger data table by acquiring and preprocessing chronological ledger files, and then standardize the conversion of chronological ledger files of different formats; to extract project feature vectors and chronological ledger feature vectors from the monthly reports of R&D projects and the standard chronological ledger data table respectively, and to perform matching based on the feature vectors to improve the matching coverage and success rate; to determine the project dimension amount and consolidated deduction amount for each project object based on the successfully matched chronological ledger records, reducing the manpower and time costs of manual calculation; and to generate a project summary table, a matching detail table, and a remaining detail table based on the matching results, thereby realizing the hierarchical display of financial data based on the matching results and improving the traceability of financial data.

[0032] Reference Figure 1 The diagram illustrates a flowchart of a financial data processing method according to some embodiments of the present invention, which may specifically include the following steps: Step 101: Obtain the chronological ledger file, preprocess the chronological ledger file to obtain a standard chronological ledger data table; wherein the standard chronological ledger data table includes multiple chronological ledger records.

[0033] In practical applications, chronological ledger files exported from the financial accounting system can be obtained and preprocessed to produce a standard chronological ledger data table. This standard chronological ledger data table can contain multiple chronological ledger records, each corresponding to a specific economic transaction in the chronological ledger file.

[0034] In some embodiments, the chronological ledger file can be a spreadsheet file exported from financial software, such as Excel (Microsoft Excel, spreadsheet software) format. The chronological ledger file can record the journal entries of each accounting voucher of the enterprise in chronological order.

[0035] Preprocessing may include identifying and merging multi-level column headers in the chronological ledger file, automatically locating the required columns (such as debit amount columns, auxiliary item columns, and account name columns), and cleaning the data (such as converting monetary text to numerical values, removing leading and trailing spaces, and recording the original line numbers). Here, "account" can refer to the category name of expense expenditures, such as "R&D Expenses - Personnel Costs," "Administrative Expenses - Office Expenses," and "Sales Expenses - Advertising Expenses."

[0036] A standard chronological ledger data table refers to a pre-processed table with a uniform structure, fixed column names, and standardized data format. Each chronological ledger record corresponds to a row of data in the original Excel file, such as an expense expenditure on a specific date in a specific month of a specific year.

[0037] For example, a company exported a file named "2024 Annual Chronological Ledger.xlsx" from its financial software system. The first two lines of the chronological ledger file contain a merged header, the third line contains column names, and the data begins on the fourth line.

[0038] The first three rows are detected as column header areas. The multi-level column headers are merged into a single-level column name (such as "Date|Summary|Subject Name|Auxiliary Item|Debit Amount|Credit Amount"). Keyword matching determines that "Debit Amount" is in column 5 and "Auxiliary Item" is in column 4.

[0039] By reading the data from these columns, "10,000.00" is converted to the number 10000, and the row number of each data entry in the original file (i.e., the chronological ledger file) is recorded (e.g., row 4 corresponds to original row number 4), generating a standard chronological ledger data table. In the generated standard chronological ledger data table, the first row can be "Original table row number = 4, Account name = R&D expenses, Debit amount = 10000, Auxiliary item = [Budget code: RD001]", and the second row is similar, thus completing the conversion from the original heterogeneous file to a standardized data table.

[0040] In some embodiments, after obtaining the chronological ledger file, multi-level column header adaptive parsing can be performed: 1. Inspect the column header level of the chronological ledger file. Analyze data type consistency, null value rate, and numerical characteristics to automatically identify the number of rows occupied by the column header.

[0041] 2. Perform column header merging. For each column, obtain the multi-level column header values, remove null values, and obtain a valid list. If the valid list is empty, skip the column; if the valid list has only one element, use that element as the column name; if the valid list has multiple elements, use a concatenation operator to join the multi-level column names into a single identifier.

[0042] 3. Generate a standard chronological ledger data table. Apply the merged single-level column headers to the data reading to obtain a standardized data table structure (i.e., the single-level column headers required for a standard chronological ledger data table).

[0043] In the above embodiments, since the chronological ledger file adopts a multi-level column header structure, the hard-coded index requires code modification when the format changes. By adopting adaptive parsing, it can adapt to different levels of column header structure, and can complete the reading of chronological ledger files of different formats without manually modifying the code, thereby improving adaptability.

[0044] Step 102: Obtain the monthly report of R&D projects, extract features from the monthly report of R&D projects to obtain project feature vectors corresponding to multiple project objects, and extract features from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records.

[0045] In practical applications, feature extraction can be performed on the monthly report to obtain the project feature vectors corresponding to multiple project objects in the R&D project monthly report. Similarly, feature extraction can be performed on the standard chronological ledger data table to obtain the chronological ledger feature vectors corresponding to multiple chronological ledger records in the standard chronological ledger data table.

[0046] In some embodiments, the monthly R&D project report can be a summary table that records the basic information of each R&D project in the current month. The monthly R&D project report may include fields such as project name, project code, and topic classification.

[0047] In the R&D project monthly report, each project can be considered a project object. The R&D project monthly report can record information for each project in the "Project Name" column. However, the information for each project in the Project Name column can include not only a single string, but also multiple levels of semantic content, such as project file number, currently used project name, and the name of the topic to which it belongs. The information for each project can be combined together using specific separators, such as 【】, spaces, commas, etc.

[0048] To obtain the project feature vector corresponding to a project object, a set of regular expressions can be predefined. Each regular expression is used to match and extract semantic content at a certain level. For example, a regular expression can be defined to extract the project file list (which may contain multiple file numbers), a regular expression can be defined to extract the current name, and a regular expression can be defined to extract the topic name, while retaining the original full name as a dimension.

[0049] By combining the content extracted from regular expressions, a project feature vector corresponding to the project object is constructed. The project feature vector can contain multiple components such as a list of project files, the current name, the topic name, and the original full name.

[0050] For example, the original text of the "Project Name" column in a certain row of a monthly R&D project report is "[Project File:RD001][Project File:RD002][Current Name: Intelligent Cockpit System][Topic Name: Cockpit]". Multiple regular expressions can be applied to this original text: the regular expression for "Project File" can match "RD001" and "RD002", resulting in a list of project files ["RD001", "RD002"]; the regular expression for "Current Name" can match "Intelligent Cockpit System"; the regular expression for "Topic Name" can match "Cockpit"; and the original text is retained as the original complete name.

[0051] The project feature vector corresponding to the intelligent cockpit system project object can be: Project file list = ["RD001", "RD002"], Current name = [Intelligent cockpit system], Topic name = [Cockpit], Original full name = "[Project file:RD001][Project file:RD002][Current name: Intelligent cockpit system][Topic name: Cockpit]".

[0052] Feature extraction from a standard chronological ledger data table can refer to reading each chronological ledger record in the table one by one, parsing the tagged information contained in the auxiliary text of each record, such as budget codes, customer files, project files, department files, personnel files, etc., and organizing this tagged information into an array-like data structure as a chronological ledger feature vector.

[0053] For example, in the standard chronological ledger data table, there is a chronological ledger record with the auxiliary text "[Budget Code: RD001][Customer Profile: XX Technology Company][Department: R&D Department II]". By extracting features from this auxiliary text, a chronological ledger feature vector can be obtained; the chronological ledger feature vector can contain: Budget Code = [RD001], Customer Profile = [XX Technology Company], Project Profile = [(empty if not present in the auxiliary text)], Department Profile = [R&D Department II], Personnel Profile = [(empty if not present)].

[0054] Step 103: Based on the project feature vector and the chronological ledger feature vector, obtain the matching results between the multiple project objects and the multiple chronological ledger records.

[0055] In practical applications, the semantic relationship between multiple project objects and multiple chronological ledger records can be determined by comparing the semantic association between the project feature vector and the chronological ledger feature vector, and the correspondence can be used as the matching result.

[0056] In some embodiments, it is possible to compare whether each semantic component in the project feature vector has an inclusion relationship or an equality relationship with the corresponding field in the chronological ledger feature vector. For example, it can be determined whether the current name in the project feature vector is a substring of the budget code in the chronological ledger feature vector, or whether the code in the project file list in the project feature vector is the same as the project file in the chronological ledger feature vector. The matching results can be recorded in the form of a list or set for the project objects matched by each chronological ledger record.

[0057] For example, the project feature vector includes the original full name "Intelligent Cockpit System", the current name "Intelligent Cockpit", the topic name "Cockpit", and the project file list ["RD001"]. The chronological ledger feature vector includes the budget code "RD001-2024", the customer file "XX Company", and the project file is empty.

[0058] By comparison, "RD001" in the project file list of the project feature vector is a substring of the budget code "RD001-2024" in the chronological ledger feature vector. Therefore, it can be determined that the chronological ledger record matches the project object successfully, and a matching result is obtained. If the chronological ledger record belongs to the "Intelligent Cockpit System" project, the matching type is "Budget code matches project file". If all fields in the chronological ledger feature vector of a chronological ledger record cannot match the information in any project feature vector, the matching result can mark the chronological ledger record as a failed match.

[0059] Step 104: Based on the amount corresponding to the successfully matched chronological ledger record, determine the project dimension amount corresponding to each project object, and determine the internal chronological ledger record in the successfully matched chronological ledger record. Based on the amount corresponding to the internal chronological ledger record, determine the consolidated deduction amount corresponding to each project object.

[0060] In practical applications, the sum of the amounts of all successfully matched chronological ledger records under each project object can be calculated based on the amounts corresponding to the successfully matched chronological ledger records, and this sum can be used as the project dimension amount corresponding to the project object.

[0061] Furthermore, among the successfully matched chronological ledger records, it is possible to identify whether the chronological ledger record belongs to the nature of an internal transaction. If so, the chronological ledger record is identified as an internal chronological ledger record. Based on the amount corresponding to the internal chronological ledger record, the sum of the amounts of all internal chronological ledger records under each project object is calculated and used as the consolidation deduction amount corresponding to the project object.

[0062] In some embodiments, a project object can correspond to multiple successfully matched chronological ledger records. The project-level amount can be the sum of the amounts of all successfully matched chronological ledger records belonging to the same project object, reflecting all expenses actually incurred by the project object.

[0063] Internal chronological ledger records refer to those records where the customer profile belongs to an internal unit of the enterprise (such as a parent company, subsidiary, branch, or internal R&D center). The transactions corresponding to these chronological ledger records are internal transactions of the enterprise. For example, a list of internal units can be prepared in advance (which can be stored in an external configuration file). By extracting the customer profile information from each successfully matched chronological ledger record, the customer profile is matched with the list of internal units. A successful match can be identified as an internal chronological ledger record.

[0064] The consolidated deduction amount can refer to the sum of all internal chronological ledger records belonging to the same project object. This sum can be deducted from the project-level amount when preparing consolidated financial statements to avoid double counting of internal transactions.

[0065] Each project object can calculate both the project-level amount and the consolidated deduction amount simultaneously. The difference between the project-level amount and the consolidated deduction amount can reflect the project object's actual expenditures to external third parties.

[0066] For example, if the project object is "intelligent cockpit system" and there are three successfully matched chronological account records with amounts of 100,000 yuan, 50,000 yuan, and 30,000 yuan respectively, then the project dimension amount is 180,000 yuan. The chronological account record with an amount of 100,000 yuan has a customer profile of "XX Technology Company," which is also included in the internal unit list; therefore, this chronological account record is identified as an internal chronological account record. The customer profiles for the two records with amounts of 50,000 yuan and 30,000 yuan are not in the internal unit list, therefore they are not internal chronological account records.

[0067] Therefore, the consolidated deduction amount for the project object (intelligent cockpit system) can be determined to be RMB 100,000 (i.e. the sum of the amounts recorded in the internal chronological ledger). The project-level amount of RMB 180,000 can be used for internal cost accounting, and the consolidated deduction amount of RMB 100,000 can be deducted when making consolidated financial statements, resulting in a net external expenditure of RMB 80,000.

[0068] Step 105: Based on the matching results, generate multiple functional reports; wherein, the multiple functional reports include a project summary table, a matching details table, and a remaining details table. The project summary table includes the project dimension amount, the consolidated deduction amount, and the net amount. The matching details table includes traceability information of successfully matched chronological ledger records. The remaining details table includes traceability information of unmatched chronological ledger records and traceability information of excluded chronological ledger records.

[0069] In practical applications, the project summary table can include the project dimension amount, the consolidated deduction amount, and the net amount obtained by subtracting the consolidated deduction amount from the project dimension amount for each project object.

[0070] In some embodiments, the matching results may include information such as whether each chronological ledger record was successfully matched, which item was matched, the matching type, and the matching basis. Functional reports can be used to display the aggregation results to users or to provide reports for auditing and verification purposes.

[0071] The project summary table can summarize and display the total cost, internal transaction deduction amount, and external net expenditure for each project by project object dimension, which facilitates the preparation of monthly reports or consolidated financial statements by finance personnel. The matching details table can list each successfully matched chronological ledger record and include traceability information, which may include the original line number, the name of the matched project, the matching type, the matching content, the matching priority, whether it is an internal unit, whether deconstruction feature matching was used, the amount, the account name, and the customer profile field.

[0072] The remaining details table can be used to record traceability information for chronological ledger records that failed to be properly aggregated. This can include traceability information for records that failed to match (i.e., matched but no corresponding item was found) and excluded records (i.e., records that were actively removed because the account does not belong to the R&D scope or other rules). The traceability information can include fields such as the original table row number, the reason for exclusion or the status of non-matching, the original data, and the system's suggested operation.

[0073] For example, for the "Intelligent Cockpit System" project, the project summary table can show that the project object is the intelligent cockpit system, the project amount is 180,000 yuan, the consolidated deduction amount is 100,000 yuan, and the net amount is 80,000 yuan.

[0074] The matching details table can list three records: The first record is from the original table, row number 5, amount 100,000 yuan, matching type is "budget code matching", customer is "XX Technology Company", and internal unit is "yes"; the second record is from the original table, row number 12, amount 50,000 yuan, matching type is "project file matching", and internal unit is "no"; the third record is from the original table, row number 23, amount 30,000 yuan, matching type is "current name matching", and internal unit is "no".

[0075] The remaining details table can contain one unmatched record (original table row number 6, auxiliary item is "[Project File: Unknown Project]", status is "unmatched") and one excluded record (original table row number 20, project is "Management Expenses", exclusion reason is "non-R&D related project").

[0076] In some embodiments, a traceability tag can also be generated for each processed chronological ledger record: For each successfully matched record, a unique traceability identifier is generated, recording the original Excel row number, the name of the matched project, the matching type, the matched content, the matching priority, whether it is an internal unit, whether the deconstruction feature was used, the amount, the account name, the customer file, and the processing timestamp.

[0077] For excluded records, a unique traceability identifier is generated, recording the original Excel row number, exclusion reason, account name, amount, and processing timestamp.

[0078] For unmatched records, generate a unique traceability identifier, and record the original Excel row number, unmatched status, auxiliary item content, and processing timestamp.

[0079] In this embodiment of the invention, a chronological ledger file is acquired and preprocessed to obtain a standard chronological ledger data table, which includes multiple chronological ledger records. A monthly report of R&D projects is acquired, and features are extracted from the report to obtain project feature vectors corresponding to multiple project objects. Similarly, features are extracted from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records. Based on the project feature vectors and chronological ledger feature vectors, matching results are obtained between multiple project objects and multiple chronological ledger records. Based on the amounts corresponding to the successfully matched chronological ledger records, the project dimension amount corresponding to each project object is determined. Internal chronological ledger records are identified from the successfully matched records, and the consolidated deduction amount corresponding to each project object is determined based on the amounts corresponding to the internal chronological ledger records. Based on the matching results, multiple functional reports are generated, including a project summary table, a matching details table, and a remaining... The system comprises three tables: a project summary table (containing project-level amounts, consolidated deduction amounts, and net amounts), a matching details table (including traceability information for successfully matched chronological ledger records), and a remaining details table (including traceability information for unmatched and excluded chronological ledger records). This system achieves standardized conversion of chronological ledger files of different formats by obtaining and preprocessing them to obtain a standard chronological ledger data table. By extracting project feature vectors and chronological ledger feature vectors from the R&D project monthly report and the standard chronological ledger data table, and performing matching based on these feature vectors, the system improves matching coverage and success rate. By determining the project-level amount and consolidated deduction amount for each project object based on successfully matched chronological ledger records, the system reduces the manpower and time costs of manual calculation. Finally, by generating project summary tables, matching details tables, and remaining details tables based on the matching results, the system enables hierarchical display of financial data based on the matching results and improves the traceability of financial data.

[0080] In some embodiments of the present invention, the chronological ledger file is preprocessed to obtain a standard chronological ledger data table, including: Sub-step 1011: Detect the multi-level column headers in the chronological ledger file and merge the multi-level column headers into a single-level column header required by the standard chronological ledger data table; wherein, the column name of the single-level column header is a single identifier that connects the multi-level column names through a concatenation operator.

[0081] In practical applications, it is possible to detect whether a chronological ledger file contains multi-level column headers and merge these multi-level column headers into a single-level column header, which serves as the column header for the standard chronological ledger data table. In the merged single-level column header, the column name of each column can be a single identifier formed by concatenating column names from multiple levels using a concatenation operator.

[0082] In some embodiments, multi-level column headers can refer to a column header area occupying multiple rows in a chronological ledger file exported by financial software. For example, the first row can be the general category name of the column (such as "Item" or "Amount"), and the second row can be the specific field name (such as "Code", "Name", "Debit", or "Credit").

[0083] By analyzing the distribution of null values, data type consistency, and numerical characteristics of the first few rows of the chronological ledger file, it can be determined which rows belong to the column header area. The merging operation can be performed on each column by extracting its multi-row column names from top to bottom in order and concatenating them into a complete column name using a connector (such as an underscore "_"), thus combining the column header information scattered across multiple rows into a single-level column header.

[0084] For example, the first two rows of a chronological ledger file are column headers: the first row contains "Item", "Item", "Amount", "Amount"; the second row contains "Code", "Name", "Debit", "Credit". For the first column, the multi-level column names are "Item" and "Code", and the merged single-level column name is "Item_Code"; the second column is merged into "Item_Name"; the third column is merged into "Amount_Debit"; and the fourth column is merged into "Amount_Credit". Thus, in the resulting single-level column header, each column name is a single identifier formed by connecting multi-level names with underscores.

[0085] Sub-step 1012: Determine the matching score between the column name of the single-level column header and the keywords in the preset column name semantic feature library, and determine the target column required for the standard chronological ledger data table based on the matching score.

[0086] In practical applications, the matching score between each column name in the single-level column header and the keywords in the pre-established column name semantic feature library can be calculated, and the target columns (such as debit amount column, auxiliary item column, account name column, etc.) required by the standard chronological ledger data table can be determined based on the matching score.

[0087] In some embodiments, the column name semantic feature library can be a predefined data structure, and a corresponding set of keywords and the weight of each keyword can be set for each target semantic (such as "debit amount", "auxiliary item", "account name").

[0088] Determining the matching score can be achieved by: calculating the weighted matching score between each column name in the single-level column header and each target semantic, such as summing the weights of keywords appearing in the column name and then dividing by the sum of the weights of all keywords in the target semantic. For each target semantic, the column with the highest matching score can be selected as the target column for that semantic. If the highest matching score for a target semantic is lower than a preset threshold, a degradation strategy can be enabled, such as using a preset column position index as the target column.

[0089] For example, targeting the semantic meaning of "debit amount", the preset keywords include "debit" (weight 0.6), "local currency" (weight 0.4), and "amount" (weight 0.3). A single-level column header contains a column named "amount_debit", which contains the keywords "amount" and "debit". Therefore, the match score is (0.6+0.3) / (0.6+0.4+0.3)=0.9 / 1.3≈0.69. Since 0.69 is higher than the preset threshold of 0.5, this column can be designated as the target column for debit amount. Similarly, targeting the semantic meaning of "auxiliary items", the preset keywords include "auxiliary items" and "auxiliary". If a column name has the highest match score, it can be designated as the auxiliary item column.

[0090] In some embodiments, corresponding keyword sets and weights for each keyword can be set for columns such as debit amount, auxiliary items, and account name, to construct a column name semantic feature library; as shown in Table 1:

[0091] Table 1 Sub-step 1013 involves performing quality cleaning on the data in the target column and generating a standard chronological ledger data table based on the single-level column header, the target column, and the cleaned data.

[0092] In practical applications, the data corresponding to the identified target columns can be cleaned to improve quality, and a standard chronological ledger data table can be generated based on the merged single-level column headers, the identified target column positions, and the cleaned data.

[0093] In some embodiments, quality cleaning may include operations such as monetary value conversion, text normalization, and recording original row numbers. Monetary value conversion may refer to converting text in a monetary column (such as "10,000.00") into a numeric type (such as 10000) for subsequent summation calculations; for non-numeric content that cannot be converted, it can be padded with zeros and the original value can be saved for verification. Text normalization may refer to removing leading and trailing whitespace characters from text fields such as account names and auxiliary items, and uniformly treating null values ​​as empty strings.

[0094] Recording the original row number refers to recording the actual row number in the original chronological ledger file for each data row read (e.g., row 5 in the original file). The row number can be retained as a column for subsequent auditing and tracing. When generating a standard chronological ledger data table, the cleaned data can be filled into the corresponding columns according to the structure defined in the single-level column header (i.e., the order and meaning of the column names), while retaining the original row number column, forming a table with a unified structure and standardized data.

[0095] For example, in the original chronological ledger file, the debit amount in line 4 is listed as "10,000.00", the auxiliary item is listed as "[Budget Code:RD001]", and the account name is listed as "Research and Development Expenses". The debit amount can be converted to the number 10,000; leading and trailing spaces in the auxiliary item and account name can be removed; and the original line number can be recorded as 4.

[0096] Based on the column names in the single-level column header (such as "Account Name", "Debit Amount", "Auxiliary Item"), generate a standard row of data: Account Name = "R&D Expenses", Debit Amount = 10000, Auxiliary Item = "[Budget Code: RD001]", and add a column "Original Table Row Number" with a value of 4. Repeat this process to process all data rows to obtain a complete standard chronological ledger data table.

[0097] In some embodiments, data cleansing of the target column may include converting amounts to numeric values, standardizing text, and recording original row numbers. For example, amount fields are converted to numeric types, non-numeric fields that cannot be converted are filled with zeros, and the original values ​​are marked for verification; leading and trailing whitespace characters are removed from text fields, and null values ​​are converted to empty strings; the row number of each record in the original Excel file is recorded for subsequent audit tracing. As shown in Table 2:

[0098] Table 2 In the above embodiments, the target field is dynamically located by matching keyword weights through a multi-level column header fusion algorithm and semantic column intelligent positioning technology, thereby achieving adaptive parsing of heterogeneous Excel formats.

[0099] In some embodiments of the present invention, the matching score between the column name of the single-level column header and keywords in a preset column name semantic feature library is determined, and the target column required for the standard chronological ledger data table is determined based on the matching score, including: Sub-step 10121: Obtain the column name semantic feature library, which contains the correspondence between the target semantics and the keyword set, as well as the weight of each keyword in the keyword set.

[0100] In practical applications, the semantic feature library can pre-establish the correspondence between target semantics and keyword sets, and set corresponding weights for each keyword.

[0101] The target semantics can include "debit amount" and "auxiliary items." Specifically, the target semantics (debit amount) can be used to locate columns in the chronological ledger that record expense amounts; the target semantics (auxiliary items) can be used to locate columns in the chronological ledger that record auxiliary accounting information (such as budget codes, customer files, project files, etc.). Different target semantics can correspond to different sets of keywords and weight configurations. By calculating the matching score between column names and each target semantic, the actual data column corresponding to each target semantic can be determined.

[0102] For example, in a pre-built column name semantic feature library, for the target semantic "debit amount", the following information is stored: the keyword set is {"debit", "local currency", "debit", "amount"}, with corresponding weights of {0.6, 0.4, 0.3, 0.3}. For the target semantic "auxiliary item", the keyword set can be stored as {"auxiliary item", "auxiliary", "auxiliary", "assist"}, with weights of {0.7, 0.3, 0.3, 0.2}.

[0103] Sub-step 10122: For each column name in the single-level column header, determine the weighted matching score of the target semantics corresponding to the column name and the keyword based on the keyword that matches the column name and the weight of the keyword.

[0104] In practical applications, for each column name in a single-level column header, a weighted matching score between the column name and a certain target semantic can be calculated based on the keywords matched in the column name string and the weights corresponding to the keywords.

[0105] In some embodiments, for a given target semantics, each keyword in the keyword set corresponding to the target semantics can be traversed, and it can be checked whether the keyword appears in the column name string. If it appears, the weight of this keyword can be added to a total score; if it does not appear, it is not added.

[0106] The weighted match score is obtained by dividing the total score by the sum of the weights of all keywords for the target semantic meaning. The weighted match score ranges from 0 to 1, with a higher score indicating a stronger relevance between the column name and the target semantic meaning. For the same column name, weighted match scores can be calculated separately for different target semantic meanings. For example, a column name might match some keywords for both "debit amount" and "auxiliary item," but the target semantic meaning with the highest weighted match score represents the true meaning of the column name.

[0107] For example, a single-level column header contains a column named "Local Currency Debit". For the target semantic "Debit Amount", the keyword set is {"Debit" (0.6), "Local Currency" (0.4), "debit" (0.3), "amount" (0.3)}. Analysis confirms that the keywords "Local Currency" and "Debit" appear in the column name, therefore the cumulative score is 0.6 + 0.4 = 1.0. The sum of the weights of all keywords is 0.6 + 0.4 + 0.3 + 0.3 = 1.6. The weighted match score is 1.0 / 1.6 = 0.625. For the target semantic "Auxiliary Items", no keywords are matched in the single-level column header's column name, resulting in a weighted match score of 0.

[0108] In some embodiments, for each column name in a single-level column header, a weighted match score with the target semantic keyword set can be calculated. The weighted match score can be equal to the keyword weight multiplied by the weighted sum of indicator functions (e.g., 1 for keywords appearing in the column name, 0 otherwise), and then divided by the total weights; for example, the weighted match score can be calculated using the following formula:

[0109] in, This refers to the weighted matching score between the column name and the target semantics; This refers to the preset weight of keyword k; This refers to an indicator function that takes the value 1 if the keyword k appears in the column name col, and 0 otherwise. This refers to the sum of the weights of all keywords under the target semantics.

[0110] Sub-step 10123: Select the column with the highest weighted matching score as the target column corresponding to the target semantics.

[0111] In practical applications, for each target semantic, the column with the highest weighted matching score can be selected from the single-level column header as the target column corresponding to that target semantic.

[0112] Sub-step 10124: When the weighted matching score is lower than a preset threshold, the column corresponding to the preset position is taken as the target column corresponding to the target semantics.

[0113] In practical applications, if the highest weighted matching score corresponding to a certain target semantic is lower than a preset threshold, a column corresponding to a preset position can be used as the target column of that target semantic.

[0114] In some embodiments, the preset threshold can be a numerical limit, such as 0.5 or 0.3, used to determine the confidence level of the weighted matching score. If the weighted matching score is lower than the first threshold (e.g., 0.5), a warning message can be marked, but the column with the highest weighted matching score is still used as the target column; if the weighted matching score is lower than the second threshold (e.g., 0.3), it indicates that automatic identification may be unreliable, and a degradation strategy can be enabled, that is, data is read according to a preset column position index (e.g., fixing the 5th column as the debit amount column and the 4th column as the auxiliary item column).

[0115] The preset position can be pre-configured according to the export format of the financial software, or manually specified by the user, to ensure that it can continue to run in extreme abnormal situations (such as column names being all garbled or empty values) and will not crash.

[0116] For example, in a single-level column header of a chronological ledger file, the weighted matching score of all column names with the target semantic "debit amount" is 0.25, which is lower than the second threshold of 0.3. The identification result is deemed unreliable, and a degradation strategy can be initiated, using a preset position index: the debit amount column is fixed at column 5, and the auxiliary item column is fixed at column 4. After using the column corresponding to the preset position as the target column for this semantic, a warning log can be generated to prompt the user to check the accuracy of the automatic identification.

[0117] If the highest weighted match score is 0.45, which is between 0.3 and 0.5, a warning can be issued, but the column with the highest weighted match score should still be used as the target column, and the user should be prompted that manual review may be required.

[0118] In some embodiments, the column with the highest weighted matching score can be selected as the target column. If the highest weighted matching score is lower than a first threshold, a warning can be issued but the column can still be used; if the highest weighted matching score is lower than a second threshold, a degradation strategy can be enabled, and a preset position index can be used as the target column corresponding to the target semantics, such as reading column H (index 7).

[0119] For example, the target column can be selected using the following criteria: like If the value is greater than 0.5, select that column as the target column.

[0120] like If the value is ≤0.5, a warning is indicated, but the column is still used.

[0121] like If the value is ≤0.3, a degradation strategy is enabled, and the preset position index is used as the target column corresponding to the target semantics.

[0122] In some embodiments of the present invention, the project feature vector includes one or more of the following: project file list, current name, topic name, original full name; the chronological ledger feature vector includes one or more of the following: budget code, customer file, project file, department file, personnel file.

[0123] In practical applications, the project file list can contain the file number of one or more projects in the financial system; the current name can be the name currently used by the project; the topic name can be the name of the topic or sub-project to which the project belongs; and the original full name can be an unparsed raw string read directly from the monthly report.

[0124] Budget code can be the identification code of the project budget; customer file can be the name of the supplier or customer; project file can be the project file information extracted from auxiliary items; department file can be the name of the department to which the expenses belong; personnel file can be the name of the person in charge.

[0125] In some embodiments of the present invention, feature extraction is performed on the monthly report of the R&D project to obtain project feature vectors corresponding to multiple project objects, and feature extraction is performed on the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records, including: Sub-step 1021: Obtain the project name of each project object in the monthly report of the R&D project, extract features from the project name using regular expression groups, and generate a project feature vector corresponding to each project object based on the extracted features.

[0126] In practical applications, each row in the monthly R&D project report can correspond to a project object, and the "Project Name" column of each row can store the complete name string of that project object. This string can contain project file list, current name, topic name, and other project-related information, and the relevant project information can be combined together using specific delimiters (such as 【】, spaces, commas, etc.).

[0127] A regular expression group can refer to a predefined set of regular expressions, each of which can be used to match and extract semantic content at a certain level.

[0128] For example, you can define a regular expression to match project file number (e.g., "[Project File:RD001]"), a regular expression to match current name (e.g., "[Current Name: Intelligent Cockpit System]"), and a regular expression to match topic name (e.g., "[Topic Name: Cockpit]").

[0129] By applying regular expressions sequentially to the project name string, the corresponding field values ​​can be extracted. The extracted field values ​​(such as a list of project files, current name, topic name) and / or the original project name string itself are combined into a structured array or list as the project feature vector corresponding to the project object.

[0130] In some embodiments, such as Figure 2 It can perform multi-dimensional feature extraction based on project name; it can define extraction modes for various semantic information such as project archives, current names, and topic names; the project archive mode can support extraction of multiple archive numbers, while the current name and topic name modes can support extraction of a single value.

[0131] During feature extraction, semantic features can be extracted in parallel using groups of regular expressions: 1. Extract project file collection: Match all project file numbers, support handling separators (semicolon, comma, pause mark, space), and split composite files into a list of independent files.

[0132] 2. Extract current name: Match the current name field and remove leading and trailing whitespace.

[0133] 3. Extract topic name: Match the topic name field and remove leading and trailing whitespace.

[0134] 4. Retain the original full name as a backup feature.

[0135] After feature extraction, the extracted features can be organized into a structured feature vector (i.e., project feature vector), which can contain four dimensions: a list of project files, the current name, the topic name, and the original full name, as shown in the following formula:

[0136] in, This refers to the project feature vector; This refers to the project file feature list (multi-valued). This refers to the currently used name characteristic (single value); This refers to the topic name feature (single value); This refers to the original, complete name.

[0137] Sub-step 1022: Obtain the auxiliary item text for each chronological ledger record in the standard chronological ledger data table. The auxiliary item text contains a tag structure consisting of pairs of tag names and tag content. Use a regular expression that matches each tag name and tag content to extract features from the auxiliary item text, and generate a chronological ledger feature vector corresponding to each chronological ledger record based on the extracted features.

[0138] In practical applications, auxiliary item text for each chronological ledger record in a standard chronological ledger data table can be obtained. This auxiliary item text may contain a tag structure consisting of pairs of tag names and tag content. Features are extracted from the auxiliary item text using regular expressions that match each tag name and tag content, and a chronological ledger feature vector is generated for each chronological ledger record based on the extracted features.

[0139] In some embodiments, each chronological ledger record in a standard chronological ledger data table may include an “auxiliary item” column, in which the text stored may be a string consisting of multiple tags, such as [tag name: tag content]. Here, the tag name indicates the type of information (such as budget code, customer file, project file, etc.), and the tag content indicates the specific value.

[0140] By pre-constructing regular expressions for each preset tag type (such as budget code, customer file, project file, department file, personnel file, etc.), the regular expressions can be used to match the corresponding tag structure and capture the tag content within it.

[0141] For example, for budget coding, a regular expression can be constructed as "

Budget Coding:([^]]+)

Customer Profiles:([^]]+)

[0142] By organizing all extracted tag content (such as budget codes, customer files, project files, department files, personnel files, etc.) into an array or list, it serves as the chronological ledger feature vector corresponding to the chronological ledger record.

[0143] In some embodiments, such as Figure 2 This method can perform tag-based parsing of auxiliary items in standard chronological ledger data tables. Since auxiliary items are stored in a tag format, extracting structured information from unstructured text can include the following steps: 1. Define a set of tag patterns. Establish a set of tag types that includes budget codes, project files, customer files, department files, and personnel files.

[0144] 2. Construct the extraction pattern. For each tag type, construct a corresponding regular expression extraction pattern. The pattern structure is: tag start tag, tag name, delimiter, capture group (extracted content), and tag end tag. For example, construct the regular expression using the following formula:

[0145] in, This refers to a regular expression pattern dynamically constructed based on the type of t tag (such as budget code, customer profile, etc.); This represents the raw string, ensuring that backslashes are not escaped; t is a variable representing the specific tag type (such as budget code, customer file, etc.); [ indicates matching Chinese left square brackets, marking the beginning of a tag; This refers to matching colons to separate tag names and content; This refers to a capture group; This indicates that any single character except for "】" and "=". This indicates a non-greedy match, repeating once or multiple times to match in the shortest possible amount of time. The symbol indicates that the matched content will be captured for later extraction; the symbol 】 indicates that the right square bracket of Chinese characters will be matched to mark the end of the tag.

[0146] 3. Perform the extraction operation. Apply various extraction modes to the auxiliary text to obtain field values ​​such as budget code, customer profile, and project profile. If a certain type is not matched, the field value will be empty. See the following formula:

[0147] in, This refers to the extracted tag values, such as Value_{Budget Code}=RD001, or Value_{Customer Profile}=XX Company; This refers to a custom or built-in function that applies a regular expression to helper text. If a match is found, it returns the content of the capture group (i.e., the value of the tag); if a match fails, it returns an empty value or an empty string. This refers to the raw text of auxiliary fields in chronological ledger records, such as [Budget Code: RD001] [Customer Profile: XX Company]; This refers to a regular expression dynamically generated based on the tag type t.

[0148] 4. Construct auxiliary feature vectors. Organize the extracted results into structured feature vectors (i.e., chronological account feature vectors), which may include fields such as budget codes, customer profiles, and project profiles. See the formula below:

[0149] in, B represents the chronological account feature vector; Q represents the customer profile; C represents the project profile; D represents the department profile; and P represents the person profile.

[0150] In some embodiments of the present invention, the matching result between the plurality of project objects and the plurality of chronological ledger records is obtained based on the project feature vector and the chronological ledger feature vector, including: Sub-step 1031 involves determining the inclusion relationship between each semantic component in the project feature vector and the budget encoding component in the chronological account feature vector, using this as the first matching channel.

[0151] In practical applications, the semantic components in a project feature vector can include the original full name, the current name, the topic name, and various elements in the project file list. The budget coding component in a chronological ledger feature vector can be the value of the budget coding field extracted from the auxiliary item text.

[0152] Inclusion relationship determination can be used to determine whether a string (such as a semantic component in a project feature vector) is a substring of another string (such as a budget encoding component).

[0153] Sub-step 1032 involves determining the inclusion relationship between each semantic component in the project feature vector and the project file component in the chronological ledger feature vector, which serves as the second matching channel.

[0154] In practical applications, the item file component in the chronological ledger feature vector can be the value of the item file field extracted from the auxiliary item text.

[0155] The inclusion relationship between the semantic components (such as the original full name, the current name, the topic name, the project file list elements, etc.) in the project feature vector and the project file component can be determined, that is, check whether the project semantic component is a substring of the project file component.

[0156] Sub-step 1033: According to the preset priority order, the inclusion relationship judgment in the first matching channel and the second matching channel is executed sequentially, and when any inclusion relationship judgment is successful, the chronological ledger record corresponding to the chronological ledger feature vector is matched with the project object corresponding to the project feature vector.

[0157] In some embodiments, the preset priority order can be specified to execute the first matching channel first, and if all inclusion relationship judgments in the first matching channel fail, then the second matching channel is executed.

[0158] Within each matching channel, semantic components can be evaluated sequentially according to a certain priority order (e.g., first the original full name, then the current name, then the topic name, and finally the elements in the project file list). Once a judgment is successful, subsequent judgments can be stopped immediately, and the chronological ledger record is marked as having matched the project object, thereby improving matching efficiency.

[0159] A matching relationship can be a correspondence between a chronological ledger record and a research and development project object. The matching relationship can include information such as the original table row number of the chronological ledger record, the identifier of the matched project object, the name of the successfully matched channel, the semantic component of the successfully matched object, and the matching priority.

[0160] For example, the first matching channel can be executed: it determines whether the original full name of a project feature vector is a substring of the chronological ledger budget code. If it is, the match is successful and a matching relationship is established; otherwise, it continues to determine the current name. If all semantic components in the first matching channel fail to be determined, the second matching channel is entered, and the semantic components of the project are determined in a preset order to determine whether they are substrings of the chronological ledger project file.

[0161] Once a match is established, further matching of the chronological ledger record can be stopped. If all matches in both channels fail, the chronological ledger record can be marked as unmatched.

[0162] In some embodiments, such as Figure 2 A multi-channel parallel matching algorithm can be used to determine the matching results between multiple project objects and the multiple chronological ledger records. For example... Figure 3 A dual-channel parallel architecture can be established. By constructing two parallel matching channels, the two channels are executed independently, and a match is determined to be successful if either channel hits the target.

[0163] In some embodiments of the present invention, the inclusion relationship determination in the first matching channel and the second matching channel is performed sequentially according to a preset priority order, including: In the first matching channel, the inclusion relationship judgment is performed sequentially according to the following priority order: First priority: Determine whether the original complete name in the project feature vector is a substring of the budget code in the chronological ledger feature vector; Second priority: Determine whether the current name in the project feature vector is a substring of the budget code in the chronological account feature vector; Third priority: Determine whether the topic name in the project feature vector is a substring of the budget code in the chronological account feature vector; Fourth priority: Determine whether any element in the project file list of the project feature vector is a substring of the budget code in the chronological ledger feature vector; If all priority inclusion relationship checks in the first matching channel fail, then the inclusion relationship checks in the second matching channel will be performed sequentially according to the following priority order: Fifth priority: Determine whether the original complete name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Sixth priority: Determine whether the current name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Seventh priority: Determine whether the topic name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Eighth priority: Determine whether any element in the project file list of the project feature vector is a substring of the project file in the chronological ledger feature vector.

[0164] In practical applications, the first matching channel can prioritize using the semantic components in the project feature vector to determine the inclusion relationship between the budget encoding field in the chronological account feature vector (e.g., whether it is a substring). When no match is found through the judgment conditions in the first matching channel, the second matching channel can be used to determine the inclusion relationship between the semantic components in the project feature vector and the project file field in the chronological account feature vector.

[0165] In some embodiments, priority order can determine the order of judgment. Higher priority judgments will be executed first. When a certain priority judgment is successful, subsequent priority judgments can be stopped, and the chronological ledger record can be matched with the corresponding project object.

[0166] A substring can be a continuous segment in which one string appears completely within another string. For example, the result of determining whether "ABC" is a substring of "ABCDE" is yes; the result of determining whether "ABF" is a substring of "ABCDE" is no.

[0167] The original full name can be the raw string of the project name directly read from the monthly R&D project report, without any parsing or splitting. The current name can be the currently used project name extracted from the project name. The topic name can be the name of the topic or sub-project to which the project belongs, extracted from the project name.

[0168] A project file list can be a collection of one or more project file numbers extracted from project names. A budget code can be a budget number field extracted from chronological ledger auxiliary items. A project file can be a project file field extracted from chronological ledger auxiliary items.

[0169] In some embodiments, inclusion relationship matching can be performed through a first matching channel and a second matching channel. When there is a descriptional difference between the item name and the auxiliary item identifier, and an exact match fails, but a semantic inclusion relationship exists, a single matching channel four-level progressive matching method can be used, as follows: 1. Establish an inclusion relationship judgment function to determine whether the first string (i.e., each semantic component in the project feature vector) is a substring of the second string (i.e., the budget code component and the project file component), as shown in the following formula:

[0170] in, This refers to the function that determines the inclusion relationship; 'a' refers to the first string; 'b' refers to the second string. Indicates condition If the condition is met, that is, if string a is a substring of string b (all characters in a appear consecutively and completely in b), then the inclusion relationship is true. Indicates condition This condition is not met, meaning that string a is not a substring of string b, and the inclusion relationship test is false.

[0171] 2. Set a four-level priority matching strategy, and perform matching in order of priority: Level 1 (priority 1.0): Determine if the original complete project name is a substring of the budget code.

[0172] The second level (priority 0.9) determines whether the current name is a substring of the budget code.

[0173] The third level (priority 0.8) determines whether the topic name is a substring of the budget code.

[0174] Level 4 (priority 0.7): Determine if any element in the project file list is a substring of the budget code.

[0175] If the budget coding channel (i.e., the first matching channel) fails to match, the same four-level matching is performed in the project file channel (i.e., the second matching channel), with the priority decreasing sequentially (from 0.6 to 0.3), as shown in Table 3:

[0176] Table 3 In the above embodiments, by employing multi-level semantic deconstruction technology, the composite project name can be decomposed into multi-dimensional feature vectors. Combined with a four-level progressive matching strategy, the matching coverage rate can be increased from 60% to 94%.

[0177] In some embodiments, a global anti-duplicate mechanism can also be established by creating a global matching index set to record matched chronological ledger records. The matching process is as follows: Iterate through each item and extract its semantic feature vector for each item. Iterate through the chronological ledger records, checking if the current record index is already in the global matching index set. If it already exists, skip it, ensuring that each chronological ledger record is only collected once. Parse the auxiliary item feature vector of the current record. Perform dual-channel progressive matching. If a match is successful, record the matching result (including matching type, matching content, priority, amount, etc.) and add the current record index to the global matching index set.

[0178] Specifically, for single-record multi-item matching conflicts, if the same chronological ledger matches multiple items using different features, the highest priority match can be selected; if the highest priorities are similar (difference less than the threshold), it is marked as "requires manual review". For channel conflicts, if both the budget coding channel and the project file channel match, the budget coding channel result is used first. For low-confidence matches, if the highest priority is below the threshold, it is marked as "low confidence" and added to the review list.

[0179] In the above embodiments, the dual-channel parallel matching architecture can eliminate duplicate collection errors by coordinating the budget coding channel (i.e., the first matching channel) and the project file channel (i.e., the second matching channel) with a global anti-duplicate indexing mechanism.

[0180] In some embodiments of the present invention, an internal chronological ledger record is determined from the successfully matched chronological ledger records, and the consolidated deduction amount for each project object is determined based on the amount corresponding to the internal chronological ledger record, including: Obtain an external configuration file and read the list of internal units from the external configuration file; extract customer files from the successfully matched chronological ledger records; match the customer files with the list of internal units, and identify the successfully matched chronological ledger records as internal chronological ledger records.

[0181] In some embodiments, the external configuration file can be a separately stored text file or configuration table, which may include the names of all legal entities or departments within the corporate group that need to be consolidated and eliminated. The internal unit list can be a collection of unit names read from the external configuration file, such as "Group Headquarters," "R&D Center Headquarters," "XX Technology Company," "Beijing Branch," etc. The customer / supplier profile can be the names of customers or suppliers extracted from the auxiliary item text of the chronological ledger records, such as "XX Technology Company."

[0182] Matching methods can include exact matching (i.e., the names in the customer profile are exactly the same as those in the internal unit list), containment matching (i.e., one string is a substring of another string), or similarity matching based on edit distance.

[0183] In practical applications, exact matching can be used first. If it fails, inclusion matching or similarity matching can be used. Successfully matched chronological ledger records can be marked as internal chronological ledger records.

[0184] For example, the external configuration file "Internal Unit List.txt" contains the following unit names: "XX Technology Company", "R&D Center", and "Group Headquarters". There is a successfully matched chronological ledger record whose extracted customer profile is "XX Technology Company". By matching this customer profile with the internal unit list, confirming that "XX Technology Company" exists in the list, this chronological ledger record can be identified as an internal chronological ledger record.

[0185] In some embodiments, the list of internal units can be loaded from an external configuration file. The configuration file supports comment and blank line filtering for easy maintenance. The file encoding format is automatically detected during loading to ensure correct reading of Chinese unit names. The list of internal units is stored as a collection structure for fast lookup.

[0186] After obtaining the list of internal units, customer profiles can be extracted from the successfully matched chronological ledger records. Regular expressions can then be used to extract the customer profile field from the auxiliary feature vector. The regular expression structure can be: tag start marker, customer profile tag name, separator, capture group (extracting customer name), and tag end marker.

[0187] When matching customer files with internal unit lists, a three-level fuzzy matching identification method can be used, such as establishing a three-level identification strategy: Level 1 (Exact Match): Determines whether the extracted customer name is exactly the same as a certain unit in the internal unit list.

[0188] The second level (including matching) determines whether the customer's name is a substring of a certain internal unit's name, or whether a certain internal unit's name is a substring of the customer's name.

[0189] The third level (similarity matching) calculates the edit distance between the customer's name and the internal unit's name. If it is less than the threshold, it is considered a match (handling typos and historical name changes).

[0190] In some embodiments, for successfully matched records, two amount calculations can be performed simultaneously: calculating the project-level amount, i.e., summing the debit amounts of all matched records, converted to ten thousand yuan; and calculating the consolidated deduction amount, summing only the debit amounts of matched records where the customer / merchant is identified as an internal unit, also converted to ten thousand yuan. This can be performed simultaneously using the following formula:

[0191] in, This refers to the amount in the project dimension; This refers to summing the amounts of all successfully matched chronological ledger records under a specific project object. This refers to all successfully matched chronological ledger records under a specific project object; This refers to the unit conversion factor, such as 1 / 10000.

[0192] in, This refers to the deductible amount under the consolidated accounting method; This refers to a binary flag: when the customer file recorded in the chronological ledger belongs to the internal unit list, the flag is set to 1; otherwise, it is set to 0. {0,1}.

[0193] In some embodiments of the present invention, the method further includes: constructing a bidirectional index structure based on the matching detail table and the remaining detail table; the bidirectional index structure includes a forward index and a reverse index; wherein the forward index uses the project name as the key and the list of all successfully matched chronological ledger records corresponding to the project name as the value; the reverse index uses the original table row number as the key and the processing result of the chronological ledger record corresponding to the original table row number as the value.

[0194] After generating the matching details table and the remaining details table, a two-way index structure can be built based on the matching details table and the remaining details table.

[0195] The bidirectional index structure can include forward indexes and reverse indexes. A forward index can use the project name as the lookup key and the list of all successfully matched chronological ledger records corresponding to the project name as the value of the key. A reverse index can use the original line number (i.e., the line number of the chronological ledger record in the original file) as the lookup key and the processing result of the chronological ledger record corresponding to the original line number as the value of the key.

[0196] In some embodiments, the matching details table can record all successfully matched chronological ledger records. Each record can include information such as the original table row number, the name of the matched item, the amount, and the matching type. The remaining details table can record unmatched and excluded chronological ledger records. Each record can also include information such as the original table row number and the processing status (e.g., the reason for non-match or exclusion).

[0197] To facilitate quick user queries, forward and reverse indexes can be built based on the matching details table and the remaining details table. Forward indexes can be organized by project name; for example, all successfully matched chronological account records under the same project name can be collected into a list, with the project name as the index key. When a user needs to view all expense details for a specific project, they can quickly retrieve the list of records for that project directly through the forward index, without needing to traverse the entire matching details table.

[0198] Inverted indexes can be organized by row numbers in the original table. For example, the processing results for each chronological expense record (including successfully matched, unmatched, and excluded records) can be stored using the original row number as the key. The processing results can include information such as whether the record was successfully matched, the matched item, the match type, or the reason for unmatch or exclusion. When a user needs to trace the processing status of a specific expense record, they can quickly locate the corresponding processing result using the inverted index based on the original row number.

[0199] In the above embodiments, the bidirectional index architecture enables bidirectional, second-level queries from project to details and from row number to processing result, which can improve traceability efficiency and provide an interpretable and verifiable operational basis for financial data collection, avoiding query delays caused by full table traversal.

[0200] In some embodiments of the present invention, the method further includes: providing an interface for querying by project name, which, in response to an input project name, returns a list of matching details and statistical information corresponding to the project name; providing an interface for querying by original table row number, which, in response to an input original table row number, returns the processing result of the chronological ledger record corresponding to the original table row number; providing an interface for querying by amount range, which, in response to an input amount range, returns a sample of matching records within the amount range; and generating an audit report for the specified project in response to an audit request for the specified project; wherein the audit report includes: total project amount, matching type distribution, internal transaction ratio, number of low-confidence matches, and sampling details.

[0201] In practical applications, the interface for querying by project name can serve as a query function entry point. Users can enter or select a project name (such as "Intelligent Cockpit System") on the interface. By utilizing the constructed positive index, all successfully matched chronological account records under that project can be quickly found and displayed in list format. Statistical information can include the number of chronological account records under that project, the total amount, and the number of records of different matching types.

[0202] The interface for querying by row number in the original table allows users to input a row number (such as "5"). By using an inverted index, the interface can quickly locate the processing result corresponding to that row number, such as whether the chronological account record was successfully matched, the matched item, the matching type, etc.; or if it was not matched or excluded, it can display the status of not matching or the reason for exclusion.

[0203] The interface for querying by amount range can be used for audit sampling. For example, if a user enters an amount range of "10,000 to 50,000 yuan", the system can filter out the chronological ledger records with amounts falling within this range from the successfully matched chronological ledger records, and randomly or according to certain rules select a number of records as samples to be returned, making it easier for auditors to verify.

[0204] In some embodiments, audit requests can be initiated by the user through a graphical user interface. For example, a button or link can be placed next to each project in the project summary table or matching details table, with the button labeled "Generate Audit Report". When a user clicks the button corresponding to a project, that project is considered the designated project, and the audit report generation process is automatically triggered.

[0205] Alternatively, a separate report generation interface can be provided, which may include a drop-down list or input box for users to select or fill in the project name, as well as a "Generate Report" submit button; after the user selects the project and clicks the button, the audit request will be triggered.

[0206] In some embodiments, audit requests can be triggered via an application programming interface (API). For example, an external system or script can send an HTTP request, with the request path or parameters carrying a project identifier (such as a project name or project code). Upon receiving the request, the project identifier can be parsed, used as the specified project, and then an audit report can be generated and returned in formats such as JSON, PDF, or HTML.

[0207] In some embodiments, audit requests can be triggered by scheduled tasks or event-driven mechanisms. For example, an audit report can be automatically generated for all projects at the end of each month and saved to a specified directory or sent to relevant finance personnel. Alternatively, an audit request can be automatically triggered when a project's matching results show a large number of low-confidence matches, alerting finance personnel to pay close attention.

[0208] The total project amount can be the sum of the amounts of all successfully matched chronological ledger records under this project object, and its value is the same as the project dimension amount. Matching type distribution can refer to classifying a project object according to the different matching methods used when successfully associating chronological ledger records with the project object, and counting the proportion of records or amounts corresponding to each matching method to the total.

[0209] Internal transaction percentage can be the ratio of consolidated deduction amount to project-level amount. Low-confidence match count can refer to the number of records with lower matching priority (e.g., below a certain threshold). Sampling details can be detailed information about sampled chronological ledger records, such as original table row number, amount, match type, customer / vendor profile, etc.

[0210] Reference Figure 4 The diagram illustrates a flowchart of another financial data processing method provided by some embodiments of the present invention, which may specifically include the following steps: Step 401: Obtain the chronological ledger file, preprocess the chronological ledger file to obtain a standard chronological ledger data table; wherein the standard chronological ledger data table includes multiple chronological ledger records.

[0211] Step 402: Obtain the project name of each project object in the monthly report of R&D projects, extract features from the project name using regular expression groups, and generate a project feature vector corresponding to each project object based on the extracted features.

[0212] Step 403: Obtain the auxiliary item text for each chronological ledger record in the standard chronological ledger data table. The auxiliary item text contains a tag structure consisting of pairs of tag names and tag content. Use a regular expression that matches each tag name and tag content to extract features from the auxiliary item text, and generate a chronological ledger feature vector corresponding to each chronological ledger record based on the extracted features.

[0213] Step 404: Based on the project feature vector and the chronological ledger feature vector, obtain the matching results between the multiple project objects and the multiple chronological ledger records.

[0214] Step 405: Based on the amount corresponding to the successfully matched chronological ledger record, determine the project dimension amount corresponding to each project object, and determine the internal chronological ledger record in the successfully matched chronological ledger record. Based on the amount corresponding to the internal chronological ledger record, determine the consolidated deduction amount corresponding to each project object.

[0215] Step 406: Based on the matching results, generate multiple functional reports; wherein, the multiple functional reports include a project summary table, a matching details table, and a remaining details table. The project summary table includes the project dimension amount, the consolidated deduction amount, and the net amount. The matching details table includes traceability information of successfully matched chronological ledger records. The remaining details table includes traceability information of unmatched chronological ledger records and traceability information of excluded chronological ledger records.

[0216] In this embodiment of the invention, a standard chronological ledger data table is obtained by acquiring a chronological ledger file and preprocessing it. The standard chronological ledger data table includes multiple chronological ledger records. The project name of each project object in the monthly R&D project report is acquired, and features are extracted from the project name using regular expressions. A project feature vector corresponding to each project object is generated based on the extracted features. The auxiliary item text of each chronological ledger record in the standard chronological ledger data table is acquired. The auxiliary item text contains a tag structure consisting of pairs of tag names and tag content. Features are extracted from the auxiliary item text using regular expressions that match each tag name and tag content. A chronological ledger feature vector corresponding to each chronological ledger record is generated based on the extracted features. Matching results between multiple project objects and multiple chronological ledger records are obtained based on the project feature vector and the chronological ledger feature vector. The project dimension amount corresponding to each project object is determined based on the amount corresponding to the successfully matched chronological ledger records. Internal chronological ledger records are determined from the successfully matched chronological ledger records. The amount corresponding to each project object is determined based on the amount corresponding to the internal chronological ledger records. The system consolidates the deductible amount under a consolidated caliber. Based on the matching results, it generates multiple functional reports, including a project summary table, a matching detail table, and a remaining detail table. The project summary table includes project-level amounts, consolidated deductible amounts, and net amounts. The matching detail table includes traceability information for successfully matched chronological ledger records, and the remaining detail table includes traceability information for unmatched and excluded chronological ledger records. This system achieves standardized conversion of chronological ledger files of different formats by obtaining and preprocessing them to obtain a standard chronological ledger data table. By extracting project feature vectors and chronological ledger feature vectors from the R&D project monthly report and the standard chronological ledger data table, and performing matching based on these feature vectors, the system improves matching coverage and success rate. By determining the project-level amount and consolidated deductible amount for each project object based on successfully matched chronological ledger records, the system reduces the manpower and time costs of manual calculation. By generating project summary tables, matching detail tables, and remaining detail tables based on the matching results, the system enables hierarchical display of financial data based on the matching results and improves the traceability of financial data.

[0217] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0218] Reference Figure 5The diagram shows a structural schematic of a financial data processing apparatus provided in some embodiments of the present invention, which may specifically include the following modules: The standard chronological ledger data table acquisition module 501 is used to acquire a chronological ledger file, preprocess the chronological ledger file, and obtain a standard chronological ledger data table; wherein, the standard chronological ledger data table includes multiple chronological ledger records; The feature vector extraction module 502 is used to obtain the monthly report of R&D projects, extract features from the monthly report of R&D projects to obtain project feature vectors corresponding to multiple project objects, and extract features from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records. The matching result obtaining module 503 is used to obtain the matching result between the multiple project objects and the multiple chronological ledger records based on the project feature vector and the chronological ledger feature vector; The amount determination module 504 is used to determine the project dimension amount corresponding to each project object based on the amount corresponding to the successfully matched chronological ledger record, and to determine the internal chronological ledger record in the successfully matched chronological ledger record, and to determine the consolidated deduction amount corresponding to each project object based on the amount corresponding to the internal chronological ledger record. The functional report generation module 505 is used to generate multiple functional reports based on the matching results; wherein, the multiple functional reports include a project summary table, a matching detail table, and a remaining detail table, the project summary table includes the project dimension amount, the consolidated deduction amount, and the net amount, the matching detail table includes the traceability information of successfully matched chronological ledger records, and the remaining detail table includes the traceability information of unmatched chronological ledger records and the traceability information of excluded chronological ledger records.

[0219] In some embodiments of the present invention, the chronological ledger file is preprocessed to obtain a standard chronological ledger data table, including: The multi-level column headers in the chronological ledger file are detected, and the multi-level column headers are merged into a single-level column header required by the standard chronological ledger data table; wherein, the column name of the single-level column header is a single identifier that connects the multi-level column names through a concatenation operator; Determine the matching score between the column name of the single-level column header and the keywords in the preset column name semantic feature library, and determine the target column required for the standard chronological ledger data table based on the matching score; The data in the target column is cleaned to improve its quality, and a standard chronological ledger data table is generated based on the single-level column header, the target column, and the cleaned data.

[0220] In some embodiments of the present invention, the matching score between the column name of the single-level column header and keywords in a preset column name semantic feature library is determined, and the target column required for the standard chronological ledger data table is determined based on the matching score, including: Obtain a column name semantic feature library, which contains the correspondence between target semantics and keyword set, as well as the weight of each keyword in the keyword set; For each column name in the single-level column header, a weighted matching score of the target semantics corresponding to the keyword is determined based on the keyword that matches the column name and the weight of the keyword. Select the column with the highest weighted matching score as the target column corresponding to the target semantics; When the weighted matching score is lower than a preset threshold, the column corresponding to the preset position is taken as the target column corresponding to the target semantics.

[0221] In some embodiments of the present invention, feature extraction is performed on the monthly report of the R&D project to obtain project feature vectors corresponding to multiple project objects, and feature extraction is performed on the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records, including: Obtain the project name of each project object in the monthly report of the R&D project, extract features from the project name using regular expression groups, and generate a project feature vector corresponding to each project object based on the extracted features; Obtain the auxiliary item text for each chronological ledger record in the standard chronological ledger data table. The auxiliary item text contains a tag structure consisting of pairs of tag names and tag content. Use a regular expression that matches each tag name and tag content to extract features from the auxiliary item text, and generate a chronological ledger feature vector corresponding to each chronological ledger record based on the extracted features.

[0222] In some embodiments of the present invention, the project feature vector includes any one or more of the following: a list of project files, a current name, a topic name, and an original full name; The chronological account feature vector includes one or more of the following: budget code, customer file, project file, department file, and personnel file.

[0223] In some embodiments of the present invention, the matching result between the plurality of project objects and the plurality of chronological ledger records is obtained based on the project feature vector and the chronological ledger feature vector, including: The semantic components in the project feature vector are compared with the budget coding components in the chronological account feature vector to determine their inclusion relationship, which is then used as the first matching channel. The inclusion relationship between each semantic component in the project feature vector and the project file component in the chronological ledger feature vector is determined and used as the second matching channel. According to the preset priority order, the inclusion relationship judgment in the first matching channel and the second matching channel are executed sequentially. When any inclusion relationship judgment is successful, the chronological ledger record corresponding to the chronological ledger feature vector is matched with the project object corresponding to the project feature vector.

[0224] In some embodiments of the present invention, the inclusion relationship determination in the first matching channel and the second matching channel is performed sequentially according to a preset priority order, including: In the first matching channel, the inclusion relationship judgment is performed sequentially according to the following priority order: First priority: Determine whether the original complete name in the project feature vector is a substring of the budget code in the chronological ledger feature vector; Second priority: Determine whether the current name in the project feature vector is a substring of the budget code in the chronological account feature vector; Third priority: Determine whether the topic name in the project feature vector is a substring of the budget code in the chronological account feature vector; Fourth priority: Determine whether any element in the project file list of the project feature vector is a substring of the budget code in the chronological ledger feature vector; If all priority inclusion relationship checks in the first matching channel fail, then the inclusion relationship checks in the second matching channel will be performed sequentially according to the following priority order: Fifth priority: Determine whether the original complete name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Sixth priority: Determine whether the current name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Seventh priority: Determine whether the topic name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Eighth priority: Determine whether any element in the project file list of the project feature vector is a substring of the project file in the chronological ledger feature vector.

[0225] In some embodiments of the present invention, an internal chronological ledger record is determined from the successfully matched chronological ledger records, and the consolidated deduction amount for each project object is determined based on the amount corresponding to the internal chronological ledger record, including: Obtain an external configuration file and read the list of internal units from the external configuration file; Extract customer profiles from successfully matched chronological ledger records; The customer files are matched with the internal unit list, and the matching chronological records are identified as internal chronological records.

[0226] In some embodiments of the present invention, the apparatus further includes: A bidirectional index structure construction module is used to construct a bidirectional index structure based on the matching detail table and the remaining detail table; the bidirectional index structure includes a forward index and a reverse index; The forward index uses the project name as the key and the list of all successfully matched chronological ledger records corresponding to the project name as the value; the reverse index uses the original table row number as the key and the processing result of the chronological ledger record corresponding to the original table row number as the value.

[0227] In some embodiments of the present invention, the apparatus further includes: The project name query module provides an interface for querying by project name. In response to the input project name, it returns a list of matching details and statistical information corresponding to the project name. The original table row number query module provides an interface for querying by original table row number. In response to the input original table row number, it returns the processing result of the chronological ledger record corresponding to the original table row number. The amount range query module provides an interface for querying by amount range. In response to the input amount range, it returns a sample of matching records within the amount range. The audit report generation module is used to generate an audit report for a specified project in response to an audit request for that project. The audit report includes: total project amount, distribution of matching types, percentage of internal transactions, number of low-confidence matches, and sampling details.

[0228] Some embodiments of the present invention also provide an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method described above.

[0229] Some embodiments of the present invention also provide a computer-readable storage medium on which a computer program is stored, and which, when executed by a processor, implements the method described above.

[0230] Some embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0231] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0232] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0233] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0234] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0235] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0236] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0237] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0238] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the present invention.

[0239] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the aforementioned element.

[0240] The foregoing has provided a detailed description of a method, apparatus, device, medium, and product for processing financial data. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method of processing financial data, characterized by, The method includes: Obtain a chronological ledger file, preprocess the chronological ledger file to obtain a standard chronological ledger data table; wherein the standard chronological ledger data table includes multiple chronological ledger records; Obtain the monthly report of R&D projects, extract features from the monthly report of R&D projects to obtain project feature vectors corresponding to multiple project objects, and extract features from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records. Based on the project feature vector and the chronological ledger feature vector, the matching results between the multiple project objects and the multiple chronological ledger records are obtained; Based on the amount corresponding to the successfully matched chronological ledger records, determine the project dimension amount corresponding to each project object, and determine the internal chronological ledger record in the successfully matched chronological ledger records. Based on the amount corresponding to the internal chronological ledger record, determine the consolidated deduction amount corresponding to each project object. Based on the matching results, multiple functional reports are generated; wherein, the multiple functional reports include a project summary table, a matching details table, and a remaining details table. The project summary table includes the project dimension amount, the consolidated deduction amount, and the net amount. The matching details table includes traceability information of successfully matched chronological ledger records. The remaining details table includes traceability information of unmatched chronological ledger records and traceability information of excluded chronological ledger records.

2. The method according to claim 1, characterized in that, The chronological ledger file is preprocessed to obtain a standard chronological ledger data table, including: The multi-level column headers in the chronological ledger file are detected, and the multi-level column headers are merged into a single-level column header required by the standard chronological ledger data table; wherein, the column name of the single-level column header is a single identifier that connects the multi-level column names through a concatenation operator; Determine the matching score between the column name of the single-level column header and the keywords in the preset column name semantic feature library, and determine the target column required for the standard chronological ledger data table based on the matching score; The data in the target column is cleaned to improve its quality, and a standard chronological ledger data table is generated based on the single-level column header, the target column, and the cleaned data.

3. The method according to claim 2, characterized in that, Determine the matching score between the column name of the single-level column header and keywords in a preset column name semantic feature library, and determine the target columns required for the standard chronological ledger data table based on the matching score, including: Obtain a column name semantic feature library, which contains the correspondence between target semantics and keyword set, as well as the weight of each keyword in the keyword set; For each column name in the single-level column header, a weighted matching score of the target semantics corresponding to the keyword is determined based on the keyword that matches the column name and the weight of the keyword. Select the column with the highest weighted matching score as the target column corresponding to the target semantics; When the weighted matching score is lower than a preset threshold, the column corresponding to the preset position is taken as the target column corresponding to the target semantics.

4. The method according to claim 1, characterized in that, Feature extraction is performed on the monthly report of the R&D projects to obtain project feature vectors corresponding to multiple project objects. Feature extraction is also performed on the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records, including: Obtain the project name of each project object in the monthly report of the R&D project, extract features from the project name using regular expression groups, and generate a project feature vector corresponding to each project object based on the extracted features; Obtain the auxiliary item text for each chronological ledger record in the standard chronological ledger data table. The auxiliary item text contains a tag structure consisting of pairs of tag names and tag content. Use a regular expression that matches each tag name and tag content to extract features from the auxiliary item text, and generate a chronological ledger feature vector corresponding to each chronological ledger record based on the extracted features.

5. The method according to claim 4, characterized in that, The project feature vector includes one or more of the following: project file list, current name, topic name, and original full name; The chronological account feature vector includes one or more of the following: budget code, customer file, project file, department file, and personnel file.

6. The method according to any one of claims 1-5, characterized in that, Based on the project feature vector and the chronological ledger feature vector, the matching results between the plurality of project objects and the plurality of chronological ledger records are obtained, including: The semantic components in the project feature vector are compared with the budget coding components in the chronological account feature vector to determine their inclusion relationship, which is then used as the first matching channel. The inclusion relationship between each semantic component in the project feature vector and the project file component in the chronological ledger feature vector is determined and used as the second matching channel. According to the preset priority order, the inclusion relationship judgment in the first matching channel and the second matching channel are executed sequentially. When any inclusion relationship judgment is successful, the chronological ledger record corresponding to the chronological ledger feature vector is matched with the project object corresponding to the project feature vector.

7. The method according to claim 6, characterized in that, According to a preset priority order, the inclusion relationship judgments in the first matching channel and the second matching channel are executed sequentially, including: In the first matching channel, the inclusion relationship judgment is performed sequentially according to the following priority order: First priority: Determine whether the original complete name in the project feature vector is a substring of the budget code in the chronological ledger feature vector; Second priority: Determine whether the current name in the project feature vector is a substring of the budget code in the chronological account feature vector; Third priority: Determine whether the topic name in the project feature vector is a substring of the budget code in the chronological account feature vector; Fourth priority: Determine whether any element in the project file list of the project feature vector is a substring of the budget code in the chronological ledger feature vector; If all priority inclusion relationship checks in the first matching channel fail, then the inclusion relationship checks in the second matching channel will be performed sequentially according to the following priority order: Fifth priority: Determine whether the original complete name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Sixth priority: Determine whether the current name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Seventh priority: Determine whether the topic name in the project feature vector is a substring of the project file in the chronological ledger feature vector; Eighth priority: Determine whether any element in the project file list of the project feature vector is a substring of the project file in the chronological ledger feature vector.

8. The method according to any one of claims 1-5, characterized in that, Identify the internal chronological ledger records from the successfully matched chronological ledger records, and determine the consolidated deduction amount for each project object based on the amount corresponding to the internal chronological ledger records, including: Obtain an external configuration file and read the list of internal units from the external configuration file; Extract customer profiles from successfully matched chronological ledger records; The customer files are matched with the internal unit list, and the matching chronological records are identified as internal chronological records.

9. The method according to any one of claims 1-5, characterized in that, Also includes: Based on the matching details table and the remaining details table, a bidirectional index structure is constructed; the bidirectional index structure includes a forward index and a reverse index. The forward index uses the project name as the key and the list of all successfully matched chronological ledger records corresponding to the project name as the value; the reverse index uses the original table row number as the key and the processing result of the chronological ledger record corresponding to the original table row number as the value.

10. The method according to claim 9, characterized in that, Also includes: Provides an interface for querying by project name, which, in response to the input project name, returns a list of matching details and statistical information corresponding to the project name; It provides an interface for querying by the original table row number, and in response to the input original table row number, returns the processing result of the chronological ledger record corresponding to the original table row number; Provides an interface for querying by amount range, and in response to the input amount range, returns a sample of matching records within the amount range; In response to an audit request for a specified project, an audit report for the specified project is generated; wherein the audit report includes: total project amount, distribution of matching types, percentage of internal transactions, number of low-confidence matches, and sampling details.

11. A financial data processing apparatus, characterized in that, The device includes: The standard chronological ledger data table acquisition module is used to obtain a chronological ledger file, preprocess the chronological ledger file, and obtain a standard chronological ledger data table; wherein, the standard chronological ledger data table includes multiple chronological ledger records; The feature vector extraction module is used to obtain the monthly report of R&D projects, extract features from the monthly report of R&D projects to obtain project feature vectors corresponding to multiple project objects, and extract features from the standard chronological ledger data table to obtain chronological ledger feature vectors corresponding to multiple chronological ledger records. The matching result obtaining module is used to obtain the matching result between the multiple project objects and the multiple chronological ledger records based on the project feature vector and the chronological ledger feature vector; The amount determination module is used to determine the project dimension amount corresponding to each project object based on the amount corresponding to the successfully matched chronological ledger records, and to determine the internal chronological ledger records in the successfully matched chronological ledger records, and to determine the consolidated deduction amount corresponding to each project object based on the amount corresponding to the internal chronological ledger records. The functional report generation module is used to generate multiple functional reports based on the matching results. The multiple functional reports include a project summary table, a matching detail table, and a remaining detail table. The project summary table includes the project dimension amount, the consolidated deduction amount, and the net amount. The matching detail table includes traceability information of successfully matched chronological ledger records. The remaining detail table includes traceability information of unmatched chronological ledger records and traceability information of excluded chronological ledger records.

12. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 10.

Images