An electronic accounting file query method and related device

Abstract

This application discloses a method and related apparatus for querying electronic accounting records. The method involves parsing query instructions to obtain intent and key entities; generating a graph query plan based on the constraint information, intent, and key entities corresponding to the query instructions; modifying the graph query plan; executing the modified graph query plan to obtain query results and corresponding execution logs; extracting core data objects from the query results; generating an explanatory evidence chain based on the core data objects and execution logs; and constructing the final query result based on the explanatory evidence chain, query results, and corresponding execution logs. By parsing query instructions into a graph query plan and incorporating rule constraints to ensure source compliance, and after execution, generating an explanatory evidence chain based on the results and logs, the method ultimately outputs an audit package integrating results, logs, and evidence. This achieves a transformation from fuzzy querying to end-to-end interpretability and verifiability, meeting stringent audit requirements.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and related apparatus for querying electronic accounting records. Background Technology

[0002] Electronic accounting records are typically stored in relational databases, requiring auditors to perform complex data queries to obtain information and trace the basis of calculations.

[0003] Currently, the retrieval of electronic accounting records mainly relies on large-scale language models to convert natural language into query statements. While this improves the convenience of interaction, its generation mechanism is "black box" and prone to "illusion" phenomena, posing significant limitations in serious audit and compliance scenarios. Simply outputting query results without a verifiable calculation process and a complete chain of evidence fails to meet the stringent requirements of audit conclusions being interpretable and verifiable. Summary of the Invention

[0004] This application provides a method and related device for querying electronic accounting records, with the aim of meeting the stringent requirements that audit conclusions must be interpretable and verifiable.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] The first aspect of this application provides a method for accessing electronic accounting records, including:

[0007] The query instructions for electronic accounting records are parsed to obtain the intent and key entities; the query instructions include subject attributes.

[0008] A graph query plan is generated based on the constraint information corresponding to the query instruction, the intent, and the key entities; the graph query plan is a directed acyclic graph composed of operators; the operators encapsulate specific logical operations.

[0009] The graph query plan is modified based on the main attributes to obtain the modified graph query plan;

[0010] Execute the modified graph query plan to obtain the query results and the corresponding execution logs.

[0011] Extract the core data object from the query results; the core data object is key data that must be verified.

[0012] Generate an explanatory evidence chain based on the core data object and the execution log;

[0013] The final query result is constructed based on the explained evidence chain, the query result, and the execution log corresponding to the query result.

[0014] Optionally, generating a graph query plan based on the constraint information corresponding to the query instruction, the intent, and the key entities includes:

[0015] The key entities are transformed using a knowledge base to obtain the transformed key entities;

[0016] Select audit templates from the audit template library that correspond to the stated intent and the transformed key entities;

[0017] The transformed key entities are populated into the audit template to obtain the initial audit template;

[0018] Add the constraint information corresponding to the query command to the initial audit template to obtain the graph query plan.

[0019] Optionally, after generating a graph query plan based on the constraint information corresponding to the query instruction, the intent, and the key entities, the method further includes:

[0020] Extract the path pattern of the operator from the graph query plan;

[0021] The path pattern of the operator is validated using a metagraph structure to obtain the validation result; the metagraph structure includes meta nodes for defining legal data types and meta edges for defining the relationships between legal data types.

[0022] When the verification result indicates that the path pattern verification of the operator is successful, the step of modifying the graph query plan according to the subject attribute to obtain the modified graph query plan is executed.

[0023] Optionally, modifying the graph query plan according to the subject attribute to obtain the modified graph query plan includes:

[0024] Obtain the node type and node attributes from the query plan;

[0025] An access control context is constructed based on the subject attribute, the node type, and the node attribute;

[0026] The security policy corresponding to the access control context is selected from the security policy library; the security policy consists of rules; the rules contain Boolean expressions and effect identifiers;

[0027] The graph query plan is rewritten according to the security policy to obtain the modified graph query plan.

[0028] Optionally, executing the modified graph query plan and obtaining the query results and the corresponding execution logs include:

[0029] Each operator is executed sequentially in a pipeline manner according to the topological order of the directed acyclic graph; wherein the output of the upstream operator is directly transmitted to the downstream operator as streaming data.

[0030] During the execution of the operator, an execution log is generated based on the operator's execution data. The execution log includes at least the amount of input data, the amount of output data, key intermediate calculation results, and triggered access control actions of the operator.

[0031] After the modified graph query plan is executed, the query result of the terminal operator is determined as the query result, and all execution logs are determined as the execution logs corresponding to the query result; the execution logs are used to trace the query process of the query result.

[0032] Optionally, generating an explanatory evidence chain based on the core data object and the execution log includes:

[0033] Using the core data object as the query anchor, perform a search in the graph database and generate the minimum correlation subgraph connecting all the core data objects;

[0034] Extract the direct criteria that led to the query result being determined to be true from the execution log; the direct criteria include data entities, attribute values, and associated paths;

[0035] By fusing the direct judgment criteria and the minimum correlation subgraph, an explanatory evidence chain is obtained.

[0036] Optionally, after generating a graph query plan based on the constraint information corresponding to the query instruction, the intent, and the key entities, the method further includes:

[0037] The graph query plan is optimized to obtain an optimized graph query plan.

[0038] A second aspect of this application provides a computer-readable storage medium comprising a stored program, wherein the program, when executed by a processor, performs the electronic accounting record query method provided in the first aspect of this application.

[0039] A third aspect of this application provides an electronic device, comprising: a processor, a memory, and a bus; wherein the processor and the memory are connected via the bus.

[0040] The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the electronic accounting record query method provided in the first aspect of this application.

[0041] The fourth aspect of this application provides a computer program product, including executable computer instructions, which, when executed by a processor of a computer device, are used to implement the electronic accounting record query method provided in the first aspect of this application.

[0042] The technical solution provided in this application parses query instructions from electronic accounting records to obtain intent and key entities; generates a graph query plan based on the constraint information, intent, and key entities corresponding to the query instructions; modifies the graph query plan; executes the modified graph query plan to obtain query results and corresponding execution logs; extracts core data objects from the query results; generates an explanatory evidence chain based on the core data objects and execution logs; and constructs the final query result based on the explanatory evidence chain, query results, and corresponding execution logs. Parsing query instructions into a graph query plan and incorporating rule constraints ensures compliance at the source. After execution, an explanatory evidence chain is generated based on the results and logs, ultimately outputting an audit package integrating results, logs, and evidence. This achieves a transformation from fuzzy queries to end-to-end interpretability and verifiability, meeting stringent audit requirements. Attached Figure Description

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

[0044] Figure 1 A first flowchart illustrating a method for querying electronic accounting records provided in this application embodiment;

[0045] Figure 2 A schematic diagram of a graph structure provided in an embodiment of this application;

[0046] Figure 3 A schematic diagram illustrating an electronic accounting record query process provided in this application embodiment;

[0047] Figure 4 A second flowchart illustrating a method for querying electronic accounting records provided in this application embodiment;

[0048] Figure 5 A third flowchart illustrating a method for querying electronic accounting records provided in this application embodiment;

[0049] Figure 6 A fourth flowchart illustrating a method for querying electronic accounting records provided in this application embodiment;

[0050] Figure 7This is a schematic diagram of the architecture of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] 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 skilled in the art without creative effort are within the scope of protection of this application.

[0052] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0053] like Figure 1 The diagram shown is a first flowchart of a method for querying electronic accounting records according to an embodiment of this application, including the following steps:

[0054] S101: Parse the query instructions for electronic accounting records to obtain the intent and key entities.

[0055] The query command includes subject attributes, which include at least user ID, role, department, and security level.

[0056] Understandably, the system receives query commands sent by users through the client. These query commands are natural language questions. The system then parses the query commands to obtain the intent (e.g., aggregation query, path search, anomaly detection, comparative analysis, evidence collection query, etc.) and key entities (e.g., entity, time, metric, constraint, etc.).

[0057] For example, the entities are employee Zhang San and supplier A, the time period is the past 12 months, the metric is amount, and the constraint is anomaly.

[0058] S102: Generate a graph query plan based on the constraint information, intent, and key entities corresponding to the query command.

[0059] The graph query plan is a directed acyclic graph composed of operators; the operators encapsulate specific logical operations.

[0060] Understandably, the constraints associated with query commands typically include industry-wide rules and hard financial indicators. An accurate and executable graph query plan needs to be generated based on these constraints, user intent, and identified key entities.

[0061] Optionally, in another embodiment of this application, the specific implementation of step S102 includes processes A1 to A4.

[0062] A1: Use the knowledge base to transform the key entities to obtain the transformed key entities.

[0063] The knowledge base is used to centrally store and manage various business constraints and reference data, including audit rules, financial regulations, charts of accounts, tax rate tables, organizational structures, process constraints (such as approval workflows), terminology dictionaries, and alias databases. It provides the necessary constraint information and business context to support accurate query parsing and plan synthesis.

[0064] Understandably, the alias library in the knowledge base is used to normalize key instances in the query, converting them into recognizable standard query elements (i.e., the transformed key entities). For example, mapping the entity "Zhang San" to an employee node: converting it into a precise pattern of (e: employee{name:"Zhang San"}) or matching by employee ID (e: employee{empId:"12345"}). Defining the time range "last 12 months" as a time window: converting it into structured window function parameters, such as Window(range="last_12_months",alignBy="v.period"), for use in subsequent calculations.

[0065] A2: Select audit templates from the audit template library that correspond to the intent and the transformed key entity.

[0066] Among them, based on the intent and the transformed key entity, the most suitable audit template is selected and matched from the audit template library.

[0067] A3: Populate the converted key entities into the audit template to obtain the initial audit template.

[0068] A4: Add the constraint information corresponding to the query command to the initial audit template to obtain the graph query plan.

[0069] Understandably, the constraint information corresponding to this query instruction is added to the initial audit template, and industry rules and financial regulations are automatically embedded when the query plan is generated, thereby completing the hard conditions that the user has not explicitly stated but must follow. The entire process is based on predefined processes and rules in the knowledge base, ensuring that the query not only meets the user's intent but also satisfies business compliance.

[0070] For example, when a user asks, "Calculate the total travel expense reimbursement amount for Zhang San in the sales department this year," the system first performs semantic parsing to extract key entities and intent.

[0071] -Employee="Zhang San";

[0072] - Category="Travel";

[0073] - Calculation function = SUM(reimbursement amount).

[0074] Subsequently, a search of the knowledge base revealed a rule that "only documents with a status of 'approved,' 'paid,' or 'in progress' can be included in valid financial data; documents with a status of 'draft,' 'rejected,' or 'withdrawn' must not be included in statistics." This rule will be automatically injected into the query conditions as a hidden constraint.

[0075] The final graph query plan is as follows:

[0076] SQL;

[0077] Employee="Zhang San";

[0078] Category="Travel";

[0079] Function = SUM(Amount);

[0080] --The following is the constraint information for the injection;

[0081] ANDstatusIN["Approved","Paid","Posting"];

[0082] ```.

[0083] As can be seen, this approach ensures the accuracy and compliance of results while responding to user queries, and avoids including invalid or pending documents incorrectly in the statistics.

[0084] Optionally, after step S102, the generated graph query plan also needs to be verified to ensure that the generated query plan is executable and meaningful under the structural constraints of the graph database, avoiding performance problems or logical errors caused by structural mismatch. Therefore, another embodiment of this application provides a graph query plan verification method, including processes B1 to B3.

[0085] B1: Path patterns for extracting operators from graph query plans.

[0086] This involves traversing all operators in the graph query plan and extracting the path pattern from each operator. For example, the path pattern is (A:Employee)-[:Handler]->(B:Invoice).

[0087] B2: Use the metagraph structure to verify the path pattern of the operator and obtain the verification result.

[0088] The metagraph structure includes meta nodes for defining legal data types and meta edges for defining the relationships between legal data types.

[0089] Specifically, the metagraph structure serves as the "skeleton" of the data definition. This metagraph is not actual data, but rather contains complete schema constraints. It primarily consists of two parts: metanodes, which define all legal node types and their attribute structures (e.g., the `Employee` node contains the `name:String` attribute); and metaedges, which define all legal connections between nodes (e.g., `(Employee)-[:REIMBURSE]->(Voucher)` is allowed, while `(Employee)-[:PAY]->(Supplier)` might be deemed invalid because payment must pass through a voucher node). This set of graph schema definitions collectively forms the benchmark for query validation, ensuring that all generated query plans are structurally valid and compliant.

[0090] Understandably, the metagraph structure is used as the verification benchmark to perform structural validation on path patterns in all query operators. Specifically, reachability checks (such as BFS or adjacency list-based lookups) are run on the metagraph to determine if the path pattern is valid at the schema level. For example, it checks whether there exists a corresponding meta-edge in the metagraph that runs from an "employee" type node to an "invoice" type node with a relationship type of "handler".

[0091] B3: When the verification result indicates that the path pattern verification of the operator has passed, execute step S103.

[0092] Optionally, after step S102, the graph query plan can be optimized to obtain an optimized graph query plan.

[0093] Specifically, the graph query plan is optimized by cost estimation, index selection, and predicate pushdown to obtain an optimized graph query plan.

[0094] S103: Modify the graph query plan according to the subject attributes to obtain the modified graph query plan.

[0095] Understandably, based on the subject attributes, namely user identity (such as role, department) and data attributes (such as sensitivity level, domain), the graph query plan is modified. By dynamically injecting row-level filtering conditions (visibility predicates) or column-level data transformation rules (de-identification strategies), it is ensured that different users can only access data that has been securely processed within their authorized scope, thereby achieving automatic control of data security and compliance.

[0096] S104: Execute the modified graph query plan and obtain the query results and the corresponding execution log.

[0097] Specifically, the modified graph query plan is executed, using parallel or streaming processing techniques (such as path search, aggregation operations, and window function calculations), resulting in the final query results and the corresponding execution logs.

[0098] S105: Extract the core data object from the query results.

[0099] Among them, the core data object is the critical data that must be verified.

[0100] S106: Generate an explanatory chain of evidence based on core data objects and execution logs.

[0101] Specifically, the direct evidence that led to the query result being deemed valid is first extracted from the execution log, and then an explanatory evidence chain is generated based on the direct evidence and the core data object.

[0102] S107: Construct the final query result based on the explained evidence chain, query results, and execution logs corresponding to the query results.

[0103] Understandably, an initial query result is constructed based on the explained evidence chain, query results, and their corresponding execution logs. Subsequently, to ensure the legal non-repudiation of the entire evidence chain, the initial query result is hashed and digitally signed, ultimately generating a final query result that integrates the answer, evidence package, execution logs, data anchors, digital signature, and trusted timestamp. This final query result possesses complete credibility and auditability and is returned to the user.

[0104] It should be noted that the final query results output all adopt a structured object design to ensure the reproducibility of the report and convenient access by external systems. Among them, the "Answer and Execution Summary" object fully records the result of a question-and-answer request. Its structure includes basic metadata (such as a unique answer identifier, the original natural language question text, and the request execution status), calculation results (including aggregate statistics such as total amount, time-series details such as statistical lists grouped by month, and anomaly records such as anomaly entity IDs and their causes and confidence levels), traceability links (related evidence IDs and execution plan IDs), and contextual information (such as generation timestamps and attribute-based access control security contexts, which record operator roles and fields anonymized due to permission policies). At the same time, the "evidence package" object encapsulates the minimum trusted dataset that supports the correctness of the answer. Its structure includes identification information (a unique evidence package ID and its associated answer ID), graph data (including key entity nodes involved in the reasoning chain and their IDs, types, key attributes and security tags, as well as business relationship edges between entities), original credential anchors (such as storage references pointing to the original document image and its file hash value, as well as execution log references pointing to key steps), and digital signatures (including signature algorithms, signature values ​​and trusted timestamps) used to ensure the integrity and non-repudiation of the entire evidence package.

[0105] Furthermore, graph data is constructed based on a "vertex-edge-attribute" model, abstracting the real-world electronic accounting record business entities and relationships into a graph structure, such as... Figure 2 As shown in the diagram. Vertices represent specific document entities, such as purchase contracts, VAT invoices, and bank receipts. Each vertex has a unique ID, an entity type label, and a series of business attributes, such as contract number, amount, and date. Edges represent business relationships between two document entities, such as "contract-generation-invoice" or "invoice-association-receipt." Each edge can have a direction and carry attributes, such as relationship creation time and the person in charge. Typical node types include: enterprise, department, employee, supplier, customer, project, contract, invoice, invoice line, voucher, voucher details, account, payment, receipt, expense report, approval record, image file, system account, equipment, and geographical location.

[0106] For example, typical edge relationships are as follows (direction →): Enterprise → Department (inclusive), Department → Employee (affiliation), Supplier → Invoice (issued), Invoice → Voucher (accounting entry), Voucher → Payment (verification), Expense Report → Approval Record (inclusive), Image File → Invoice / Voucher (anchored), Account → Approval Record (operation), Equipment → Account (login).

[0107] Key attributes include: amount, tax, currency, period, account code, direction, quantity, tax rate, invoice code / number / verification code, OCR recognition field, signature fingerprint, document hash, timestamp (occurrence / registration / archiving), session ID, IP / device fingerprint, etc.

[0108] In order to better understand Figure 1 The content shown is explained below. See also: Figure 3 This diagram illustrates a process for querying electronic accounting records. Figure 3 The system comprises a semantic parser, an audit knowledge base, a plan generator, an execution optimizer, an attribute-based access control (ABAC) engine (controlling data access based on subject, resource, and environment attributes), an execution engine, an evidence packager, and a parsing error corrector. The semantic parser parses the user's natural language input (i.e., query instructions), extracting intent and key entities, and then filters the corresponding audit template based on these. The plan generator generates a complete graph query plan with type checks based on the constraint information, intent, and key entities provided by the audit knowledge base. The execution optimizer optimizes the graph query plan, resulting in an optimized graph query plan. The ABAC policy engine modifies the graph query plan based on the subject attributes, resulting in a modified graph query plan. The execution engine executes the modified graph query plan, obtaining the query results and corresponding execution logs. The evidence packager constructs the final query results based on the explained evidence chain, the query results, and the corresponding execution logs, and then generates a readable report to provide feedback to the user. The parsing error corrector collects and updates information based on the user's manual review feedback.

[0109] It should be noted that when users find errors in the execution plan or the final answer output by semantic parsing, they can mark and correct them. This feedback will be fed into the parsing error corrector in real time for immediate correction of similar problems; at the same time, this feedback will serve as a high-quality negative sample for offline continuous fine-tuning of the semantic parsing model and template matching priority, thereby driving the continuous evolution of overall accuracy.

[0110] It should be noted that, based on the processes shown in S101-S107 above, this embodiment can achieve the following beneficial effects:

[0111] 1. The system utilizes natural language to graph query language parsing technology to transform natural language problems (such as "tracing the financial path of an employee's related suppliers over the past year") into executable graph query plans. This approach does not require auditors to be proficient in graph query language or attribute graph query language, thus reducing reliance on technical professionals.

[0112] 2. Faced with the multi-entity, multi-layered network data structure of electronic accounting records, such as "employees-suppliers-invoices-vouchers," the Path operator enables flexible path searching, and the Window operator achieves precise time window slicing, thereby efficiently supporting complex audit queries across departments and time periods. This approach effectively overcomes the limitations of traditional relational databases in terms of flexibility when handling such relational queries.

[0113] 3. By parsing query commands in a structured manner, a transparent graph query plan is generated, and constraint information based on subject attributes is dynamically integrated into the plan, ensuring the compliance and accuracy of the query from the source. After execution, an explanatory chain of evidence is generated based on the query results and execution logs. Finally, an audit package integrating query results, complete execution logs, and the explanatory chain of evidence is output, realizing a fundamental shift from result-oriented fuzzy queries to end-to-end interpretability and verifiability, thus fully meeting the stringent requirements of audit and compliance scenarios.

[0114] 4. By integrating timestamp signature and file hash verification technologies, a complete evidence collection chain covering the entire process of "data generation - query execution - evidence output" is constructed, thereby ensuring that all evidence is legally irrefutable and meets audit compliance requirements.

[0115] like Figure 4 The diagram shown is a second flowchart of a method for querying electronic accounting records provided in an embodiment of this application, including the following steps:

[0116] S401: Parse the query command to obtain the intent and key entities.

[0117] The query command includes subject attributes; the subject attributes include at least user ID, role, department, and security level.

[0118] It should be noted that the specific implementation of step S401 can be found in step S101, and will not be repeated here.

[0119] S402: Generate a graph query plan based on the constraint information, intent, and key entities corresponding to the query command.

[0120] The graph query plan is a directed acyclic graph composed of operators; the operators encapsulate specific logical operations.

[0121] It should be noted that the specific implementation of step S402 can be referred to step S102 accordingly, and will not be repeated here.

[0122] S403: Retrieve node type and node attributes from the query plan.

[0123] Node type refers to a predefined category or label in the graph data, and node attribute refers to a predefined field name or key in the graph data that belongs to that node type.

[0124] It should be noted that, since actual data has not yet been accessed, the analysis is based on the data model (Schema). For example, when a node is mentioned in the graph query plan, the data type "voucher" is identified, along with field names such as "amount" and "date" that may be used in the graph query plan (i.e., node attributes), rather than any specific voucher number or amount.

[0125] S404: Construct an access control context based on subject attributes, node type, and node attributes.

[0126] Specifically, an access control context is constructed based on subject attributes, node types, and node attributes, which means standardizing subject attributes, node types, and node attributes into ABAC elements.

[0127] For example, the main attribute is {"uid":"u_101","role":"JuniorAuditor","dept":"Audit_Dept","clearance":"L2"}.

[0128] S405: Select the security policy corresponding to the access control context from the security policy library.

[0129] The security policy consists of rules; each rule contains a Boolean expression and an effect identifier.

[0130] Understandably, a pre-built security policy library (such as the ABAC policy library) is loaded, and the access control context (such as user identity, resource type, etc.) is input into it for policy matching. Each policy typically consists of a set of rules, which include two parts: Condition (a Boolean expression) and Effect (an effect identifier). The condition is a Boolean expression that describes the specific scenario in which the policy takes effect; the effect identifier defines the access control decision after matching the condition, such as allow, deny, or de-identify.

[0131] For example, a rule might be defined as: Condition: `Subject.role=='JuniorAuditor' AND Resource.type=='Voucher' AND Resource.domain=='HR'`, Effect identifier: `Deny`. This means that when a user with the role of "Junior Auditor" attempts to access data related to the resource type "Voucher" and the data domain "Human Resources", the request will be completely denied.

[0132] S406: Rewrite the graph query plan according to the security policy to obtain the modified graph query plan.

[0133] Understandably, directly modifying the directed acyclic graph (DAG) of the query plan based on the security policy transforms the abstract security policy into concrete execution logic; this process is called the "physicalization" of the policy. When the security policy determines that a user can only access partial data (i.e., row-level security), it locates the Filter operator in the DAG and injects additional filtering conditions (WHERE clauses) into it, thereby achieving data pruning at the query execution level.

[0134] For example: 1. Original plan snippet: `MATCH(v:Voucher)->Filter(v.date>'2024-01-01')`, meaning: find all credentials from 2024 onwards. 2. Policy action: Based on the security policy library, the user with the current role `JuniorAuditor` is not authorized to view credentials in the `HR` (Human Resources) domain. 3. Rewritten plan snippet: `MATCH(v:Voucher)->Filter(v.date>'2024-01-01'ANDv.domain!='HR')`, meaning: find all credentials from 2024 onwards that do not belong to the HR domain. The condition `v.domain!='HR'` is automatically added, thus completing the permission filtering during data reading.

[0135] S407: Execute the modified graph query plan and obtain the query results and the corresponding execution log.

[0136] It should be noted that the specific implementation of step S407 can be found in step S104, and will not be repeated here.

[0137] S408: Extract the core data object from the query results.

[0138] Among them, the core data object is the critical data that must be verified.

[0139] It should be noted that the specific implementation of step S408 can be found in step S105, and will not be repeated here.

[0140] S409: Generate an explanatory chain of evidence based on core data objects and execution logs.

[0141] It should be noted that the specific implementation of step S409 can be found in step S106, and will not be repeated here.

[0142] S410: Construct the final query result based on the explained evidence chain, query results, and execution logs corresponding to the query results.

[0143] It should be noted that the specific implementation of step S410 can be found in step S107, and will not be repeated here.

[0144] In summary, based on the security policy corresponding to the access control context, the graph query plan is dynamically intervened before query execution. This mechanism prunes data that users do not have permission to access (such as filtering out HR field records) and injects necessary de-identification rules (such as masking sensitive monetary fields), thereby ensuring that data access complies with preset permission specifications in real time.

[0145] like Figure 5 The diagram shown is a third flowchart of a method for querying electronic accounting records provided in this application, which includes the following steps:

[0146] S501: Parse the query command to obtain the intent and key entities.

[0147] The query command includes subject attributes, which include at least user ID, role, department, and security level.

[0148] It should be noted that the specific implementation of step S501 can be found in step S101, and will not be repeated here.

[0149] S502: Generate a graph query plan based on the constraint information, intent, and key entities corresponding to the query command.

[0150] The graph query plan is a directed acyclic graph composed of operators; the operators encapsulate specific logical operations.

[0151] It should be noted that the specific implementation of step S502 can be referred to step S102 accordingly, and will not be repeated here.

[0152] S503: Modify the graph query plan based on the subject attributes to obtain the modified graph query plan.

[0153] It should be noted that the specific implementation of step S503 can be found in step S103, and will not be repeated here.

[0154] S504: Execute each operator sequentially in a pipeline manner according to the topological order of the directed acyclic graph.

[0155] In this process, the output of the upstream operator is directly transmitted to the downstream operator as streaming data.

[0156] It is understandable that each operator will be executed sequentially in a pipelined manner according to the topological order of the security query plan (i.e., according to the topological order of the directed acyclic graph). The output result of the previous operator will be transmitted to the subsequent operator in real time as streaming data. For example, the nodes filtered by `Filter(employee = "Zhang San")` will be streamed to the `Path(...)` operator for path exploration, and the result will be further streamed to the `GroupBy(month)` operator to complete grouping. During this process, all operators (including mathematical and aggregation functions) follow the principle of deterministic calculation: standard aggregations (such as `SUM()`, `AVG()`) and anomaly detections (such as calculating Z-Score based on a mathematical formula: \(Z(x_i)=(x_i-\mu_W) / \sigma_W\), or determining path rarity: \(f(p)<F_q(0.05)\)) are strictly executed according to predefined rules, without any "black box" or speculative logic (such as the free play of large models), thus ensuring that all output results (such as anomaly score 0.92) are reproducible and verifiable calculated values.

[0157] Specifically, an operator is the smallest functional unit in the graph query execution plan that encapsulates specific mathematical or logical operations and is the "building block" for constructing complex audit queries. Its core types include: Filter for property, temporal, or role filtering (predicates such as `amount>10000 AND taxRate IN[0.03,0.06]`); Join for connecting heterogeneous nodes and edges according to a graph pattern; Path for path search (source node, target node, maximum hop count, and meta-path constraints can be defined, such as `(employee)-[handled]->(voucher)-[recorded]->(invoice)`); Window for implementing time window slicing (range such as the last 12 months or a specified interval); GroupBy for grouping; Aggregate for performing aggregation operations (such as `SUM()`, `COUNT()`); Anomaly for running anomaly detection (the detector returns combinable anomaly scores); ExplainMinSubgraph for generating the minimum explanatory subgraph (for specific answer elements); and Redact for data cropping or desensitization according to the ABAC policy. These operators, through an orderly combination, jointly support the complete audit analysis process from data screening, correlation analysis to anomaly insight and result interpretation.

[0158] Furthermore, audit templates are predefined combinations of operators and execution structures for specific audit scenarios (such as "path tracing," "fund aggregation," and "anomaly detection"). Like a fill-in-the-blank exercise, it specifies a fixed execution order for operators while reserving "slots" for specific entities or parameters to fill in. This encapsulates complex audit logic (such as cross-period and multi-hop queries) into a standard, reusable pattern, avoiding the repetitive work of building a query plan from scratch each time. For example, when faced with the question "The accounting path and amount distribution of a certain employee (E) and related suppliers (S) in the past (T) months, and identify abnormal peaks," the semantic parsing model only needs to identify that this is a "related path and anomaly detection" template and fill in the parameters "Zhang San (emp_zhangsan), Company A (sup_A), past 12 months" into the corresponding slots. The execution graph query plan corresponding to this template is as follows: First, filtering is performed using `Filter(E)`, `Filter(S)`, and `Window(T)`; second, the association is established by the `Path` operator according to the meta-path `(Employee)->(Voucher)->(Invoice)<-(Supplier)`; then, the amount is aggregated by month using `GroupBy` and `Aggregate`; then, abnormal peaks are identified using the `Anomaly` operator; finally, an explanatory subgraph is generated as evidence using `ExplainMinSubgraph`.

[0159] S505: During the execution of an operator, an execution log is generated based on the operator's execution data.

[0160] The execution log includes at least the amount of input data, output data, key intermediate calculation results, and triggered access control actions of the operator.

[0161] S506: After the modified graph query plan is executed, the query result of the terminal operator is determined as the query result, and all execution logs are determined as the execution logs corresponding to the query result.

[0162] The execution log is used to trace the query process for the query results.

[0163] Understandably, execution logs are the core carrier for achieving "interpretability," generating detailed records at each step of execution. For example, `[Operator:Filter]` records changes in the number of input and output nodes (e.g., N input nodes, M output nodes); `[Operator:Anomaly]` records the specific detection calculation process and results (e.g., the zscore of node V2024-06-123 is 3.1, exceeding the threshold of 3.0); and `[Operator:ABAC]` records the specific effectiveness of security policies (e.g., according to the policy pol_ext_auditor_hr, 3 nodes belonging to the HR domain have been filtered). These structured logs together constitute a complete and auditable chain of evidence.

[0164] Specifically, the query results are detailed answer information (such as total amount, exception list, etc.), while the execution log records in detail how the detailed answer information was calculated step by step.

[0165] S507: Extract the core data object from the query results.

[0166] Among them, the core data object is the critical data that must be verified.

[0167] It should be noted that the specific implementation of step S507 can be found in step S105, and will not be repeated here.

[0168] S508: Generate an explanatory chain of evidence based on core data objects and execution logs.

[0169] It should be noted that the specific implementation of step S508 can be found in step S106, and will not be repeated here.

[0170] S509: Construct the final query result based on the explained evidence chain, query results, and execution logs corresponding to the query results.

[0171] It should be noted that the specific implementation of step S509 can be found in step S107, and will not be repeated here.

[0172] In summary, firstly, all computational processes (including aggregation operations such as SUM and anomaly detection such as Z-score) strictly adhere to predefined deterministic rules, eliminating any random or speculative elements. Secondly, a complete end-to-end execution log is maintained, covering key steps such as operator input / output data volume, the basis for anomaly score calculation, and ABAC strategy pruning records. Together, these two elements clearly and structurally present the complete logical chain of "how the answer is derived." Based on deterministic computation, identical inputs ensure completely consistent outputs, meeting audit traceability requirements. Furthermore, the end-to-end log allows any result to be traced back to the original data and computational rules, completely eliminating "black box" concerns and achieving the design goal of complete process transparency and reproducible, verifiable results.

[0173] like Figure 6 The diagram shown is a fourth flowchart of a method for querying electronic accounting records provided in this application, which includes the following steps:

[0174] S601: Parse the query command to obtain the intent and key entities.

[0175] The query command includes subject attributes, which include at least user ID, role, department, and security level.

[0176] It should be noted that the specific implementation of step S601 can be found in step S101, and will not be repeated here.

[0177] S602: Generate a graph query plan based on the constraint information, intent, and key entities corresponding to the query command.

[0178] The graph query plan is a directed acyclic graph composed of operators; the operators encapsulate specific logical operations.

[0179] It should be noted that the specific implementation of step S602 can be found in step S102, and will not be repeated here.

[0180] S603: Modify the graph query plan based on the subject attributes to obtain the modified graph query plan.

[0181] It should be noted that the specific implementation of step S603 can be found in step S103, and will not be repeated here.

[0182] S604: Execute the modified graph query plan and obtain the query results and the corresponding execution log.

[0183] It should be noted that the specific implementation of step S604 can be found in step S104, and will not be repeated here.

[0184] S605: Extract the core data object from the query results.

[0185] Among them, the core data object is the critical data that must be verified.

[0186] For example, if the query result's answer details are anomalies:["V2024-06-123"], then the node V2024-06-123 is the core data object.

[0187] S606: Using core data objects as query anchors, perform a search in the graph database and generate the minimum relational subgraph connecting all core data objects.

[0188] Understandably, the goal of step S606 is to efficiently construct the minimum evidence subgraph that can explain a specific conclusion. This is essentially a Steiner tree problem, i.e., finding the minimum association subgraph that connects all specified terminal nodes. Since this problem is NP-hard (i.e., extremely difficult to solve efficiently and precisely), a multinomial-time approximation algorithm (such as the KMB algorithm or the shortest path heuristic SPH) is used to solve it. For example, to explain the association between employee `emp_zhangsan`, supplier `sup_A`, and voucher `V2024-06-123`, an approximate minimum association subgraph `G_steiner` is generated, with a possible structure of: `(emp_zhangsan)->(v_123)<-(inv_01)<-(sup_A)`.

[0189] The result generated by this approximation algorithm is a "minimum correlation subgraph" that meets the requirements of audit interpretation. This subgraph refers to the smallest set of nodes and edges extracted from the full dataset that rigorously supports a conclusion (such as "employee Zhang San exhibits abnormal correlation behavior with a supplier"). It has three core characteristics: 1. Subgraph structure: It is not an isolated data point, but a local network reflecting the relationships between entities (e.g., Zhang San -> expense report <- invoice <- supplier). 2. Evidence attributes: Each element in the graph (node, edge, and its attributes) is an indispensable link in the reasoning chain. 3. Minimalism: While ensuring complete interpretation, this subgraph has eliminated all redundant information; removing any node or edge would lead to a break in the reasoning or insufficient interpretation.

[0190] S607: Extract the direct criteria from the execution log that led to the query result being deemed valid.

[0191] The direct criteria for judgment include data entities, attribute values, and associated paths.

[0192] It's important to note that simply presenting the minimum related subgraph (i.e., the related path) is insufficient; the "reasons" behind the judgments must be clearly explained. To this end, the specific judgment criteria recorded in the execution log will be extracted. For example, the execution log might show that voucher `V2024-06-123` is marked as abnormal because the tax rate `taxRate=0.05` of its associated invoice `inv_01` is outside the normal range, and the related path `p` of this entity exhibits a rare pattern in the overall graph.

[0193] S608: The direct judgment criteria and the minimum correlation subgraph are fused to obtain the explanatory evidence chain.

[0194] For example, the node (inv_01:{taxRate:0.05}) and its attributes, as well as all nodes and edges on the associated path "p", are forcibly merged into the minimum associated subgraph.

[0195] As can be seen, after steps S605 to S608, the explanatory evidence chain is a graph data structure (containing a list of nodes and a list of edges). This structure, in the form of a minimized subgraph, constitutes the explanatory evidence body that supports the conclusion.

[0196] S609: Construct the final query result based on the explained evidence chain, query results, and execution logs corresponding to the query results.

[0197] It should be noted that the specific implementation of step S609 can be found in step S107, and will not be repeated here.

[0198] In summary, only the core elements supporting the conclusions are retained, including key nodes (such as employees, suppliers, and abnormal vouchers), related edges (such as handling and accounting relationships), and specific constraint evidence (such as abnormal tax rate values ​​and rare path identifiers), thereby eliminating interference from redundant information. Simultaneously, this minimally related subgraph is bound to the corresponding original voucher image anchor point (such as invoice PDFs), allowing users to directly access the original data for verification, fully meeting the "traceability and verifiability" standards required for auditing work.

[0199] Another embodiment of this application provides an electronic device, such as... Figure 7 As shown, it includes: memory 701, processor 702 and bus 703.

[0200] The memory 701 is used to store the program.

[0201] The processor 702 is used to execute a program, which, when executed, is specifically used to implement a method for querying electronic accounting records as provided in any of the above embodiments.

[0202] The electronic devices mentioned in this article can be servers, PCs, tablets, mobile phones, ECUs (Electronic Control Units), VCUs (Vehicle Control Units), MCUs (Micro Controller Units), HCUs (Hybrid Control Units), etc.

[0203] Another embodiment of this application provides a computer storage medium for storing a computer program, which, when executed, implements a method for querying electronic accounting records as provided in any of the above embodiments.

[0204] Computer storage media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0205] This application also provides a computer program product comprising executable computer instructions, which, when executed by a processor of a computer device, are used to implement a method for querying electronic accounting records as provided in any of the above embodiments.

[0206] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. In particular, for system or system embodiments, since they are fundamentally similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. Components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0207] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0208] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for querying electronic accounting records, characterized in that, include: The query instructions for electronic accounting records are parsed to obtain the intent and key entities; the query instructions include subject attributes. A graph query plan is generated based on the constraint information corresponding to the query instruction, the intent, and the key entities; the graph query plan is a directed acyclic graph composed of operators; The operator encapsulates specific logical operations; The graph query plan is modified based on the main attributes to obtain the modified graph query plan; Execute the modified graph query plan to obtain the query results and the corresponding execution logs. Extract the core data object from the query results; The core data object is critical data that must be verified. Generate an explanatory evidence chain based on the core data object and the execution log; The final query result is constructed based on the explained evidence chain, the query result, and the execution log corresponding to the query result.

2. The method according to claim 1, characterized in that, The generation of a graph query plan based on the constraint information corresponding to the query instruction, the intent, and the key entities includes: The key entities are transformed using a knowledge base to obtain the transformed key entities; Select audit templates from the audit template library that correspond to the stated intent and the transformed key entities; The transformed key entities are populated into the audit template to obtain the initial audit template; Add the constraint information corresponding to the query command to the initial audit template to obtain the graph query plan.

3. The method according to claim 1, characterized in that, After generating a graph query plan based on the constraint information corresponding to the query instruction, the intent, and the key entities, the method further includes: Extract the path pattern of the operator from the graph query plan; The path pattern of the operator is validated using a metagraph structure to obtain the validation result; the metagraph structure includes meta nodes for defining legal data types and meta edges for defining the relationships between legal data types. When the verification result indicates that the path pattern verification of the operator is successful, the step of modifying the graph query plan according to the subject attribute to obtain the modified graph query plan is executed.

4. The method according to claim 1, characterized in that, The step of modifying the graph query plan according to the subject attributes to obtain the modified graph query plan includes: Obtain the node type and node attributes from the query plan; An access control context is constructed based on the subject attribute, the node type, and the node attribute; The security policy corresponding to the access control context is selected from the security policy library; the security policy consists of rules; the rules contain Boolean expressions and effect identifiers; The graph query plan is rewritten according to the security policy to obtain the modified graph query plan.

5. The method according to claim 1, characterized in that, The execution of the modified graph query plan, obtaining the query results and the corresponding execution logs, includes: Each operator is executed sequentially in a pipeline manner according to the topological order of the directed acyclic graph; wherein the output of the upstream operator is directly transmitted to the downstream operator as streaming data. During the execution of the operator, an execution log is generated based on the operator's execution data. The execution log includes at least the amount of input data, the amount of output data, key intermediate calculation results, and triggered access control actions of the operator. After the modified graph query plan is executed, the query result of the terminal operator is determined as the query result, and all execution logs are determined as the execution logs corresponding to the query result; the execution logs are used to trace the query process of the query result.

6. The method according to claim 1, characterized in that, The generation of an explanatory evidence chain based on the core data object and the execution log includes: Using the core data object as the query anchor, perform a search in the graph database and generate the minimum correlation subgraph connecting all the core data objects; Extract the direct criteria that led to the query result being determined to be true from the execution log; the direct criteria include data entities, attribute values, and associated paths; By fusing the direct judgment criteria and the minimum correlation subgraph, an explanatory evidence chain is obtained.

7. The method according to claim 1, characterized in that, After generating a graph query plan based on the constraint information corresponding to the query instruction, the intent, and the key entities, the method further includes: The graph query plan is optimized to obtain an optimized graph query plan.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed by a processor, performs the electronic accounting record query method according to any one of claims 1-7.

9. An electronic device, characterized in that, include: Processor, memory, and bus; The processor and the memory are connected via the bus; The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the electronic accounting record query method according to any one of claims 1-7.

10. A computer program product, characterized in that, It includes executable computer instructions, which, when executed by a processor of a computer device, are used to implement the electronic accounting record query method as described in any one of claims 1-7.

Images