Invoice auditing method, device and system

Abstract

The application discloses a document auditing method, device and system, wherein the document auditing method can be applied to the technical field of information auditing, and the method comprises the following steps: obtaining a field evidence unit extracted for a document; the field evidence unit carries multi-dimensional attribute information; determining a role allocation result of each field evidence unit based on the multi-dimensional attribute information; the role allocation result comprises an allocated business role; taking the field evidence unit as a node, constructing an edge based on the multi-dimensional attribute information and the role allocation result to obtain a role typing evidence graph; in response to an auditing task, extracting an evidence path in the role typing evidence graph based on a target business role carried by the auditing task, and determining a task key field according to a business fact inquired by the auditing task; and when the evidence path does not comprise any task key field or there is a negative edge corresponding to an unsolved contradictory relationship, the generation of a positive auditing conclusion for the auditing task is blocked. The application improves the auditing security and the computing efficiency.

Description

Technical Field

[0001] This application relates to the field of information verification technology, and in particular to document verification methods, apparatus and systems. Background Technology

[0002] Automated review of trade documents typically involves processing various types of documents, including contracts, pro forma invoices, commercial invoices, bills of lading, logistics documents, customs declarations, payment records, packing lists, and letters of credit. The same business entity may assume different business roles in different documents. For example, the same company may appear as the seller in a contract but as the shipper in a bill of lading. Furthermore, the payee in a bank payment record is not necessarily the same as the seller, and the notify party in a bill of lading is not necessarily the same as the consignee. This complexity of overlapping roles significantly complicates automated review across multiple documents.

[0003] Currently, technicians generally use technologies such as Optical Character Recognition (OCR), multimodal document parsing, field extraction, field rule comparison, knowledge graph question answering, or Retrieval-Augmented Generation (RAG) to process the aforementioned documents. The standard processing flow is as follows: first, fields such as company name, account number, address, amount, currency, and date are extracted from the document image or electronic file; then, cross-document consistency verification is performed based on field names, field values, semantic similarity, or preset business rules; finally, a large language model generates audit opinions or risk warnings.

[0004] However, the existing practices described above have significant shortcomings. On the one hand, directly verifying extracted fields can easily lead to the indiscriminate mixing of fields representing different business roles, resulting in incorrect comparisons between the shipper's address and the buyer's address, causing false positives or false negatives. On the other hand, ordinary retrieval enhancement methods rely on semantic similarity to recall evidence, which may very well recall semantically related but inconsistent business roles as verification criteria, thus causing inaccurate audit conclusions. These deficiencies severely restrict the reliability and credibility of automated trade document auditing. Summary of the Invention

[0005] To address the problems of existing technologies, this application provides a document review method, apparatus, and system. The technical solution is as follows: On the one hand, a document review method is provided, the method comprising: Obtain multiple field evidence units extracted from multiple documents; each field evidence unit carries multi-dimensional attribute information; The role allocation result for each field evidence unit is determined based on the multi-dimensional attribute information; the role allocation result includes the assigned business role. Using the field evidence unit as a node, edges are constructed based on the multi-dimensional attribute information and the role allocation result to obtain a role classification evidence graph; the edges include negative edges that represent contradictory relationships between nodes; In response to an audit task, evidence paths are extracted from the role classification evidence graph based on the target business role carried by the audit task; and key task fields are determined based on the business facts queried by the audit task. When the evidence path does not include any key field of the task, or when there is a negative edge in the evidence path where the corresponding contradictory relationship has not been resolved, the generation of an affirmative audit conclusion for the audit task is blocked.

[0006] On the other hand, a document verification device is provided, the device comprising: The field acquisition module is used to acquire multiple field evidence units extracted from multiple documents; the field evidence unit carries multi-dimensional attribute information. The role allocation module is used to determine the role allocation result of each field evidence unit based on the multi-dimensional attribute information; the role allocation result includes the assigned business role. The evidence graph construction module is used to construct edges based on the multi-dimensional attribute information and the role allocation result, using the field evidence units as nodes, to obtain a role classification evidence graph; the edges include negative edges that represent contradictory relationships between nodes; The evidence extraction module is used to extract evidence paths from the role-class evidence graph based on the target business role carried by the audit task in response to the audit task. The field determination module is used to determine the key fields of the task based on the business facts inquired by the audit task. The audit blocking module is used to block the generation of a positive audit conclusion for the audit task when the evidence path does not include any key field of the task, or when there is a negative edge in the evidence path with an unresolved contradiction.

[0007] In one exemplary embodiment, the apparatus further includes a conclusion generation module for generating an affirmative review conclusion, the conclusion generation module comprising: The evidence verification module is used to verify the field evidence units in the evidence path when the evidence path includes key fields of each task and there are no negative edges in the evidence path where the corresponding contradiction relationship has not been resolved. The verification-passing module is used to generate an affirmative audit conclusion for the audit task if the verification passes.

[0008] In one exemplary implementation, the evidence extraction module includes: The constraint retrieval module is used to perform role constraint retrieval in the role classification evidence graph based on the target business role to obtain candidate evidence paths; the nodes in the candidate evidence paths include anchor nodes that match the target business role carried by the review task, and associated nodes that have edges with the anchor nodes. The evidence admission module is used to determine the evidence admission of each node in the candidate evidence path based on the role allocation result and the multi-dimensional attribute information, and to determine the node that passes the evidence admission determination as the admission evidence unit. The evidence determination module is used to determine the evidence path based on the admission evidence unit and the edges between the admission evidence units in the role classification evidence diagram.

[0009] In one exemplary implementation, the role allocation result further includes a role status, which is either a confirmed status or an abnormal status; the multi-dimensional attribute information includes a document version; the evidence access module includes: The admission evidence determination module is used to determine the nodes in the candidate evidence path that have a confirmed role status and a valid document version as the admission evidence unit.

[0010] In one exemplary implementation, the role assignment module includes: The candidate generation module is used to generate a set of candidate business roles for each field evidence unit; The attribute acquisition module is used to acquire the role attribute information of each candidate business role in the candidate business role set. The score calculation module is used to calculate the role binding score of the field evidence unit relative to each candidate business role in the candidate business role set based on the multi-dimensional attribute information and the role attribute information. The role determination module is used to determine the role status and assigned business role of the field evidence unit based on the role binding score.

[0011] In one exemplary embodiment, the fraction calculation module includes: The neighborhood acquisition module is used to acquire the neighboring field information of the field evidence units adjacent to the field evidence unit; The history retrieval module is used to retrieve role binding records from historical audit records that are associated with the current business scenario; The comprehensive calculation module is used to calculate the role binding score of the field evidence unit relative to each candidate business role based on the adjacent field information, the role binding record, the multi-dimensional attribute information, and the role attribute information.

[0012] In one exemplary implementation, the multi-dimensional attribute information includes document version; the role determination module includes: The sorting determination module is used to determine a first binding score and a second binding score among multiple role binding scores corresponding to the field evidence unit; the first binding score is higher than the role binding scores other than the first binding score among the multiple role binding scores corresponding to the field evidence unit, and the second binding score is higher than the role binding scores other than the first binding score and the second binding score among the multiple role binding scores corresponding to the field evidence unit; The status marking module is used to mark the role status of the field evidence unit as confirmed when the first binding score reaches a preset confidence threshold, the difference between the first binding score and the second binding score reaches a preset difference threshold, and the document version is valid.

[0013] In one exemplary embodiment, the device further includes an anomaly marking module, which is used to mark the role status of the field evidence unit as an anomaly when the first binding score is lower than a preset confidence threshold, or the difference between the first binding score and the second binding score is lower than a preset difference threshold, or the document version is invalid.

[0014] In one exemplary implementation, the evidence graph construction module includes at least one of the following: The conflict edge construction module is used to construct role conflict edges based on the mutual exclusion relationship between business roles assigned between different field evidence units under preset business rules. The first ambiguity edge construction module is used to construct a role ambiguity edge if at least one of the different field evidence units that have a relationship under the preset business rules is in an abnormal state. The second ambiguity edge construction module is used to construct the role ambiguity edge based on the unconfirmed association relationship between different field evidence units under the preset business rules; The numerical edge construction module constructs numerical conflict edges based on the logical contradictions between numerical fields in different field evidence units. The version edge construction module is used to construct version substitution edges based on the substitution relationship between document versions with different field evidence units.

[0015] In one exemplary implementation, the edge further includes a positive edge representing a mutual corroboration relationship between nodes; the evidence graph construction module includes at least one of the following: The Same Role Edge module is used to construct same role corroboration edges based on evidence units in different fields that are assigned the same business role. The cross-role edge module is used to construct cross-role association edges based on different business roles assigned to different field evidence units that have a relationship under preset business rules. The Historical Binding Edge module is used to construct historical binding edges based on the role binding records of business roles assigned to different field evidence units in historical audit records.

[0016] In one exemplary implementation, the multi-dimensional attribute information includes document type, field type, subject identifier, and document version; the constraint retrieval module includes: Anchor node filtering module is used to filter anchor nodes from the nodes of the role classification evidence diagram based on the target business role, target document type, target field type, target subject identifier and target document version carried by the audit task. The candidate node determination module is used to select the anchor node and the associated nodes in the role classification evidence graph that have edges with the anchor node as candidate nodes. The candidate path determination module is used to determine the candidate evidence path based on the candidate nodes and the edges between the candidate nodes in the role classification evidence graph.

[0017] In one exemplary embodiment, the apparatus further includes a post-processing module for post-processing after blocking the generation of an affirmative review conclusion for the review task, the post-processing module including at least one of the following: The risk warning generation module is used to generate risk warning information for nodes in the candidate evidence path that are associated with the negative edge; The rejection output module is used to output rejection results to the review end; The review and dispatch module is used to dispatch review tasks carrying the candidate evidence path and the reason for the blockage to the manual review platform.

[0018] On the other hand, a document review system is provided, the system including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the document review method of any of the above aspects.

[0019] On the other hand, an electronic device is provided, including a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the document review method of any of the above aspects.

[0020] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or the at least one program being loaded and executed by a processor to implement the document review method as described above.

[0021] On the other hand, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the document review method described above.

[0022] This application embodiment independently assigns business roles to each field evidence unit based on multi-dimensional attribute information, extracting the business semantics of "role" from the text content and explicitly presenting it as a data structure. Using field evidence units as nodes and role assignment results and attribute associations as edges, a role-fractional evidence graph containing "negative edges" is constructed. This graph explicitly solidifies conflict logics such as role mutual exclusion, numerical contradictions, and version substitution into the graph's edge structure, making logical conflicts between evidence an organic component of the graph topology. When an audit task arrives, evidence paths are extracted from the role-fractional evidence graph based on the target business role carried by the audit task. The key fields of the task are determined according to the business facts inquired by the audit task. This is equivalent to completing "role security checks" and "path pruning" of the evidence before entering consistency verification, effectively filtering out interfering evidence that does not match the audit task. When the filtered evidence path does not include any key task field, or contains negative edges with unresolved corresponding contradictory relationships, it indicates that there are still irreconcilable logical contradictions between the nodes in the evidence path, or that the key business facts lack evidentiary support. In this case, the generation of an affirmative conclusion is forcibly blocked. This application establishes structured rules for expressing contradictions and blocking paths at the data level, enabling the reliable identification and interception of complex business conflicts across documents and roles. This significantly reduces the risk of missed reports due to role confusion, while precisely narrowing the scope of review to the path nodes where contradictions actually exist, thus achieving a simultaneous improvement in audit security, interpretability, and computational efficiency. Attached Figure Description

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

[0024] Figure 1This is a flowchart illustrating a document review method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating another document review method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the field evidence unit generation method provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the method for generating cross-document subject identifiers and candidate business role sets provided in this application embodiment; Figure 5 This is a flowchart illustrating the method for determining the role status provided in an embodiment of this application; Figure 6 This is a structural example diagram of the role classification evidence diagram provided in the embodiments of this application; Figure 7 This is a flowchart illustrating the candidate evidence path extraction and evidence admission method provided in the embodiments of this application; Figure 8 This is a flowchart illustrating the consistency verification and controlled conclusion generation method provided in the embodiments of this application; Figure 9 This is a schematic diagram of the process of running audit logs and manual review feedback provided in the embodiments of this application; Figure 10 This is a structural block diagram of a document verification device provided in an embodiment of this application; Figure 11 This is a hardware structure block diagram of a computer device that runs a document review method, as provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0027] It is understood that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0028] In cross-border trade document review scenarios, the documents to be reviewed typically originate from different business participants, and these documents from different sources exhibit significant differences in format, language, and field naming conventions. For example, different types of documents, such as contracts, invoices, bills of lading, logistics documents, customs declarations, payment records, packing lists, and letters of credit, have different field layouts and expressions. Even the same type of document may present drastically different formats and terminology in different companies, regions, and language environments. Furthermore, in actual business processes, documents often have multiple revised versions. If fields from older, expired, or replaced documents are directly entered into the review process without version validity verification, they are highly likely to be incorrectly cited as evidence, leading to erroneous review conclusions. The complexity of multiple sources, formats, languages, and version changes makes traditional review methods based on direct field comparison or simple semantic retrieval unreliable in distinguishing field evidence corresponding to different business roles, thus increasing the risk of role mismatch, misuse of evidence, and inaccurate affirmative conclusions.

[0029] In view of this, this application proposes a document review method, please refer to [link / reference]. Figure 1The diagram illustrates a document review method according to an embodiment of this application. It should be noted that while this specification provides method steps as shown in the embodiments or flowcharts, more or fewer steps may be included based on conventional or non-inventive methods. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or product execution, the method can be executed sequentially according to the embodiments or accompanying drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 1 As shown, the method may include: S101, Obtain multiple field evidence units extracted from multiple documents.

[0030] Among them, the field evidence unit carries multi-dimensional attribute information.

[0031] In one specific implementation, the aforementioned multiple documents may include at least one of the following: contracts, invoices, bills of lading, logistics documents, customs declarations, payment records, packing lists, and letters of credit. Field evidence units can be obtained by performing optical character recognition, layout analysis, table recognition, image region recognition, and document type recognition on the document set. The multi-dimensional attribute information carried by each field evidence unit may include at least one of the following: field text, document type, page number, image region coordinates, field type, language type, subject identifier, document version, visual layout features, and extraction confidence level. The subject identifier can be obtained by normalizing subject information such as company name, address, account number, and tax number, enabling the unified association of different representations of the same subject in different documents, thereby achieving consistent subject identification across documents. The document version is used to identify the document version status from which the field evidence unit originates, including currently valid, invalid, or replaced status, and is used for subsequent version validity verification of evidence admission.

[0032] In this embodiment, the field evidence unit is the smallest granularity of evidence for document review. Each field evidence unit corresponds to an independent field entity extracted from the document, which not only contains the value of the field but also carries multi-dimensional attribute information characterizing the source and characteristics of the field. Specifically, the multi-dimensional attribute information may include document type, field type, subject identifier, and document version. Among them, the document type is used to identify the type of document from which the field originates, such as contract, pro forma invoice, commercial invoice, bill of lading, customs declaration, payment voucher, packing list, or letter of credit; the field type is used to identify the business meaning category of the field, such as company name, bank account, address, amount, currency, date, goods description, or document number; the subject identifier is used to identify the business entity associated with the field, which can be obtained by performing entity recognition and normalization processing on the field content. Different expressions of the same business entity in different documents can be mapped to a unified subject identifier; the document version is used to identify different revisions of the same document, which can be characterized by version number, revision timestamp, or version status marker. By configuring the aforementioned multi-dimensional attribute information for each field evidence unit, subsequent role assignment and evidence graph construction can be based on structured attribute data.

[0033] Please see Figure 2 The diagram illustrates the overall workflow of another document review method provided in this application. This method uses a multimodal set of cross-border trade documents as the starting point. These documents can include at least one of the following: contracts, proforma invoices (PI), commercial invoices (CI), bills of lading, logistics documents, and payment records. Through processing such as optical character recognition, layout analysis, table recognition, and image region localization (where image region localization uses a bounding box), field evidence units are extracted from the multimodal documents, and the source version information of each unit is recorded.

[0034] Please see Figure 3The diagram illustrates a flowchart of the field evidence unit generation method provided in this application embodiment. This method uses multimodal document images or electronic documents as input. The document format can include images, PDF files, scanned copies, and spreadsheets. Specifically, three types of recognition processing are performed in parallel on the input document: the first type is text recognition processing, used to extract field text content and language type information from the document; the second type is layout recognition processing, used to identify layout structural elements such as table areas, seals, signatures, and headers in the document, and obtain the image area coordinates corresponding to each field; the third type is document type recognition processing, used to determine the type of document based on its layout and content characteristics, such as contracts, invoices, bills of lading, logistics documents, or payment records. After summarizing the results of the above three types of recognition processing, the data is further input into the source version recognition module; the source version recognition module determines the document version status of each field evidence unit based on information such as the document's collection time, revision version mark, version replacement relationship, and expiration identifier, including currently valid, expired, or replaced statuses. Ultimately, the recognition results from each dimension are encapsulated into structured field evidence units. Each field evidence unit carries multi-dimensional attribute information including at least: field text, document type, page number, image region coordinates, field type, subject identifier, document version, text features, and visual features. The generated field evidence units are further used as index inputs to construct text vector indexes, image region indexes, and role classification evidence maps, providing a structured data foundation for subsequent role assignment and evidence retrieval.

[0035] The field evidence unit delivery package may include a composite image, image path information, field bounding boxes, and visual probe information. The composite image is a standardized image obtained after preprocessing the original document image, which can be used for subsequent field location and content recognition. The image path information identifies the image's location in the storage system for quick indexing and retrieval. The field bounding boxes mark the location area of ​​each field in the document image, providing spatial coordinates for accurate field-level extraction. The visual probe information records the visual features of the field areas, providing visual support data for subsequent role classification and evidence comparison. Furthermore, the extraction model used for automatic optical character recognition extraction can be pre-trained on public datasets and further fine-tuned and enhanced using the enterprise's own scanned document data to adapt to the field extraction needs of different industries and document formats, thereby continuously improving the accuracy and coverage of the generated field evidence units.

[0036] S103, determine the role allocation result of each field evidence unit based on multi-dimensional attribute information.

[0037] The role allocation result includes the assigned business role and the role status; the role status is either confirmed or abnormal.

[0038] In an exemplary implementation, step S103 may include the following steps: generating a set of candidate business roles for each field evidence unit; obtaining role attribute information of each candidate business role in the set of candidate business roles; calculating the role binding score of the field evidence unit relative to each candidate business role in the set of candidate business roles based on the multi-dimensional attribute information and the role attribute information; and determining the role status and assigned business role of the field evidence unit based on the role binding score.

[0039] The generation of the candidate business role set can be accomplished jointly based on the multi-dimensional attribute information of field evidence units and a preset role knowledge base. The preset role knowledge base stores the definitions of all business roles that may appear in various business scenarios, as well as the mapping relationship between each business role and document type and field type. For each field evidence unit, the preset role knowledge base can first be used to retrieve the possible corresponding business roles based on its document type and field type, forming an initial candidate set; then, semantic analysis of the field content is performed to supplement the candidate set with fields semantically associated with a certain type of business role. Role attribute information refers to attribute data used to characterize the characteristics of a business role, which may include the role's definition description, typical field characteristics, common manifestations in various documents, associations with other roles, and role mutual exclusion rules. By obtaining the role attribute information of each candidate business role in the candidate business role set, a multi-dimensional comparison benchmark can be provided for subsequent role binding score calculation.

[0040] In one specific implementation, the candidate business roles in the candidate business role set may include at least two of the following: buyer, seller, shipper, consignee, notify party, payer, payee, agent for payment, freight forwarder, and unrelated party. When generating the candidate business role set for each field evidence unit, it can be based on a combination of factors, including role tag keywords in the field text, location features of the image area where the field is located, prior role distribution of the document type, and role information of adjacent fields. For example, when role tag text such as supplier, seller, or beneficiary exists near a field, a seller or payee candidate role can be generated for that field evidence unit; when the image area coordinates of the field are located in the shipper area, consignee area, or notify party area of ​​the bill of lading, a shipper, consignee, or notify party candidate role can be generated accordingly.

[0041] like Figure 2 As shown, the information such as the subject name, address, and account in the field evidence unit is normalized to generate a cross-document subject identifier, so that different expressions of the same subject in different documents can be uniformly associated; a set of candidate business roles is generated for each field evidence unit, and the role binding score of each candidate role is calculated. The role status of the field evidence unit is determined to be either confirmed or abnormal through a dual threshold gating mechanism.

[0042] Please see Figure 4 The diagram illustrates a flowchart of the method for generating cross-document entity identifiers and candidate business role sets provided in this application embodiment. This method starts with different ways of writing the same entity. For example, the same company may be represented in different documents as "ABC Trading Co., Ltd.", "ABC Trading", or "ABC TRDG LTD". Entity normalization processing unifies these different expressions to the same entity. Entity normalization processing specifically includes steps such as name standardization, translation consistency verification, address matching, account matching, and tax number matching to ensure that multiple expressions of the same entity can be accurately identified and merged. After entity normalization processing, the system generates a unique cross-document entity identifier, entity_id, for example, entity_id = E-001 as shown in the diagram, thereby achieving cross-document entity consistency association. Simultaneously, the system generates a candidate business role set for field evidence units based on multiple role candidate sources. Role candidate sources may include at least one of the following: multilingual role dictionaries, prior knowledge of document types, field area templates, historical transaction binding records, and manual review records. Based on the aforementioned candidate sources, the system generates a set of candidate business roles for each field evidence unit. These candidate business roles can include at least two of the following: seller, shipper, consignee, notify party, payee, and agent for payment. The generated set of candidate business roles then enters the role binding scoring stage, where the system calculates the role binding score for each field evidence unit relative to each candidate business role, providing a quantitative basis for subsequent role status determination.

[0043] The subject normalization result plays a crucial role in several subsequent steps. In the role assignment step, the subject normalization result allows multiple field evidence units corresponding to the same subject to share subject-dimensional attribute information. This mutual corroboration through the role distribution characteristics of different fields under the same subject improves the accuracy of role binding score calculation. Simultaneously, based on the role assignment results of multiple fields for the same subject, cross-field role consistency verification can be performed, preventing the same subject from being assigned contradictory business roles in the same business context. In the role classification evidence graph construction step, the subject normalization result is the foundation for constructing role conflict edges. When two field evidence units correspond to the same subject identifier and their assigned business roles are mutually exclusive, a role conflict edge is constructed between them. Similarly, the construction of same-role corroboration edges also relies on the subject normalization result. When different field evidence units correspond to the same subject identifier and their assigned business roles are the same, same-role corroboration edges are constructed. In the candidate evidence path extraction and evidence admission steps, the subject normalization result allows candidate evidence paths to extend along different fields of the same subject, and allows other role nodes that meet the business association conditions to enter the candidate evidence path, forming a complete evidence chain. At the same time, target node screening can also be accurately located based on subject identifiers, retaining only nodes that match the target subject identifier specified by the audit task, further narrowing the scope of evidence retrieval. By unifying and associating subject information scattered in different documents through the subject normalization step, the entire audit process can organize evidence and make logical inferences across documents based on the subject, fundamentally solving the problem of inconsistent subject identities in multi-document, multi-role scenarios.

[0044] The calculation of the role binding score of the field evidence unit relative to each candidate business role in the candidate business role set, based on multi-dimensional attribute information and role attribute information, may include the following steps: obtaining the adjacent field information of the field evidence unit adjacent to the field evidence unit; obtaining the role binding record associated with the current business scenario in the historical review records; and calculating the role binding score of the field evidence unit relative to each candidate business role based on the adjacent field information, role binding record, multi-dimensional attribute information, and role attribute information.

[0045] Adjacent field information refers to information about other field evidence units that are spatially adjacent or logically related to the current field evidence unit in the same document. In paper or electronic documents, fields in the same table row, the same information block, or adjacent text paragraphs often have strong semantic connections in business context. For example, when a company name field and an address field appear adjacent to each other, they usually point to the same business role. Therefore, by introducing adjacent field information, the accuracy of role assignment can be enhanced by leveraging contextual information. Role binding records in historical audit records refer to the confirmed binding relationship data between field evidence units and business roles in previously audited documents. This data can be used as prior knowledge to assist in current role assignment decisions. When calculating the role binding score, the matching degree score between multi-dimensional attribute information and role attribute information, the support degree score of adjacent field information for candidate roles, and the confidence score of historical binding records for candidate roles can be calculated separately. Then, a comprehensive role binding score is obtained by weighted summation or weighted average. The weights of each dimension can be preset and configured according to different business scenarios.

[0046] Among them, the role attribute information of candidate business roles is a set of structured attributes used to characterize the features of business roles from multiple dimensions. Specifically, it may include role name identifier, role definition description, typical field features, associated document type, field value mode, role association relationship, and role mutual exclusion relationship. The role attributes are as follows: Role Name Identifier: Used to uniquely identify the business role, such as "Seller," "Buyer," "Shipper," "Consignee," "Notifying Party," "Issuing Bank," and "Beneficiary"; Role Definition Description: Used to describe the responsibilities and positioning of the business role in the business scenario; Typical Field Characteristics: Used to describe which field types the role typically appears in in documents, such as company name, address, and bank account number for the seller role; Related Document Types: Used to identify which types of documents the role typically appears in, such as bills of lading for the shipper role and letters of credit for the beneficiary role; Field Value Patterns: Used to describe the typical value characteristics of the fields corresponding to the role, such as specific digits and format characteristics for bank account number fields; Role Associations: Used to define the business associations between the role and other business roles, such as the corresponding relationship between the seller and buyer roles in contracts; Role Exclusions: Used to define the mutual exclusion constraints between the role and other business roles, such as the same entity not being able to simultaneously assume the roles of seller and buyer. Through these multi-dimensional role attribute information, a complete feature profile can be established for each business role, providing rich comparison benchmarks for subsequent role binding calculations.

[0047] When calculating the role binding score, the role attribute information of each candidate business role is used as a comparison benchmark and matched against the multi-dimensional attribute information of the field evidence unit. Specifically, the document type of the field evidence unit can be matched with the associated document type in the role attribute information. If the document type from which the field evidence unit originates belongs to the associated document type of the candidate business role, a matching score is generated for the corresponding dimension. The field type of the field evidence unit can be matched with the typical field features in the role attribute information. If the field type belongs to the typical field type of the candidate business role, a matching score is generated for the corresponding dimension. The field value content of the field evidence unit can be matched with the field value pattern in the role attribute information. If the field value matches the value pattern corresponding to the role, a matching score is generated for the corresponding dimension. In addition, based on the role association relationship in the role attribute information and combined with the role allocation tendency of other fields in the adjacent field information, the contextual consistency score between the current field evidence unit and the candidate business role can be calculated. After weighted fusion of the matching scores of the above dimensions, the role binding score of the field evidence unit relative to the candidate business role is obtained. By using role attribute information as a standardized comparison benchmark, the calculation of role binding scores is based on multi-dimensional matching of structured business characteristics, which significantly improves the accuracy and reliability of role allocation.

[0048] In one specific implementation, the role binding score can be calculated by weighting multiple dimensions of features, which may include text matching features, layout anchor point features, visual region features, document type prior features, adjacent field consistency features, historical binding features, subject consistency features, and document version validity features. Among them, text matching features can be obtained from the degree of matching between field text, adjacent label text and multilingual role dictionary or role synonyms, translation consistency and vector cosine similarity; layout anchor point features can be obtained from the overlap between the image region coordinates of the field and the preset role region or the region hit result, such as the preset role anchor regions such as the shipper region, consignee region, and notify party region in the bill of lading; visual region features can be obtained from the visual region classification results such as tables, seals, signatures, headers, and payment account areas; document type prior features can be obtained from the prior association between document type and business role; adjacent field consistency features can be obtained from the spatial pairing relationship between role labels and field values ​​in the same row or column or adjacent fields; historical binding features can be obtained from historical role binding records of the same enterprise, the same counterparty, the same logistics channel or the same template; subject consistency features can be obtained from whether the subject identifiers of cross documents are consistent; document version validity features can be obtained from whether the document version is in the current valid state, whether it has expired or been replaced.

[0049] The validity of a document version can be determined based on at least one of the following: version number comparison, version timestamp, or version status marker. Specifically, when multiple versions of the same document exist, the relationship between the older and newer versions can be determined by comparing the version numbers; a version with a larger version number is usually the newer version. Alternatively, the version sequence can be determined by comparing the generation or revision timestamps of each version; a version with a later timestamp is usually the newer version. Furthermore, the version validity can be directly determined by the version status marker on the document. For example, versions marked "invalid," "expired," or "replaced" are invalid versions, while versions marked "effective," "current," or "final" are valid versions. Only when the document version from which the field evidence unit originates is a valid version can that field evidence unit serve as evidence for confirming its status. If the document version is invalid, even if the role binding score is high, it should not be marked as confirmed, thus avoiding drawing incorrect audit conclusions based on an expired document version.

[0050] One feasible approach is to normalize each of the aforementioned feature factors to a value range of 0 to 1, and then sum them according to preset weights to obtain the character binding score. For example, the character binding score Score (u, r) can be calculated using the following formula:

[0051] Where u represents the field evidence unit, r represents the candidate business role, and TextMatch(u, r) represents the normalized score of the text matching feature, which measures the semantic matching degree between the text content of the field evidence unit and the typical text features of the candidate business role. It can be obtained by calculating the semantic similarity or keyword matching rate between the field text and the set of keywords for the role. This term usually has a higher weight than other terms in the formula because the text content is the most direct basis for determining role affiliation. LayoutAnchor(u, r) represents the normalized score of the layout anchor feature, which measures the degree of agreement between the layout position of the field evidence unit in the document and the typical occurrence position of the candidate business role. It can be obtained by calculating the overlap or distance between the coordinate position of the field bounding box and the preset anchor area of ​​the role. The layout position is an important auxiliary clue for role positioning in the document structure. `VisualRegion(u, r)` represents the normalized score of the visual region features, used to measure the degree of matching between the features of the visual region where the field evidence unit is located and the typical visual features of the candidate business role. It can be obtained by extracting visual features such as font, font size, color, and border of the field region and comparing them with the role visual template. Visual features can help distinguish fields with similar formats but different roles. `DocTypePrior(u, r)` represents the normalized score of the prior features of the document type, used to measure the strength of the prior association between the document type from which the field evidence unit originates and the candidate business role. It can obtain the corresponding prior probability value based on a preset document type and role association matrix. Document type provides scenario-level prior constraints for role judgment. `NeighborConsistency(u, r)` represents the normalized score of the consistency features of adjacent fields, used to measure the degree of consistency between the role tended by the adjacent fields of the field evidence unit and the current candidate business role. It can be obtained by statistically analyzing the proportion of roles in adjacent fields that have business associations with the current candidate role. The contextual information of adjacent fields can effectively correct the role judgment bias of a single field. HistoricalBinding (u, r) represents the normalized score of the historical binding feature, used to measure the binding frequency or confidence level between the current entity identifier and the candidate business role in historical review records. It can be obtained by retrieving the historical binding statistics of the corresponding entity and role from the historical binding knowledge base. Historical data provides empirical prior support for role allocation. EntityConsistency (u, r) represents the normalized score of the entity consistency feature, used to measure the consistency between the roles assigned to other fields under the same entity identifier and the current candidate business role. It can be obtained by statistically analyzing the proportion of roles already assigned under the same entity that are compatible with the current candidate role. The role distribution of the same entity should meet the requirement of business logic self-consistency.`SourceVersionValidity(u)` represents the normalized score of the document version validity feature, used to measure the validity of the document version from which the field evidence unit originates. This value is 1 when the document version is valid, and 0 or a set penalty coefficient when the document version is invalid. Version validity is a prerequisite for field evidence to be considered reliable evidence. Through the weighted fusion of the above eight sub-scores, the role binding score can comprehensively consider multiple dimensions of information, including text, layout, visual aspects, prior knowledge, context, and history, to achieve a comprehensive quantitative assessment of the matching degree between the field evidence unit and the business role. `w1` to `w8` are the preset weights for each feature. In an exemplary weight configuration, `w1` can be 0.20, `w2` can be 0.15, `w3` can be 0.10, `w4` can be 0.10, `w5` can be 0.15, `w6` can be 0.10, `w7` can be 0.10, and `w8` can be 0.10. The above weight configuration is only an implementation example and can be calibrated and adjusted based on the training results of the labeled samples.

[0052] The multi-dimensional attribute information includes document version. Determining the role status of a field evidence unit based on role binding scores can include the following steps: determining a first binding score and a second binding score among multiple role binding scores corresponding to the field evidence unit; the first binding score being higher than all other role binding scores among the multiple role binding scores corresponding to the field evidence unit except for the first binding score, and the second binding score being higher than all other role binding scores among the multiple role binding scores corresponding to the field evidence unit except for the first and second binding scores; when the first binding score reaches a preset reliability threshold, the difference between the first and second binding scores reaches a preset difference threshold, and the document version is valid, the role status of the field evidence unit is marked as confirmed; when the first binding score is lower than a preset reliability threshold, or the difference between the first and second binding scores is lower than a preset difference threshold, or the document version is invalid, the role status of the field evidence unit is marked as abnormal.

[0053] In one specific implementation, the preset reliability threshold can be set to 0.75, and the preset difference threshold can be set to 0.15. When the first binding score (highest role binding score) is not lower than 0.75, and the difference between the first binding score and the second binding score (second highest role binding score) is not lower than 0.15, and the document version is valid, the role status of the evidence unit in that field is marked as confirmed. When the first binding score is lower than the preset reliability threshold, or the difference between the first binding score and the second binding score is lower than the preset difference threshold, it indicates that the role attribution of the evidence unit in that field is uncertain, and its role status is marked as a role ambiguity type in an abnormal state. When there are mutually exclusive roles, inconsistent subject identifiers, contradictory numerical logic, or invalid document versions in the same candidate evidence path, the role status of the relevant evidence unit in that field is marked as a role conflict type in an abnormal state, or directly marked as a blocking state. The above threshold values ​​are only one implementation example and can be calibrated and adjusted according to the labeled samples in the actual business scenario.

[0054] Please see Figure 5 The diagram illustrates a flowchart of the method for determining role status provided in this application. This method uses multi-dimensional scoring features as input, which may include at least one of the following: multilingual semantic matching, visual layout anchors, document type priors, consistency of adjacent fields, historical transaction binding, subject consistency, and source version validity. Based on the above scoring features, the system calculates the role binding score of the field evidence unit relative to each candidate business role according to a preset weighting method, i.e., role_score(u, r) = Σ wi fi(u, r), where u represents the field evidence unit, r represents the candidate business role, wi represents the weight of the i-th scoring feature, and fi(u, r) represents the normalized score of the i-th scoring feature. After calculation, the system determines the first binding score (highest score) and the second binding score (second highest score) from the role binding scores corresponding to multiple candidate business roles. Then, the system uses a dual-threshold gating mechanism to determine the role status of the field evidence unit: when the first binding score is greater than or equal to the preset confidence threshold T1, and the score difference between the first binding score and the second binding score is greater than or equal to the preset difference threshold T2, and the document version is valid, the role status of the field evidence unit is marked as confirmed, i.e., the role has been confirmed; otherwise, when any of the above conditions are not met, the role status of the field evidence unit is marked as abnormal, i.e., role ambiguity or role conflict. Through the dual-threshold gating mechanism, evidence with clear role attribution and evidence with questionable roles can be effectively distinguished, preventing low-confidence or ambiguous fields from directly entering the subsequent review process.

[0055] Furthermore, when the role binding result of a field evidence unit fails to meet the criteria for confirmation, the system distinguishes whether the field evidence unit should be marked as role ambiguity or role conflict based on the clarity of the conflicting evidence and the validity of the source version. Specifically, if there is clear conflicting evidence, such as the same entity being simultaneously assigned to two mutually exclusive business roles with binding scores reaching a certain threshold, or irreconcilable logical contradictions in the values ​​of the same field in different documents, it is determined to be in a role conflict state. If there is no clear conflicting evidence, but the document version from which the field evidence unit originates is determined to be invalid, or the role binding score is below the confidence threshold and the clear source of conflict cannot be determined, it is determined to be in a role ambiguity state. Through the above distinction mechanism, the uncertainties in role allocation can be further subdivided into two categories: conflicts with clear contradictions and ambiguities caused by insufficient information. This provides a basis for the differential construction of role conflict edges and role ambiguity edges in the subsequent role classification evidence graph, enabling uncertain information of different natures to be accurately expressed in the graph structure with different edge types.

[0056] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application decompose the role allocation process into two stages: candidate generation and precise matching by first generating a set of candidate business roles and then calculating the binding score one by one. The candidate generation stage quickly narrows down the range of roles based on field attributes, avoiding the computational overhead of matching all roles. The precise matching stage performs fine-grained scoring based on multi-dimensional attributes, ensuring the accuracy of allocation, thus achieving a good balance between computational efficiency and allocation accuracy. At the same time, the introduction of role attribute information as a matching benchmark enables role allocation to be based on multi-dimensional comparison of structured role features, effectively solving the matching failure problem when field descriptions are diverse and role names are inconsistent. By introducing adjacent field information and leveraging the contextual semantics inherent in the spatial or logical adjacency relationships of fields in documents, additional supporting evidence is provided for role assignment. This allows for a comprehensive judgment of the role of a single field based on the role tendencies of surrounding fields, effectively reducing the risk of misassignment due to ambiguity or non-standard descriptions of individual field information. By introducing role binding records from historical audit records, past audit experience is transformed into prior knowledge, providing historical data support for the calculation of role binding scores. As audit data continues to accumulate, the accuracy of role assignment can be iteratively improved, achieving self-learning and self-optimization of the audit system. By setting dual judgment conditions of confidence threshold and difference threshold, combined with document version validity verification, a multi-dimensional role status confirmation mechanism is constructed. This ensures that only when the role binding result has sufficiently high confidence, is significantly distinguishable from the suboptimal role, and the source document version is valid, is a field evidence unit marked as confirmed. This guarantees from the source that all confirmation nodes entering the evidence graph have high credibility, preventing low-confidence or ambiguous role assignment results from being determined as admission evidence units and affecting the reliability of the final audit conclusion.

[0057] S105. Using field evidence units as nodes, edges are constructed based on multi-dimensional attribute information and role allocation results to obtain a role classification evidence graph.

[0058] Among them, the edges include negative edges that represent contradictory relationships between nodes.

[0059] Specifically, such as Figure 2 As shown, a structured evidence association network is constructed with field evidence units as nodes and relationships such as role corroboration, role ambiguity, role conflict, and version substitution as edges.

[0060] In an exemplary implementation, the step of constructing edges based on multi-dimensional attribute information and role allocation results may include the following steps: constructing role conflict edges based on the mutual exclusion relationship between the business roles assigned between different field evidence units under preset business rules; and / or constructing role ambiguity edges if the role status of at least one of the different field evidence units that have an association relationship under preset business rules is abnormal; and / or constructing role ambiguity edges based on the unconfirmed association relationship between different field evidence units under preset business rules; and / or constructing numerical conflict edges based on the logical contradiction relationship of numerical fields in different field evidence units; and / or constructing version substitution edges based on the substitution relationship between document versions of different field evidence units.

[0061] Among them, preset business rules refer to a set of rules pre-defined according to the business logic and compliance requirements of a specific business scenario. These rules are used to define the relationships between different business roles and the verification logic between fields. In the trade document review scenario, preset business rules may include role mutual exclusion rules and role association rules. Role mutual exclusion rules are used to define which business roles cannot be simultaneously assumed by the same entity. For example, in the same trade transaction, the same entity cannot be both the buyer and the seller at the same time, nor can it be both the shipper and the consignee at the same time. When the business roles assigned to two field evidence units meet the role mutual exclusion rules and their entity identifiers are the same, a role conflict edge is constructed between them. Logical contradictions in numerical fields refer to situations where numerical fields in different field evidence units should be consistent in business logic but actually contradict each other. Examples include inconsistencies between contract amount and invoice amount, mismatches between bill of lading quantity and packing list quantity, and discrepancies in currency conversion amounts. When such logical contradictions are detected, a numerical conflict edge is constructed between the corresponding field evidence units. The substitution relationship between document versions refers to the relationship between different versions of the same document where a new version replaces an old version. When two field evidence units come from different versions of the same document and correspond to the same field, the field evidence unit of the new version replaces the field evidence unit of the old version, and a version substitution edge is constructed between the two. The field evidence unit of the old version is no longer used as valid evidence.

[0062] In one specific implementation, role conflict edges can be constructed based on the mutually exclusive relationships between the business roles assigned to different field evidence units under preset business rules. For example, when the same field evidence unit is simultaneously assigned to both the seller and buyer roles, a role conflict edge is constructed; or, in the same document, when two different field evidence units are assigned to the same unique role (such as two different seller fields in a contract), a role conflict edge is constructed. Role ambiguity edges can be constructed based on the fact that at least one of the different field evidence units with a relationship under preset business rules is in an abnormal state. For example, when a payer field with an monetary relationship with a seller field is in an ambiguous state, a role ambiguity edge is constructed between the two. Role ambiguity edges can also be constructed based on unconfirmed relationships between different field evidence units under preset business rules. For example, when there should be an agency collection relationship between the seller field in the contract and the payee field in the payment record, but this agency collection relationship is not confirmed, a role ambiguity edge is constructed between the two. Numerical conflict edges can be constructed based on logical contradictions in numerical fields within different field evidence units, such as discrepancies between contract amounts and invoice amounts, or payments exceeding receivables. Version substitution edges can be constructed based on substitution relationships between document versions within different field evidence units. For example, when a new version of an invoice replaces an old version, a version substitution edge can be constructed between the field evidence units of the old version and the corresponding field evidence units of the new version, indicating that the old field has been replaced by the new field and should not be used as valid evidence.

[0063] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application unify the abstraction of different types of business conflicts such as role conflicts, role ambiguities, numerical contradictions, and version substitutions into negative edges in the role classification evidence graph, thereby realizing the structured expression and unified processing of heterogeneous conflict information. This allows conflicts from different sources and of different natures to be consistently identified and transmitted in the same graph structure. At the same time, the four types of negative edges correspond to different conflict detection dimensions, covering the contradictory relationships at the role semantic level, state level, numerical logic level, and version timing level, forming a comprehensive conflict detection system that ensures that all kinds of potential business risks can be captured in a timely manner and reflected in the evidence graph structure.

[0064] In an exemplary implementation, the edge also includes a positive edge representing a mutual corroboration relationship between nodes; the step of constructing edges based on multi-dimensional attribute information and role allocation results may include the following steps: constructing a same-role corroboration edge based on the fact that the business roles assigned to different field evidence units are the same; and / or constructing a cross-role association edge based on the fact that the business roles assigned to different field evidence units are different but have an association relationship under preset business rules; and / or constructing a historical binding edge based on the fact that the business roles assigned to different field evidence units have role binding records in historical audit records.

[0065] In one specific implementation, a same-role corroboration edge can be constructed based on the shared business role assigned to different field evidence units. For example, if both the seller field in the contract and the seller field in the invoice are confirmed as belonging to the seller role, a same-role corroboration edge can be constructed between them, representing mutual corroboration of evidence of the same role in different documents. A cross-role association edge can be constructed based on different business roles assigned to different field evidence units that have a relationship under preset business rules. For example, the business relationship between the seller role and the payee role, or the business relationship between the shipper role and the seller role. A cross-role association edge can establish logical connections between different business roles. A historical binding edge can be constructed based on the existence of role binding records in historical audit records for the business roles assigned to different field evidence units. For example, if a seller entity and a payee entity have a long-term agency collection relationship in historical transactions, a historical binding edge can be constructed between the corresponding field evidence units, representing the existence of a historically verified role relationship between them.

[0066] Please see Figure 6The diagram shown is a structural example of the role-based evidence diagram provided in this application embodiment. This role-based evidence diagram uses field evidence units as nodes and the relationships between nodes as edges to construct a structured evidence association network. The diagram exemplarily shows five field evidence unit nodes: Node 1 is the seller field in the contract, with a confirmed role status; Node 2 is the seller field in the pro forma invoice, with a confirmed role status; Node 4 is the payee field in the payment record, with a confirmed role status; Node 3 is the shipper field in the bill of lading, with an ambiguous role status; and Node 5 is a field in the old version of the invoice, with a version status indicating it has been superseded. The edges in the graph are divided into two categories: positive edges and negative edges. Positive edges represent mutual corroboration or association between nodes. For example, the same-role corroboration edge between node 1 and node 2 indicates that both are sellers and corroborate each other; the cross-role relationship edge between node 2 and node 4 indicates that there is a business relationship between the seller and the payee. Negative edges represent contradictions between nodes. For example, the role ambiguity edge between node 2 and node 3 indicates that the role attribution of node 3 is ambiguous; the numerical conflict edge and role conflict edge between node 3 and node 5 indicate that there is a logical contradiction in their numerical or role information; the version replacement edge from node 5 to node 2 indicates that the old version of the document corresponding to node 5 has been replaced by the new version of the document corresponding to node 2. In addition, the role classification evidence graph can also include historical binding edges to represent the role binding relationships that exist in historical audit records. Through the above-mentioned various types of graph edges, the role classification evidence graph can explicitly express the complex logical relationships such as corroboration, association, conflict, and replacement between evidence, providing a structured foundation for subsequent candidate evidence path extraction, risk detection, and evidence admission.

[0067] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application introduce positive edges to construct mutual corroboration relationships between field evidence units, so that the role classification evidence graph can not only express conflicts and contradictions, but also support and corroboration, forming a complete evidence association network; the same role corroboration edges strengthen the evidence linkage between different fields under the same role, the cross-role association edges establish business connections between different roles, and the historical binding edges solidify historical experience into connection relationships in the graph structure. The three work together to make the extraction of candidate evidence paths more in line with business logic and improve the completeness and persuasiveness of the evidence chain.

[0068] S107, in response to the audit task, extract the evidence path from the role classification evidence graph based on the target business role carried by the audit task; and determine the key fields of the task based on the business facts inquired by the audit task.

[0069] Specifically, by extracting evidence paths from the role-based evidence diagram, scattered field evidence units can be organized into logically related evidence chains, making the formation of audit conclusions have a clear evidence path to follow, and improving the interpretability and traceability of the audit process.

[0070] Among them, the key fields of the task refer to the necessary fields determined based on the problem description, target field type, and target document type of the audit task, used to determine whether the business facts involved in the audit task are true. For example, when the audit task is "to determine whether the seller has completed the receipt of payment", the business fact that the audit task inquires about is whether the payment corresponding to the current transaction has been paid to the seller or the seller's approved agent for collection. Based on this business fact, the system determines at least one of the following as the key fields of the task: the seller's identity in the contract or invoice, the payee's identity in the payment record, the relationship between the seller and the agent for collection, and the transaction number, payment amount, currency, and payment date used to determine the transaction corresponding to the payment.

[0071] In an exemplary implementation, the step S107 above, which involves extracting evidence paths from the role classification evidence graph based on the target business role carried by the audit task, may specifically include the following steps: performing role constraint retrieval in the role classification evidence graph based on the target business role to obtain candidate evidence paths; the nodes in the candidate evidence paths include anchor nodes that match the target business role carried by the audit task, and associated nodes that have edges (including positive or negative edges) with the anchor nodes; based on the role allocation results and multi-dimensional attribute information, performing evidence admission judgment on each node in the candidate evidence paths, and determining the nodes that pass the evidence admission judgment as admission evidence units; and determining the evidence path based on the admission evidence units and the edges between the admission evidence units in the role classification evidence graph.

[0072] Among them, the associated node can be a field evidence unit that has a same role corroboration relationship, cross-role association relationship, role conflict relationship or numerical contradiction relationship with the anchor node.

[0073] Among them, the candidate evidence path is an initial set of evidence that has not been screened for admission. Its purpose is to recall as much evidence as possible related to the review task while ensuring the relevance of the evidence, so as to avoid missing key evidence.

[0074] The evidence admission determination is a crucial step in filtering the quality of nodes in the candidate evidence path. The determination criteria include, but are not limited to, whether the role status of the field evidence unit is confirmed, whether the document version is valid, whether the subject identifier matches the target subject specified in the audit task, and whether the document type and field type meet the search criteria of the audit task. Nodes that pass the evidence admission determination are designated as admissible evidence units, which are field evidence units qualified to serve as audit evidence. Nodes that fail the evidence admission determination (e.g., nodes with an abnormal role status, or nodes whose document versions are invalid or have been replaced) are excluded from subsequent evidence paths, thus filtering out interfering evidence before the evidence path is determined.

[0075] The evidence path consists of field evidence units that are eligible for inclusion and the edges between them, ensuring that each node in the evidence path is qualified to serve as the basis for review, and each edge represents the relationship between two qualified pieces of evidence.

[0076] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application decompose the evidence path extraction process into two screening stages: role constraint retrieval (broad recall) and evidence admission judgment (strict admission). The role constraint retrieval stage uses the target business role as the anchor point to ensure the relevance and comprehensiveness of the evidence recall. The evidence admission judgment stage uses the role allocation result and multi-dimensional attribute information as the basis to achieve precise filtering of evidence quality. This makes the final extracted evidence path not only fully cover the evidence related to the review task, but also effectively exclude interference evidence units that do not have the qualifications for review, such as abnormal role status or invalid version. This provides a reliable evidence basis for subsequent contradiction detection and review conclusion generation.

[0077] In an exemplary implementation, the multi-dimensional attribute information includes document type, field type, subject identifier, and document version. The step of performing role constraint retrieval in the role classification evidence graph based on the target business role to obtain candidate evidence paths may include the following steps: based on the target business role, target document type, target field type, target subject identifier, and target document version carried by the audit task, anchor nodes are selected from the nodes in the role classification evidence graph; anchor nodes and related nodes in the role classification evidence graph that have edges with anchor nodes are selected as candidate nodes; and candidate evidence paths are determined based on the candidate nodes and the edges between candidate nodes in the role classification evidence graph.

[0078] Among them, field evidence units with abnormal role status or invalid document version are retained in the candidate evidence path for evidence admission determination, risk warning or manual review, but are not used as admission evidence units for consistency verification and positive audit conclusion generation.

[0079] Specifically, the system recalls anchor nodes based on at least one of the following: target business role, target document type, target field type, target entity identifier, and target document version carried by the audit task. It also expands associated nodes based on same-role corroboration edges, cross-role association edges, or historical binding edges, while retaining negative edges associated with anchor nodes and their endpoints. Candidate evidence paths may include field evidence units matching the target business role, as well as field evidence units of other business roles associated with the target business role based on preset business association relationships. Candidate evidence paths may also include field evidence units with abnormal role status or invalid source versions, used for subsequent evidence admission determination, risk warnings, or manual review.

[0080] In practice, the extraction of candidate evidence paths can be based on graph traversal algorithms. Specifically, the target business role, target document type, target field type, target subject identifier, and target document version can be determined first based on the audit task. Then, starting from any anchor node that satisfies any of the above targets, a depth-first traversal or breadth-first traversal is performed along the edges in the role classification evidence graph. During the traversal, only the anchor nodes that match any of the above targets, the associated nodes connected to the anchor nodes, and the edges between the retained nodes are retained to obtain the candidate evidence paths.

[0081] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application pre-screen the confirmation status nodes based on multi-dimensional conditions such as target business role, target document type, target field type, target subject identifier, and target document version, and then extract evidence paths based on the screened target nodes. This is equivalent to completing precise filtering at the node level before traversing the path, which greatly reduces the scale of nodes that need to be traversed and significantly improves the efficiency of evidence path extraction. At the same time, the multi-dimensional screening conditions ensure that the extracted evidence paths are highly matched with the needs of the audit task, avoid irrelevant evidence interfering with the audit judgment, and improve the accuracy of the audit results.

[0082] In an exemplary implementation, the step of determining the evidence admission of each node in the candidate evidence path based on the role allocation result and multi-dimensional attribute information, and determining the node that passes the evidence admission determination as the admission evidence unit, may include: for the nodes in the candidate evidence path, determining the nodes whose role status is confirmed and whose document version is valid as the admission evidence unit.

[0083] Among them, the candidate evidence path refers to the set of evidence obtained through role constraints in response to the review task that has not yet been subject to evidence admission judgment. It may include field evidence units whose role status is confirmed or abnormal, and whose source version is valid or invalid.

[0084] Among them, the admission evidence unit refers to the field evidence unit where the role status is confirmed and the source version is valid.

[0085] like Figure 2 As shown, when an audit task is initiated, the system filters evidence according to business role, subject identifier, field type, document type, and document version through the role constraint retrieval module based on the target business role and problem description; only field evidence units with a confirmed role status and a valid document version are allowed to enter the subsequent process.

[0086] As can be seen from the above technical solutions of the embodiments of this application, in the embodiments of this application, the system only allows field evidence units with a confirmed role status and a valid document version to enter the evidence path; for field evidence units with an abnormal role status (including role ambiguity and role conflict) or an invalid document version, they are not included in the evidence path, thereby completing the role confirmation gate before the evidence enters the consistency verification and the generation of the affirmative audit conclusion, and avoiding the pollution of the audit basis by evidence with unconfirmed roles or invalid versions.

[0087] Please see Figure 7 The diagram illustrates the flowchart of the candidate evidence path extraction and evidence admission method provided in this application embodiment. This method uses an audit task as the input starting point, which carries the target business role, problem description, and field requirement information. Based on the audit task, the system performs a joint search across multiple retrieval indexes, which may include at least one of the following: role-based evidence graph index, text vector index, image region index, and document version index. The search results are filtered multi-dimensionally by a role constraint filtering module. Specific filtering conditions include: role status is confirmed, subject identifier matches the target subject, document version is valid, and document type and field type match the target. After role constraint filtering, the results are divided into two categories: one is a blocked state, i.e., evidence paths with issues such as role ambiguity, invalid version, or numerical conflicts are directly blocked and do not enter the subsequent consistency verification and generation process; the other is an admitted state, i.e., evidence paths that meet all filtering conditions. These paths are further sorted and optimized by a reordering module, based on factors such as role consistency, subject consistency, source weight, and evidence confidence. The rearranged access evidence path is output to subsequent modules, entering the consistency verification and controlled generation process of audit conclusions. Through the above-mentioned role constraint retrieval and filtering mechanism, role confirmation gating can be completed before evidence enters the verification and generation process, effectively filtering out interfering evidence with abnormal role status or invalid version.

[0088] S109, when the evidence path does not include any task key field, or when there is a negative edge in the evidence path with an unresolved conflicting relationship, the generation of an affirmative audit conclusion for the audit task is blocked.

[0089] In this system, negative edges in the evidence path are those related to the audit task. At least one endpoint of each negative edge connects to a field evidence unit that is a key field of the task, ensuring that the conflict represented by the negative edge directly relates to the business facts that the audit task requires to verify. The field evidence units corresponding to the two endpoints of the negative edge belong to the same audit object; that is, the entity identifier, transaction package identifier, or business object identifier associated with the two endpoints is consistent. This ensures that the conflict represented by the negative edge occurs between different pieces of evidence within the same audit object, rather than a superficial conflict arising from different entities across fields of different audit objects. Based on this, it is possible to effectively distinguish between substantive conflicts directly related to the audit task and non-substantive conflicts unrelated to the audit task or across objects, avoiding erroneous blocking of the generation of affirmative audit conclusions due to irrelevant negative edges in the evidence path, and further improving the accuracy and reliability of audit blocking.

[0090] Among them, negative edges whose corresponding contradictions have not been resolved refer to those whose contradictions have not been eliminated by manual review results or valid version evidence, and whose contradictions still affect the current audit conclusion. Negative edges corresponding to contradictions eliminated by manual review results or valid version evidence are marked as resolved and will no longer trigger blocking, but these negative edges may be retained for audit purposes.

[0091] For example, the payee in a payment record could be the seller or an unrelated third party, and the system could not find a matching entity or a valid agency relationship. In this case, the payee's role remains uncertain, and this ambiguity directly affects whether the seller has completed payment collection. Therefore, it represents an unresolved negative aspect of the corresponding contradictory relationship, and an affirmative conclusion should be blocked. If manual verification confirms that the payee is the seller's agent and a valid agency relationship is recorded, then the ambiguity is resolved and no longer needs to be blocked.

[0092] For example, the candidate evidence path may contain both old and new versions of invoices, with a version substitution edge between them. If it cannot be determined which version is currently valid, the version substitution relationship is not yet resolved and should be blocked; if the new version is confirmed to be valid and the key fields of the task have been covered by the new version's admission evidence, the old version is not allowed, but the version issue has been resolved, and the generation of conclusions based on the new version is not blocked.

[0093] For example, if the contract amount is 1 million yuan and the invoice amount is 1.2 million yuan, and the system finds no supplementary contract, price adjustment record, or other explanatory materials, this discrepancy still affects the current audit facts and therefore constitutes an unresolved numerical conflict. If the system finds a valid supplementary contract confirming that the transaction amount has been adjusted from 1 million yuan to 1.2 million yuan, then the conflict has been explained by valid evidence and will no longer trigger a blocking mechanism.

[0094] Specifically, when the evidence path does not include any of the key fields corresponding to the business facts inquired about by the audit task, it indicates that the key business facts lack evidentiary support and an affirmative conclusion should not be generated; when there is a role conflict edge in the evidence path and the role conflict contradiction has not been resolved, it indicates that there is a logical contradiction of mutual exclusion between roles among the evidence and an affirmative conclusion should not be generated; when there is a role ambiguity edge in the evidence path and the role ambiguity contradiction has not been resolved, it indicates that the role attribution of the key evidence has not been confirmed and is insufficient to support an affirmative conclusion; when there is a numerical conflict edge in the evidence path and the numerical conflict contradiction has not been resolved, it indicates that there is a numerical logical contradiction among the evidence and an affirmative conclusion should not be generated; when there is a version substitution edge in the evidence path and the version conflict contradiction has not been resolved, it indicates that the evidence path contains fields from old versions that have been substituted or invalid documents and should not be used as valid evidence to generate an affirmative conclusion.

[0095] Specifically, the evidence admission determination is used to determine whether a single field evidence unit can be used as evidence. Two field evidence units may be qualified when viewed separately, but may still conflict when placed together. Negative edges are used to determine whether there is a contradiction between two field evidence units.

[0096] For example, the audit task is to determine whether the payable amount for the current transaction is USD 100,000. The candidate evidence path includes the following evidence units: "Contract Amount: USD 100,000, Seller Role Confirmed, Contract Version Valid" and "Commercial Invoice Amount: USD 120,000, Seller Role Confirmed, Invoice Version Valid." After evidence admission, both the contract amount and the invoice amount evidence units pass the admission test. However, the amounts are inconsistent, resulting in a numerical conflict. At this point, while individual pieces of evidence are credible, the relationship between the evidence is contradictory, and the numerical conflict remains unresolved. Therefore, a definitive conclusion that "the payable amount is USD 100,000" cannot be generated. If a valid supplementary contract is later found, proving that the amount has been adjusted from USD 100,000 to USD 120,000, the numerical conflict is resolved, and the system can continue verification based on the supplementary contract and the new invoice.

[0097] For example, the audit task is to determine whether the seller has completed receiving payment. The candidate evidence path includes the following field evidence units: "The seller in the invoice is Company A, role confirmed, version valid," and "The payee in the payment record is Company B, role confirmed, payment record version valid." Both are admissible evidence units. However, it cannot be confirmed whether Company B is Company A's agent for receiving payment; the role ambiguity between the seller node and the payee node still exists. Since this ambiguity directly affects "whether payment was made to the seller or its agent," it represents an unresolved negative edge, thus blocking the affirmative conclusion. If manual review confirms that Company B is a valid agent for receiving payment for Company A, then Company B's payee field can be used as admissible evidence, the corresponding role ambiguity is resolved, and the original negative edge can remain in the graph for auditing purposes, but will no longer trigger blocking.

[0098] It should be noted that after the evidence admission determination is completed for the candidate evidence path, the field evidence units that are not determined as admission evidence units and the related negative edges are still retained in the candidate evidence path for risk detection and manual review; the negative edges between admission evidence units are used to determine whether there are unresolved contradictions between different admission evidence units.

[0099] Accordingly, when the evidence path includes key fields of each task and there are no negative edges in the evidence path where the corresponding contradiction relationship has not been resolved, the field evidence units in the evidence path are verified; if the verification passes, an affirmative audit conclusion for the audit task is generated.

[0100] In practice, this verification refers to consistency verification, which may include at least one of the following: amount, currency, quantity, date, address, entity, payment / receipt relationship, and logistics entity. If the consistency verification fails, the generation of an affirmative audit conclusion will be blocked; if the consistency verification passes, an affirmative audit conclusion will be generated based on the access evidence unit, and at least one of the following evidence citation information will be output: field value, business role, source document, page number, image area coordinates, entity identifier, and document version.

[0101] In an exemplary implementation, after step S109, the following steps may also be included: generating risk warning information for nodes associated with negative edges in the candidate evidence path; and / or outputting rejection results to the review end; and / or dispatching a review task carrying the candidate evidence path and the reason for blocking to the manual review platform.

[0102] Specifically, manual review tasks include the candidate evidence path and the reasons for blocking it; affirmative audit conclusions cite the access evidence unit. In addition, the audit log records the audit results and the basis for decision-making.

[0103] In one specific implementation, while blocking an affirmative review conclusion, the system can generate risk warning information for nodes associated with negative edges in the candidate evidence path, clearly indicating the conflict type, the field evidence units involved, and the specific reasons; and / or output a rejection result to the review end, indicating that the current evidence is insufficient to support an affirmative conclusion; and / or dispatch a review task carrying the candidate evidence path and the reasons for blocking to the manual review platform, whereby manual reviewers confirm and adjudicate the evidence with conflicts or ambiguities.

[0104] Please see Figure 8 The diagram illustrates the flowchart of the consistency verification and controlled conclusion generation method provided in this application. This method takes an evidence path as input, which contains a set of task-critical field evidence units related to the audit task. The system first performs a first-level judgment: determining whether all field evidence units in the evidence path are in a role-confirmed state and whether the source version (i.e., document version) is valid. If any field evidence unit has an unconfirmed role or an invalid document version, the system directly blocks the positive result generation, outputs a rejection result, risk warning information, or a manual review task, and writes the reason for the blocking to the runtime audit log. Combined with... Figure 2If all evidence units are confirmed and the document version is valid, the system proceeds to the second stage of judgment: checking whether key fields such as amount, currency, quantity, date, and subject are consistent among the evidence. If there are inconsistencies in these key fields, i.e., numerical or subject conflicts, the system will also block the generation of a positive conclusion, outputting a rejection result, risk warning information, or a manual review task, and recording the corresponding reasons for the block. If all key fields are consistent, the system generates a positive audit conclusion, which includes complete evidence citation information such as field values, business roles, documents, page numbers, image area coordinates, and version, to ensure the traceability and interpretability of the audit conclusion. Regardless of whether a positive or blocking conclusion is ultimately generated, the system will write the audit results and decision basis to the operational audit log, recording the specific reasons for evidence admission or blocking. The system outputs evidence citation information, which carries multi-dimensional location information such as field values, business roles, source documents, page numbers, bounding boxes, and document versions. Specifically, field values ​​identify the specific content of the cited evidence, business roles indicate the assigned business role, source documents identify the document from which the evidence originates, page numbers indicate the page number position of the evidence within the document, bounding boxes indicate the spatial coordinates of the evidence within the document page, and document versions indicate the version of the document from which the evidence originates. By outputting evidence citations with this multi-dimensional location information, audit conclusions, rejection results, risk warnings, and manual review tasks can all be accurately traced to their specific evidence sources. Auditors can quickly locate the corresponding field positions in the document for verification based on the evidence citation information, significantly improving the interpretability and traceability of audit results. It also provides precise data support for subsequent audit verification and quality backtracking.

[0105] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application realize a graded handling mechanism after risk interception by providing risk warnings, rejection outputs, and manual review assignments after blocking affirmative review conclusions. This not only provides timely feedback of risk information to the review end, but also accurately transfers complex or questionable cases to the manual review platform, ensuring a reasonable balance between security and processing efficiency in the automated review system. At the same time, dispatching review tasks with candidate evidence paths and reasons for blocking to the manual review platform allows manual reviewers to directly locate evidence nodes with contradictions and conflicts, without having to sort through all documents from scratch, greatly improving the efficiency and pertinence of manual review.

[0106] In one specific implementation, the system can also record operational audit logs and manual review results. The operational audit logs can record the role allocation process, role binding score, role status, evidence path extraction results, and the decision basis for generating or blocking affirmative conclusions for each field's evidence unit, making the entire review process traceable and auditable. For manual review tasks, when a human reviewer completes the review and provides a correction result, the system can record information such as the original field evidence unit, the incorrect role, the corrected role, image region coordinates, document type, subject identifier, document version, and review reason, and construct role mismatch difficulty examples by combining these incorrect roles with the corrected roles. These role mismatch difficulty examples can be used to subsequently update the role disambiguation model, retrieval rearrangement model, role dictionary, or historical binding index, thereby continuously improving the accuracy of role allocation and the reliability of evidence path extraction. Through this closed-loop mechanism of audit logs and manual review feedback, the system can continuously accumulate difficulty examples and optimize the model during actual operation, gradually reducing the role mismatch rate and evidence false admission rate. It should be noted that manual review uses candidate evidence paths, while affirmative conclusions and evidence citations use admission evidence units.

[0107] like Figure 2 As shown, the erroneous roles and corrected roles in the review process are constructed as difficult case samples, which are used to update the role disambiguation model and retrieval rules, forming a closed loop of continuous optimization.

[0108] Please see Figure 9The diagram illustrates the process flow of the operation audit log and manual review feedback provided in this embodiment. The process begins with the operation audit log, which records information such as the operation identifier, transaction package identifier, subject identifier, role binding score, gating decision, and evidence citation unit for each review. Based on the operation audit log, the system calculates verification metrics, which may include at least one of the following: false positive rate, false negative rate, role binding accuracy, citation accuracy, version leakage rate, and manual time consumption, to quantitatively evaluate the overall system performance. When a manual review task exists, the manual review result includes information such as the incorrect role, the corrected role, and the review reason. The system constructs the pairing of the incorrect role and the corrected role as a role mismatch hard case sample for subsequent model optimization. Based on the above hard case samples and verification metrics, the system updates relevant objects, which may include at least one of the following: role dictionary, scoring weight, historical binding index, and retrieval reordering model. After the update is completed, the system enters the next verification phase, which uses a fixed test set for verification to prevent sample leakage and ensure the objectivity and reliability of the evaluation results. The verification results can be fed back to the verification indicator calculation stage, forming a closed-loop mechanism for continuous iterative optimization. Through the above-mentioned operational audit and manual review feedback mechanism, the system can continuously accumulate difficult case samples, optimize model parameters and rules in actual operation, and gradually improve the accuracy of role disambiguation and the reliability of evidence retrieval.

[0109] As can be seen from the above technical solutions of the embodiments of this application, the embodiments of this application independently assign business roles to each field evidence unit based on multi-dimensional attribute information, and extract the business semantics of "role" from the text content and make it explicit into a data structure. With the field evidence unit as the node and the role assignment result and attribute association as the edge, a role classification evidence graph containing "negative edges" is constructed. This graph explicitly solidifies the conflict logic such as role mutual exclusion, numerical contradiction, and version substitution in the graph with the edge structure, so that the logical conflict between evidence becomes an organic part of the graph topology. When an audit task arrives, evidence paths are extracted from the role-based evidence graph based on the target business role carried by the audit task. Key task fields are determined according to the business facts inquired about by the audit task. This is equivalent to completing a "role security check" and "path pruning" of the evidence before entering consistency verification, effectively filtering out interfering evidence that does not match the audit task. When the selected evidence path does not include any key task field, or contains unresolved negative edges indicating contradictory relationships, it means that there are still irreconcilable logical contradictions between the nodes in the evidence path, or that the key business facts lack evidentiary support. In this case, the generation of a positive conclusion is forcibly blocked. When the evidence path covers all key task fields and has no unresolved negative edges, the evidence path is verified, and a positive conclusion is generated after verification. This application establishes structured contradiction expression and path blocking rules at the data level, enabling the reliable identification and interception of complex business conflicts across documents and roles. This significantly reduces the risk of missed reports due to role confusion, while precisely narrowing the scope of review to the path nodes where contradictions truly exist, achieving a simultaneous improvement in audit security, interpretability, and computational efficiency.

[0110] To facilitate a full understanding of the proposed solution, a specific example of cross-border trade document review will be used for illustration below.

[0111] In this embodiment, the system first prepares a cross-border trade document review environment, deploying text recognition, layout analysis, vector retrieval, graph databases or relational databases, and large language model calling services, and establishing field templates and role dictionaries for document types such as contracts, invoices, bills of lading, and payment records. The system acquires multiple documents from a transaction package, such as contracts, pro forma invoices, bills of lading, and bank payment records, and assigns a transaction package identifier to the package. For each document, optical character recognition, layout analysis, and image region recognition are performed to obtain text blocks, field labels, field values, page numbers, and image region coordinates. For example, the system recognizes the seller field in a contract, the beneficiary field in an invoice, the shipper / consignee / notifying party area in a bill of lading, and the payee field in a payment record. The recognition results are encapsulated into field evidence units, each recording the field text, document type, page number, image region coordinates, field type, document version, extraction confidence level, and adjacent field information.

[0112] The system normalizes information such as subject name, address, account number, and tax number in the field evidence unit to generate subject identifiers. For example, different expressions such as "A Trading Co., Ltd.", "A Trading Ltd.", and "A TRADING" are merged into the same subject identifier to achieve subject consistency association across documents. A set of candidate business roles is generated for each field evidence unit. For example, the contract seller field generates candidate seller roles; the bill of lading shipper area generates candidate shipper and seller roles; the bill of lading notify party area generates candidate notify party and consignee roles; and the bank payment record payee field generates candidate payee, agent payee, and seller roles. The system calculates the role binding score for each candidate business role. Specifically, the system calculates text matching score, layout anchor point score, visual area score, document type prior score, adjacent field consistency score, historical binding score, subject consistency score, and document version validity score, and weights them according to preset weights to obtain a total score. The first binding score is compared with a preset reliability threshold, and the difference between the first binding score and the second binding score is compared with a preset difference threshold. For example, if the first binding score is not less than 0.75, the difference between the first binding score and the second binding score is not less than 0.15, and the document version is valid, the evidence unit of this field is marked as confirmed; otherwise, it is marked as abnormal (including role ambiguity or role conflict).

[0113] The system constructs a role-based evidence graph, where nodes are field evidence units and edges include positive and negative edges. Positive edges include edges that corroborate within the same role, those that are related across roles, and those that are historically linked; negative edges include edges that conflict with a role, those that are ambiguous about a role, those that conflict with a value, and those that replace a version. When the audit task is "to determine whether the seller has completed payment," the system identifies the target business role as the seller and performs a role constraint search in the role-based evidence graph, retrieving seller evidence in confirmed status in contracts and invoices, payee evidence in payment records, and historical agency payment relationships. If the payee in the payment record has the same entity identifier as the seller in the contract or invoice, or is confirmed to be an agent for that seller, and the amount, currency, date, and document version all meet the audit conditions, the system generates a positive audit conclusion, citing field values, business roles, documents, page numbers, image area coordinates, and document versions as evidence. If the payee in the payment record cannot be confirmed as the seller or an agent for payment, the system outputs a role ambiguity prompt or a manual review task. In this embodiment, the target business role is the seller, which is used to limit the target facts and retrieval direction of the audit task; the candidate evidence path may include the payee or agent payee field evidence unit in the payment record. When the role status is confirmed, the document version is valid, and the business relationship between the seller and the seller meets the preset conditions, the field evidence unit is used as admission evidence to generate an affirmative audit conclusion that "the seller has completed the receipt of payment".

[0114] When manual review confirms that a field was originally misclassified as belonging to the seller but actually belonged to the shipper or the notifying party, the system records the original field, the incorrect role, the corrected role, the image region coordinates, the document type, the subject identifier, the document version, and the reason for review. This creates a sample of role mismatch difficulties for subsequent updates to the role disambiguation model, retrieval rearrangement model, or historical binding index. For documents with revised versions, the system records the document version status. When an old invoice has been replaced by a confirmed valid new invoice, and the evidence unit derived from the new invoice includes the corresponding task-critical field, the field evidence unit derived from the old invoice is not included in the generation of an affirmative audit conclusion (i.e., it is not admitted). However, its corresponding version replacement edge does not prevent the generation of an affirmative audit conclusion based on the new invoice. Through the above implementation methods, in cross-border trade multi-document material review scenarios, the system can first confirm and disambiguate the business roles of field evidence units before deciding whether the evidence can enter the retrieval, verification, and positive review conclusion generation, thereby effectively reducing erroneous citations and erroneous review conclusions caused by role mismatch. By adding business role confirmation gating before evidence enters the retrieval and generation process, the system reduces the risk of erroneous evidence admission caused by misbinding roles such as seller and shipper, consignee and notify party, and payee and seller. By unifying the different ways of writing the same subject in different documents through subject identification, the system reduces erroneous verification caused by subject inconsistency. By using dual-threshold role gating, the system distinguishes and handles role confirmation status, role ambiguity, and role conflict separately, preventing low-confidence fields from directly entering positive conclusions. By only allowing evidence with a confirmed status and valid document version to enter the verification and generation process, the system reduces the risk of cross-role evidence contaminating the retrieval and generation process, and lowers the probability of erroneous citations and erroneous positive conclusion generation.

[0115] Corresponding to the document review methods provided in the above embodiments, this application also provides a document review device. Since the document review device provided in this application corresponds to the document review methods provided in the above embodiments, the implementation methods of the aforementioned document review methods are also applicable to the document review device provided in this embodiment, and will not be described in detail in this embodiment.

[0116] Please see Figure 10 The diagram shows a structural schematic of a document review device provided in an embodiment of this application. This device 1000 has the function of implementing the document review method described in the above method embodiment. This function can be implemented by hardware or by hardware executing corresponding software. Figure 10 As shown, the device 1000 may include: The field acquisition module 1010 is used to acquire multiple field evidence units extracted from multiple documents; the field evidence units carry multi-dimensional attribute information. The role assignment module 1020 is used to determine the role assignment result of each field evidence unit based on multi-dimensional attribute information; the role assignment result includes the assigned business role. The evidence graph construction module 1030 is used to construct edges based on multi-dimensional attribute information and role allocation results, with field evidence units as nodes, to obtain a role classification evidence graph; the edges include negative edges that represent contradictory relationships between nodes; The evidence extraction module 1040 is used to extract evidence paths from the role classification evidence graph based on the target business role carried by the audit task in response to the audit task. The field determination module 1050 is used to determine the key fields of the task based on the business facts inquired about in the audit task. The audit blocking module 1060 is used to block the generation of a positive audit conclusion for the audit task when the evidence path does not include any key field of the task, or when there is a negative edge in the evidence path with an unresolved contradiction.

[0117] In one exemplary embodiment, the apparatus 1000 further includes a conclusion generation module for generating an affirmative review conclusion, the conclusion generation module comprising: The evidence verification module is used to verify the field evidence units in the evidence path when the evidence path includes key fields of each task and there are no negative edges in the evidence path where the corresponding contradiction relationship has not been resolved. The verification-passing module is used to generate a positive audit conclusion for the audit task if the verification passes.

[0118] In one exemplary embodiment, the evidence extraction module 1040 includes: The constraint retrieval module is used to perform role constraint retrieval in the role classification evidence graph based on the target business role to obtain candidate evidence paths. The nodes in the candidate evidence paths include anchor nodes that match the target business role carried by the review task, as well as associated nodes that have edges with the anchor nodes. The evidence admission module is used to make evidence admission judgments for each node in the candidate evidence path based on the role allocation results and multi-dimensional attribute information, and to determine the nodes that pass the evidence admission judgment as admission evidence units. The evidence determination module is used to determine the evidence path based on the admission evidence unit and the edges between admission evidence units in the role classification evidence graph.

[0119] In one exemplary implementation, the role assignment result also includes role status, which is either a confirmed status or an abnormal status; multi-dimensional attribute information includes document version; and the evidence access module includes: The Admission Evidence Determination Module is used to determine nodes in the candidate evidence path that have a confirmed role status and a valid document version as admission evidence units.

[0120] In one exemplary embodiment, the role assignment module 1020 includes: The candidate generation module is used to generate a set of candidate business roles for each field evidence unit; The attribute acquisition module is used to acquire the role attribute information of each candidate business role in the candidate business role set; The score calculation module is used to calculate the role binding score of the field evidence unit relative to each candidate business role in the candidate business role set based on multi-dimensional attribute information and role attribute information. The role determination module is used to determine the role status and assigned business role of the field evidence unit based on the role binding score.

[0121] In one exemplary embodiment, the fraction calculation module includes: The neighborhood acquisition module is used to acquire the neighboring field information of the field evidence unit that is adjacent to the field evidence unit; The history retrieval module is used to retrieve role binding records from historical audit records that are associated with the current business scenario; The comprehensive calculation module is used to calculate the role binding score of the field evidence unit relative to each candidate business role based on adjacent field information, role binding records, multi-dimensional attribute information, and role attribute information.

[0122] In one exemplary implementation, the multi-dimensional attribute information includes document version; the role determination module includes: The sorting determination module is used to determine the first binding score and the second binding score among multiple role binding scores corresponding to the field evidence unit; the first binding score is higher than the role binding scores other than the first binding score among the multiple role binding scores corresponding to the field evidence unit, and the second binding score is higher than the role binding scores other than the first binding score and the second binding score among the multiple role binding scores corresponding to the field evidence unit. The status marking module is used to mark the role status of the field evidence unit as confirmed when the first binding score reaches the preset confidence threshold, the difference between the first binding score and the second binding score reaches the preset difference threshold, and the document version is valid.

[0123] In an exemplary embodiment, the device 1000 further includes an anomaly marking module, which is used to mark the role status of the field evidence unit as an anomaly state when the first binding score is lower than a preset confidence threshold, or the difference between the first binding score and the second binding score is lower than a preset difference threshold, or the document version is invalid.

[0124] In one exemplary implementation, the evidence graph construction module 1030 includes at least one of the following: The conflict edge construction module is used to construct role conflict edges based on the mutual exclusion relationship between business roles assigned between different field evidence units under preset business rules. The first ambiguity edge construction module is used to construct a role ambiguity edge if at least one of the different field evidence units that have a relationship under the preset business rules is in an abnormal state. The second ambiguity edge construction module is used to construct role ambiguity edges based on the unconfirmed associations between different field evidence units under preset business rules. The numerical edge construction module constructs numerical conflict edges based on the logical contradictions between numerical fields in different field evidence units. The version edge construction module is used to construct version substitution edges based on the substitution relationship between document versions with different field evidence units.

[0125] In one exemplary implementation, the edges also include positive edges representing the existence of mutual corroboration relationships between nodes; the evidence graph construction module 1030 includes at least one of the following: The Same Role Edge module is used to construct same role corroboration edges based on evidence units in different fields that are assigned the same business role. The cross-role edge module is used to construct cross-role association edges based on different business roles assigned to different field evidence units that have a relationship under preset business rules. The Historical Binding Edge module is used to construct historical binding edges based on the role binding records of business roles assigned to different field evidence units in historical audit records.

[0126] In one exemplary implementation, the multi-dimensional attribute information includes document type, field type, subject identifier, and document version; the constraint retrieval module includes: The anchor node filtering module is used to filter anchor nodes from the nodes of the role classification evidence diagram based on the target business role, target document type, target field type, target subject identifier, and target document version carried by the audit task. The candidate node determination module is used to select the anchor node and the related nodes in the role classification evidence graph that have edges with the anchor node as candidate nodes. The candidate path determination module is used to determine candidate evidence paths based on candidate nodes and the edges between candidate nodes in the role classification evidence graph.

[0127] In one exemplary embodiment, the apparatus 1000 further includes a post-processing module for post-processing after blocking the generation of an affirmative audit conclusion for the audit task, the post-processing module including at least one of the following: The risk warning generation module is used to generate risk warning information for nodes associated with negative edges in the candidate evidence path; The rejection output module is used to output rejection results to the review end; The review and dispatch module is used to dispatch review tasks to the manual review platform, which include the candidate evidence path and the reason for the block.

[0128] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0129] This application provides a document review system, which includes a processor and a memory. The memory stores at least one instruction or at least one program. The processor loads and executes the instruction or program to implement any of the document review methods provided in the above method embodiments.

[0130] This application provides an electronic device including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement any of the document review methods provided in the above method embodiments.

[0131] Memory is used to store software programs and modules. The processor executes these stored software programs and modules to perform various functional applications and data processing. Memory can primarily consist of a program storage area and a data storage area. The program storage area stores the operating system, application programs required for functionality, etc.; the data storage area stores data created based on device usage, etc. Furthermore, memory can include high-speed random access memory (RAM) and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory can also include a memory controller to provide the processor with access to the memory.

[0132] The method embodiments provided in this application can be executed in a computer terminal, server or similar computing device, that is, the above-mentioned electronic device may include a computer terminal, server or similar computing device. Figure 11 This is a hardware structure block diagram of a computer device for running a document review method provided in an embodiment of the present invention, such as... Figure 11 As shown, the internal structure of this computer device may include, but is not limited to, a processor, a network interface, and a memory. The processor, network interface, and memory within the computer device can be connected via a bus or other means, as illustrated in the embodiments of this specification. Figure 11 Taking the example of a connection between China and Israel via a bus.

[0133] The processor (or CPU, Central Processing Unit) is the computing and control core of the computer device. The network interface may optionally include a standard wired interface or a wireless interface (such as Wi-Fi, mobile communication interface, etc.). Memory is the storage device in the computer device used to store programs and data. It is understood that the memory here can be a high-speed RAM storage device, or a non-volatile storage device, such as at least one disk storage device; optionally, it can also be at least one storage device located remotely from the aforementioned processor. The memory provides storage space, which stores the operating system of the electronic device, including but not limited to: Windows (an operating system), Linux (an operating system), Android (a mobile operating system), iOS (a mobile operating system), etc., which are not limited in this invention; and the storage space also stores one or more instructions suitable for being loaded and executed by the processor, which can be one or more computer programs (including program code). In the embodiments of this specification, the processor loads and executes one or more instructions stored in the memory to implement the document review method provided in the above method embodiments.

[0134] Embodiments of this application also provide a computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a document review method. The at least one instruction or the at least one program is loaded and executed by the processor to implement any of the document review methods provided in the above-described method embodiments.

[0135] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0136] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0137] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0138] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0139] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A document review method, characterized in that, The method includes: Obtain multiple field evidence units extracted from multiple documents; each field evidence unit carries multi-dimensional attribute information; The role allocation result for each field evidence unit is determined based on the multi-dimensional attribute information; the role allocation result includes the assigned business role. Using the field evidence unit as a node, edges are constructed based on the multi-dimensional attribute information and the role allocation result to obtain a role classification evidence graph; the edges include negative edges that represent contradictory relationships between nodes; In response to an audit task, evidence paths are extracted from the role classification evidence graph based on the target business role carried by the audit task; and key task fields are determined based on the business facts queried by the audit task. When the evidence path does not include any key field of the task, or when there is a negative edge in the evidence path where the corresponding contradictory relationship has not been resolved, the generation of an affirmative audit conclusion for the audit task is blocked.

2. The method according to claim 1, characterized in that, The method further includes: When the evidence path includes key fields of each task, and there are no negative edges in the evidence path where the corresponding contradictory relationship has not been resolved, the field evidence units in the evidence path are verified. If the verification passes, a positive audit conclusion is generated for the audit task.

3. The method according to claim 1 or 2, characterized in that, The extraction of evidence paths from the role-classification evidence graph based on the target business role carried by the audit task includes: Based on the target business role, a role constraint retrieval is performed in the role classification evidence graph to obtain candidate evidence paths; the nodes in the candidate evidence paths include anchor nodes that match the target business role carried by the review task, and associated nodes that have edges with the anchor nodes. Based on the role allocation results and the multi-dimensional attribute information, each node in the candidate evidence path is subject to evidence admission judgment, and the node that passes the evidence admission judgment is determined as the admission evidence unit. The evidence path is determined based on the access evidence unit and the edges between the access evidence units in the role classification evidence diagram.

4. The method according to claim 3, characterized in that, The role allocation result also includes role status, which is either a confirmed status or an abnormal status; the multi-dimensional attribute information includes document version; based on the role allocation result and the multi-dimensional attribute information, the evidence admission determination is performed on each node in the candidate evidence path, and the node that passes the evidence admission determination is determined as an admission evidence unit, including: For each node in the candidate evidence path, the node whose role status is confirmed and whose document version is valid is determined as the admission evidence unit.

5. The method according to claim 4, characterized in that, The determination of the role allocation result for each field evidence unit based on the multi-dimensional attribute information includes: Generate a set of candidate business roles for each field of evidence unit; Obtain the role attribute information of each candidate business role in the candidate business role set; Based on the multi-dimensional attribute information and the role attribute information, the role binding score of the field evidence unit relative to each candidate business role in the candidate business role set is calculated; Based on the role binding score, determine the role status and assigned business role of the field evidence unit.

6. The method according to claim 5, characterized in that, The step of calculating the role binding score of the field evidence unit relative to each candidate business role in the candidate business role set based on the multi-dimensional attribute information and the role attribute information includes: Obtain the adjacent field information of the field evidence unit adjacent to the field evidence unit; Retrieve role binding records from historical review records that are associated with the current business scenario; Based on the adjacent field information, the role binding record, the multi-dimensional attribute information, and the role attribute information, the role binding score of the field evidence unit relative to each candidate business role is calculated.

7. The method according to claim 5, characterized in that, The step of determining the role status of the field evidence unit based on the role binding score includes: Among the multiple role binding scores corresponding to the field evidence unit, a first binding score and a second binding score are determined; the first binding score is higher than the role binding scores other than the first binding score among the multiple role binding scores corresponding to the field evidence unit, and the second binding score is higher than the role binding scores other than the first binding score and the second binding score among the multiple role binding scores corresponding to the field evidence unit. When the first binding score reaches the preset reliability threshold, the difference between the first binding score and the second binding score reaches the preset difference threshold, and the document version is valid, the role status of the field evidence unit is marked as confirmed.

8. The method according to claim 7, characterized in that, The method further includes: When the first binding score is lower than the preset reliability threshold, or the difference between the first binding score and the second binding score is lower than the preset difference threshold, or the document version is invalid, the role status of the field evidence unit is marked as abnormal.

9. The method according to claim 4, characterized in that, The construction of edges based on the multi-dimensional attribute information and the role allocation result includes: Based on the mutual exclusion relationship between the business roles assigned between different field evidence units under the preset business rules, a role conflict edge is constructed; And / or if at least one of the different field evidence units that are related under the preset business rules has an abnormal role status, then a role ambiguity edge is constructed; And / or construct the role ambiguity edge based on the unconfirmed association relationships that exist between different field evidence units under the preset business rules; And / or construct numerical conflict edges based on the logical contradictions between numerical fields in different field evidence units; And / or construct version substitution edges based on substitution relationships between document versions based on different field evidence units.

10. The method according to claim 1, characterized in that, The edges also include positive edges representing mutual corroboration relationships between nodes; the construction of edges based on the multi-dimensional attribute information and the role allocation results includes: Based on the fact that different fields of evidence units are assigned the same business role, construct the same role corroboration edge; And / or the business roles assigned based on different field evidence units are different and have a relationship under the preset business rules, construct cross-role association edges; And / or the business roles assigned based on different field evidence units have role binding records in the historical audit records, constructing historical binding edges.

11. The method according to claim 3, characterized in that, The multi-dimensional attribute information includes document type, field type, subject identifier, and document version; the step of performing role constraint retrieval based on the target business role in the role classification evidence graph to obtain candidate evidence paths includes: Based on the target business role, target document type, target field type, target subject identifier, and target document version carried by the audit task, anchor nodes are selected from the nodes of the role classification evidence diagram. The anchor node and the associated nodes in the role classification evidence graph that have edges with the anchor node are selected as candidate nodes. Based on the candidate nodes and the edges between the candidate nodes in the role classification evidence graph, the candidate evidence path is determined.

12. The method according to claim 3, characterized in that, After the blocking process generates an affirmative audit conclusion for the audit task, it further includes: For nodes in the candidate evidence path that are associated with the negative edge, generate risk warning information; and / or output the rejection result to the reviewer; And / or dispatch a review task carrying the candidate evidence path and the reason for blocking to the manual review platform.

13. A document verification device, characterized in that, The device includes: The field acquisition module is used to acquire multiple field evidence units extracted from multiple documents; the field evidence unit carries multi-dimensional attribute information. The role allocation module is used to determine the role allocation result of each field evidence unit based on the multi-dimensional attribute information; the role allocation result includes the assigned business role. The evidence graph construction module is used to construct edges based on the multi-dimensional attribute information and the role allocation result, using the field evidence units as nodes, to obtain a role classification evidence graph; the edges include negative edges that represent contradictory relationships between nodes; The evidence extraction module is used to extract evidence paths from the role-class evidence graph based on the target business role carried by the audit task in response to the audit task. The field determination module is used to determine the key fields of the task based on the business facts inquired by the audit task. The audit blocking module is used to block the generation of a positive audit conclusion for the audit task when the evidence path does not include any key field of the task, or when there is a negative edge in the evidence path with an unresolved contradiction.

14. A document approval system, characterized in that, It includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the document review method as described in any one of claims 1 to 12.

Images