A system and method for processing enterprise financial data

Abstract

The present application relates to the technical field of data processing, and more particularly to a kind of enterprise financial data processing system and method.The method comprises the following steps: obtaining multi-source enterprise financial data, and carrying out dynamic data type identification and structure conversion, to obtain preprocessed enterprise financial data;The graph embedding structure conversion is carried out to the preprocessed enterprise financial data, to obtain enterprise financial semantic fusion data;According to enterprise financial semantic fusion data, financial data audit path is constructed;The time state version mapping is carried out to the data format fluctuation characteristics in financial data audit path, to record the structure change process of various kinds of vouchers and asset-liability data in financial data audit path, and the hierarchical file compression is carried out to the time state version mapping result, to obtain structured financial data audit path;According to structured financial data audit path, time series causal link construction is carried out, to obtain financial cognitive reasoning model.The present application is helpful to improve audit efficiency and risk monitoring ability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a processing system and method for enterprise financial data. BACKGROUND

[0002] Enterprise financial data presents the characteristics of large scale, wide source, different structure, and frequent update, covering multiple types, multiple cycles, and multiple dimensions of financial information such as accounting vouchers, report data, invoice information, tax records, budget execution, fund flow, and asset and liability details. Enterprises continuously generate and accumulate massive amounts of financial data in their business activities, which are important basis for internal control, business decision-making, and compliance auditing. In order to protect the integrity, accuracy, and real-time nature of enterprise financial data, and improve data processing efficiency and financial decision-making quality, it is urgent to establish an efficient, standardized, and scalable financial data processing mechanism.

[0003] Traditional enterprise financial data processing methods mainly rely on manual input and rule-driven data aggregation logic. Specifically, most enterprises use financial software for voucher input, subject classification, account book generation, and report compilation, supplemented by manual reconciliation, accounting, aggregation, and proofreading, forming a preliminary processing flow of financial data. Such methods are usually based on fixed accounting standards and business rules, with clear data flow paths but poor flexibility. When the business structure of an enterprise is complex, the business is extensive, or the financial system is diverse, traditional methods gradually reveal defects in processing efficiency, data consistency, cross-system compatibility, and analysis timeliness. SUMMARY

[0004] Therefore, it is necessary to provide a processing system and method for enterprise financial data to solve at least one of the above technical problems.

[0005] To achieve the above-mentioned purpose, a processing method for enterprise financial data comprises the following steps:

[0006] Step S1: acquiring multi-source enterprise financial data, and performing dynamic data type identification and structure conversion on the multi-source enterprise financial data to obtain preprocessed enterprise financial data;

[0007] Step S2: performing effective financial data screening on image-type invoice data and table-type bill data in the preprocessed enterprise financial data, and performing graph embedding structure conversion according to the effective financial data to obtain enterprise financial semantic fusion data;

[0008] Step S3: performing compliance label annotation and redundant field discrimination according to the enterprise financial semantic fusion data to obtain enterprise financial labeled data; and constructing a financial data audit path based on the enterprise financial labeled data;

[0009] Step S4: Temporal version mapping is performed on the data format fluctuation characteristics in the financial data audit path to record the structural change process of various types of vouchers and balance sheet data in the financial data audit path, and hierarchical file compression is performed on the temporal version mapping results to obtain a structured financial data audit path;

[0010] Step S5: Time series causal link construction is performed according to the structured financial data audit path to obtain a financial cognitive reasoning model, and the financial cognitive reasoning model is uploaded to an enterprise internal financial management system to perform a model deployment task.

[0011] Optionally, step S1 is specifically:

[0012] Step S11: Obtain multi-source enterprise financial data, and label and classify the multi-source enterprise financial data according to the data source types to obtain original financial data;

[0013] Step S12: Perform file format recognition and content structure analysis on the original financial data to construct structure type feature data;

[0014] Step S13: Perform structure universalization mapping conversion on the structure type feature data to obtain financial intermediate structure representation data;

[0015] Step S14: Perform field standardization processing on the financial intermediate structure representation data, and establish a field index table for high-frequency fields in the standardization processing result;

[0016] Step S15: Perform consistency verification and conflict field elimination on the financial intermediate structure representation data in combination with the field index table to obtain preprocessed enterprise financial data.

[0017] Optionally, step S13 is specifically:

[0018] Step S131: Analyze the field level depth, nesting mode, record unit distribution, and file format characteristics of each structure type in the structure type feature data, and perform structure type-semantic unit mapping on the analysis results based on a preset structure mode library to obtain a structure mapping template set;

[0019] Step S132: Perform universalization translation on the structure type feature data by calling the structure mapping template set to obtain structure mapping intermediate data;

[0020] Step S133: Perform format standardization and field label standardization on the structure mapping intermediate data to generate a unified structure unit set;

[0021] Step S134: Perform structure semantic association expression according to the business semantic relationship between the structure units in the unified structure unit set to obtain the financial intermediate structure representation data.

[0022] Optionally, the effective financial data screening in step S2 is specifically:

[0023] Extracting image-type invoice data and table-type bill data from the pre-processed enterprise financial data;

[0024] Performing structure-aware OCR recognition on the image-type invoice data, extracting invoice field content, and constructing an invoice field structure set;

[0025] Performing cell semantic classification and financial logic block labeling on the table-type bill data, and constructing a bill structure label set;

[0026] Performing content integrity evaluation and field confidence evaluation according to the invoice field structure set, and performing effectiveness scoring using the content integrity evaluation result and the field confidence evaluation result, and only retaining invoice field structure data with effectiveness score greater than or equal to 0.85, thereby obtaining effective invoice field structure data;

[0027] Performing field matching rate analysis and multi-column dependency verification on the financial logic blocks in the bill structure label set, and only retaining bill segments with high field matching rate and complete column dependency relationship, thereby generating effective bill structure data;

[0028] Normalizing and packaging the effective invoice field structure data and the effective bill structure data according to the preset structure encoding specification, thereby obtaining effective financial data.

[0029] Optionally, the graph embedding structure conversion in step S2 is specifically:

[0030] Performing financial semantic entity recognition on the graph semantic input data, thereby constructing a financial base node set;

[0031] Constructing multi-level semantic relationship edges according to the financial base node set, thereby generating a semantic connection candidate graph;

[0032] Performing field attribute expansion on each node in the semantic connection candidate graph, and labeling the expanded nodes with financial labels, thereby obtaining a graph expansion structure unit;

[0033] Performing semantic merging on redundant nodes in the graph expansion structure unit, and performing entity deduplication and graph simplification on the semantic merging result, thereby obtaining a unified structure graph;

[0034] Converting the unified structure graph into a graph embedding vector, thereby generating enterprise financial semantic fusion data.

[0035] Optionally, step S3 is specifically:

[0036] Step S31: using a preset financial field compliance rule library to perform field compliance rule matching on the enterprise financial semantic fusion data, thereby generating a field compliance label set;

[0037] Step S32: The non-compliant fields in the field compliance annotation set are labeled according to the preset risk classification rule, and a label index is established according to the labeling result and the path of the graph structure where the corresponding field is located, and a multi-dimensional financial data label set is obtained;

[0038] Step S33: In the enterprise financial semantic fusion data, if multiple field paths point to the same node, the uniqueness contribution degree of each field is evaluated, and the field with a uniqueness contribution degree lower than a preset contribution degree threshold is marked as a redundant field, thereby outputting a redundant field structure set;

[0039] Step S34: All fields in the multi-dimensional financial data label set that appear in the redundant field structure set and whose label propagation path can be replaced are removed, and a simplified financial label node set is obtained;

[0040] Step S35: The simplified financial label node set and the corresponding nodes and edges in the enterprise financial semantic fusion data are combined to form a ternary segment set of nodes-field-labels, and are grouped according to the time dimension and the subject dimension, thereby obtaining a basic audit segment;

[0041] Step S36: A financial data audit path is constructed according to the structural dependency relationship of the basic audit segment and the label propagation path.

[0042] Optionally, the temporal version mapping in step S4 is specifically:

[0043] Version nodes are identified for the field structure in the financial data audit path, and a structural version point set is constructed;

[0044] Each version point in the structural version point set is aligned to the time dimension and is temporally anchored, and a structural version timeline is constructed;

[0045] Changes between adjacent structural version snapshots in the structural version timeline are compared, and a structural change difference matrix is generated;

[0046] Each node field path in the structural change difference matrix is bound to the version of the corresponding time period in the structural version timeline, and a structural change segment is labeled, and a version annotated path set is generated;

[0047] A structural evolution trajectory graph is constructed based on the version annotated path set and the structural change difference matrix, and the structural evolution trajectory graph is the temporal version mapping result.

[0048] Optionally, the hierarchical file compression in step S4 is specifically:

[0049] A cross-version common structure is identified based on the structural evolution trajectory graph, and a structural segment folding graph is constructed;

[0050] According to the structural fragment folding map, the meta attributes of the cross-version common structural nodes are aggregated to obtain a field aggregation table; meanwhile, the distribution of each field value in different versions is counted by using the version path annotation set, and fields with a repeated value rate exceeding 90% in the distribution are extracted to generate a field value redundancy pool;

[0051] By using the field index and nesting information in the field aggregation table, combining the path structure in the version path annotation set and the field use period in the structural version timeline, a structural compression tree is constructed;

[0052] Based on the structural compression tree, path version expansion and difference compression coding are performed to generate a structural compression index set;

[0053] The structural compression tree, the structural compression index set, the field aggregation table, the field value redundancy pool and the version annotation path set are hierarchically encapsulated to generate a structured financial data audit path.

[0054] Optionally, step S5 is specifically:

[0055] Step S51: parse the structured financial data audit path to construct a time series causal candidate event set;

[0056] Step S52: classify each path in the time series causal candidate event set according to the field type and the structural level, and perform causal correlation on the classification results based on the time sequence relationship and the path dependence relationship to obtain a causal graph structure;

[0057] Step S53: perform causal reasoning modeling on the causal graph structure to generate a causal link matrix;

[0058] Step S54: according to the causal link matrix, perform structural number replacement and path matching to the structural compression index set to generate a structured causal unit, organize all structured causal units into a logical execution graph to obtain a financial cognitive reasoning model;

[0059] Step S55: upload the financial cognitive reasoning model to an enterprise internal financial management system to perform a model deployment task.

[0060] The application comprehensively improves the efficiency, accuracy and intelligent level of enterprise financial data processing by constructing a processing flow that integrates structure unification, semantic enhancement, path evolution modeling and causal reasoning for multi-source heterogeneous financial data. By introducing a data source type tagging classification mechanism in the data preprocessing stage, combined with file structure analysis and field standardization operation, the consistency and comparability of original data from different sources and formats are ensured during structure conversion, reducing the need for manual intervention in cross-system integration. The process of setting structure mapping templates and field indexes makes the data structure after standardization reusable and migratable, laying a data foundation for subsequent graph structure construction; for example, only high-frequency fields are retained in the field index table, and the threshold is set to the top 30% of fields by frequency, which helps to exclude semantic interference from low-frequency fields and improve the aggregation efficiency of standardized fields. In the financial data screening stage, image data OCR structure recognition and table data semantic annotation are introduced, combined with field confidence evaluation and integrity evaluation mechanism, and the effectiveness score threshold is set to 0.85, which can significantly exclude redundant, fuzzy and incomplete data items, and only retain high-quality data content for graph construction. In the graph embedding structure conversion process, through node attribute expansion, semantic edge relationship generation and graph simplification mechanism, the problems of multi-path redundancy and semantic repetition in the structure graph are effectively solved, and the compactness and semantic coverage of the graph vector after conversion are improved. In the label annotation and audit path construction stage, through compliance rule matching, field risk label annotation and unique contribution calculation, the contribution threshold is set to 0.4, which can effectively identify redundant fields with low semantic expression contribution in the graph, significantly compress the data volume without affecting the integrity of label transmission, and improve the semantic concentration of the audit path. Through structure evolution modeling and version difference analysis of the audit path, the evolution process of voucher structure, field naming and subject grouping changing over time can be accurately recorded, enhancing the traceability and structure transparency of financial data. Setting the time anchor window to the financial quarterly reporting cycle (90 days) not only fits the business cycle of enterprises, but also ensures that the granularity of change nodes is consistent with the actual management. In the causal modeling stage, the event path is classified according to the field level and time sequence, and the causal strength retention threshold is set to 0.7, ensuring that the reasoning link has high relevance, and the constructed reasoning model not only reflects the business evolution path of the structure data, but also can be used to identify the logical association between key data. Finally, the reasoning model is automatically deployed to the financial management system through the enterprise intranet, supporting periodic updates and reasoning service calls, thereby realizing data-driven financial decision support, improving audit efficiency and risk monitoring capability, and forming a full-process closed-loop mechanism that runs through data integration, structure reconstruction, risk identification and decision reasoning.

[0061] Optionally, the present application also provides a business financial data processing system for executing the business financial data processing method as described above, the business financial data processing system comprising:

[0062] a data acquisition module for acquiring multi-source business financial data and performing dynamic data type identification and structure conversion on the multi-source business financial data to obtain preprocessed business financial data;

[0063] a structure conversion module for performing effective financial data screening on image-type invoice data and table-type bill data in the preprocessed business financial data, and performing graph embedding structure conversion according to the effective financial data to obtain business financial semantic fusion data;

[0064] a financial annotation module for performing compliance label annotation and redundant field discrimination according to the business financial semantic fusion data to obtain business financial annotation data; and constructing a financial data audit path based on the business financial annotation data;

[0065] a data compression module for performing temporal version mapping on data format fluctuation characteristics in the financial data audit path to record the structure change process of various types of vouchers and asset liability data in the financial data audit path, and performing hierarchical file compression on the temporal version mapping result to obtain a structured financial data audit path;

[0066] a model construction module for constructing a time series causal link according to the structured financial data audit path to obtain a financial cognitive reasoning model, and uploading the financial cognitive reasoning model to an enterprise internal financial management system to perform a model deployment task.

[0067] The business financial data processing system of the present application can implement any one of the business financial data processing methods of the present application, and is used as a medium for joint operation and signal transmission between modules to complete the business financial data processing method. The modules in the system cooperate with each other, thereby realizing data-driven financial decision support and improving audit efficiency and risk monitoring capability. BRIEF DESCRIPTION OF DRAWINGS

[0068] Other features, objects and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments made with reference to the accompanying drawings:

[0069] Fig. 1 a step flowchart of the business financial data processing method of the present application;

[0070] Fig. 2 a detailed step flowchart of step S1 in the present application;

[0071] Fig. 3 a detailed step flowchart of step S13 in the present application;

[0072] The objectives, functional characteristics and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0073] The technical method of the present application will be described clearly and completely below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by those skilled in the art without creative work fall within the scope of the present application.

[0074] In addition, the accompanying drawings are only schematic illustrations of the present application, and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus repeated description thereof will be omitted. Some of the block diagrams shown in the drawings are functional entities, which do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0075] It should be understood that although the terms "first", "second" and the like can be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element can be referred to as a second element, and similarly a second element can be referred to as a first element. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0076] To achieve the above-mentioned object, please refer to Figs. 1 to 3 The present application provides a processing method of enterprise financial data, the method comprising the following steps:

[0077] Step S1: acquiring multi-source enterprise financial data, and performing dynamic data type identification and structure transcoding on the multi-source enterprise financial data to obtain preprocessed enterprise financial data;

[0078] In this embodiment, financial data from the financial system, business system, tax terminal and procurement platform is collected, and the original data includes electronic vouchers in JSON format, invoice images in PDF format, billing accounts in XLSX format and fund details in XML format. The system first classifies the data by source according to the data source identification field (such as the source_type field), and marks it as "INVOICE_IMAGE", "ACCOUNT_TABLE", "FUND_XML" and other categories. Subsequently, the file structure deconstruction process is performed, and a corresponding format recognition module is called for each type of data, such as an OCR module for recognizing PDF image text, a structure extractor for extracting key-value pairs in table cells, and a "hierarchical label-content-position offset" triplet record field structure. In the structure conversion stage, according to the structure template (such as the three-layer nested voucher format template and the billing structure mapping table with tab identification) constructed in advance, the fields are mapped and normalized, and the unified field structure is generated as follows: { "field identification": "account name", "hierarchical path": ["billing information", "payment details", "account section"], "value": "bank"}. Finally, the high-frequency fields are standardized and coded, and the invalid fields are removed, forming a structured and computable preprocessed enterprise financial data set.

[0079] Step S2: effective financial data screening is performed on the image type invoice data and table type billing data in the preprocessed enterprise financial data, and graph embedding structure conversion is performed according to the effective financial data to obtain enterprise financial semantic fusion data;

[0080] In this embodiment, the part of the pre-processed enterprise financial data with the field identifier "INVOICE_IMAGE" is extracted, the structure recognition device is called to identify the fields of the PDF format invoice, the confidence of the identified fields such as "buyer name", "tax amount" and "invoice number" is evaluated, and the high-quality invoice data is screened according to the criteria that the field completeness rate is not less than 90% and the confidence score is not less than 0.85. Then the bill data is processed, the table is divided into "row-column-block", the labels such as "total account block" and "expense detail block" are identified, and the column dependency is analyzed, such as whether the logical association of "payer", "amount" and "subject" columns is established, only the blocks that pass the dependency verification are reserved, and the bill structure data is generated. Then the screened invoice and bill data are uniformly packaged into a JSON-LD format structure, each structure is embedded with nested field groups such as "subject", "predicate" and "object", forming the initial nodes and edges of the graph. The system calls the graph construction module to take the field content as the node and the field association as the edge, performs multi-level semantic expansion, such as deriving "subject = management fee" from "expense type = office expense", constructs the topological structure, and calls the graph vector generator to map the structure graph to a 128-dimensional financial graph embedding vector, and finally forms the enterprise financial semantic fusion data.

[0081] Step S3: According to the enterprise financial semantic fusion data, the compliance label annotation and the redundant field discrimination are performed to obtain enterprise financial annotation data; and a financial data audit path is constructed based on the enterprise financial annotation data;

[0082] In this embodiment, the generated semantic fusion data is executed for field compliance annotation using a preset financial rule library, which includes national standards, local tax reporting formats and industry financial standards. The system traverses each semantic node one by one, matches the node attribute (such as the "tax rate" field) with the rule library, and if there is "no match or missing", a "field non-compliance" label is generated and the risk level is marked, for example, "tax rate field missing, risk level: medium". Then the system analyzes the label propagation path, maps the path nodes of the non-compliant fields into the financial graph, and constructs a field label index table. The system then counts the number of unique values and the frequency distribution entropy of each field value for each graph structure path where multiple fields point to the same node, for example, when multiple "project number" fields are mapped to a "department expense node", only the field with a uniqueness contribution higher than 0.05 is retained. The excluded fields will be recorded in the redundant field path table and labeled with the "redundant type = structural redundancy" label. Finally, the exclusion results are merged with the original graph nodes and labels to form node-field-label ternary segments, which are grouped according to "time = month" and "subject = administrative expenses" to form structure-dependent paths, and cross-node and cross-field financial data audit paths are constructed.

[0083] Step S4: Temporal version mapping is performed on the data format fluctuation characteristics in the financial data audit path to record the structural change process of various types of vouchers and balance sheet data in the financial data audit path, and hierarchical file compression is performed on the temporal version mapping results to obtain a structured financial data audit path;

[0084] In this embodiment, structure version identification is performed on the nodes on each path in the output audit path, the field structure is divided into multiple structure version points according to its naming specification, hierarchical position and business semantic change, for example, the asset voucher format is changed from “[asset category]-[amount]-[accounting date]” to “[asset code]-[amount]-[department]-[accounting time]”. The system anchors all structure version points according to the month dimension, constructs a structure time axis, and compares the changes such as appearance, absence, renaming of fields in each version snapshot, and outputs a change difference matrix. After binding the difference fields in the matrix with the time dimension, mark them as structure change segments, and record the change type (such as “field added” and “field renamed”). After constructing the structure evolution track diagram, the system detects the cross-version repeated structure in the diagram, such as the common sub-field of the “asset information” module, and the structure consistency rate in the five versions is as high as 95%. The system folds these structures into the “structure segment folding diagram”, and calculates the value distribution of each field across versions, and adds the field value redundancy pool when the field value repetition rate exceeds 90%. In the process of constructing the structure compression tree, the system integrates the structure hierarchy, field index and field use period to form a path tree with minimal redundancy. The system finally generates a compressed index set in units of “version-node-path-field index”, and encapsulates all structures as a structured financial data audit path.

[0085] Step S5: According to the structured financial data audit path, a time series causal link is constructed to obtain a financial cognitive reasoning model, and the financial cognitive reasoning model is uploaded to an enterprise internal financial management system to perform a model deployment task.

[0086] In this embodiment, the structured financial data audit path formed is analyzed, and "event nodes" (such as expense submission, account entry, audit pass, etc.) and their occurrence times are extracted therefrom to constitute a time series causal candidate event set. The system classifies events based on field types (such as cost type, liability type) and path levels, identifies potential causal path groups, and constructs a causal graph structure according to the time sequence of event occurrence and the field dependency relationship in the path (for example, expense audit must be after submission). The time series of each pair of events is extracted for strength scoring, such as using a sliding time window of 5 days to calculate the delay mutual information and Granger correlation. Paths with a score greater than 0.7 are screened as stable causal paths, a causal weight graph is generated and converted to a sparse matrix form, where the rows and columns represent field event numbers, and the element values represent path causal weights (such as 0.84). The matrix is further mapped to a set of structure compression indexes, used for field number replacement and path structure matching, to construct a structured causal unit, generate a logical flowchart in the order of event execution, and finally constitute a financial cognitive reasoning model, which is uploaded to the "prediction decision engine" module of the enterprise internal financial management system through an API interface, and is called in real time in actual account processing and early warning generation.

[0087] Optionally, step S1 is specifically:

[0088] Step S11: Obtain multi-source enterprise financial data, and label and classify the multi-source enterprise financial data according to the data source type to obtain original financial data;

[0089] In this embodiment, the interface scheduling platform interfaces with the financial system (such as Uuoo NC), the tax control system (such as the Jintie plate), the procurement platform (such as the SRM system) and the online banking transaction flow platform, and collects the data source content of the past three months. Each piece of data is attached with a collection source identification field when collected, such as "source_sys=NC_GL", "source_sys=TAX_INVOICE" and the like, and the system distributes the data to the initial classification bucket according to the source_sys field and labels the identification. In the process of labeling classification, for PDF invoice files, set "DATA_TYPE=IMAGE_PDF", for CSV or XLSX bills, set "DATA_TYPE=TABLE_STRUCT", and for structured data returned by the interface API, mark "DATA_TYPE=JSON_FEED". The label structure is encapsulated in JSON, such as: {"source_sys": "TAX_INVOICE", "data_type": "IMAGE_PDF", "timestamp":"2025-06-30T10:21:05", "origin": "Guangdong Wide Area Invoice Platform"}. All labeled data is written into the metadata table and uniformly stored in the preliminary data warehouse area to form the original financial data set as the input for subsequent structure recognition and analysis.

[0090] Step S12: file format recognition and content structure analysis are performed on the original financial data to construct structure type feature data;

[0091] In this embodiment, the label field "data_type" is relied on for analysis. For "IMAGE_PDF" type invoice data, the OCR recognition component is called to automatically divide the text block area, identify the field position on the ticket and extract the content, while recording the coordinate matrix, font features and recognition confidence of each field. For "TABLE_STRUCT" type data, the system traverses the table header and the cell content of each row, identifies the table type (such as flow type, summary type, multi-page segmentation type), and analyzes the nested relationship according to the cell merging rules in the format row. For example, the "payment information" field in the bill table has two rows of up-down merging, and the system infers that "payer", "account number" and "bank" are parallel fields, and marks the parent field as "payment information". Finally, the system constructs structure type feature data, including field name, layer path, data unit form (such as string, float), page number and the like to form a field structure body, such as: {"field": "payment amount", "type": "float", "layer": ["payment information", "details"], "shape": "merged_row"}. This data structure is used as the input of the structure mapping module.

[0092] Step S13: Perform structure generalization mapping conversion according to the structure type feature data to obtain financial intermediate structure representation data;

[0093] In this embodiment, the generated structure type feature data is read, and first, a general mapping is performed based on the matching template in the pre-set structure template library. The structure template library is established according to common financial data types, such as "invoice format A", "bill template B", "voucher template C" and the like. Each template contains a field position mapping table, a structure path rule, and a field renaming specification. The system first matches "invoice format A", maps the hierarchical path ["payment information", "details"] to the standard path ["Invoice", "Details"], and renames the field "payment amount" as "amount_paid". In the mapping process, the system identifies inconsistent fields in the structure and performs structure normalization operations, such as merging multiple flat fields into nested structures or flattening nested fields into key-value pair sets. Conversion logs are recorded during the mapping process, including the original path of the field, the target path, the modification type, and the timestamp, which facilitates subsequent backtracking. Finally, the financial intermediate structure representation data is generated, each piece of data containing standardized field names, field types, uniform structure paths, and original source information, for example: {"standard_field": "amount_paid", "field_type": "float", "path": ["Invoice", "Details"], "source_id": "INV_GD20240618"}.

[0094] Step S14: Perform field standardization processing on the financial intermediate structure representation data, and establish a field index table for high-frequency fields in the standardization processing result;

[0095] In this embodiment, in the standardization process, the field set in the financial intermediate structure representation data is extracted first, and the value type and content length of each field are traversed to perform format normalization processing. For example, the amount field is uniformly converted to a floating-point number with two decimal places, the date field is uniformly converted to "YYYY-MM-DD" format, and the noun fields such as "payee" and "payee" are uniformly adopted in "simplified Chinese full name". For text fields, non-structural symbols such as tab, space group, and line feed are removed to ensure clear content. After standardization, the system counts the frequency of all standard fields, and establishes a field index table for the top 50 fields with the highest frequency. The field index table records the field name, frequency, standard path, field length distribution, and belongs to the module (such as "invoice_section" and "bank_details"), and is used for subsequent data conflict detection. For example, the "amount_paid" field appears 2103 times, the standard path is ["Invoice", "Details"], the length range is [7, 12], and it is recorded as a high-frequency field. The field index table structure is as follows: {"field": "amount_paid", "frequency": 2103, "module": "invoice_section", "path": ["Invoice", "Details"], "range": [7, 12]}.

[0096] Step S15: consistency verification and conflict field removal of financial intermediate structure representation data combined with the field index table to obtain preprocessed enterprise financial data.

[0097] In this embodiment, in the consistency verification process, the generated field index table is used to check the field conflicts of the intermediate structure representation data. The system first performs value domain distribution check and content repeatability analysis on each field to detect whether the same field has inconsistent types or conflicting content in different records. For example, the value interval of the "amount_paid" field should be between [1.00, 99999.99], and if negative values or null values appear, the system records it as a conflict field. In terms of path level conflict, the system checks whether the same field has multiple structure path attributions, and if "amount_paid" appears in both ["Invoice", "Details"] and ["Settlement", "Summary"], the system retains the main path mapping according to the field context semantic information and field index priority, and removes the secondary path field. For conflict fields, the system generates conflict removal records, records the field name, conflict reason, removal time and correction suggestion. All checked data is written into the preprocessed enterprise financial data set, and a statistical summary is generated according to "business type-field number-processing status" for subsequent structure conversion and audit process calling.

[0098] Optionally, step S13 is specifically:

[0099] Step S131: parse the field hierarchical depth, nested mode, record unit distribution, and file format features in each structure type in the structure type feature data, and perform structure type-semantic unit mapping on the parsed results based on a preset structure mode library to obtain a structure mapping template set;

[0100] In this embodiment, for the generated structure type feature data, first, the field hierarchical information in each data entry is extracted, and the complexity of the data structure is judged by traversing the path depth, the number of nested fields, and the record unit density. For example, for a financial voucher document in XML format, the field "supplier→payment→account→bankCode" has a 4-layer nested hierarchical structure, and the record density is 10 groups per page, and accordingly, the structure depth is 4, and the nested mode is a multiple parent-child structure. Then, the file header, tail, and line separator are extracted to judge that it is an XML nested document format. Subsequently, rules in the preset structure mode library are called, and structure-semantic unit mapping is performed according to the feature field keywords (such as "amount", "account_no", and "invoice_no") and their position order. The structure mode library is divided into six categories (such as "invoice structure A type" and "payment detail structure B type") according to the data type, and each category includes path mapping templates, field semantic grouping, and constraint relationships between field groups. Finally, according to the mapping rules, "supplier→payment→account→bankCode" is mapped to the semantic unit "account information→bank code", and a structure mapping template set is generated. Each template is composed of a structure path, a semantic label, and a constraint condition, such as: {“path”:“supplier→payment→account→bankCode”,“semantic_label”:“bank_identifier”,“depth”:4}.

[0101] Step S132: call the structure mapping template set to perform generalization translation on the structure type feature data to obtain structure mapping intermediate data;

[0102] In this embodiment, the generated structure mapping template set is called to translate the structure type feature data one by one. The specific process is as follows: first, take the field path as the main index, match the original path with the template, such as detecting the path "vendor→billing→total_amount", and matching to the mapping template "invoice_entity→summary→amount". After matching, rewrite the field original path to the standard path, and synchronously add semantic label, field expected format and value range limit. For example, the field "total_amount" requires to be a floating point type in the standard template and the value range is between 0-1000000, then the limit specification is added synchronously. For the path that cannot be completely matched, the closest path mapping is carried out by using the root similarity and the structure position priority, and the matching confidence is recorded. All the translated fields and their original paths, standard paths, translation states are written in the structure mapping intermediate data set. Each record contains: original field name, standard field name, original path, target path, semantic label, path matching confidence, translation timestamp and other field information. For example: {“raw_field”:“vendor.billing.total_amount”,“standard_field”:“amount_total”,“semantic_label”:“invoice_amount”,“confidence”:0.92}.

[0103] Step S133: Perform format standardization and field label standardization on the structure mapping intermediate data to generate a unified structure unit set;

[0104] In this embodiment, after the intermediate data for structure mapping is generated, the process enters the format standardization and field label normalization process. During this stage, localized symbols in numeric fields, such as "¥" and ",", are prioritized and uniformly removed. Amount fields are converted to floating-point standard format, date fields are converted to "YYYY-MM-DD", and all boolean fields are mapped to an explicit "true / false" structure. Text fields are uniformly converted to UTF-8 encoding and truncated to within 255 characters to avoid abnormal overflow. Furthermore, field labels are uniformly mapped to the data source; for example, "Payer Name" and "Buyer Name" labels are uniformly set to "payer_name", and a data source identifier is added to the field. In this process, the field label specification table plays a crucial role, containing standard field names, allowed aliases, semantic groups, and unit standards (e.g., amount categories are uniformly set to "yuan"). After processing, each data structure clearly defines field values, data types, units, semantic labels, and other information, forming a unified set of structural units. The sample structure is as follows: {"field_name":"amount_total","data_type":"float","unit":"CNY","semantic_group":"invoice_summary","source":"Golden Tax Phase III"}. This unified structural unit is integrated as the basis for the next step of semantic expression.

[0105] Step S134: Based on the business semantic relationships between structural units in the unified structural unit set, perform structural semantic association expression to obtain financial intermediate structural representation data.

[0106] In this embodiment, after the standardization of the structural units, the associated expression is constructed according to the semantic logical relationship between the units. In specific implementation, the "semantic group" is taken as the minimum calculation unit, and the dependency structure between the field groups is constructed. For example, in the unified structural unit set, the field "amount_total" belongs to the "invoice_summary" group, and the field "payer_name" belongs to the "invoice_party" group. According to the template rule, the context relationship between the two field groups is established as "paying party → corresponding → invoice total". At the same time, the path dependence rule is introduced for connectivity verification. For example, if the "invoice_id" field exists in multiple structural paths, it must be the index field of other field groups. The structural semantic association expression is completed by constructing a directed field dependency graph. Each node represents a standard field, and the edge represents the business dependency path. Finally, these dependency graphs are encapsulated as financial intermediate structure representation data, recording the field name, dependency target field, path length, weight level and semantic annotation. For example: { "field": "payer_name", "depends_on": "amount_total", "relation": "payer → payment → total", "weight": "strong"}. Through the construction of this structured dependency relationship, the effective integration of information between structures is realized, supporting the subsequent semantic fusion and audit modeling.

[0107] Optionally, the effective financial data screening in step S2 is specifically:

[0108] Extracting image type invoice data and table type bill data from the preprocessed enterprise financial data;

[0109] Performing structure-aware OCR recognition on the image type invoice data, extracting the invoice field content, and constructing an invoice field structure set;

[0110] In this embodiment, format tag recognition is performed on the preprocessed enterprise financial data, and files with image format tags (such as JPEG, PNG, TIFF) are classified as image-type invoice data, and files with structured two-dimensional table features (such as XLSX, CSV, PDF embedded table structure) are identified as table-type bill data. The classification operation is completed based on the joint identification of data header byte characteristics and file extension, and the file source path, extraction timestamp and data source identification are recorded. Subsequently, the image-type invoice data is applied to the structure-aware text analysis component, which combines the invoice image printing template border identification, field alignment line identification and invoice common item area mapping rules to extract text regions and perform field segmentation. The content after field extraction includes standard fields such as "invoice code", "invoice date", "amount (including tax)", "buyer name", etc. Each field content and its position information in the image, segmentation confidence, and template area label are encapsulated as a record to form an invoice field structure set. The record of the structure set is shown as follows: {“field_name”:“invoice_code”,“value”:“031001900211”,“bbox”:[128,92,252,114],“confidence”:0.94}.

[0111] The cell semantic classification and financial logic block annotation are performed on the table-type bill data to construct a bill structure label set.

[0112] In this embodiment, the structure analysis operation is performed on each worksheet in the table-type bill data according to the row and column coordinates. First, the regional data block boundaries in the table are identified, such as "income details", "accounts payable", "historical balance", etc., and the field naming, cell data type and unit attribution information are established according to the regional block division. Then, the logic attributes of each type of structure block are annotated, such as "account period continuity", "currency consistency", "amount column monotonicity", etc., and all structure information is constructed into a bill structure label set. To improve semantic accuracy, a field meaning dictionary constructed by humans is introduced, and table header fields such as "payment time", "amount subtotal", "balance before value" are standardized and merged into unified financial semantic labels.

[0113] According to the invoice field structure set, content integrity evaluation and field confidence evaluation are performed, and the effectiveness score is calculated using the content integrity evaluation result and the field confidence evaluation result. Only the invoice field structure data with an effectiveness score greater than or equal to 0.85 is retained, thereby obtaining effective invoice field structure data;

[0114] The field matching rate analysis and multi-column dependency verification are performed on the financial logic blocks in the bill structure label set, and only the bill segments with high field matching rate and complete column dependency relationship are retained to generate effective bill structure data.

[0115] The effective invoice field structure data and the effective bill structure data are normalized and packaged according to a preset structure coding specification to obtain effective financial data.

[0116] In this embodiment, in order to filter low-quality invoice data, the total number of fields in the invoice field structure set is judged for integrity, only invoice records with a field number not less than 12 are reserved, and the confidence of each field is statistically averaged to calculate the effectiveness score. For example, if an invoice contains 14 fields and the average confidence is 0.89, it can be identified as effective invoice structure data. The threshold is set to 0.85. In the bill data processing, the frequency of fields in each structure block is analyzed, and the inter-row matching rate of each field is counted. If the proportion of a field in all rows is not less than 95%, and the field has a stable financial logical relationship with other columns (such as "amount payable = subtotal - paid amount" has a verification success rate of more than 99%), the block is determined as effective bill structure data.

[0117] In this embodiment, the effective invoice field structure data and the effective bill structure data are respectively coded according to the structure standard, and the field name, unit, currency and numerical accuracy are packaged according to the enterprise-defined structure identification specification, for example, the "total amount" field is converted to "total_amount_CNY_2dp" format, and the original field name and standard mapping are recorded. The packaging result is stored in JSON structure, and is accompanied by a unique data identifier and record time information as the basic data input for subsequent graph structure embedding. The effective financial data structure not only retains the original data context, but also has standardized field identification and structure consistency, ensuring the basis of subsequent semantic processing and audit modeling.

[0118] Optionally, the graph embedding structure conversion in step S2 is specifically:

[0119] The graph semantic input data is subjected to financial semantic entity recognition, thereby constructing a set of financial basic nodes;

[0120] In this embodiment, structured effective financial data is received as graph semantic input data, where the data structure contains invoice field structure data and bill structure label data, and the field name and content have been packaged according to unified specifications. First, the built-in financial semantic dictionary is used to perform entity identification operation on the input data, and field combinations with independent semantic attributes are identified, such as “seller name + tax number”, “invoice date + invoice code”, “payee account + transaction amount”, etc. Each group of combinations is mapped to a financial basic entity node, and the node attributes include entity category (such as “transaction subject” and “document element”), field source, field confidence, etc. information, thereby constructing an initial financial basic node set. Each node in the node set needs to contain a unique entity identifier and a data source trace label, and the example structure is as follows: {“node_id”:“N0035”,“type”:“invoice_subject”,“source”:“OCR_invoice”,“confidence”:0.93}.

[0121] According to the financial basic node set, multi-level semantic relationship edges are constructed, and a semantic connection candidate graph is generated;

[0122] In this embodiment, multi-level semantic relationship edges are constructed for node pairs in the financial basic node set. This stage is responsible for traversing all node pairs by the semantic graph construction, and generates associated edges in combination with upstream and downstream business semantic rules (such as chain rule templates such as “payee → payment time → transaction amount → corresponding invoice number → associated contract number”). Each semantic edge must be bound with edge type (such as “occurred”, “corresponding to”, “derived from”), connection logic (such as primary key dependency, time sequence, numerical mapping), structure level depth (limited to 1-5 levels), and edge confidence score (value range is 0.6-1.0). Finally, a semantic connection candidate graph is generated. This graph is stored in a temporary graph database instance in a bidirectional graph structure, and contains a structure compression index to improve the subsequent retrieval efficiency.

[0123] Field attribute expansion is performed on each node in the semantic connection candidate graph, and financial label annotation is performed on the expanded nodes to obtain a graph expansion structure unit;

[0124] In this embodiment, the attributes of each node in the candidate graph are expanded one by one. Through the association field index table, the fields that are not explicitly displayed in the node but have a logical connection in the same data segment or structure position are injected into the node attribute set. For example, for the "invoice header" node, the "invoice type", "business subject", "corresponding account period" and the like in the file where the node is located are added as derived attributes, ensuring that the node has complete business context information. The extended node will further access the existing financial event labels in the enterprise financial label library for label annotation process. Each node allows binding of multiple labels, and each label includes a label name, a binding path, a label inference confidence (the score needs to be greater than or equal to 0.7), a label source field group, and a label propagation constraint parameter.

[0125] According to the semantic merging of the redundant nodes in the graph expansion structure unit, and performing entity deduplication and graph simplification on the semantic merging result, a unified structure graph is obtained.

[0126] In this embodiment, the redundant nodes in the candidate graph are merged semantically, mainly to identify node sets with different field sources but repeated semantics or highly coinciding structures. The judgment logic is based on three standards: field name similarity ≥ 0.85, field value distribution entropy difference ≤ 0.05, and upstream and downstream connection edge overlap rate ≥ 60%. The nodes that meet the conditions are combined. The combined nodes are uniformly assigned a new node ID, and all original path mapping indexes are retained. At the same time, entity deduplication processing is performed to remove duplicate entities caused by text OCR fuzzy recognition or multiple versions of bills, and the connection relationship between nodes is simplified to generate a unified structure graph.

[0127] The unified structure graph is converted into a graph embedding vector to generate enterprise financial semantic fusion data.

[0128] In this embodiment, after the unified structure graph is constructed, graph embedding is used to perform embedding vector conversion on all nodes and edges in the structure graph. A dense vector construction method is used to encode the attribute information of each node and the type sequence of its adjacent edges to generate a 128-dimensional vector. The embedding process is controlled by parameters such as node type, edge type, node context window size (set to 5), and embedding training rounds (set to 30 rounds). The final output result is enterprise financial semantic fusion data, which is stored in the form of a structured graph vector file. Each record in the file includes a node identifier, a vector code, an original data reference path, and a bound label tuple, and is packaged as a partitioned compressed data packet for subsequent audit path construction module to call and use.

[0129] Optionally, step S3 specifically comprises:

[0130] Step S31: using a preset financial field compliance rule library to perform field compliance rule matching on the enterprise financial semantic fusion data to generate a field compliance annotation set;

[0131] In this embodiment, when processing the enterprise financial semantic fusion data, a pre-set financial field compliance rule library is first loaded, which is composed of multiple field logic rules based on the "Enterprise Accounting Standards" and tax specifications. The rules are stored in a structured table form, and each rule contains field name, data type requirement, value range, context dependency condition, etc. For each node in the enterprise financial semantic fusion data, a field matching process is performed, where the fields exist in the form of attribute key-value pairs, such as "invoice amount: 26500.00", "tax rate: 13%", etc. In the identification process, the fields are compared one by one to see if they meet the legal conditions defined in the rule library, such as the amount field should be non-negative and not exceed 10 million yuan, the time field should meet the ISO 8601 format, and match the logical sequence order defined in the upstream and downstream fields. For the fields that match successfully, a "compliance" label is added; for the fields that fail to match successfully, a "suspected violation" or "format inconsistency" label is added, and the original path, field context and rule number are recorded, and finally a field compliance labeling set is generated, which serves as the basis for subsequent label classification and index establishment.

[0132] Step S32: The non-compliant fields in the field compliance labeling set are labeled according to the pre-set risk classification rules, and a label index is established according to the labeling result and the path of the corresponding field in the graph structure, to obtain a multi-dimensional financial data label set;

[0133] In this embodiment, based on the generated field compliance labeling set, risk classification processing is performed on all fields marked as "non-compliant". The classification standard comes from the enterprise's pre-set risk grading rules, covering six categories such as tax anomalies, subject mismatch, duplicate billing, and amount critical points. The classification rules are defined in JSON structure and associated with risk level numbers. In the classification process, the rule failure type and semantic path positioning information of each non-compliant field are analyzed, for example, a "payment date" field is identified as a cross-account period anomaly, which is classified as a "time sequence mismatch" risk and assigned a medium risk code R3. Thereafter, according to the node position and path direction in the graph structure where the field is located, a field-node-path ternary index is constructed, each index entry stores the field unique number, label code, path hop count, upstream subject number, etc. information, forming a label path table that can be used for propagation tracking. All label path table entries are combined to generate a multi-dimensional financial data label set, which provides a structured basis for redundant field identification and label cleaning.

[0134] Step S33: In the enterprise financial semantic fusion data, if multiple field paths point to the same node, evaluate the uniqueness contribution degree of each field, and mark the fields with a uniqueness contribution degree lower than a pre-set contribution degree threshold as redundant fields, thereby outputting a redundant field structure set;

[0135] In this embodiment, in the case where multiple field paths converge on the same node in the graph structure, the contributions of these field paths need to be measured and analyzed. First, retrieve all the same-pointing path sets in the enterprise financial semantic fusion data, and jointly count the number of unique values of the fields bound by these paths and the frequency of the fields in the node data. For example, if two fields "total amount A" and "total amount B" both point to the "settlement node", and "total amount A" appears 30 times in the node with 10 unique values, while "total amount B" appears 25 times with only 3 unique values, then the uniqueness contribution of "total amount A" is higher. The number of de-duplicated values and frequency entropy are used as weights to calculate the contribution index. If the contribution of a field path is lower than the preset threshold 0.05, and its information can be derived or replaced by other paths, then the path field will be marked as a redundant field. The redundant field information includes field ID, corresponding node, redundancy reason, replaceable field index, etc. The redundant field structure set is integrated to provide a structural basis for subsequent label optimization.

[0136] Step S34: Remove all fields in the multi-dimensional financial data label set that appear in the redundant field structure set and whose label propagation path can be replaced, to obtain a refined financial label node set.

[0137] In this embodiment, after obtaining the redundant field structure set, the multi-dimensional financial data label set generated in the previous stage is cross-removed. The specific process is as follows: all field IDs are selected from the label set, and these fields are compared with the field IDs in the redundant field structure set. Only when the field ID meets the following two conditions at the same time, it is removed: first, the field's corresponding label propagation path in the label set can be replaced by a non-redundant field throughout; second, the field itself does not perform unique identification function in the business node. The field that meets the above conditions is removed from the original label set, and the structure graph path on which the label propagation path depends is updated, the path hop count is adjusted synchronously, and the updated label propagation path reconstructs the label node structure graph. The final output of the refined financial label node set retains label fields with strong semantic expression ability, high structural contribution degree, and controllable propagation path, providing a high-quality label set after cleaning for the construction of basic audit segments.

[0138] Step S35: Combine the refined financial label node set with the corresponding nodes and edges in the enterprise financial semantic fusion data to form a ternary segment set of node-field-label, and group them according to the time dimension and the subject dimension, to obtain the basic audit segments.

[0139] In this embodiment, the simplified financial tag node set is fused with the graph structure elements in the enterprise financial semantic fusion data. The unique identification key (such as voucher number, account code, etc.) of each node is aligned one by one, and the field label information is combined to form a triple structure: "node-field-label". This structure is designed as a nested array form storage, and is grouped according to the field time attribute (such as voucher date, entry time) and the subject dimension (such as asset class, expense class). Taking "2023 first quarter-asset class" as a group, all triple fragments in it are aggregated and arranged to generate audit fragments with time sequence and accounting subject dependence. For example, a node contains "fixed assets-purchase amount-compliance", "fixed assets-scrapped time-suspected abnormality" and other triple labels, which will be classified into the "asset class" path and retain the label time sequence context, and the generated basic audit fragments are organized in JSON array form to provide time and subject structure guarantee for subsequent path construction.

[0140] Step S36: According to the structure dependence relationship of the basic audit fragment, build a financial data audit path.

[0141] In this embodiment, on the basis of the basic audit fragment, a structure dependence relationship identification process is started. First, a directed reference graph is constructed according to the time mark of the label in each audit fragment and the hop number of the path node, and the "label propagation path" is defined as the edge weight. In this reference graph, the node represents the audit fragment, and the edge represents the dependence path of the label or field from one fragment to another. For example, the amount field in a "reimbursement voucher" fragment is transmitted to the "expense summary" fragment, that is, the edge "reimbursement voucher→expense summary" is established. If the path has branches or aggregation, the branches or aggregation will be identified and the upper limit of the hop number (for example, not more than 5 hops) will be recorded. Then, according to the dependence edges in the graph, a path clue set is constructed, and each path clue is attached with source field, label type, path span and timestamp information. Finally, by merging all path clues, a complete financial data audit path graph is constructed, which provides a complete structure carrier for version mapping and causal reasoning.

[0142] Especially important is that step S33 is specifically:

[0143] Step S331: Traverse all nodes in the enterprise financial semantic fusion data, extract all paths that have field-node mapping relationship with the same target node, and construct a same-pointing path set;

[0144] In this embodiment, all nodes in the enterprise financial semantic fusion data are comprehensively traversed, and the cases where multiple field paths point to the same target node are identified. By analyzing the field-node mapping relationship of each node, all field paths pointing to the node are collected, and these paths are grouped according to the target node to form multiple same-pointing path sets. Taking the "fixed asset node" as an example, if multiple field paths such as "purchase amount path" and "depreciation amount path" point to the node, these paths are aggregated into the same set. This operation ensures that the subsequent evaluation of the uniqueness contribution of the field can cover all possible redundant field paths, and effectively identifies redundant data. During the operation, the node traversal rate can be set to 5000 nodes per second to ensure processing efficiency.

[0145] Step S332: Count the number of de-duplication values and the frequency distribution entropy of the fields bound by each path in the same-pointing path set in the enterprise financial semantic fusion data, and calculate the field uniqueness contribution degree according to the number of de-duplication values and the frequency distribution entropy;

[0146] In this embodiment, for each path in the same-pointing path set, the system counts the number of de-duplication values of the field bound by the path in the enterprise financial semantic fusion data and the uniformity of the frequency distribution. The specific operation is to scan all node records corresponding to the field, calculate the number of unique values of the field to reflect the information diversity, and measure the distribution of the field value at different time points or in different accounts to evaluate the data stability. For example, if the "purchase amount" field has 950 different values in 1000 records, the de-duplication number is high and the frequency distribution is uniform, which shows a high uniqueness contribution degree. Based on the number of de-duplication values and the uniformity of the distribution, the uniqueness contribution degree of the field is comprehensively evaluated, and the operation parameters such as the minimum record number are set to 300 to ensure the representativeness of the statistical results.

[0147] Step S333: Mark the fields corresponding to the field paths in the same-pointing path set as redundant fields if the field uniqueness contribution degree is lower than the contribution degree threshold 0.05; integrate all field paths with redundant fields and mark the redundant type label and the corresponding node to obtain a redundant field path set;

[0148] In this embodiment, for the field paths in the same direction path set whose evaluated uniqueness contribution is below the threshold value 0.05, redundant field marking is performed. The threshold value is adjusted by enterprise experience data, and the purpose is to eliminate data paths that have little contribution to the information of the target node or can be replaced by other fields. During the marking process, the system attaches a redundant type label (such as "value repetition", "information missing") and the node identification belonging to each redundant field path, forming a complete redundant field path set. For example, the "reimbursement amount repetition path" is marked as "value repetition" and belongs to the "expense reimbursement node". This set is then integrated and stored to support subsequent structure optimization and label elimination steps.

[0149] Step S334: The redundant field path set is mapped to the enterprise financial semantic fusion data to construct a redundant field structure set.

[0150] In this embodiment, the generated redundant field path set is mapped back to the overall structure of the enterprise financial semantic fusion data. The specific method is to use the mapping information of the fields and nodes in the path set to identify the corresponding field nodes in the original graph structure, and construct a redundant field structure set in the original structure, which is represented as a set of structured entries containing field ID, node ID, redundant label and other attributes. Through this mapping, the enterprise financial data system can have a clear understanding of the position, number and impact range of the redundant fields, facilitating the subsequent field elimination and audit path optimization. The system uses batch data update in this mapping step to ensure accurate mapping and does not affect data reading efficiency.

[0151] Optionally, the temporal version mapping in step S4 is specifically:

[0152] Version nodes are identified for the field structure in the financial data audit path to construct a structure version point set;

[0153] In this embodiment, when identifying the version nodes for the field structure in the financial data audit path, all fields and their associated nodes in the audit path are first traversed, and the version information of the fields at different time points is collected. The definition of the version node is identified according to the timestamp of the field content change and the trigger point of the structure attribute change, for example, if the "accounts receivable" field in the balance sheet is adjusted in format or the field value changes in March 2023, then this time point is marked as a version node. During the identification process, the minimum time interval is limited to one day to prevent too many version nodes from being generated due to frequent minor changes. After this processing, the structure version point set formed lays the foundation for subsequent version timeline construction.

[0154] Each version point in the structure version point set is aligned to the time dimension and temporally anchored to construct a structure version timeline;

[0155] In this embodiment, each version node in the structural version point set is mapped to the time dimension, and combined with the accounting period setting of enterprise finance, the time anchoring operation is performed to form a structural version timeline. The timeline takes day as the basic time unit, and marks the start time and duration of the validity of each version node. For example, the version node of the "fixed asset depreciation rate" field in the first quarter of 2023 covers March 1 to May 31. The time anchoring process ensures that the version points are accurately positioned on the timeline, facilitating the comparison of differences between subsequent version snapshots and the analysis of version relationships.

[0156] The structural change difference matrix is generated by comparing the changes between adjacent structural version snapshots in the structural version timeline;

[0157] In this embodiment, the field content and structural changes of adjacent version snapshots in the structural version timeline are compared, and a structural change difference matrix is generated for each pair of consecutive versions. The difference matrix takes the field path as the row, the version pair as the column, and records the change type (such as addition, deletion, modification) and specific change content of the field attribute value. For example, the "accounts payable" field added the "overdue days" attribute in the version snapshot of April 2023, and this change is clearly recorded in the matrix. When operating, the threshold for difference detection is set to 5% of the field change rate to avoid meaningless minor adjustments interfering with version analysis. Through this matrix, the dynamic changes of field structure between versions can be expressed.

[0158] Each node field path in the structural change difference matrix is bound to the corresponding version in the structural version timeline, and the structural change segment is marked to generate a version marked path set;

[0159] In this embodiment, each node field path in the structural change difference matrix is bound to the corresponding version in the structural version timeline according to the change time period it occurs in, and the change segment is marked to form a version marked path set. In specific implementation, the field change row in the difference matrix is mapped to the corresponding version node interval in the timeline, and the change content type (such as field addition, field attribute adjustment) is annotated. The version marked path set is saved in a graphical data structure, containing version number, field path, change type, change time, etc. attributes, providing rich semantic support for version evolution track construction.

[0160] The structural evolution track graph is constructed based on the version marked path set and the structural change difference matrix, and the structural evolution track graph is the temporal version mapping result.

[0161] In this embodiment, based on the version-annotated path set and the structural change difference matrix, a structural evolution trajectory graph is further constructed. The trajectory graph takes version nodes as graph nodes and change paths as directed edges. Each edge in the graph describes the evolution relationship and change type of the field structure between two version nodes. For example, the path between the "2023Q1 version node" and the "2023Q2 version node" represents the evolution of the "asset class subject" structure in this period. The evolution trajectory graph is the completed temporal version mapping result, which clearly shows the whole process of the field structure evolution in the financial data audit path over time, providing a complete time sequence structure basis for subsequent version management and audit analysis.

[0162] Optionally, the hierarchical file compression in step S4 is specifically:

[0163] Based on the structural evolution trajectory graph, cross-version common structure is identified, and a structural fragment folding graph is constructed.

[0164] In this embodiment, when identifying cross-version common structure based on the structural evolution trajectory graph, all version nodes and connection edges in the trajectory graph are traversed to identify similar field structures and node features that repeatedly appear in multiple versions. In this process, the similarity threshold is set to 85%, and only nodes with a structure feature matching degree reaching the threshold are recognized as common structures. After identification, the cross-version common structures are classified and summarized to construct a structural fragment folding graph. This graph aggregates common nodes and folds repeated structure paths to minimize the structure redundancy between versions, improving the efficiency and data compression rate of subsequent processing.

[0165] According to the structural fragment folding graph, the meta attributes of the cross-version common structure nodes are aggregated to obtain a field aggregation table. Meanwhile, the distribution of each field value in different versions is counted using the version path annotation set, and fields with a repeated value rate exceeding 90% in the distribution are extracted to generate a field value redundancy pool.

[0166] In this embodiment, according to the structural fragment folding graph, the meta attributes of the aggregated common structure nodes are integrated to form a field aggregation table. The field aggregation table records the index position, field type, field name, and nested level information of each field in different versions, etc. For example, the index and level of the "accounts receivable" field in version 1 and version 3 are integrated together. At the same time, the distribution frequency of field values between versions is counted using the version path annotation set. For those fields whose values remain unchanged in more than 90% of the versions, the high-repetition field values are extracted and stored in the field value redundancy pool to optimize storage space and access efficiency.

[0167] Using the field index and nesting information in the field aggregation table, combined with the path structure in the version path annotation set and the field usage period in the structural version timeline, a structure compression tree is constructed.

[0168] In this embodiment, the field index in the field aggregation table is combined with the nesting information, and a structure compression tree is constructed according to the path structure in the version path marking set and the use period characteristics of the fields in the structure version timeline. The tree structure takes the fields as nodes, reflects the hierarchical relationship between the fields and the continuous use between the versions. In the operation, the field use period threshold is set to three months, and the field is regarded as a long-term valid node if it exceeds the period. The construction of the structure compression tree helps to manage the multi-version structure in a hierarchical manner, facilitating efficient compression and fast access.

[0169] Path version expansion and differential compression encoding are performed based on the structure compression tree to generate a structure compression index set;

[0170] In this embodiment, path version expansion and differential compression encoding processing are performed based on the constructed structure compression tree. Path version expansion means that each path in the tree is disassembled into finer-grained version snapshots according to the version time sequence, and the changes between adjacent version snapshots are stored efficiently by combining differential compression encoding, avoiding repeated redundant data. For example, for a field attribute that does not change in multiple versions, it is stored only once, and the changed part is recorded in the form of differential encoding. This processing generates a structure compression index set, which provides fast positioning function for subsequent query and version matching.

[0171] The structure compression tree, the structure compression index set, the field aggregation table, the field value redundancy pool and the version marking path set are hierarchically encapsulated to generate a structured financial data audit path.

[0172] In this embodiment, the structure compression tree, the structure compression index set, the field aggregation table, the field value redundancy pool and the version marking path set are hierarchically encapsulated to form a complete structured financial data audit path. In the encapsulation process, a hierarchical storage strategy is adopted, the field value redundancy pool and the field aggregation table are stored in the bottom layer, the structure compression tree and the index set are stored in the middle layer, and the version marking path set is associated in the top layer, realizing hierarchical management and efficient calling of data access. The structured audit path meets the needs of financial audit and version tracking, and provides a solid foundation for subsequent analysis and model construction.

[0173] Optionally, step S5 is specifically:

[0174] Step S51: parsing the structured financial data audit path to construct a time series causal candidate event set;

[0175] In this embodiment, when analyzing the structured financial data audit path, first, the time series of each type of node and field in the audit path is sorted, the possible event trigger points are extracted according to the timestamp and structure level, and the time series causal candidate event set is constructed. This process sets the time window parameter to events within 30 days as continuous association, ensuring the capture of changes in financial data within a continuous time period. The event candidate set includes field changes, certificate updates, and accounting adjustments, and each event has a timestamp and structure path information, which facilitates subsequent causal correlation analysis.

[0176] Step S52: Classify each path in the time series causal candidate event set by field type and structure level, and perform causal correlation based on the time sequence and path dependence relationship to obtain a causal graph structure;

[0177] In this embodiment, the time series causal candidate event set is grouped and classified according to the field type (such as asset type, liability type, income type, etc.) and its hierarchical position in the financial structure, forming a set of event paths of the same type. The classified event paths are further correlated causally according to the time sequence and the dependence relationship between paths to establish the correlation and dependence chain between events. For example, a certain asset impairment event is followed by a related liability adjustment event, and the two are causally connected. The entire process uses threshold parameters to control the allowed interval of time sequence, with a default of no more than 15 days. Finally, a causal graph structure describing the causal relationship between events is obtained, showing the network form of financial event evolution.

[0178] Step S53: Perform causal reasoning modeling on the causal graph structure to generate a causal link matrix;

[0179] In this embodiment, based on the above-mentioned causal graph structure, all node pairs and connection paths are processed by reasoning to form a causal link matrix. The matrix takes event node pairs as elements, records the causal strength and direction between them, and reflects the influence relationship between events. In the construction process, the stability and repeatability of causal connection are screened to remove node pairs that do not have significant causal correlation, ensuring the sparsity and effectiveness of the matrix. For example, only causal relationships that occur in three consecutive financial periods are retained. This matrix structure provides basic data support for subsequent model mapping and reasoning.

[0180] Step S54: Map the causal link matrix to the structure compression index set to replace the structure number and match the path, generate a structured causal unit, organize all structured causal units into a logical execution graph, and obtain a financial cognitive reasoning model;

[0181] In this embodiment, when the causal link matrix is mapped to the structured compression index set, the event node numbers in the matrix are replaced by the corresponding compression structure numbers through index mapping, and the corresponding relationship of the event path in the compression structure is confirmed according to the path matching rule. The mapping result forms a structured causal unit, which integrates the event causal relationship and the structure path information. All causal units are organized into an execution graph according to the logical dependency relationship, presenting the flow and node interaction of event reasoning. The execution graph supports distributed calling and modular management, meeting the needs of enterprise financial management for dynamic reasoning models.

[0182] Step S55: uploading the financial cognitive reasoning model to the enterprise internal financial management to perform a model deployment task.

[0183] In this embodiment, the generated financial cognitive reasoning model is packaged and uploaded to the enterprise internal financial management. During the uploading process, the compatibility and security of the model are ensured, and incremental updating and version management of the model are supported. The deployment parameters include setting the model refresh cycle to once every quarter, supporting real-time financial event monitoring and automatic early warning. After the deployment is completed, the enterprise finance can perform causal link analysis based on the model, assist in audit decision-making and risk identification, and improve the intelligent and automated level of financial data processing.

[0184] Especially important is that step S53 specifically includes:

[0185] Traversing all node pairs in the causal graph structure body, screening path pairs with directed edge connection, and extracting the corresponding time series of each path pair to construct a causal path time series set;

[0186] In this embodiment, when traversing the causal graph structure body, all node pairs are checked one by one to identify path pairs with directed edge connection, ensuring that the path direction conforms to the directionality of the causal relationship. For each path pair that meets the conditions, the corresponding time series data is extracted, which includes the timestamp of event occurrence and related field change information. The time span parameter is set to half a year during the extraction process to ensure that the time series covers recent effective financial events. Through this process, a complete causal path time series set is constructed as the basis for subsequent correlation analysis.

[0187] Performing bivariate causal strength evaluation on each path pair in the causal path time series set, and obtaining a stable causal path set according to the path pairs whose causal strength evaluation is lower than the preset causal strength threshold 0.7;

[0188] In this embodiment, the bivariate causal strength of each path pair of event sequence is evaluated in the constructed causal path time series set to evaluate the tightness of the causal relationship between the two events. Factors such as time sequence, event frequency and impact duration are considered in the evaluation process, and the evaluation results are quantitatively scored. The evaluation threshold is set to 0.7, that is, only the path pairs with causal strength higher than 0.7 are considered as effective causal paths. The screening operation will eliminate path pairs below this threshold, ensuring that the remaining path pairs have stable and significant causal relationships, forming a stable causal path set.

[0189] Based on the stable causal path set, a causal weight atlas is constructed. The causal weight atlas is converted into a standardized matrix representation and subjected to path sparsification processing to obtain a causal link matrix.

[0190] In this embodiment, based on the stable causal path set obtained by screening, a causal weight atlas is constructed. Each node in the atlas represents an event, and the edge connection represents the causal relationship, and the edge weight reflects the causal strength. The weight allocation considers the path frequency and event importance, and the parameter setting normalizes the weight to the 0-1 interval. Subsequently, the weight atlas is converted into a standardized matrix form, and the matrix elements correspond to the causal relationship weight between events. In order to improve the calculation efficiency, the matrix is subjected to path sparsification processing, removing the connection edges with very low weight, and only retaining the key causal paths, finally obtaining a compact and efficient causal link matrix, providing a foundation support for subsequent reasoning and model application.

[0191] Optionally, the present application also provides an enterprise financial data processing system for executing the enterprise financial data processing method as described above, the enterprise financial data processing system comprising:

[0192] A data acquisition module is configured to acquire multi-source enterprise financial data, and perform dynamic data type identification and structure conversion on the multi-source enterprise financial data to obtain preprocessed enterprise financial data.

[0193] A structure conversion module is configured to perform effective financial data screening on image-type invoice data and table-type bill data in the preprocessed enterprise financial data, and perform atlas embedding structure conversion according to the effective financial data to obtain enterprise financial semantic fusion data.

[0194] A financial annotation module is configured to perform compliance label annotation and redundant field discrimination according to the enterprise financial semantic fusion data to obtain enterprise financial annotation data, and construct a financial data audit path based on the enterprise financial annotation data.

[0195] The data compression module is configured to perform time version mapping on data format fluctuation characteristics in the financial data audit path, to record structural change processes of various types of vouchers and balance sheet data in the financial data audit path, and to perform hierarchical file compression on the time version mapping results, to obtain the structured financial data audit path.

[0196] The model construction module is configured to construct a time series causal link according to the structured financial data audit path, to obtain a financial cognitive reasoning model, and to upload the financial cognitive reasoning model to an enterprise internal financial management system, to perform a model deployment task.

[0197] Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting, the scope of the application being defined by the appended claims and not by the above description, and all variations falling within the meaning and the scope of the equivalent elements of the application file are intended to be included in the application.

[0198] The above description is merely one specific implementation of the application, which enables a person skilled in the art to understand or implement the application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the application. Therefore, the application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of processing enterprise financial data, characterized by, The method comprises the following steps: Step S1: obtaining multi-source enterprise financial data, and performing dynamic data type identification and structure conversion on the multi-source enterprise financial data to obtain preprocessed enterprise financial data; Step S2: performing effective financial data screening on image-type invoice data and table-type bill data in the preprocessed enterprise financial data, and performing graph embedding structure conversion according to the effective financial data to obtain enterprise financial semantic fusion data; Step S3: performing compliance label annotation and redundant field discrimination on the enterprise financial semantic fusion data to obtain enterprise financial labeled data; constructing a financial data audit path based on the enterprise financial labeled data; Step S4: performing temporal version mapping on data format fluctuation characteristics in the financial data audit path to record the structure change process of various types of vouchers and asset liability data in the financial data audit path, and performing hierarchical file compression on the temporal version mapping result to obtain a structured financial data audit path; Step S5: constructing a time series causal link based on the structured financial data audit path to obtain a financial cognitive reasoning model, and uploading the financial cognitive reasoning model to an enterprise internal financial management system to perform a model deployment task; Step S5 specifically comprises: Step S51: analyzing the structured financial data audit path to construct a time series causal candidate event set; Step S52: classifying each path in the time series causal candidate event set according to field type and structure level, and performing causal correlation on the classification result based on time sequence and path dependence to obtain a causal graph structure; Step S53: performing causal reasoning modeling on the causal graph structure to generate a causal link matrix; Step S54: replacing the structure number according to the mapping of the causal link matrix to the structure compression index set to generate a structured causal unit, organizing all structured causal units into a logical execution graph to obtain a financial cognitive reasoning model; Step S55: uploading the financial cognitive reasoning model to the enterprise internal financial management system to perform a model deployment task.

2. The method of processing financial data of an enterprise according to claim 1, wherein, Step S1 specifically comprises: Step S11: obtaining multi-source enterprise financial data, and performing label classification according to the data source type of the multi-source enterprise financial data to obtain original financial data; Step S12: performing file format recognition and content structure analysis on the original financial data to construct structure type feature data; Step S13: performing structure universal mapping conversion according to the structure type feature data to obtain financial intermediate structure representation data; Step S14: performing field standardization processing on the financial intermediate structure representation data, and establishing a field index table for high-frequency fields in the standardization processing result; Step S15: combining the field index table to perform consistency verification and conflict field elimination on the financial intermediate structure representation data to obtain preprocessed enterprise financial data.

3. The method of processing financial data of an enterprise according to claim 2, wherein, Step S13 specifically comprises: Step S131: analyzing the field level depth, nesting mode, record unit distribution, and file format characteristics of each structure type in the structure type feature data, and performing structure type-semantic unit mapping on the analysis result based on a preset structure mode library to obtain a structure mapping template set; Step S132: Call the structure mapping template set to convert the structure type feature data into generalization, and obtain structure mapping intermediate data; Step S133: Perform format standardization and field label standardization on the structure mapping intermediate data to generate a unified structure unit set; Step S134: According to the business semantic relationship between the structure units in the unified structure unit set, perform structure semantic association expression to obtain financial intermediate structure representation data.

4. The method of processing enterprise financial data of claim 1, wherein, The effective financial data filtering in step S2 is specifically: Extract image type invoice data and table type bill data from the preprocessed enterprise financial data; Perform structure-aware OCR recognition on the image type invoice data to extract invoice field content and construct an invoice field structure set; Perform cell semantic classification and financial logic block labeling on the table type bill data to construct a bill structure label set; Perform content integrity evaluation and field confidence evaluation on the invoice field structure set, and use the content integrity evaluation result and the field confidence evaluation result to perform effectiveness scoring. Only invoice field structure data with an effectiveness score greater than or equal to 0.85 is retained, thereby obtaining effective invoice field structure data; Perform field matching rate analysis and multi-column dependency verification on the financial logic blocks in the bill structure label set. Only bill segments with high field matching rate and complete column dependency relationship are retained to generate effective bill structure data; Normalize and encapsulate the effective invoice field structure data and the effective bill structure data according to the preset structure encoding specification to obtain effective financial data.

5. The method of processing financial data of an enterprise according to claim 1, wherein, The graph embedding structure conversion in step S2 is specifically: Perform financial semantic entity recognition on the graph semantic input data to construct a financial base node set; Construct a multi-level semantic relationship edge based on the financial base node set to generate a semantic connection candidate graph; Perform field attribute expansion on each node in the semantic connection candidate graph, and label the expanded nodes with financial labels to obtain a graph expansion structure unit; Perform semantic merging on the redundant nodes in the graph expansion structure unit, and perform entity deduplication and graph simplification on the semantic merging result to obtain a unified structure graph; Convert the unified structure graph into a graph embedding vector to generate enterprise financial semantic fusion data.

6. The method of processing financial data of an enterprise according to Claim 1, wherein, Step S3 is specifically: Step S31: Use the preset financial field compliance rule library to perform field compliance rule matching on the enterprise financial semantic fusion data to generate a field compliance label set; Step S32: Label the non-compliant fields in the field compliance label set according to the preset risk classification rules, and establish a label index according to the labeling result and the graph structure path where the corresponding field is located to obtain a multi-dimensional financial data label set; Step S33: In the enterprise financial semantic fusion data, if multiple field paths point to the same node, evaluate the uniqueness contribution degree of each field, and mark the fields with a uniqueness contribution degree lower than a preset contribution degree threshold as redundant fields, thereby outputting a redundant field structure set; Step S34: Remove all fields in the multi-dimensional financial data label set that appear in the redundant field structure set and whose label propagation path can be replaced to obtain a simplified financial label node set; Step S35: combine the nodes and edges in the simplified financial tag node set with the corresponding nodes and edges in the enterprise financial semantic fusion data to form a set of node-field-tag ternary fragments, and group them according to the time dimension and the subject dimension to obtain basic audit fragments; Step S36: construct a financial data audit path according to the structural dependency relationship of the basic audit fragments and the label propagation path.

7. The method of processing financial data of an enterprise according to Claim 1, wherein, The time version mapping in step S4 is specifically: identify the version nodes of the field structure in the financial data audit path, and construct a set of structural version points; align each version point in the set of structural version points to the time dimension, and perform time anchoring to construct a structural version timeline; compare the change content between adjacent structural version snapshots in the structural version timeline to generate a structural change difference matrix; bind each node field path in the structural change difference matrix to the version in the corresponding time period of the structural version timeline, and label the structural change fragments to generate a set of version labeled paths; construct a structural evolution trajectory based on the set of version labeled paths and the structural change difference matrix, wherein the structural evolution trajectory is the time version mapping result.

8. The method of processing financial data of an enterprise according to Claim 1, wherein, The hierarchical file compression in step S4 is specifically: identify the cross-version common structure based on the structural evolution trajectory, and construct a structural fragment folding graph; aggregate the meta attributes of the cross-version common structure nodes according to the structural fragment folding graph to obtain a field aggregation table; at the same time, use the version path labeling set to count the distribution of field values in different versions, and extract the fields with a repeated value rate of more than 90% in the distribution to generate a field value redundancy pool; construct a structural compression tree using the field index and nesting information in the field aggregation table, combined with the path structure in the version path labeling set and the field usage period in the structural version timeline; perform path version expansion and difference compression encoding based on the structural compression tree to generate a set of structural compression indexes; perform hierarchical encapsulation of the structural compression tree, the set of structural compression indexes, the field aggregation table, the field value redundancy pool, and the version labeled path set to generate a structured financial data audit path.

9. A system for processing enterprise financial data, characterized by The enterprise financial data processing system for performing the method of claim 1 comprises: a data acquisition module for acquiring multi-source enterprise financial data and performing dynamic data type recognition and structural conversion on the multi-source enterprise financial data to obtain preprocessed enterprise financial data; a structural conversion module for performing effective financial data filtering on image-type invoice data and table-type bill data in the preprocessed enterprise financial data, and performing graph embedding structural conversion based on the effective financial data to obtain enterprise financial semantic fusion data; a financial labeling module for performing compliance label annotation and redundant field discrimination based on the enterprise financial semantic fusion data to obtain enterprise financial labeled data; and constructing a financial data audit path based on the enterprise financial labeled data; a data compression module for performing time version mapping on the data format fluctuation characteristics in the financial data audit path to record the structural change process of various vouchers and asset liability data in the financial data audit path, and performing hierarchical file compression on the time version mapping result to obtain a structured financial data audit path. A model construction module is configured to construct a time series causal link according to the structured financial data audit path, obtain a financial cognitive reasoning model, and upload the financial cognitive reasoning model to an enterprise internal financial management system to perform a model deployment task.

Images