Intelligent document data processing method, system, device and medium

Abstract

The application discloses an intelligent document data processing method, system, device and medium, and is applied to the technical field of data processing. The method comprises the following steps: performing multi-element analysis on an unstructured industry and finance document and converting the unstructured industry and finance document into structured analysis data containing coordinate data; calling a preconfigured extraction template containing a prompt word or a field mode to perform semantic extraction on the structured analysis data to generate structured business data; calling a preconfigured review strategy containing a review instruction or a script mode to review the structured business data and output a review result; and filling the structured business data with the review result being compliant into a downstream system after converting the structured business data into standardized business data required by the downstream system. The application improves the complex document analysis accuracy and cross-scene adaptation efficiency, realizes data compliance closed-loop verification and standardized reuse of industry and finance capabilities.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an intelligent document data processing method, system, device and medium. Background Technology

[0002] The business finance domain (i.e., the integrated management of enterprise finance and business) involves the processing of a large number of unstructured documents, including contracts, invoices, expense reports, and acceptance forms. These documents are usually in formats such as PDF, Word, and images. Key fields (such as contract amount, invoice code, and reason for expense) need to be extracted from them before being entered into downstream systems such as Enterprise Resource Planning (ERP) systems and financial systems.

[0003] Current technologies primarily employ a combined approach of "manual data entry + rule engine + Robotic Process Automation (RPA) scripts": receiving unstructured documents such as PDFs, Word documents, and images, extracting key fields using pre-defined regular expressions (e.g., fixed-position field matching), and then converting them into a standardized data format required by downstream systems using customized RPA scripts before inputting them into the downstream systems. This approach has the following main shortcomings: First, the ability to process complex documents is insufficient. Fixed regular expressions are difficult to adapt to non-standard layouts (such as handwritten annotations and cross-page tables), resulting in low accuracy in extracting key fields and requiring a large amount of manual data entry. Secondly, cross-scenario adaptation is inefficient. RPA scripts are strongly coupled with document types, and new business scenarios require the redevelopment of RPA scripts, which is time-consuming and cannot meet the needs of rapid iteration. Third, data quality is not guaranteed. When critical fields are parsed incorrectly (such as reading a date as an amount), downstream systems need to backtrack and correct them, resulting in a high rate of discrepancies in financial reconciliation, significant compliance risks, and difficulty in meeting regulatory requirements. Summary of the Invention

[0004] This application provides an intelligent document data processing method, system, device, and medium to address the problems of insufficient complex document parsing capabilities, low scene adaptation efficiency, and lack of data quality assurance in existing technologies. The technical solution provided by this application is as follows: On the one hand, this application provides an intelligent document data processing method, including: In response to a user's upload of an unstructured business document, the system parses the layout elements of the unstructured business document to obtain layout element data. Then, it performs semantic logic reorganization and coordinate mapping on the layout element data to obtain structured logical object data. The structured logical object data is a hierarchical tree structure. In response to the user's configuration operation for the extraction template, the extraction template is invoked to extract business data from the structured logical object data to obtain structured business data; In response to the user's configuration of the review policy, the review policy is invoked to conduct a compliance review of the structured business data and obtain the review results; In response to the user's configuration operation for the pattern rules, the pattern rules are invoked to convert the structured business data that has passed the review into standardized business data required by the downstream system; In response to the user's configuration of the fill method, the fill method is invoked to fill standardized business data into the downstream system.

[0005] The above solution transforms unstructured business and financial documents into structured logical object data that retains spatial coordinates and logical relationships through a two-stage process of parsing layout elements, reorganizing semantic logic, and restoring coordinate mapping. This decouples document format from business logic. Configurable extraction templates, review strategies, and pattern rules enable configurable responses for business data extraction, compliance verification, and standardized conversion. Configurable filling methods facilitate automated integration with downstream systems, thus solving the technical problems of difficult complex document parsing, slow scenario adaptation, and lack of data compliance verification.

[0006] Optionally, page element parsing is performed on unstructured business and financial documents to obtain page element data, including: Perform pixel-level visual analysis on unstructured business documents to identify each physical element in the unstructured business documents, as well as the element content, element type, and element coordinates of each physical element; Sort all physical elements according to page number, vertical coordinate, and horizontal coordinate, and assemble them into layout element data.

[0007] The above scheme accurately identifies each physical element in the document through pixel-level visual analysis and assembles it into layout element data in the order of page number, vertical coordinate and horizontal coordinate, providing the underlying data foundation that preserves the original spatial position relationship for subsequent semantic logic reorganization.

[0008] Optionally, semantic logic reorganization and coordinate mapping restoration of the layout element data are performed to obtain structured logical object data, including: Spatial clustering analysis and semantic coherence judgment are performed on multiple physical elements located in adjacent or identical areas in the page element data. The physical elements belonging to the same cell are reorganized into a logical object, and two physical elements that are adjacent across pages and belong to the same paragraph are reorganized into a logical object. For each reorganized logical object, if the logical object consists of a single physical element, then the element coordinates of the physical element are used as the object coordinates of the logical object. If a logical object consists of at least two physical elements, then a coordinate array is generated based on the element coordinates of each physical element as the object coordinates of the logical object; wherein, the coordinate array contains the element coordinates of each physical element; All the reorganized logical objects are sorted according to page number, vertical coordinate, and horizontal coordinate, and assembled into structured logical object data with a hierarchical tree structure; each logical object in the structured logical object data contains object content, object type, and object coordinates.

[0009] The above solution reorganizes fragmented physical elements into semantically complete logical objects through spatial clustering analysis and semantic coherence judgment, effectively solving the problem of logical breaks in complex layout elements such as merged cells and cross-page paragraphs. At the same time, through the coordinate mapping restoration mechanism, it ensures that each logical object retains a precise correspondence with the physical location of the original document, providing a spatial indexing basis for subsequent review and data tracing.

[0010] Optionally, the extraction template includes prompt words and / or a list of fields; by invoking the extraction template, business data is extracted from the structured logical object data to obtain structured business data, including: Extract candidate logical objects from structured logical object data based on prompt words and / or field lists; After semantically extracting business data from each candidate logical object, the business data is assembled into a JSON structure to form structured business data.

[0011] The above solution provides a flexible extraction template configuration mechanism through two configuration methods: prompt words and / or field lists. The prompt word mode is suitable for semantically driven fuzzy extraction scenarios, while the field list mode is suitable for precise extraction scenarios of structured fields. The two modes can be used alone or in combination to meet the extraction needs of different business documents.

[0012] Optionally, the review strategy includes at least one review rule, each review rule being associated with review fields and review conditions; the review strategy is invoked to perform a compliance review on the structured business data to obtain the review results, including: Match each business field in the structured business data with each review rule in the review strategy to determine the mapping relationship between business fields and review conditions; Based on the review mode of each review rule, a compliance review is conducted on each business field according to the mapping relationship between business fields and review conditions; The compliance review results for each business field are assembled into a JSON structure to form the review results. The review results include the review status (review passed or failed), a list of risk items, and modification suggestions.

[0013] The above solution establishes a mapping relationship between business fields and review conditions through field matching, supports flexible configuration of multiple review modes, and outputs the review results in a standardized JSON structure, providing a structured decision-making basis for subsequent risk handling and data correction.

[0014] Optionally, the schema rules include target field mapping rules, data type conversion rules, and required metadata completion rules; by invoking the schema rules, the structured business data that has passed the review is converted into standardized business data required by the downstream system, including: For each business field in the structured business data, according to the target field mapping rules, data type conversion rules, and required metadata completion rules, the business field is mapped to the target field, converted to the data type, and required metadata is completed to obtain the standardized business field; All standardized business fields are assembled into the standard message format required by downstream systems to form standardized business data.

[0015] The above solution uses a triple conversion mechanism of target field mapping, data type conversion, and required metadata completion to uniformly convert the approved structured business data into the standard format required by downstream systems. This eliminates the data heterogeneity barrier between different systems and realizes the automated connection of business data from extraction to downstream system integration.

[0016] Optionally, after invoking the population method to populate standardized business data into the downstream system, the process also includes: Receive status receipts from downstream systems for standardized business data; if the status receipt indicates that the standardized business data has been successfully populated, write the status receipt back and associate it with the entire process record of the unstructured business and financial documents. If the status receipt indicates that the standardized business data has failed to be populated, an exception log will be generated and an exception handling operation will be triggered. The exception handling operation includes generating a visual to-do order and pushing it to the user. In response to user repair operations on visual pending work orders, the repaired standardized business data is repopulated into the downstream system; when the downstream system returns a new status receipt indicating that the repaired standardized business data has been successfully populated, the new status receipt is written back and associated with the entire process record of the unstructured business and financial documents.

[0017] The above solution achieves closed-loop feedback of data filling results through a status feedback mechanism. When filling is successful, the feedback is associated with the entire process record to ensure the traceability of the processing link. When filling fails, the automatic discovery and manual intervention correction of anomalies are achieved through the repair process driven by anomaly logs and visual pending work orders, thus ensuring the final consistency of data.

[0018] On the other hand, this application also provides an intelligent document data processing system, including: The document parsing layer is used to respond to user upload operations for unstructured business documents. After parsing the layout elements of the unstructured business documents to obtain layout element data, the layout element data is semantically and logically reorganized and coordinately mapped to obtain structured logical object data; among which, the structured logical object data is a hierarchical tree structure. The field extraction layer is used to respond to the user's configuration operation for the extraction template, call the extraction template, and extract business data from the structured logical object data to obtain structured business data; The compliance review layer is used to respond to user configuration operations for review policies, invoke review policies, and perform compliance reviews on structured business data to obtain review results; The schema conversion layer is used to respond to user configuration operations for schema rules, invoke schema rules, and convert structured business data that has passed the review into standardized business data required by downstream systems. The data population layer is used to respond to the user's configuration operation for the population method, call the population method, and populate the standardized business data into the downstream system.

[0019] The above solution achieves decoupling and collaboration among the functional modules of document parsing, data extraction, compliance review, schema conversion, and data population through a layered architecture, supporting the stable operation and expansion of the above method.

[0020] On the other hand, this application also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described intelligent document data processing method.

[0021] On the other hand, this application also provides a readable storage medium that stores computer instructions, which, when executed by a processor, implement the above-described intelligent document data processing method.

[0022] The beneficial effects of this application are as follows: This application utilizes a two-stage processing approach—page element parsing and semantic logic reorganization, along with coordinate mapping restoration—to transform unstructured business and financial documents into structured logical object data that retains spatial coordinates and logical relationships. This overcomes the limitations of traditional rule-based matching in adapting to complex layouts, improving the completeness and accuracy of information extraction from the data source. Through configurable extraction templates, review strategies, and pattern rules, the extraction, compliance verification, and standardization transformation of business data are decoupled from hard-coded processes. This allows for adaptation to new scenarios with only configuration adjustments, eliminating the need for script refactoring and significantly shortening the response cycle for new business scenarios. By embedding a compliance review mechanism within the processing chain, data quality is effectively guaranteed, reducing financial reconciliation discrepancies and compliance risks, thus better meeting regulatory requirements.

[0023] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description or may be learned by practicing this application. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram outlining the intelligent document data processing method in the embodiments of this application; Figure 2 This is a schematic diagram of the composition structure of the intelligent document data processing system in the embodiments of this application; Figure 3 This is a schematic diagram of the hardware structure of the electronic device in the embodiments of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and beneficial effects of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] Example 1 like Figure 1 As shown in the figure, this application provides an intelligent document data processing method. This method constructs a complete processing link from parsing unstructured business documents to downstream system population, specifically including the following steps: Step S101: In response to the user's upload operation for unstructured business documents, after parsing the layout elements of the unstructured business documents to obtain layout element data, the layout element data is semantically and logically reorganized and coordinately mapped to obtain structured logical object data; wherein, the structured logical object data is a hierarchical tree structure.

[0027] Specifically, unstructured business and financial documents can be business and financial files in various formats such as PDF, Word, and images, such as contracts, invoices, and expense reports.

[0028] After a user uploads an unstructured business document to be processed through the system interface, the system first parses the document's layout elements, identifies various physical elements in the document, and extracts their content, type, and coordinates to form layout element data. A physical element refers to the smallest rectangle that encloses a complete visual unit (e.g., a complete word, an independent table cell, the outline of an image, etc.). Each physical element includes: element content, which refers to the specific characters within the physical element (e.g., "Total", "¥500,000"), the binary description of an image, or the LaTeX code of a formula; element type, which refers to the physical attribute label of the physical element (e.g., paragraph, table, image, handwriting, header, etc.); and element coordinates, which refers to the precise position of the physical element on the original document page (e.g., the [X1, Y1, X2, Y2] values ​​of the four corners of the smallest rectangle, and the page number page_num).

[0029] Subsequently, the system performs semantic and logical reorganization on the layout element data, aggregating fragmented physical elements into complete logical objects according to semantic relationships. A coordinate mapping restoration mechanism ensures that each logical object retains a precise correspondence with its physical location in the original document. The final output structured logical object data contains both machine-readable semantic information and maintains its spatial mapping relationship with the original document, providing a unified data foundation for subsequent accurate extraction and interactive review. The structured logical object data includes multiple logical objects, each composed of at least one physical element. Each logical object includes object content, object type, and object coordinates. Specifically, the object coordinates of each logical object are a coordinate array used to associate the logical node with its multiple physical locations in the original document. Each entry (i.e., physical element) in the coordinate array contains the following data: Page number: The data type is an integer, used to indicate which page of the original document the physical element is located on; for example: "page": 3 means that the physical element is on page 3.

[0030] Bounding box coordinates: A quaternion integer array [x1, y1, x2, y2], used to mark the physical location area of ​​the element on the corresponding page. Here, x1 is the horizontal coordinate of the top-left corner of the bounding box (usually in pixels or points, with the origin at the top-left corner of the page); y1 is the vertical coordinate of the top-left corner of the bounding box; x2 is the horizontal coordinate of the bottom-right corner of the bounding box; and y2 is the vertical coordinate of the bottom-right corner of the bounding box. For example, "bbox": [120, 750, 580, 800] indicates that the physical element is located within a rectangular area on the page from (120, 750) to (580, 800).

[0031] Supplementary data (optional, depending on implementation needs): Page size context: e.g., "page_width": 1024, "page_height": 1448, used to accurately restore coordinate proportions at different resolutions; Physical element order identifier: e.g., "order": 1, used to mark the reading order of the physical element in a cross-page paragraph (e.g., fragments on page 3 first, fragments on page 4 last), ensuring that the front-end rendering or large model reading is spliced ​​and displayed in the correct order; Confidence: e.g., "confidence": 0.98, used to indicate the reliability of the identification and coordinate positioning of the physical element, for reference in subsequent manual review or error correction.

[0032] Step S102: In response to the user's configuration operation for the extraction template, the extraction template is invoked to extract business data from the structured logical object data to obtain structured business data.

[0033] Specifically, users can pre-configure extraction templates based on their business needs. These templates define which business data needs to be extracted from the document and how. After responding to the user's configuration, the system loads the corresponding extraction template, performs semantic extraction on the structured logical object data generated in step S101, extracts the target business data according to the extraction rules defined in the template, and assembles the extraction results into a structured data format. Because the input data has already undergone pre-processing for layout structuring, the extraction process can perceive layout features such as table row and column relationships and paragraph levels, thereby improving the accuracy of extracting complex layout content.

[0034] Step S103: In response to the user's configuration operation for the review policy, the review policy is invoked to perform a compliance review on the structured business data and obtain the review result.

[0035] Specifically, users can pre-configure review strategies based on business compliance requirements. Each review strategy contains one or more review rules, and each rule defines the fields to be validated and their corresponding review conditions. After responding to the user's configuration, the system loads the corresponding review strategy and automatically validates each item of the structured business data generated in step S102 using the review rules. The system then outputs review results including review status, a list of risk items, and suggested modifications. This process transforms compliance audits, which previously relied on manual experience, into an automated machine validation process, ensuring consistency in review standards and high execution efficiency.

[0036] Step S104: In response to the user's configuration operation for the pattern rule, invoke the pattern rule to convert the structured business data that has passed the review into standardized business data required by the downstream system.

[0037] Specifically, users can pre-configure schema rules based on the data interface requirements of downstream systems. These schema rules define conversion logic such as field mapping, data type conversion, and metadata completion. Upon responding to the user's configuration, the system loads the corresponding schema rules and converts the approved structured business data to conform to the data specifications of the downstream system. This configurable conversion mechanism eliminates data heterogeneity barriers between different systems, enabling automated connection of business data from extraction to downstream system integration.

[0038] Step S105: In response to the user's configuration operation for the filling method, the filling method is invoked to fill the standardized business data into the downstream system.

[0039] Specifically, users can pre-configure the data entry method based on the downstream system's access method, such as writing directly via API or simulating manual data entry using an RPA component. After responding to the user's configuration, the system automatically fills the standardized business data generated in step S104 into the target downstream system according to the configured data entry method, completing the fully automated processing from document parsing to data entry.

[0040] Through the above steps S101 to S105, this embodiment constructs a standardized intelligent document data processing pipeline. By decoupling document layout and business logic through a two-stage processing of layout element parsing and semantic logic reorganization, and realizing configurable response to business requirements through configurable extraction templates, review strategies, pattern rules and filling methods, it effectively solves the technical problems of difficult processing of complex documents, slow adaptation and lack of data compliance verification in business and finance scenarios.

[0041] Example 2 This embodiment provides a detailed explanation of the specific implementation of page element parsing and semantic logic reorganization in step S101.

[0042] As one implementation method, in step S101, the layout element data of the unstructured business document is obtained by parsing the layout elements, including: performing pixel-level visual analysis on the unstructured business document to identify each physical element in the unstructured business document as well as the element content, element type and element coordinates of each physical element; sorting all physical elements according to page number, vertical coordinate and horizontal coordinate, and assembling them into layout element data.

[0043] Specifically, pixel-level visual analysis refers to performing pixel-by-pixel visual analysis of a document page, identifying individual physical elements within the document through a layout analysis model. A physical element is the smallest rectangular box that encloses a complete visual unit, such as a complete text paragraph, an individual table cell, or the outline of an image, rather than a single pixel. Each physical element contains three types of attributes: element content, i.e., the specific characters, image descriptions, or formula codes identified in that area; element type, i.e., the element's physical attribute label, such as paragraph, table, image, handwriting, header, etc.; and element coordinates, i.e., the element's precise position on the original document page, typically composed of the coordinates of its four corners and its page number. After identification, the system sorts all physical elements according to page number, vertical coordinates, and horizontal coordinates, assembling them into layout element data. This sorting method ensures that the layout element data is arranged according to the natural reading order of the document, providing an ordered data foundation for subsequent semantic logic reorganization.

[0044] As one implementation method, in step S101, semantic logical reorganization and coordinate mapping restoration of the page element data are performed to obtain structured logical object data, including: performing spatial clustering analysis and semantic coherence judgment on multiple physical elements located in adjacent or the same area in the page element data, reorganizing each physical element belonging to the same cell into a logical object, and reorganizing two physical elements that are adjacent across pages and belong to the same paragraph into a logical object.

[0045] Specifically, spatial clustering analysis refers to grouping physical elements located in adjacent or identical regions based on their coordinates; semantic coherence judgment involves analyzing the semantic relationships between physical elements within a group to determine whether they belong to the same logical object. For example, in a complex table, a merged cell may contain multiple physical elements (such as multiple lines of text). The system identifies these elements as belonging to the same region through spatial clustering, and then confirms that these elements belong to the same cell through semantic coherence judgment, thereby reorganizing these elements into a single logical object. Similarly, when a paragraph spans two pages, the system identifies two adjacent and semantically coherent physical elements on both pages and reorganizes these two physical elements into a single cross-page logical object.

[0046] In practical implementation, when reorganizing various physical elements belonging to the same cell into a single logical object, the following methods can be used, but are not limited to: First, based on the element coordinates of all physical elements in the layout element data, determine the bounding rectangle of the table in the business and finance document page and all candidate physical elements located within the bounding rectangle of the table.

[0047] The system filters physical elements of type table from the page element data, detects continuous horizontal and vertical lines based on the element coordinates of each physical element of type table, fits the outer rectangle boundary of the table in the business and financial document page (i.e. the overall range of the table) based on the horizontal and vertical lines, and marks all physical elements located within the outer rectangle boundary of the table as candidate table elements.

[0048] Then, based on the bounding rectangle of the table and the element coordinates of all candidate physical elements located within the bounding rectangle of the table, the cell division result is determined; wherein, the cell division result includes the horizontal dividing axis of each row and the vertical dividing axis of each column; the horizontal dividing axis is used to define the upper and lower boundaries of the row, and the vertical dividing axis is used to define the left and right boundaries of the column.

[0049] The system extracts the vertical boundary X-axis coordinates (representing potential column boundaries) and horizontal boundary Y-axis coordinates (representing potential row boundaries) of all candidate physical elements within the bounding rectangle of the table. Through cluster analysis, it infers the theoretical table structure—that is, the maximum number of rows and columns the table should have (e.g., inferred to be 5 rows × 4 columns)—and determines the horizontal boundary axis of each row and the vertical boundary axis of each column. This theoretical table structure serves as a reference coordinate system for subsequently comparing the coordinates of the geometric center point of each candidate physical element with the horizontal boundary axis of each row and the vertical boundary axis of each column.

[0050] Specifically, the system iterates through each candidate physical element within the bounding rectangle of the table, calculates the coordinates (cx, cy) of the geometric center point of the candidate physical element, compares the Y-axis coordinate cy of the geometric center point with all horizontal dividing axes, and compares the X-axis coordinate cx of the geometric center point with all vertical dividing axes. Based on the comparison results, it determines the row and column intervals in which the candidate physical element falls, and then assigns the candidate physical element to the corresponding cell according to the row and column intervals. After summarizing, it obtains the set of candidate physical elements for each cell.

[0051] Subsequently, based on the horizontal dividing line of each row, the vertical dividing line of each column, and the element coordinates of each candidate physical element, the set of candidate physical elements for each cell is determined.

[0052] The system iterates through each candidate physical element within the bounding rectangle of the table, calculates the coordinates (cx, cy) of the geometric center point of the candidate physical element, compares the Y-axis coordinate cy of the geometric center point with all horizontal dividing axes, and compares the X-axis coordinate cx of the geometric center point with all vertical dividing axes. Based on the comparison results, it determines the row and column intervals in which the geometric center point of the candidate physical element falls. Based on the row and column intervals in which the geometric center point of the candidate physical element falls, it assigns the candidate physical element to the corresponding cell (such as the cell in the 2nd row and 3rd column), and summarizes the candidate physical elements assigned to each cell to obtain the set of candidate physical elements for each cell.

[0053] Secondly, based on the overlap of element coordinates in the candidate physical element set of each cell, the set of corresponding physical elements for each cell is determined.

[0054] For each cell, if it contains one candidate physical element, the system directly determines that candidate physical element is the unique element belonging to that cell. If the cell contains multiple candidate physical elements (common in cases of line breaks across multiple lines of text, handwritten annotations, or OCR breaking a single line of text into multiple small pieces), then a cell merging determination is initiated: vertical overlap and spatial overlap (IoU) checks are sequentially performed on the multiple candidate physical elements within the cell; where: (1) Perform a vertical overlap check on multiple candidate physical elements within the cell, specifically including the following steps: (1.1) Sort the candidate physical elements in the cell according to their Y-axis coordinates, and determine the pairing set of adjacent elements based on the sorting result. Specifically, the system obtains the set of candidate physical elements for the cell and extracts the Y-axis coordinate of each candidate physical element (i.e., the distance from the top edge of the element to the top edge of the financial document page). The system sorts all candidate physical elements in ascending order of their Y-axis coordinates to obtain the sorted sequence of candidate physical elements [E1, E2, E3, ..., E...]. n The system pairs adjacent elements in the sorted candidate physical element sequence to generate adjacent element pairing sets, such as (E1, E2), (E2, E3), ..., (E...). n-1 E n ).

[0055] (1.2) Based on the vertical overlap of the two candidate physical elements contained in each adjacent element pairing set, the system determines the complete horizontal fragment group and line break grouping of the cell. Specifically, for each adjacent element pairing (E... n-1 E nExtract the Y-axis coordinate interval [y1] of each of the two candidate physical elements contained therein. i y2 i ] and [y1 i+1 ,y2 i+1 The formula for calculating the longitudinal overlap is:

[0056] In this formula, This is the length of the intersection of two candidate physical elements on the Y-axis; if there is no intersection, it is set to 0. Let be the length of the union of the two candidate physical elements on the Y-axis. The value range is [0, 1].

[0057] The system will calculate the longitudinal overlap. Compare with a first preset overlap threshold (e.g., 50%): like If the two candidate physical elements in the adjacent pair are located in the same horizontal band (row), they are marked as a horizontal fragment group.

[0058] like Then, further check whether the two candidate physical elements in the adjacent pair are vertically connected and horizontally left-aligned: if the Y-axis coordinate y2 of the bottom of the previous candidate physical element is... i The Y-coordinate y1 of the top of the next candidate physical element is less than i+1 (i.e., not overlapping vertically), and the left edge of both has a x-axis coordinate of x1. i With x1 i+1 If the difference is less than the dynamic line height threshold (such as a set multiple of the average or median line height of the candidate physical elements in the cell, such as 1.2 times), then the two candidate physical elements in the adjacent pair are determined to be line break text in the same cell and are marked as line break group.

[0059] The system clusters all horizontal fragment groups and all line break groups according to their adjacency relationship, thus obtaining the complete horizontal fragment groups and line break groups within the cell.

[0060] (1.3) Based on the complete horizontal fragment groups and line break groups within the cell, determine the merged inline complete text. Specifically, for each horizontal fragment group, the system sorts the candidate physical elements within the group from smallest to largest according to the X-axis coordinate (left edge x1), and concatenates the text content of each candidate physical element in the sorted order to generate the inline complete text. For each line break group, the system sorts the candidate physical elements within the group from smallest to largest according to the Y-axis coordinate (top y1), concatenates the text content of each candidate physical element in the sorted order, and inserts a line break character at the concatenation point to generate multi-line complete text. The system uses the inline complete text and multi-line complete text obtained above as the logical text of the cell.

[0061] (2) Perform spatial overlap checks on multiple candidate physical elements within the cell, specifically including the following steps: (2.1) Based on the X-axis and Y-axis coordinate ranges of each candidate physical element within the cell (i.e., each candidate physical element contained in the logical text obtained after vertical overlap check), determine the combinations of candidate physical elements that have vertical positional overlap. Specifically, the system pairs each candidate physical element in the candidate physical element set to generate a preliminary selection of physical element combinations (E). i E j The system performs a pre-screening process for each initially selected physical element combination: it checks whether the X-axis coordinate intervals and Y-axis coordinate intervals of the two candidate physical elements in the initially selected physical element combination intersect, i.e., max(x1) = 0. i , x1 j ) <min(x2 i , x2 j And max(y1) i y1 j ) <min(y2 i y2 j If the X-axis coordinate interval or the Y-axis coordinate interval does not intersect, it is determined that the initially selected physical element combination does not have redundant overlap; if both the X-axis coordinate interval and the Y-axis coordinate interval intersect, the initially selected physical element combination is retained as a candidate physical element combination with a vertical position.

[0062] (2.2) Based on the spatial overlap of two candidate physical elements in a candidate physical element combination with a vertical position, the redundant overlapping physical element combination is determined. Specifically, for each candidate physical element combination with a vertical position, the system calculates the spatial overlap of two candidate physical elements in that combination.

[0063] First, calculate the intersection area of ​​the minimum bounding rectangles of the two candidate physics elements. :

[0064] Then calculate the union area of ​​the minimum bounding rectangles of the two candidate physical elements. :

[0065] Finally, calculate the spatial overlap: The value range is [0, 1].

[0066] The system compares the calculated spatial overlap with a preset redundancy threshold (>80%): If IoU > preset redundancy threshold, then the two candidate physical elements in the candidate physical element combination are determined to be redundant overlapping elements (for example, the printed and handwritten versions of the same character are identified as two independent elements), and are marked as a redundant overlapping physical element combination.

[0067] If IoU ≤ preset redundancy threshold, then the two candidate physical elements in the candidate physical element combination are determined not to be redundant overlapping elements, and both candidate physical elements in the candidate physical element combination are retained as independent physical elements.

[0068] (2.3) Based on the redundant overlapping physical element combinations and the confidence level of each candidate physical element in the redundant overlapping physical element combination obtained synchronously during page element parsing, a set of related physical elements after removing redundancy is obtained. Specifically, if the text content of two candidate physical elements in the redundant overlapping physical element combination is the same, the candidate physical element with higher confidence is retained, and the candidate physical element with lower confidence is removed; if the text content of two candidate physical elements in the redundant overlapping physical element combination is inconsistent (there may be true overlap rather than redundancy), no removal is performed, and the redundant overlapping physical element combination is marked as awaiting manual confirmation and pushed for review in the subsequent review stage; if the confidence level is unavailable, the candidate physical element with larger physical size (area) is retained, and the candidate physical element with smaller physical size is removed (usually printed text is more complete and has a larger area than handwritten text). The system uses the set of candidate physical elements after removing redundancy as the set of related physical elements of the cell.

[0069] Finally, the sets of physical elements belonging to each cell are merged to obtain the corresponding cell logical object. Based on the coordinate range of the sets of physical elements belonging to each cell and the occupancy of adjacent cells, the merging attribute (colspan / rowspan) of each cell logical object is determined.

[0070] For each cell logical object, the system calculates the actual coordinate range of that cell logical object (taking the bounding rectangle of the union of the coordinates of all elements belonging to the same physical element).

[0071] The system compares the actual coordinate range of a cell's logical object with the horizontal dividing lines of each row and the vertical dividing lines of each column to determine the right boundary merging attribute `colspan` and the bottom boundary merging attribute `rowspan`. Specifically, the system counts the number of vertical dividing lines crossed by the right boundary of the cell's logical object; this number represents the number of columns covered by the cell, and this number is used as the value of `colspan`. Similarly, the system counts the number of horizontal dividing lines crossed by the bottom boundary and uses this number as the value of `rowspan`. For example, if the right boundary crosses the first and second vertical dividing lines, then `colspan = 2`, meaning the cell occupies the width of two columns.

[0072] The system writes the merged complete text content, merged attributes (colspan / rowspan), and the outer rectangle coordinates (i.e., the actual coordinate range) of the cell logical object as the final structured data of the cell logical object into a table matrix structure in JSON, thus completing the accurate identification from physical elements to semantically complete cell logical objects (i.e., logical objects).

[0073] In practical implementation, when recombining two physical elements that are adjacent across pages and belong to the same paragraph into a single logical object, the following methods can be used, but are not limited to: First, multidimensional distance weights are calculated based on the element coordinates of cross-page candidate physical element pairs; where each cross-page candidate physical element pair includes a candidate physical element located at the bottom of the previous page and a candidate physical element located at the top of the next page.

[0074] After grouping all physical elements in the layout element data by page number, the system filters out candidate physical elements located at the bottom of the previous page (e.g., Y-axis coordinate greater than 70% of page height) and candidate physical elements located at the top of the next page (e.g., Y-axis coordinate less than 30% of page height), and constructs a set of cross-page candidate physical element pairs.

[0075] For each pair of candidate physical elements spanning multiple pages, the system calculates the Y-axis vertical distance weight, the X-axis horizontal alignment weight, and the category space affiliation weight. Based on these weights, a multi-dimensional distance weight is then calculated; where: Y-axis vertical distance weight: Calculate the net vertical distance between the Y-axis coordinates of candidate physical elements in the bottom region of the previous page and the Y-axis coordinates of candidate physical elements in the top region of the next page. The smaller the net vertical distance, the higher the Y-axis vertical distance weight. Based on the net vertical distance, an exponential decay function is used to calculate the Y-axis vertical distance weight; where: The formula for calculating the vertical clearance is:

[0076] In this formula, The bottom Y-coordinate of the candidate physical elements in the bottom area of ​​the previous page (i.e. ); The top Y-coordinate of the candidate physical elements in the top area of ​​the next page (i.e. ); For the height of the business and financial document page, The units of the coordinates must be consistent with the units of the element coordinates. If the element coordinates use normalized values, then... Set to 1; if element coordinates are in pixel values, then The pixel height of the business and finance document page.

[0077] The formula for calculating the weight of the Y-axis vertical distance is:

[0078] In this formula, Weighted by the vertical distance along the Y-axis; The vertical net spacing between the Y-axis coordinates of the candidate physical elements in the bottom area of ​​the previous page and the Y-axis coordinates of the candidate physical elements in the top area of ​​the next page. This is the attenuation coefficient, a hyperparameter used to control how the weight of the Y-axis vertical distance decreases as the net vertical spacing increases. When the element coordinate unit is pixels, the default value is [value to be filled in]. .

[0079] X-axis horizontal alignment weight: Calculate the horizontal overlap (intersection width divided by union width) between candidate physical elements in the bottom region of the previous page and candidate physical elements in the top region of the next page along the X-axis. The higher the horizontal overlap, the higher the X-axis horizontal alignment weight. The X-axis horizontal alignment weight is calculated based on the horizontal overlap. Where: The formula for calculating lateral overlap is:

[0080] In this formula, Horizontal overlap; The left edge X-axis coordinate (distance from the left edge of the page) of the candidate physical element in the bottom area of ​​the previous page. The X-axis coordinate of the right edge of the candidate physical element in the bottom area of ​​the previous page (distance from the right edge of the page); The left edge X-axis coordinate of the candidate physical element in the top area of ​​the next page; The right edge X-axis coordinate of the candidate physical element in the top area of ​​the next page; This represents the width of the intersection of two candidate physical elements on the X-axis; if there is no intersection, it is set to 0. The width of the union of the two candidate physical elements on the X-axis.

[0081] The formula for calculating the X-axis horizontal alignment weight is:

[0082] In this formula, The horizontal alignment weight on the X-axis; Horizontal overlap; This is the enhancement factor (default value is 2.0~3.0), used to increase the weight value when the horizontal overlap is high, and amplify the alignment difference.

[0083] Category space allocation weight Based on the X-axis coordinate distribution of all physical elements on the previous page, a clustering algorithm (such as K-Means or density-based clustering) is used to identify the column structure of the previous page (e.g., the center interval of the left column and the center interval of the right column). Similarly, based on the X-axis coordinate distribution of all physical elements on the next page, a clustering algorithm (such as K-Means or density-based clustering) is used to identify the column structure of the next page (e.g., the center interval of the left column and the center interval of the right column). The X-axis coordinates of the center points of candidate physical elements in the bottom area of ​​the previous page are also used. ) and the X-axis coordinates of the center point of the candidate physical element in the top area of ​​the next page ( Based on the X-axis coordinate range of the category they fall into on their respective pages, determine whether candidate physical elements in the bottom area of ​​the previous page and candidate physical elements in the top area of ​​the next page belong to the same category. Specifically, if the horizontal overlap in the projection of the X-axis coordinate range of the center point of the candidate physical element in the bottom area of ​​the previous page within the X-axis coordinate range of the category it falls into, and the X-axis overlap of the center point of the candidate physical element in the top area of ​​the next page within the X-axis coordinate range of the category it falls into, is greater than a second preset overlap threshold (i.e., IoU > second preset overlap threshold, such as 0.5), then the candidate physical elements in the bottom area of ​​the previous page and candidate physical elements in the top area of ​​the next page are determined to belong to the same category; otherwise, they are determined not to belong to the same category. If they belong to the same category, the category space is assigned a weight. Set the baseline value for no category isolation penalty, i.e., the first value (e.g., 1.0); if they belong to different categories, then assign the category space to a weight. Set the second value (e.g., 0.3) to apply the column isolation penalty factor to significantly reduce the probability of cross-column merging; where the second value is less than the first value.

[0084] The formula for calculating the multidimensional distance weights is:

[0085] In this formula, The preset weight coefficients, with a sum of 1, are used to control the weight of the vertical distance along the Y-axis. X-axis horizontal alignment weight Weighting of column space The relative importance in the judgment, preferably, In other words, vertical distance and column allocation play a decisive role, while X-axis alignment serves as supplementary evidence.

[0086] Then, the merged confidence score is determined based on the multidimensional distance weights and semantic anchors of cross-page candidate physical element pairs.

[0087] The system extracts the last N characters (e.g., the last 50 characters) of candidate physical elements in the bottom area of ​​the previous page and the first N characters (e.g., the first 50 characters) of candidate physical elements in the top area of ​​the next page to construct a semantic continuity feature set. Based on a semantic continuity feature set, the system detects whether there is a semantic break between the last text of candidate physical elements in the bottom region of the previous page and the first text of candidate physical elements in the top region of the next page, and marks semantic anchor points accordingly. If the text at the end of the candidate physical element in the bottom area of ​​the previous page has no period or no paragraph end mark, and the text at the beginning of the candidate physical element in the top area of ​​the next page has no uppercase start (English text) or no connecting words / grammatically continues the preceding text (Chinese text), then it is determined that there is no semantic break, and the semantic anchor is marked as "strong association". If the text at the end of a candidate physical element in the bottom area of ​​the previous page has a period, or the text at the beginning of a candidate physical element in the top area of ​​the next page is a new topic keyword, then a semantic break is determined, and the semantic anchor is marked as "weakly related" or "unrelated".

[0088] The system employs the following encoding strategy to encode semantic anchors into semantic anchor weights; wherein the encoding strategy includes: The system detects the last text of candidate physical elements in the bottom area of ​​the previous page and the first text of candidate physical elements in the top area of ​​the next page, determining the sentence completeness of the last text, the capitalization / lowercase status of the first paragraph of the first text, and the continuity of core entity words; among which: Sentence completeness The detection logic is as follows: It determines whether the text ends with a period, question mark, exclamation mark, or English period; if it ends with a terminating punctuation mark (indicating a natural end to the sentence), then... If it ends with a comma, hyphen, or no punctuation (indicating a break in meaning), then Sentence completeness as the most important indicator: The terms of finance-business contracts are relatively long. If the end of the previous page is already a period, in most cases a new sentence starts, cross-page merging shall not be performed, and the highest weight is assigned to ensure interception.

[0089] Uppercase / lowercase status of paragraph start detection logic: Determine whether the first character of the opening text is a lowercase letter (for English documents) or a transitional conjunction (for Chinese documents, such as "furthermore", "and"); if it is a lowercase letter or a transitional conjunction (indicating that the sentence is incomplete and to be continued), then ; if it is an uppercase letter or a new subject (indicating the start of a new sentence), then . The uppercase / lowercase status of paragraph start serves as an auxiliary supporting indicator for processing mixed Chinese-English documents. A lowercase start strongly implies that the content is truncated in the middle, and its weight is lower than that of sentence completeness.

[0090] Core entity word continuity detection logic: Call a lightweight NER (Named Entity Recognition) to extract the last entity word at the end of the ending text (such as "contract", "Party A", "amount") and the first entity word at the start of the opening text; if the first entity word at the start of the opening text and the last entity word at the end of the ending text form a continuity relationship (for example, the last entity word at the end of the ending text is "legal person" and the first entity word at the start of the opening text is "representative", the two form "legal representative"), then ; if there is no any continuity relationship, then . If no entity word is identified in the ending text or the opening text, then , it means there is a lack of evidence for entity word continuity, and no semantic association weight is contributed. Core entity word continuity serves as a false judgment prevention guarantee indicator. When the text spans clause numbers (such as "Article 1" and "(1)"), the entity word continuity can effectively identify items that are structurally independent but semantically belong to the same list item, with a weight second only to sentence completeness.

[0091] The system performs weighted summation on the sentence completeness, the uppercase / lowercase status of the paragraph start of the opening text, and the core entity word continuity to obtain a semantic anchor weight , so as to compress multi-dimensional semantic features into a single weight value, and the calculation formula is as follows:

[0092] In this formula, are preset weight coefficients with a sum of 1, for example, .

[0093] The system inputs the multi-dimensional distance weight and the semantic anchor weight together into a merging decision model to calculate a comprehensive merging confidence score Where γ and δ are preset weighting coefficients, satisfying γ + δ = 1. The confidence scores are combined and range from [0,1].

[0094] Secondly, the merging result of cross-page candidate physical element pairs is determined based on the comprehensive merging confidence score.

[0095] The system will compare the combined confidence score with a first preset confidence threshold (e.g., 0.85) and a second preset confidence threshold (which is less than the first preset confidence threshold, e.g., 0.50): If the overall confidence score is greater than or equal to the first preset confidence threshold, the system determines that the cross-page candidate physical element pair belongs to the same logical paragraph, automatically performs merging, and generates a single logical object. The coordinate array of this logical object contains the element coordinates of the two candidate physical elements. If the second preset reliability threshold ≤ the overall merged confidence score < the first preset reliability threshold, the system determines that it needs to be manually confirmed, generates a merge suggestion but does not automatically execute the merge, and pushes it to the review results for priority review; If the overall confidence score is less than the second preset confidence threshold, the system determines that the cross-page candidate physical element belongs to different logical paragraphs, does not perform merging, and retains them as two independent logical objects.

[0096] Based on the above judgment results, the system updates the structured logical object data: cross-page paragraph logical objects are generated based on merged cross-page candidate physical element pairs, while unmerged cross-page candidate physical element pairs retain independent paragraph logical objects. All merging suggestions for cross-page candidate physical element pairs determined to require manual confirmation, along with their corresponding confidence scores, coordinate multidimensional distance weights, and semantic anchor weights, are written into the review record for users to review and confirm or reject merging suggestions on the review interface.

[0097] Furthermore, for each reorganized logical object, if the logical object consists of a single physical element, the element coordinates of the physical element are used as the object coordinates of the logical object; if the logical object consists of at least two physical elements, a coordinate array is generated based on the element coordinates of each physical element and used as the object coordinates of the logical object; wherein, the coordinate array contains the element coordinates of each physical element. Specifically, the coordinate mapping and restoration process of the logical object is the coordinate inheritance and aggregation calculation process: For 1-to-1 mapping (ordinary paragraph / ordinary cell): the element coordinate pointer of the physical element is directly assigned to the object coordinates of the newly generated logical object. For N-to-1 mapping (spanning paragraph / merged cell): a coordinate array mapping is established, the object coordinates of the logical object point to a coordinate array, the coordinate array contains the element coordinates of all physical elements that make up the logical object and the calculated bounding rectangle coordinates [X1, Y1, X2, Y2] of the logical object, used to associate a logical object with its multiple physical locations in the original document. In other words, for logical objects with a one-to-one mapping, the element coordinates of the physical elements are directly inherited; for logical objects with a many-to-one mapping (such as paragraphs spanning multiple pages or merged cells), the system creates a coordinate array, aggregates the element coordinates of all physical elements (i.e., sub-fragments), and calculates the coordinates of the outer rectangle as the default display coordinates. This coordinate mapping restoration mechanism ensures that each logical object retains a precise correspondence with the physical location of the original document.

[0098] All reorganized logical objects are sorted by page number, vertical coordinate, and horizontal coordinate, and assembled into a hierarchical tree structure of structured logical object data. Each logical object in this structured data contains object content, object type, and object coordinates. Specifically, the hierarchical tree structure reflects the logical hierarchy of the document; for example, a document may contain multiple pages, each page may contain multiple paragraphs and tables, and each table may contain multiple cells. Each logical object contains three types of attributes: object content (addressing "what it says"), object type (addressing "what it is"), and object coordinates (addressing "where the original text is located"). This structured data organization allows subsequent extraction and review operations to accurately perceive the document's logical structure, significantly improving the processing capabilities for complex document layouts.

[0099] Example 3 This embodiment provides a detailed description of the specific implementation methods of template extraction in step S102 and review strategy in step S103.

[0100] As one implementation method, the extraction template includes prompt words and / or a list of fields; in step S102, the extraction template is called to extract business data from the structured logical object data to obtain structured business data, including: extracting candidate logical objects from the structured logical object data according to the prompt words and / or the list of fields; after semantically extracting business data from each candidate logical object, assembling the business data into a JSON structure to form structured business data.

[0101] Specifically, the extraction template includes a prompt word mode and / or a field list mode. In prompt word mode, users describe the information they need to extract using natural language, such as "extract payment terms and penalty rates from the contract." The system utilizes the semantic understanding capabilities of a large language model to match relevant logical objects within the structured logical object data. In field list mode, users define standard field names and their corresponding data types, such as "contract total," "signing date," and "supplier name," guiding the system to perform precise key-value pair extraction. Both modes can be used individually or in combination, suitable for business documents with varying degrees of structure. After extracting candidate logical objects, the system performs semantic extraction on each object, extracting specific business data values, and assembles all business data into a JSON structure, forming structured business data. This JSON format output facilitates subsequent processing and data exchange between systems.

[0102] It should be noted that the following methods can be used, but are not limited to, when generating the extraction template: First, the complete set of fields and inheritance relationships are determined based on the base template configuration.

[0103] In response to the user's creation of a base template, the system receives a set of common core fields for the user-defined business scenario (including field names, field descriptions, data types, and sample values), generates a unique identifier for the base template, and stores the base template field set as "complete field configuration".

[0104] In response to the user's operation of creating a sub-template and selecting the inheritance source, the system receives the inheritance relationship flag of which base template the user specifies to inherit from, and copies the complete field configuration of the base template to the "inheritance field pool" of the sub-template.

[0105] The system records the inheritance relationship mapping table between the base template and the child template (base template ID → list of child template IDs), and marks each child template with an "inheritance version number" (recording the version of the base template it currently inherits), and outputs a template configuration data structure containing the inheritance relationship.

[0106] Then, the complete configuration of the sub-template is determined based on the inheritance relationship mapping table and the sub-template difference field.

[0107] The system responds to the user's operation of adding or deleting differential fields in the sub-template, receives the scenario-specific fields (differential fields) configured by the user, and stores the differential fields as the "differential field pool" of the sub-template.

[0108] When loading a sub-template, the system automatically performs a merging operation of the "inherited field pool + differential field pool": if the differential field and the inherited field have no conflict, they are merged directly to generate the complete field configuration of the sub-template; if the differential field and the inherited field have the same name, the differential field overrides the inherited field, so that the sub-template overrides the base template configuration.

[0109] The system binds the merged complete field configuration to the sub-template ID, stores it in the template library for subsequent step S2 to call, and outputs the complete sub-template configuration that can be directly used for intelligent extraction.

[0110] Finally, the sub-template synchronization result is determined based on the base template change type and propagation strategy.

[0111] When the system detects that the configuration of a base template field has been modified (such as field description optimization or data type adjustment), it determines the type of the change (adding a field / deleting a field / modifying a field attribute) and obtains the inheritance relationship mapping of all sub-templates of that base template.

[0112] The system performs corresponding synchronization operations according to the propagation strategy: If the user selects the "Affect only the new version" mode, the system generates a new version number for the base template, and the published sub-templates continue to be bound to the old version base template, while newly created sub-templates are bound to the new version base template; If the user selects the "Synchronize and update all sub-templates" mode, the system iterates through all sub-templates that inherit from the base template and performs differential merging operations on each sub-template: newly added fields are automatically added, deleted fields are removed from the inheritance pool, and modified field attributes are updated while retaining the original differential overlay of the sub-template.

[0113] The system generates a synchronization operation log, recording the differences in fields before and after the update of each affected sub-template, and outputs a synchronization result report after the update is completed, including a list of sub-templates that were successfully updated and items that require manual intervention.

[0114] As one implementation method, the review strategy includes at least one review rule, and each review rule is associated with a review field and a review condition. In step S103, the review strategy is invoked to perform a compliance review on the structured business data to obtain the review result, including: matching each business field in the structured business data with each review rule in the review strategy to determine the mapping relationship between the business field and the review condition; performing a compliance review on each business field according to the review mode of each review rule and the mapping relationship between the business field and the review condition; assembling the compliance review result of each business field into a JSON structure to form the review result; wherein, the review result includes the review status of review passed or failed, a list of risk items, and modification suggestions.

[0115] Specifically, the review strategy is an ordered set of multiple review rules, each defining the business fields to be verified and their corresponding review conditions. For example, for the review rule on "contract amount reconciliation," the associated review fields are "total contract amount" and "amount of each item," and the review condition is "the total contract amount equals the sum of the amounts of each item." When performing the review, the system first matches each business field in the structured business data with the review rules to establish a mapping relationship between business fields and review conditions. Then, it executes the corresponding verification logic according to the review mode of each rule. The review mode can include rule-based deterministic verification (i.e., script mode) and large-model-based semantic analysis (i.e., instruction mode). Finally, all verification results are assembled into a JSON-structured review result, which includes the review status (passed or failed), a list of detected risk items, and modification suggestions for each risk item. This structured review result output provides a clear decision-making basis for subsequent risk handling and data correction.

[0116] Specifically, based on the review mode (instruction mode or script mode) of each review rule, the following validations are performed on the values ​​of each business field in the structured business data: Command pattern: Feed field values ​​and review conditions into the large model for semantic judgment (e.g., "Check whether the contract amount exceeds the department budget threshold"). Script mode: Execute a Python script with field values ​​as input parameters to perform precise mathematical or business logic operations (e.g., "Total amount = Item 1 + Item 2").

[0117] Next, the execution outputs of all review rules are aggregated and assembled into structured JSON, outputting the review results, including the overall status of review pass / fail, a list of risk items, and corresponding modification suggestions. Specifically, when the review strategy contains at least two review rules, the execution outputs of each review rule are aggregated and assembled into the review results; if any review rule in the review strategy is determined to be a major risk, the overall review status is fail; if only general risks exist and no major risks exist, the overall review status is pass but carries a risk label; if none of the review rules trigger risks, the overall review status is pass. The risk item list in the review results includes all risk items corresponding to the triggered review rules; the modification suggestions include modification opinions for the configuration of each review rule and / or natural language suggestions generated by the large model.

[0118] In another implementation, when invoking the review policy to conduct a compliance review of structured business data and obtaining the review results, the following methods may be used, but are not limited to: First, a task decomposition scheme for review is determined based on document type and business scenario.

[0119] During the page element parsing phase, the system determines the business scenario type of the current document based on the document type tags (contract / invoice / expense report, etc.) in the parsing results. If the type recognition confidence level is below a threshold, the user can manually select and confirm.

[0120] The system loads a pre-set review task template library and matches the corresponding review task decomposition scheme according to the document type. For example, contract documents are decomposed into sub-tasks such as clause integrity review, amount verification review, signature compliance review, timeliness review, and counterparty qualification review; invoice documents are decomposed into sub-tasks such as invoice element integrity review, invoice authenticity verification, invoice deduplication review, and tax calculation review.

[0121] The system assigns the required agent role (term reviewer / amount reviewer / compliance reviewer, etc.) to each subtask, generates a subtask-agent allocation plan, and outputs a task decomposition scheme.

[0122] Then, the instantiation review rule set is determined based on the sub-task and the agent role.

[0123] The system loads a corresponding basic rule template library for each agent based on the agent role matched for each subtask (such as the "Amount Reviewer" template library containing basic rule templates such as "Total Amount = Sum of Items" and "Tax Included = Tax Excluded + Tax Amount").

[0124] Each agent injects the structured business data field values ​​corresponding to its assigned subtasks into the basic rule template, replaces the placeholders in the template with the actual field values, and generates instantiated review rules (e.g., after injecting the actual values ​​into the "Total Amount = Sum of Items" template, it generates "1,200,000.00 = 600,000.00 + 600,000.00").

[0125] Each agent independently executes the instantiation review rules, outputs its own subset of review opinions (including violations, risk levels, and modification suggestions), and records the rule template ID and instantiation parameters called in this review for subsequent auditing and tracing.

[0126] Finally, the final review result is determined based on a subset of the multi-agent review opinions.

[0127] The master agent collects a subset of review opinions returned by each agent role and performs conflict detection on each review conclusion—checking whether the same logical node (such as the same contract clause) receives conflicting review conclusions under different subtasks.

[0128] The master control agent adjudicates detected conflicting conclusions by selecting the winning conclusion according to a preset priority strategy (compliance over standardization, security over usability). For complex conflicts that cannot be automatically adjudicated (such as a violation judgment in the amount review, or a pass judgment in the format review, even though both are based on reasonable grounds), the master control agent generates a conflict adjudication pending and marks it as "awaiting manual comprehensive judgment" in the review results.

[0129] The master control agent sorts and summarizes the review opinions of each subtask, the conflict resolution results, and the manual to-do items according to risk level, and generates a comprehensive review report containing a list of issues, compliance conclusions, modification suggestions, and traceability information of the agent's review chain, which serves as the review result.

[0130] As one implementation method, after invoking the review strategy to conduct a compliance review of the structured business data and obtaining the review results, the review results can be displayed in columns or in a floating format. For example, unstructured business and financial documents can be displayed in the first area of ​​the display interface (such as the left area), and the review results can be displayed simultaneously in the second area of ​​the display interface (such as the right area). Alternatively, the review results can be displayed in a floating window above the display area of ​​the unstructured business and financial documents. Furthermore, in response to the user's click operation on a risk item in the review results, based on the element coordinates of the risk item in the unstructured business and financial documents parsed in step S101, the system jumps to the corresponding position in the unstructured business and financial documents to display the risk level and modification suggestions for the risk item.

[0131] Specifically, this interactive linkage positioning mechanism relies on the high-precision spatial metadata retained in the structured logical object data generated in step S101. When the review results are output, each risk item not only carries the risk analysis text and modification suggestions, but also links to the coordinate information of the corresponding original text element in the structured logical object data through fields. In the front-end display interface, the system simultaneously presents the review result list and the original document preview view using a column or floating layer layout. When a user clicks on a risk item in the result list, the front-end interaction engine captures the click event, parses the associated coordinate parameters, and performs a view transformation operation accordingly: if the risk is located on a currently invisible page, the system automatically scrolls the original document preview view to the target page number; subsequently, based on the element coordinates, it calculates the pixel-level area on the document rendering layer, draws a highlighted border or a semi-transparent mask, accurately covering the corresponding text paragraph, table cell, or handwritten annotation area. Simultaneously, the system displays the risk level and modification suggestions for the risk item, enabling users to quickly understand the severity of the risk and take appropriate corrective measures. This mechanism anchors abstract review conclusions back to original vouchers in real time, constructing a two-way verification loop of data and vision, significantly shortening the cognitive path and operational time from discovering a problem to confirming it.

[0132] Example 4 This embodiment provides a detailed explanation of the specific implementation methods for standardized business data conversion and downstream system population.

[0133] As one implementation method, the schema rule is a rule that includes target field mapping rules, data type conversion rules, and mandatory metadata completion rules. In step S104, the schema rule is invoked to convert the structured business data that has passed the review into standardized business data required by the downstream system. This includes: for each business field in the structured business data, according to the target field mapping rules, data type conversion rules, and mandatory metadata completion rules, the business field is mapped to the target field, converted to the data type, and completed with mandatory metadata to obtain a standardized business field; all standardized business fields are assembled into a standard message format required by the downstream system to form standardized business data.

[0134] Specifically, the target field mapping rules define the correspondence between the extracted business fields and the target fields of the downstream system. For example, the extracted "total contract amount" field is mapped to the "contract_amount" field of the downstream system. The data type conversion rules define the format conversion logic of field values. For example, "March 15, 2024" is converted to the standard date format "2024-03-15", or "One Million Yuan" is converted to the numeric format "1000000.00". The required metadata completion rules define the fields required by the downstream system but which may be missing in the extraction results, as well as their default values ​​or generation logic. For example, metadata fields such as "data source" and "processing timestamp" are automatically added. The system performs the above three conversions on each business field in sequence, and finally assembles all standardized business fields into the standard message format required by the downstream system, such as JSON or XML messages that conform to specific API interface specifications. This configurable conversion mechanism allows the same set of extraction results to adapt to the data interface requirements of different downstream systems without the need to develop conversion code separately for each downstream system.

[0135] It should be noted that the following methods can be used, but are not limited to, when generating pattern rules: First, a draft of the schema rules is determined based on the downstream system identifier or API documentation.

[0136] The system responds to user actions such as uploading API documentation (OpenAPI / Swagger format) or entering the name of the downstream system (e.g., "SAP ERP" or "Oracle Financial System") in the downstream system configuration interface by reading the system's pre-built downstream system knowledge base (containing common field structures of mainstream business and financial systems).

[0137] If a pre-set template is available, the system directly calls the corresponding schema template; if no pre-set template is available, the system parses the API document uploaded by the user, extracts all fields in the interface definition (field name, data type, required attributes, maximum length, enumeration value list), and calls the large model to identify the business semantics of each field (such as determining whether Contract_Total_Amount corresponds to "total contract amount" and Vendor_ID corresponds to "supplier code").

[0138] The system categorizes the parsed fields according to business semantics (amount / date / encoding / description), generates a complete initial draft of the schema rules, including a field mapping table (target field name → business semantic description), data type constraints, and required field tags, and outputs a schema draft for user editing and confirmation.

[0139] Then, based on the extracted template field list and schema field list, the recommended field mapping is determined.

[0140] The system obtains the field list (source field name, field description, data type) of the configured extraction template and the target field list (target field name, business semantics, data type) of the generated schema.

[0141] The system uses an embedding model to map the source field name + field description and the target field name + business semantics into vectors, and calculates the cosine similarity between them. When the description vector of the source field total_amount is closest to the semantic vector of the target field Contract_Total_Amount, the system automatically recommends that mapping relationship.

[0142] The system marks all recommended mapping relationships with similarity below a threshold (e.g., 0.7) as "requiring manual confirmation", displays the mapping recommendation results in descending order of similarity, and outputs a draft of data transformation rules containing recommended mapping relationships and mapping items to be confirmed.

[0143] Finally, the schema rules are dynamically updated based on the user's natural language instructions.

[0144] The system provides a natural language command input box in the schema configuration interface, allowing users to describe mapping requirements in Chinese (e.g., "Map the 'total amount' in the contract to the 'total contract amount' in the ERP, keeping two decimal places, and filling in 0 if it is empty").

[0145] The system calls the large model to parse the user's natural language instructions, extracting key elements from the instructions: source field name ("total amount"), target field name ("contract total amount"), format requirements ("retain two decimal places"), and default value ("0"). The parsing results are then mapped to the corresponding schema rule configuration operations.

[0146] The system automatically updates the schema rule entries based on the parsing results: if the target field already exists, the new rule overwrites it; if the target field does not exist, a new field mapping rule is added. After the update is complete, the system displays a comparison of the rules before and after the change to the user. After the user confirms, the update is saved, and the final schema rules are output.

[0147] Furthermore, after converting the structured business data that passed the review into standardized business data required by the downstream system, the pre-configured filling method can be invoked to fill the standardized business data into the downstream system, and the status receipt returned by the downstream system for the standardized business data can be received. If the status receipt indicates that the standardized business data filling was successful, the status receipt is written back and associated with the full-process processing record of the unstructured business and financial document. If the status receipt indicates that the standardized business data filling failed, an exception log is generated and an exception handling operation is triggered. The exception handling operation includes: generating a visual to-do order and pushing it to the user; responding to the user's repair operation for the visual to-do order, refilling the repaired standardized business data into the downstream system; when the new status receipt returned by the downstream system indicates that the repaired standardized business data filling was successful, the new status receipt is written back and associated with the full-process processing record of the unstructured business and financial document. The repair operation includes at least one of the following: the user corrects the field values ​​in the standardized business data; the user adjusts the data mapping rules and regenerates the standardized business data; the user completes the missing required metadata.

[0148] Specifically, a status receipt is feedback information from the downstream system regarding the data population result, typically including a status indicator indicating success or failure, along with a related error description. The status receipt can be a communication layer receipt, an application layer receipt, or a logic layer receipt. The system determines whether population failure occurred through the following three layers of logic: triggering any one of these logics indicates failure, while failure to trigger any of the three logics indicates success. Communication layer receipts indicate communication layer anomalies (physical disconnection): HTTP requests throw timeout exceptions (e.g., no response after 5 seconds), connection refused (downstream IP is unreachable), SSL certificate verification fails.

[0149] Application layer receipts indicate explicit application layer failure (business error): The downstream system interface returned an HTTP 200 response body normally, but the business status code in the response body is not "Success", but {"code": "ERR_001", "msg": "Cost center does not exist"}.

[0150] The logic layer receipt indicates a hidden failure at the logic layer (data not written to the database): the downstream system interface returns "successful creation", but the format of the returned document number does not meet expectations (e.g., it should be an 18-digit number, but an empty string or garbled characters are returned). The system judges it as "suspected failure" and handles it as a failure to ensure absolute data security.

[0151] When the system receives a status receipt indicating successful data entry (i.e., a communication layer receipt indicating normal communication, an application layer receipt indicating explicit application layer success, and a logic layer receipt indicating implicit logic layer success), the receipt is associated with the entire processing record of the original unstructured business and financial document to form a complete processing trajectory from document upload to data entry, facilitating subsequent auditing and traceability.

[0152] When the system receives a status receipt confirming a data population failure, it first generates an exception log recording detailed information about the failure, including the failure time, cause, and affected data fields. Then, it triggers an exception handling operation, generating a visual work order and pushing it to the relevant user. The work order contains a detailed description of the failure cause and the data items to be repaired. After viewing the failure information on the work order interface, the user can repair the abnormal data. The system responds to the user's repair operation by repopulating the standardized business data into the downstream system. When the downstream system returns a new status receipt confirming successful data population, the system writes the new status receipt back and associates it with the end-to-end processing record, completing the closed loop of exception handling. This mechanism ensures the eventual consistency of data population and allows for self-healing even in the event of temporary failures through an automated exception handling process. The end-to-end processing record refers to the record of task instances throughout the entire processing flow. In practical applications, when a business and financial document enters the system, the system generates a unique task ID for it. This task ID is associated with end-to-end processing data, such as physical element data obtained through layout element parsing, business fields extracted through Prompt / field patterns, review results obtained through compliance review, target APIs called by downstream systems during population, and the schema rules used. When writing back the new status receipt and associating it with the end-to-end processing record, the system can use, but is not limited to, the following methods: Based on the task ID, the system adds or updates three fields in its corresponding data record row: downstream document number, push timestamp, and status code, thereby completing the writing back and association of the new status receipt.

[0153] Specifically, the data processing process of populating the structured business data that has passed the review into the downstream system includes the following four consecutive stages: Phase 1: Routing decisions based on review results.

[0154] Before performing the data entry, the system analyzes the review results and makes logical decisions: If a major risk is triggered, the system blocks the process, does not perform any data entry, immediately generates an alarm, and pushes the pending task to manual review; if the risk is general or fully compliant, the system determines that the data quality meets the standards, automatically issues a pass certificate with risk remarks (if any), and allows the structured business data to enter the next stage.

[0155] Phase Two: Data Mapping and Format Standardization.

[0156] The system follows the target field mapping rules, data type conversion rules, and required metadata completion rules included in the schema rules to perform target field mapping, data type conversion, and required metadata completion on the business fields in the structured business data released in the first stage. After obtaining standardized business fields, all standardized business fields are assembled into the standard message format required by the downstream system to form standardized business data. Required metadata completion refers to filling in necessary business metadata (such as the current operator ID, department code, and business timestamp) to ensure that the required field validation of the downstream system is met. Specifically, whether completion is needed depends on the interface requirements of the downstream system. In practical applications, the required fields of the downstream system (such as ERP) can be configured based on the interface documentation. Any field that is required in the interface documentation but cannot be extracted from the business and financial documents (contracts / invoices) needs to be resolved by completing the metadata. The metadata that needs to be completed is obtained in the following three ways: Static configuration (fixed values): In the downstream system, some required fields are fixed and can be directly written in the schema rules, for example, "source_system": "DocParser", which is automatically filled in on each call. Context Acquisition: Reads in real-time from environment variables at the time the API call was initiated. For example, current operator ID: parsed from the login user ID obtained from the token / session attached to the API call; current timestamp: directly retrieves the server's current system time; department code: reads the department to which the currently executing machine belongs from the RPA robot's runtime configuration file. Logical Calculation or Secondary Query: Performs reverse lookups in external systems using the extracted information. For example: the document only states "Sales Department," but the downstream ERP requires "Department Internal Code (Dept_Code)." The system will pre-configure a mapping query rule, automatically using "Sales Department" to call the organizational structure API to retrieve DEPT_SALES and fill it in.

[0157] Phase 3: Multi-mode automatic injection.

[0158] After the standardized business data transformation is completed, the system will populate the standardized business data into the downstream system using any of the following methods: API direct injection: The system calls the standard RESTful API or WebService interface opened by the downstream ERP, OA or financial system, and sends the standardized business data assembled in the second stage through the HTTPS protocol to achieve non-intrusive data filling (such as automatically generating purchase orders in SAP).

[0159] RPA component simulates data entry: When the downstream system has no open interface, the RPA component is called to simulate manual operation. The downstream system interface is opened, and standardized business data is entered into the corresponding positions (such as text boxes and drop-down boxes) one by one according to the coordinate semantics or UI element positioning parsed by S101. Then, the "Save / Submit" button is clicked.

[0160] The intelligent assistant automatically triggers the following: If the downstream system is an OA approval workflow, the intelligent assistant can fill the corresponding fields of the approval form with standardized business data and automatically submit it to the next approval node.

[0161] Phase 4: Write back the execution results and confirm the closed loop.

[0162] To prevent discrepancies caused by data being sent but not successfully saved by the system, this embodiment can also perform the following closed-loop operation after automatic filling: Capture Status Receipt: Receive status receipts returned by the downstream system after processing (such as "Successfully created, document number: FKD-2026-001" or "Failed: Cost center does not exist").

[0163] Status receipt write-back: Write back the document number, processing time, and status code from the status receipt returned by the downstream system and associate them with the entire process record of this business and financial document.

[0164] Anomaly Handling Strategy: If the status receipt indicates that the standardized business data has failed to be populated, an anomaly log will be automatically generated and a work order will be pushed to the user for manual intervention to ensure that there will be no problem where the data has been extracted and approved, but has not been entered into the downstream database.

[0165] Example 5 This embodiment details the specific implementation of the business and financial skills encapsulation. This embodiment can encapsulate at least one of the following: document parsing capability in step S101, field extraction capability in step S102, compliance review capability in step S103, schema conversion capability in step S104, and data filling capability in step S105, into a business and financial skill, and create a component package for the business and financial skill. The business and financial skill provides services to users through at least one of API interfaces, RPA components, and intelligent assistants. The business and financial skill connects to different downstream systems through different configuration instances. The component package allows users to reuse the business and financial skill by downloading or referencing it online.

[0166] Specifically, business and financial skills are the business-level abstraction and aggregation of atomic capabilities across the entire document processing chain. For example, "contract PDF parsing," "extraction of key contract elements," "procurement compliance review," "data standardization conversion," and "ERP system population" can be packaged into a business and financial skill called "Intelligent Procurement Contract Review," and a corresponding component package can be created. The component package is the standardized delivery carrier of business and financial skills at the physical level, containing executable code, configuration metadata, and dependency declarations. Business and financial skills connect to different downstream systems through different configuration instances. For example, the same "Intelligent Procurement Contract Review" skill can connect to SAP systems, Oracle systems, or enterprise-developed financial systems by configuring different mode rules and population methods. In terms of service form, business and financial skills can be published through API interfaces, suitable for backend system integration and high-concurrency calls; they can be published to the component marketplace as RPA components, suitable for desktop automation processes; and they can also be provided as intelligent assistants, supporting natural language interaction triggers. Component packages allow users to reuse business and financial skills by downloading or referencing them online. The download mode is suitable for private deployments or network-restricted environments, while the online referencing mode is suitable for SaaS integration scenarios. This encapsulation mechanism significantly reduces the technical threshold and marginal cost for enterprises to integrate intelligent document processing capabilities.

[0167] In this scenario of encapsulating business and financial skills, the extraction templates, review strategies, and schema rules invoked by the business and financial skills can be dynamically loaded in, but are not limited to, the following ways: First, the feature vector of the current task is determined based on the contextual information of the business and financial documents.

[0168] When a user uploads a business and financial document and it enters the processing flow, the system automatically collects the contextual features of the document: document type identified by parsing the layout elements (contract / invoice / expense report / acceptance form), business domain tags (purchasing / sales / expenses / cross-border), document source department, and document metadata (such as contract amount range, counterparty type, etc.).

[0169] The system encodes and transforms the collected context features: discrete features (document type, business domain, department) are one-hot encoded, and continuous features (amount range) are binned (e.g., 0-100,000, 100,000-500,000, and above 500,000) to construct a unified context feature vector.

[0170] The system associates and stores the context feature vector with the processing task ID.

[0171] Then, the recommended configuration package ranking is determined based on the context feature vector and the configuration package feature vector.

[0172] The system iterates through all published configuration packages (each configuration package is a three-in-one combination of "extract template + review strategy + schema rules") and reads the applicable context feature vector that is pre-calculated and stored for each configuration package.

[0173] The system calculates the Euclidean distance or cosine similarity between the current document context feature vector and the feature vector of each configuration package, and uses the calculation result as the matching score of the configuration package. The smaller the distance / the higher the similarity, the higher the matching degree.

[0174] The system sorts all configuration packages in descending order of matching score, selects the Top-N (e.g., Top-5) configuration packages as the recommended candidate set, displays the name, matching score and applicable scenario description of each recommended configuration package on the interface, and outputs the recommended configuration package candidate list.

[0175] Finally, the configuration combination to be automatically loaded is determined based on the recommended configuration package selected by the user.

[0176] In response to a user's selection of a configuration package from the recommended configuration package candidate list, the system reads the extraction template ID, review strategy ID, and schema rule ID corresponding to that configuration package.

[0177] The system loads the corresponding configuration entities from the template library, strategy library, and rule library according to the above IDs, and automatically binds them to steps S102 (intelligent extraction), S103 (compliance review), and S104 (schema mapping) of the current processing task, so as to achieve one-click loading of complete configuration.

[0178] When a user inputs and publishes a new configuration package, the system automatically calculates and stores the applicable context feature vector of that configuration package. If the feature vector distance between the new configuration package and an existing configuration package is less than a preset threshold (high similarity), the system prompts the user "Similar configurations already exist, do you need to inherit or modify them?" After the user confirms, the system performs a creation or merging operation, outputs the configuration publication result, and updates the feature vector index library.

[0179] Example 6 This embodiment takes the compliance review of procurement contracts in a business and finance scenario as an example to provide a detailed explanation of the above-mentioned intelligent document data processing method.

[0180] In this application scenario, business personnel first upload a PDF file of a procurement contract to be reviewed through the system interface. The system then executes step S101, parsing the layout elements of the received unstructured business document. Specifically, the system performs pixel-level visual analysis of the contract document, identifying various physical elements in the document, including text paragraphs, table cells, handwritten annotations, etc., and extracting the element content, element type, and element coordinates of each physical element. Subsequently, the system performs semantic logical reorganization on the layout element data, reorganizing multiple physical elements belonging to the same cell into a logical object, and reorganizing adjacent physical elements across pages belonging to the same paragraph into a logical object, and using coordinate mapping to ensure that each logical object retains its precise positional correspondence with the original document. The final output structured logical object data is organized in a hierarchical tree structure, laying the data foundation for subsequent accurate extraction.

[0181] Next, the user selects the pre-configured "Purchase Contract Review Extraction Template" in the system, and the system executes step S102. This extraction template uses a combination of prompt words and field lists: for standard fields such as "Contract Amount," "Signing Date," and "Supplier Name," a field list pattern defines precise key-value pair extraction rules; for unstructured content such as "Breach of Contract Clauses" and "Dispute Resolution Methods," a prompt word pattern defines semantic extraction instructions. After loading the extraction template, the system performs semantic extraction on the structured logical object data, automatically generating structured business data in JSON format.

[0182] Subsequently, the system automatically applies the associated "Procurement Compliance Review Strategy" to execute step S103. This review strategy is configured with multiple review rules, each associated with specific review fields and conditions. For example, regarding the review rule for "Contract Amount Reconciliation," the system compares the "Total Contract Amount" with the "Sum of All Item Amounts," and any discrepancies are immediately flagged as risks. Regarding the review rule for "Compliance of Liquidated Damages Ratio," the system determines whether the liquidated damages ratio exceeds the legal limit. After the review is completed, the system outputs review results including the review status, a list of risk items, and suggested modifications.

[0183] During the review results display phase, when business personnel click on the risk item "Excessive Penalty Rate" in the review results list, the system automatically redirects the document preview view to the corresponding contract page based on the element coordinates parsed in step S101. The system then precisely highlights the paragraph containing the penalty clause with a highlighted border, while simultaneously displaying the risk level and suggested modifications for that risk item. This interactive, linked positioning mechanism significantly shortens the manual review process.

[0184] After the review is approved, the system executes step S104, which calls the pre-configured schema rules to standardize the structured business data. The schema rules define the target field mapping, data type conversion, and required metadata completion, converting the extracted business data into the standard message format required by the downstream ERP system. Subsequently, the system executes step S105, which automatically populates the standardized business data into the ERP system according to the configured population method.

[0185] After the data entry is complete, the system receives a status confirmation from the ERP system. If the data entry is successful, the system writes the status confirmation back and links it to the entire process record of the procurement contract; if the data entry fails, the system generates an exception log and pushes a visual pending work order to the business personnel, who then fix the issue and re-enter the data entry until it is successful.

[0186] To transform these processing capabilities into reusable enterprise assets, document parsing, field extraction, compliance review, schema conversion, and data population capabilities can be combined and packaged into a "Smart Procurement Contract Review" business and financial skill, creating a component package. Once this component package is released, downstream financial shared service centers can directly reuse this skill by referencing it online or downloading and deploying it, eliminating the need to repeatedly develop parsing and verification code and significantly reducing cross-system integration costs.

[0187] Example 7 This embodiment provides an intelligent document data processing system, such as Figure 2 As shown, the intelligent document data processing system 200 provided in this embodiment adopts a layered architecture design to achieve decoupling and collaboration of various functional modules, specifically including: The document parsing layer 201 is used to respond to the user's upload operation for unstructured business documents. After parsing the layout elements of the unstructured business documents to obtain layout element data, the layout element data is semantically and logically reorganized and coordinately mapped to obtain structured logical object data. The structured logical object data is a hierarchical tree structure.

[0188] Specifically, the document parsing layer 201 serves as the system's data access foundation, its core function being to transform heterogeneous unstructured files into a unified machine-readable data protocol. Internally, this layer integrates a layout analysis model, an OCR engine, and a semantic reconstruction algorithm, exposing only standardized parsing interfaces externally. Regardless of whether the input is PDF, Word, or an image, this layer outputs structured logical object data containing object content, object type, and object coordinates. This design ensures that changes in upstream document formats do not affect downstream business logic, while the retained coordinate data provides a spatial indexing basis for subsequent interactive review.

[0189] The field extraction layer 202 is used to respond to the user's configuration operation for the extraction template, call the extraction template, and extract business data from the structured logical object data to obtain structured business data.

[0190] Specifically, the field extraction layer 202 is the execution module for business data extraction, responsible for semantic extraction of structured logical object data based on the extraction template configured by the user. This layer dynamically loads the extraction template configuration at runtime, supporting two configuration methods: prompt words and / or field lists, and assembles the extraction results into structured business data in JSON format. Because the calculation logic is completely separated from the configuration data, this layer supports horizontal scaling to handle high concurrency requests, and adjustments to the extraction strategy take effect without requiring a service restart.

[0191] The compliance review layer 203 is used to respond to the user's configuration operation for the review policy, invoke the review policy, and perform compliance review on the structured business data to obtain the review result.

[0192] Specifically, the compliance review layer 203, acting as the execution center for quality control, sequentially schedules the corresponding execution engines to verify structured business data according to the rules defined in the review strategy. This layer not only outputs Boolean verification conclusions but also aggregates contextual information to generate a structured review report containing review status, a list of risk items, and modification suggestions. By linking with the coordinate data output by the document parsing layer 201, this layer also supports interactive navigation between risk items and the original text on the front end, forming a complete closed loop from data verification to visual verification.

[0193] The schema conversion layer 204 is used to respond to the user's configuration operation for schema rules, invoke schema rules, and convert the structured business data that has passed the review into standardized business data required by the downstream system.

[0194] Specifically, the schema conversion layer 204 is responsible for standardizing data format conversion. Through a triple conversion mechanism of target field mapping, data type conversion, and required metadata completion, it uniformly converts approved business data into the standard message format required by downstream systems. This layer eliminates data heterogeneity barriers between different systems through configurable conversion rules, realizing automated connection from business data extraction to downstream system integration.

[0195] The data population layer 205 is used to respond to the user's configuration operation for the population method, call the population method, and populate the standardized business data into the downstream system.

[0196] Specifically, the data population layer 205 serves as the system's unified service gateway and adapter, incorporating various protocol adaptation plugins for different downstream consumption scenarios, such as direct writing via API interfaces and simulating manual data entry through RPA components. This layer is also responsible for receiving status receipts from downstream systems and performing corresponding follow-up processing based on the receipt results to ensure the eventual consistency of data population.

[0197] This embodiment constructs a highly cohesive and loosely coupled intelligent document processing platform through the collaborative work of the aforementioned five-layer architecture. Each layer interacts via standardized data interfaces, ensuring module independence under the single responsibility principle while enabling cross-layer capability reuse and flexible orchestration. In particular, structured logical object data, serving as the data link throughout the entire process, effectively decouples document formatting from business logic, supporting the agile development and large-scale deployment of intelligent business and financial applications.

[0198] As one implementation method, the document parsing layer 201 is used to perform pixel-level visual parsing of unstructured business documents, identify each physical element in the unstructured business documents as well as the element content, element type and element coordinates of each physical element; sort all physical elements according to page number, vertical coordinate and horizontal coordinate, and assemble them into layout element data.

[0199] As one implementation method, the document parsing layer 201 is used to perform spatial clustering analysis and semantic coherence judgment on multiple physical elements located in adjacent or identical areas in the page element data. It reorganizes physical elements belonging to the same cell into a single logical object, and reorganizes two adjacent physical elements across pages and belonging to the same paragraph into a single logical object. For each reorganized logical object, if the logical object consists of a single physical element, the element coordinates of the physical element are used as the object coordinates of the logical object; if the logical object consists of at least two physical elements, a coordinate array is generated based on the element coordinates of each physical element as the object coordinates of the logical object. The coordinate array contains the element coordinates of each physical element. All reorganized logical objects are sorted according to page number, vertical coordinate, and horizontal coordinate, and assembled into structured logical object data with a hierarchical tree structure. Each logical object in the structured logical object data contains object content, object type, and object coordinates.

[0200] As one implementation, the extraction template includes prompt words and / or a list of fields; the field extraction layer 202 is used to extract candidate logical objects from the structured logical object data based on the prompt words and / or the list of fields; after semantically extracting business data from each candidate logical object, the business data is assembled into a JSON structure to form structured business data.

[0201] As one implementation method, the review strategy includes at least one review rule, each review rule being associated with a review field and review conditions; the compliance review layer 203 is used to match each business field in the structured business data with each review rule in the review strategy to determine the mapping relationship between the business field and the review conditions; according to the review mode of each review rule, each business field is subject to compliance review according to the mapping relationship between the business field and the review conditions; the compliance review results of each business field are assembled into a JSON structure to form the review results; wherein, the review results include the review status of review passed or failed, a list of risk items, and modification suggestions.

[0202] As one implementation method, the schema rules include target field mapping rules, data type conversion rules, and required metadata completion rules; the schema conversion layer 204 is used to perform target field mapping, data type conversion, and required metadata completion on each business field in the structured business data according to the target field mapping rules, data type conversion rules, and required metadata completion rules to obtain standardized business fields; and assemble all standardized business fields into the standard message format required by the downstream system to form standardized business data.

[0203] As one implementation method, the data population layer 205 is also used to receive status receipts returned by downstream systems for standardized business data; if the status receipt indicates that the standardized business data population is successful, the status receipt is written back and associated with the full-process processing record of the unstructured business and financial document; if the status receipt indicates that the standardized business data population fails, an exception log is generated and an exception handling operation is triggered; wherein, the exception handling operation includes: generating a visual to-do order and pushing it to the user; responding to the user's repair operation for the visual to-do order, re-populating the repaired standardized business data into the downstream system; when the new status receipt returned by the downstream system indicates that the repaired standardized business data population is successful, the new status receipt is written back and associated with the full-process processing record of the unstructured business and financial document.

[0204] It should be noted that the principle of the intelligent document data processing system 200 provided in this embodiment to solve the technical problem is similar to that of the intelligent document data processing method described above. Therefore, the implementation of the intelligent document data processing system 200 provided in this embodiment can refer to the implementation of the intelligent document data processing method described above, and the repeated parts will not be described again.

[0205] Example 8 This embodiment provides an electronic device, which may be, but is not limited to, a computer, mobile phone, tablet computer, etc. Figure 3As shown, the electronic device 300 provided in this embodiment includes at least a processor 301, a memory 302, and a computer program stored in the memory 302 and capable of running on the processor 301. When the processor 301 executes the computer program, it implements the above-described intelligent document data processing method.

[0206] In one implementation, processor 301 can be a single processing element or a collective term for multiple processing elements. For example, processor 301 can be a central processing unit (CPU) or one or more integrated circuits configured to implement the aforementioned intelligent document data processing method. Specifically, processor 301 can be a general-purpose processor, including but not limited to CPUs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0207] In one implementation, memory 302 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 3021 and / or cache memory 3022, and may further include read-only memory (ROM) 3023; memory 302 may also include a program tool 3025 having a set (at least one) program module 3024, the program module 3024 including but not limited to: operating subsystem, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0208] In one implementation, the electronic device 300 may also include a bus 303 connecting different components (including the processor 301 and the memory 302). The bus 303 represents one or more types of bus structures, including a memory bus, a peripheral bus, a local area bus, etc.

[0209] In one implementation, the electronic device 300 can also communicate with one or more external devices 304. These external devices 304 include, but are not limited to: devices that enable a user to interact with the electronic device 300 (e.g., mobile phones, computers, etc.), and / or devices that enable the electronic device 300 to communicate with one or more other electronic devices (e.g., routers, modems, etc.). This communication can be performed through an input / output (I / O) interface 305. Furthermore, the electronic device 300 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 306. Figure 3 As shown, network adapter 306 communicates with other modules of electronic device 300 via bus 303.

[0210] It should be understood that, despite Figure 3 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 300, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) subsystems, tape drives, and data backup storage subsystems.

[0211] It should be noted that, Figure 3 The electronic device 300 shown is merely an example and should not impose any limitations on the functionality and scope of use of this embodiment.

[0212] Furthermore, this embodiment also provides a readable storage medium storing computer instructions that, when executed by a processor, implement the aforementioned intelligent document data processing method. Specifically, the computer instructions can be built into or installed in the processor, enabling the processor to implement the aforementioned intelligent document data processing method by executing the built-in or installed computer instructions.

[0213] In addition, this embodiment also provides a program product, which includes program code that, when executed by a processor, implements the above-described intelligent document data processing method.

[0214] In one implementation, the program product may employ any combination of one or more readable media, wherein the readable media may be a readable signal medium or a readable storage medium, and the readable storage medium may be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. Specifically, more specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0215] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0216] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

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

[0218] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A method for intelligent document data processing, characterized in that, include: In response to a user's upload of an unstructured business document, the system parses the layout elements of the unstructured business document to obtain layout element data, and then performs semantic logic reorganization and coordinate mapping restoration on the layout element data to obtain structured logical object data; wherein, the structured logical object data is a hierarchical tree structure; In response to the user's configuration operation for the extraction template, the extraction template is invoked to extract business data from the structured logical object data to obtain structured business data; In response to the user's configuration operation for the review strategy, the review strategy is invoked to perform a compliance review on the structured business data and obtain the review result; In response to the user's configuration operation for the pattern rule, the pattern rule is invoked to convert the structured business data that has passed the review into standardized business data required by the downstream system; In response to the user's configuration operation for the filling method, the filling method is invoked to fill the standardized business data into the downstream system.

2. The intelligent document data processing method as described in claim 1, characterized in that, The unstructured business and financial document is parsed to obtain layout element data, including: The unstructured business document is subjected to pixel-level visual analysis to identify each physical element in the unstructured business document, as well as the element content, element type, and element coordinates of each physical element. All physical elements are sorted according to page number, vertical coordinate, and horizontal coordinate, and then assembled into the layout element data.

3. The intelligent document data processing method as described in claim 1, characterized in that, The layout element data is semantically and logically reorganized and its coordinates mapped back to obtain structured logical object data, including: Spatial clustering analysis and semantic coherence judgment are performed on multiple physical elements located in adjacent or identical areas in the page element data. The physical elements belonging to the same cell are reorganized into a logical object, and two physical elements that are adjacent across pages and belong to the same paragraph are reorganized into a logical object. For each reorganized logical object, if the logical object consists of a single physical element, then the element coordinates of the physical element are used as the object coordinates of the logical object; if the logical object consists of at least two physical elements, then a coordinate array is generated based on the element coordinates of each physical element and used as the object coordinates of the logical object; wherein, the coordinate array contains the element coordinates of each physical element. All the reorganized logical objects are sorted according to page number, vertical coordinate, and horizontal coordinate, and assembled into structured logical object data with a hierarchical tree structure; wherein, each logical object in the structured logical object data contains object content, object type, and object coordinates.

4. The intelligent document data processing method as described in claim 1, characterized in that, The extraction template includes prompt words and / or a list of fields; The extraction template is invoked to extract business data from the structured logical object data, resulting in structured business data, including: Based on the prompt words and / or the field list, extract candidate logical objects from the structured logical object data; After semantically extracting business data from each candidate logical object, the business data is assembled into a JSON structure to form the structured business data.

5. The intelligent document data processing method as described in claim 1, characterized in that, The review strategy includes at least one review rule, and each review rule is associated with review fields and review conditions; The review strategy is invoked to perform a compliance review on the structured business data, and the review results are obtained, including: Each business field in the structured business data is matched with each review rule in the review strategy to determine the mapping relationship between the business fields and the review conditions. Based on the review mode of each review rule, a compliance review is conducted on each business field according to the mapping relationship between business fields and review conditions; The compliance review results for each business field are assembled into a JSON structure to form the review results; wherein, the review results include the review status of review passed or failed, a list of risk items, and modification suggestions.

6. The intelligent document data processing method as described in claim 1, characterized in that, The pattern rules include target field mapping rules, data type conversion rules, and required metadata completion rules; The pattern rules are invoked to convert the structured business data that meets the review criteria into standardized business data required by downstream systems, including: For each business field in the structured business data, according to the target field mapping rules, the data type conversion rules, and the required metadata completion rules, the business field is mapped to the target field, converted to the data type, and completed with required metadata to obtain a standardized business field. All standardized business fields are assembled into the standard message format required by the downstream system to form the standardized business data.

7. The intelligent document data processing method as described in claim 1, characterized in that, After filling the standardized business data into the downstream system using the aforementioned filling method, the process further includes: Receive the status receipt returned by the downstream system for the standardized business data; If the status receipt indicates that the standardized business data has been successfully populated, the status receipt will be written back and associated with the entire process processing record of the unstructured business financial document. If the status receipt indicates that the standardized business data filling has failed, an exception log is generated and an exception handling operation is triggered. The exception handling operation includes: generating a visual to-do order and pushing it to the user; responding to the user's repair operation on the visual to-do order, refilling the repaired standardized business data into the downstream system; when the new status receipt returned by the downstream system indicates that the repaired standardized business data filling is successful, writing the new status receipt back and associating it with the full-process processing record of the unstructured business financial document.

8. An intelligent document data processing system, characterized in that, include: The document parsing layer is used to respond to the user's upload operation for unstructured business documents. After parsing the layout elements of the unstructured business documents to obtain layout element data, the layout element data is semantically and logically reorganized and coordinately mapped to obtain structured logical object data; wherein, the structured logical object data is a hierarchical tree structure. The field extraction layer is used to respond to the user's configuration operation for the extraction template, call the extraction template, and extract business data from the structured logical object data to obtain structured business data; The compliance review layer is used to respond to the user's configuration operation for the review strategy, invoke the review strategy, and perform compliance review on the structured business data to obtain the review result; The pattern conversion layer is used to respond to the user's configuration operation for pattern rules, call the pattern rules, and convert the structured business data that has passed the review into standardized business data required by the downstream system. The data population layer is used to respond to the user's configuration operation for the population method, call the population method, and populate the standardized business data into the downstream system.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the intelligent document data processing method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores computer instructions that, when executed by a processor, implement the intelligent document data processing method as described in any one of claims 1-7.

Images