Epr multi-dimensional data financial voucher generation method and system based on large language model

Abstract

The application provides an ERP multi-dimensional data financial voucher generation method and system based on a large language model. The method comprises: acquiring multi-dimensional business data in an ERP system and generating a source data packaging result; constructing a financial event object according to the source data packaging result and generating a financial transaction graph; inputting the financial event object and the financial transaction graph into a large language model to generate an accounting semantic instruction corresponding to a current financial transaction; calling an accounting rule constraint library according to the accounting semantic instruction to determine a voucher element constraint condition and generating a voucher draft graph based on the voucher element constraint condition; performing multi-dimensional verification on the voucher draft graph to generate a voucher verification result; when the voucher verification result meets a preset entry condition, converting the voucher draft graph into a target financial voucher and writing the target financial voucher back to a financial accounting module of the ERP system. The application can improve multi-source data correlation accuracy, enhance voucher generation controllability and improve verification and tracing integrity.

Description

Technical Field

[0001] This application relates to the field of intelligent financial processing technology, and in particular to a method and system for generating ERP multi-data financial vouchers based on a large language model. Background Technology

[0002] With the improvement of enterprises' digital management level, ERP (Enterprise Resource Planning) systems have been widely used in business processes such as procurement, sales, inventory, funds, expenses, taxes, and general ledger. The generation of financial vouchers is gradually shifting from manual entry to automatic generation by the system. Existing technologies typically convert information such as amount, subject, account, and period in business documents into accounting entries based on fixed field mapping, preset voucher templates, or rule engines. Some solutions also introduce large language models to understand business text, in order to help identify business scenarios and generate voucher summaries.

[0003] However, generating financial vouchers in ERP systems requires integrating multi-source business data, process status, amount transfer relationships, tax processing rules, and accounting dimensions. Simply relying on field mapping or static rules is insufficient to handle complex business matters. Directly generating vouchers using large language models can easily lead to problems such as inaccurate account selection, inconsistent amount splitting, misjudgment of voucher stages, and missing source documentation. Furthermore, existing solutions typically lack unified modeling of business facts, accounting elements, and evidence chains. The generated vouchers cannot undergo comprehensive verification of structural integrity, debit / credit balance, source document consistency, period compliance, and evidence traceability before being posted. This results in insufficient controllability of the generation process, reliance on manual experience for anomaly correction, and an inability to meet the needs of enterprise financial accounting and audit traceability. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a method and system for generating financial vouchers based on a large language model for ERP multi-source data, in order to solve the problems of insufficient multi-source data association, poor controllability of voucher generation, and incomplete verification and traceability in the prior art.

[0005] A first aspect of this application provides a method for generating financial vouchers from multi-source data in ERP systems based on a large language model. The method includes: acquiring multi-source business data from an ERP system and configuring source identifiers, object identifiers, time identifiers, and credibility identifiers for the multi-source business data to generate source data encapsulation results; constructing financial event objects based on business relationships, monetary relationships, and process status relationships in the source data encapsulation results, and generating a financial event graph based on the financial event objects to represent business facts, accounting elements, and evidence citation relationships; inputting the financial event objects and the financial event graph into a large language model to generate accounting semantic instructions corresponding to the current financial event; calling an accounting rule constraint library based on the accounting semantic instructions to determine voucher element constraints, and generating a voucher draft diagram based on the voucher element constraints; performing multi-dimensional verification on the voucher draft diagram covering voucher structure, debit / credit relationships, source document relationships, period status, and evidence links to generate voucher verification results; and when the voucher verification results meet preset accounting conditions, converting the voucher draft diagram into a target financial voucher and writing the target financial voucher back to the financial accounting module of the ERP system.

[0006] A second aspect of this application provides an ERP multi-data financial voucher generation system based on a large language model, comprising: an acquisition module for acquiring multi-data business data from the ERP system and configuring source identifiers, object identifiers, time identifiers, and credibility identifiers for the multi-data business data to generate source data encapsulation results; a construction module for constructing financial event objects based on business relationships, monetary relationships, and process status relationships in the source data encapsulation results, and generating a financial event graph representing business facts, accounting elements, and evidence citation relationships based on the financial event objects; a generation module for inputting the financial event objects and the financial event graph into the large language model to generate accounting semantic instructions corresponding to the current financial event; a determination module for calling the accounting rule constraint library according to the accounting semantic instructions to determine voucher element constraints and generating a voucher draft diagram based on the voucher element constraints; a verification module for performing multi-dimensional verification on the voucher draft diagram covering voucher structure, debit / credit relationships, source document relationships, period status, and evidence links, and generating voucher verification results; and a write-back module for converting the voucher draft diagram into a target financial voucher and writing the target financial voucher back to the financial accounting module of the ERP system when the voucher verification results meet preset accounting conditions.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By acquiring diverse business data from the ERP system and configuring source, object, time, and credibility identifiers for this data, a source data encapsulation result is generated. Based on the business, monetary, and process status relationships within the encapsulated source data, financial event objects are constructed, and a financial event graph representing business facts, accounting elements, and evidence citation relationships is generated based on these objects. The financial event objects and the financial event graph are input into a large language model to generate accounting semantic instructions corresponding to the current financial event. The accounting rule constraint library is invoked based on these instructions to determine voucher element constraints, and a voucher draft diagram is generated based on these constraints. The voucher draft diagram undergoes multi-dimensional verification covering voucher structure, debit / credit relationships, source document relationships, period status, and evidence links, generating a voucher verification result. When the voucher verification result meets the preset posting conditions, the voucher draft diagram is converted into a target financial voucher, and the target financial voucher is written back to the financial accounting module of the ERP system. This application improves the accuracy of multi-source data association, enhances the controllability of voucher generation, and improves the integrity of verification and traceability. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, 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.

[0009] Figure 1 This is a flowchart illustrating the method for generating financial vouchers for ERP based on a large language model, as provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of the ERP multi-data financial voucher generation system based on a large language model provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] In existing technologies, ERP systems typically convert document data from business modules such as purchasing, sales, inventory, funds, expenses, and taxes into financial vouchers through fixed field mapping, preset voucher templates, or rule engines. Although some existing solutions introduce large language models to semantically understand business text or document content, they are mostly used for business scenario identification, summary generation, or voucher suggestion generation. The determination of voucher elements still mainly relies on static rules or manual review, making it difficult to uniformly model the business relationships, monetary relationships, process status relationships, and evidence citation relationships among diverse business data.

[0012] Therefore, existing technologies suffer from at least the following problems: insufficient correlation of multi-source data, poor controllability of voucher generation, and incomplete verification and traceability. Specifically, the data on documents, invoices, payments, warehousing, approvals, and historical vouchers in different business modules differ in field definitions, time definitions, and business status, making it difficult for the system to accurately identify the same financial event. If vouchers are generated directly using large language models, problems such as misjudgment of accounting processing scenarios, unclear voucher generation stages, and insufficient basis for accounts and amounts are likely to occur. At the same time, existing voucher generation results usually only perform debit and credit balance or field integrity checks, which are insufficient to cover the comprehensive verification requirements for financial accounting, such as consistency of source documents, period status, and evidence links.

[0013] To address the aforementioned issues, this application provides a method for generating financial vouchers from multi-source data in ERP systems based on a large language model. This method first acquires multi-source business data from the ERP system and configures source identifiers, object identifiers, time identifiers, and credibility identifiers to generate source data encapsulation results. Then, based on the business relationships, monetary relationships, and process status relationships within the source data encapsulation results, financial event objects are constructed. Finally, based on these financial event objects, a financial event graph is generated to represent business facts, accounting elements, and evidence citation relationships.

[0014] Based on this, this application inputs the financial event objects and financial transaction graphs into a large language model to generate accounting semantic instructions corresponding to the current financial transaction. This allows the large language model to primarily perform financial semantic parsing, accounting processing scenario identification, and voucher generation stage determination functions, rather than directly generating the final financial voucher. Subsequently, the accounting rule constraint library is invoked according to the accounting semantic instructions to determine the voucher element constraints. Based on these constraints, a voucher draft diagram is generated, thereby structurally limiting the voucher account, debit / credit direction, source of funds, accounting dimension, and evidence citation relationship through rule constraints.

[0015] Furthermore, this application performs multi-dimensional verification on the draft voucher diagram, covering voucher structure, debit / credit relationships, source document relationships, period status, and evidence chain, generating voucher verification results. When the voucher verification results meet the preset accounting conditions, the draft voucher diagram is converted into the target financial voucher, and the target financial voucher is written back to the financial accounting module of the ERP system. Therefore, this application can improve the accuracy of multi-source data association, enhance the controllability of voucher generation, and improve the integrity of verification traceability.

[0016] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0017] Figure 1 This is a flowchart illustrating the ERP multi-data financial voucher generation method based on a large language model provided in an embodiment of this application. For example... Figure 1 As shown, the method may specifically include: S101: Obtain diverse business data from the ERP system, configure source identifier, object identifier, time identifier, and credibility identifier for the diverse business data, and generate source data encapsulation results. S102, Based on the business relationships, monetary relationships and process status relationships in the source data encapsulation results, construct financial event objects, and generate financial event graphs based on the financial event objects to represent business facts, accounting elements and evidence citation relationships; S103, input the financial event object and financial transaction graph into the big language model to generate accounting semantic instructions corresponding to the current financial transaction; S104: Call the accounting rule constraint library according to the accounting semantic instructions, determine the voucher element constraint conditions, and generate a voucher draft diagram based on the voucher element constraint conditions; S105, perform multi-dimensional verification on the draft voucher diagram, covering voucher structure, credit / debit relationship, source document relationship, period status, and evidence link, and generate voucher verification results; S106: When the voucher verification result meets the preset accounting conditions, the voucher draft is converted into the target financial voucher, and the target financial voucher is written back to the financial accounting module of the ERP system.

[0018] In some embodiments, diverse business data from an ERP system are acquired, and source identifiers, object identifiers, time identifiers, and credibility identifiers are configured for the diverse business data to generate source data encapsulation results, including: Collect diverse business data related to the generation of financial vouchers from the business processing chain of the ERP system, and perform format normalization and field semantic alignment on the diverse business data to generate standard business data; Configure source identifier, object identifier, time identifier, and credibility identifier according to the business module, business object, business occurrence node, and data verification status corresponding to the standard business data; Based on object identifiers and time identifiers, standard business data is version merged and deduplicated to generate source data encapsulation results with a unified event reference basis.

[0019] Specifically, in this embodiment, the ERP system may include business processing links such as procurement management, inventory management, accounts payable management, fund management, invoice management, approval management, and general ledger management. After triggering the financial voucher generation task, the system first collects diverse business data related to the current business matter from each business processing link. Taking the business scenario of purchasing and receiving a VAT invoice as an example, the system collects purchase orders, purchase contracts, and supplier information from the procurement management link; collects receiving slips, acceptance and receiving times, and inventory valuation information from the inventory management link; collects invoice numbers, tax amounts, total price including tax, and authentication status from the invoice management link; collects provisional accounts payable records and supplier transaction information from the accounts payable management link; and collects procurement approval, receiving confirmation, and invoice review node data from the approval management link.

[0020] Because different business modules have different data formats, field names, and business definitions, the system first standardizes the collected diverse business data by converting date format, amount precision, currency unit, organization code, and business object code into a unified format. Then, through field semantic alignment, the system categorizes supplier name, business partner, invoice issuer, and contract counterparty into transaction subject semantics, order amount, warehouse receipt amount, invoice amount, and payable amount into amount semantics, and order date, warehouse receipt date, invoice date, and approval date into time semantics, thus generating standard business data.

[0021] After generating standard business data, the system configures source identifiers based on the corresponding business modules. For example, purchase orders correspond to purchase source identifiers, receiving slips correspond to inventory source identifiers, invoice data correspond to invoice source identifiers, and approval records correspond to process source identifiers. The system configures object identifiers based on the relationships between business objects, ensuring that orders, contracts, receiving slips, invoices, and accounts payable records under the same purchase item have unified or mappable object identifiers. The system also configures time identifiers based on business occurrence nodes. These time identifiers record not only the document creation time but also the business occurrence time, approval completion time, and voucher trigger time. For credibility identifiers, the system configures them based on the data verification status. For example, data that has completed approval, passed invoice authentication, and whose receiving quantity matches the order quantity is configured with a higher credibility identifier; data with amount discrepancies, abnormal subject matching, or document supplementation status is configured with a credibility identifier pending verification.

[0022] Furthermore, the system performs version merging and deduplication of standard business data based on object identifiers and time identifiers. When the same purchase order has multiple versions due to quantity changes, the system retains the valid version consistent with the latest approval status and retains historical versions as version reference information. When the same invoice data is generated synchronously from the invoice management link and the accounts payable management link respectively, the system performs deduplication based on the invoice number, transaction entity, total price including tax, and invoice time, and retains the source difference record. When there is a partial matching relationship between the warehouse receipt and the invoice, the system generates segmented reference relationships according to the correspondence between object identifiers and amounts.

[0023] After the above processing, the system encapsulates standard business data, source identifiers, object identifiers, time identifiers, credibility identifiers, version reference information, and deduplication association information into a source data encapsulation result. This source data encapsulation result provides a unified event reference basis for subsequent construction of financial event objects, enabling the voucher generation stages such as purchase receipt, invoice entry, provisional estimate reversal, and accounts payable confirmation to be associated within the same business transaction scope. This improves the accuracy of association of diverse business data and reduces the risk of duplicate voucher generation, omissions, and missing voucher basis due to inconsistent data standards.

[0024] It should be noted that in some embodiments, the credibility identifier is not directly equivalent to the original document status, nor is it configured based solely on a single field. Instead, it is obtained through a comprehensive evaluation based on the semantic objects corresponding to the standard business data after the format of diverse business data has been normalized and the semantics of the fields have been aligned. In other words, the system first normalizes data from different sources into transaction subject semantics, amount semantics, time semantics, tax semantics, process semantics, and business object semantics, and then configures the credibility identifier for the normalized semantic objects. The credibility identifier is used to characterize the degree of trustworthiness of standard business data as the basis for vouchers in the voucher generation chain, rather than simply characterizing whether a particular original document has been approved.

[0025] Specifically, the system can configure credibility evaluation factors for standard business data. These factors include source validity factors, process confirmation factors, external authentication factors, cross-consistency factors, and version stability factors. The source validity factor determines whether the data originates from a business module in the ERP system with voucher generation permissions; the process confirmation factor determines whether the business transaction has completed the corresponding approval, acceptance, or review stage; the external authentication factor determines whether externally related data such as invoices, bank statements, and tax data has passed external verification or authentication; the cross-consistency factor determines whether semantic fields such as subject, amount, quantity, tax amount, and period are consistent across different business processes; and the version stability factor determines whether the data is in a valid version and whether it has been voided, reversed, supplemented, withdrawn, or duplicated.

[0026] When configuring credibility identifiers, the system can first quantify the aforementioned credibility evaluation factors and then generate a comprehensive credibility value. For example, the source validity factor, process confirmation factor, external authentication factor, cross-consistency factor, and version stability factor can all be assigned different evaluation values ​​according to three states: passed, partially passed, and failed, and different weights can be set according to the voucher generation scenario. For the purchase-to-invoice accounting scenario, the weights of the external authentication factor and cross-consistency factor can be higher than those of the process confirmation factor; for the internal expense approval suspension scenario, the weights of the process confirmation factor and version stability factor can be higher than those of the external authentication factor. The system calculates the comprehensive credibility value based on the evaluation value and corresponding weight of each evaluation factor, and configures the credibility identifier based on the comprehensive credibility value.

[0027] For example, when the overall credibility value reaches a preset high credibility threshold and there are no key blocking factors, the system configures a higher credibility flag. A higher credibility flag can correspond to the following situations: the data comes from a valid business module, the approval or acceptance process has been completed, data involving external authentication has been authenticated, the subject, amount, quantity, tax amount, and period semantics are consistent in different business links, and the data version is in a valid state.

[0028] When the overall credibility value is below the high credibility threshold but reaches the intermediate credibility threshold, and there are no key blocking factors, the system configures a general credibility flag. The general credibility flag can correspond to the following scenarios: the business process is complete, but some external authentication is incomplete; or the invoice has been authenticated, but the business approval is still in the subsequent review stage; or the core semantics such as amount and subject are consistent, but auxiliary accounting dimensions still need to be supplemented later. Data with a general credibility flag can participate in the construction of financial event objects, but it needs to be subject to stricter rules in the subsequent voucher draft generation or accounting verification stages.

[0029] For invoices that have completed approval but are not yet certified, the system does not directly configure a higher credibility flag. Instead, it processes them in layers based on the business scenario. If the current voucher generation task is a provisional purchase entry, invoice certification is not a necessary basis for this stage. The system can configure a general or higher credibility flag based on approval completion, warehousing completion, and amount consistency, and record the uncertified invoice status as a restriction condition for subsequent invoice entry stages. If the current voucher generation task is invoice entry or input tax confirmation, invoice certification is a key evaluation factor. Uncertified invoices will lower the external certification factor evaluation value, causing the overall credibility value to decrease. When the overall credibility value still meets the intermediate credibility threshold, a credibility flag pending verification is configured. When the overall credibility value is lower than the lower credibility threshold or there are certification failure records, a lower credibility flag is configured, and formal entry is blocked.

[0030] Furthermore, the "pending verification credibility" flag indicates that standard business data cannot yet serve as formal voucher evidence, but there is a possibility that it can be transformed into valid evidence through supplementary verification or manual confirmation. The "pending verification credibility" flag can correspond to the following scenarios: the core business process has been established, but invoice authentication, entity consolidation, explanation of amount differences, attribution of auxiliary accounting, or cross-period processing rules have not yet been confirmed. Data with the "pending verification credibility" flag can be included in the financial event object and financial transaction graph, but the system needs to retain the "pending verification" mark in the graph nodes or related edges, and generate warning or blocking flags during the voucher draft verification stage.

[0031] The lower credibility flag indicates that standard business data contains substantial anomalies that affect the reliability of voucher generation and cannot be used as the basis for generating formal vouchers. The lower credibility flag can correspond to the following situations: the data source does not belong to a valid business module; the business document has been voided or withdrawn; invoice authentication failed; the entity identification result conflicts with the master data and cannot be merged; the difference in amount or tax exceeds the preset tolerance range; the business occurrence period and the payment period status seriously conflict; or multiple mutually exclusive valid versions of the same business object exist. For data configured with a lower credibility flag, the system can prohibit it from participating in the generation of target financial vouchers and only allow it to enter the anomaly handling process as an anomaly explanation, supplementary evidence, or a subject of manual review.

[0032] In some embodiments, the credibility identifier can be configured at the data granularity as a field-level credibility identifier, a document-level credibility identifier, and an event-level credibility identifier. The field-level credibility identifier is used to evaluate the reliability of semantic fields such as subject, amount, tax, period, and quantity in standard business data; the document-level credibility identifier is used to evaluate whether the normalized document data is generally trustworthy; and the event-level credibility identifier is used to evaluate the overall credibility status when multiple source data encapsulation results form a financial event object under the same business transaction. The event-level credibility identifier can be determined comprehensively based on key field-level credibility identifiers, key document-level credibility identifiers, and the necessity of the business stage. For example, the purchase provisional accounting stage can rely heavily on the credibility of the receiving slip, purchase order, and approval record, while the invoice accounting stage requires further reliance on the invoice authentication status and the credibility of the tax field.

[0033] Through the above embodiments, the generation process of credibility identifiers no longer stops at the original data layer, but performs layered evaluations before and after the construction of standard business data layers and financial event objects; higher credibility identifiers, general credibility identifiers, credibility identifiers pending verification, and lower credibility identifiers all have clear identification criteria; for mixed states such as completed approval but uncertified invoices, the system can make differentiated identifications based on the current voucher generation stage and key evaluation factors, thereby ensuring that the credibility identifier configuration process is clear and executable, and can provide clear criteria for subsequent financial event graph construction, accounting semantic parsing, and voucher entry verification.

[0034] In some embodiments, a financial event object is constructed based on the business relationships, monetary relationships, and process status relationships in the source data encapsulation result, including: Based on the object identifier and time identifier in the source data encapsulation result, the source data encapsulation results belonging to the same business item are associated and aggregated to generate a business item data group; Based on the business flow status, amount transfer relationship and voucher triggering conditions in the business transaction data group, determine the financial event type and accounting treatment stage corresponding to the business transaction data group; Based on the type of financial event and the stage of accounting processing, the entity information, amount information, period information, and evidence citation information in the business event data group are structured and encapsulated to generate financial event objects.

[0035] Specifically, in this embodiment, after completing the source data encapsulation, the system uses object identifiers and time identifiers as the main association lines to aggregate the source data encapsulation results within the same business item scope. Taking the scenario of purchase receipt and invoice posting as an example, the purchase order, purchase contract, receipt slip, supplier invoice, accounts payable provisional record, and approval record come from different business links in the ERP system, but each data carries an object identifier corresponding to the purchase item.

[0036] The system first identifies data sets belonging to the same procurement item based on object identifiers. Then, it determines the sequence of business nodes such as order creation, contract effectiveness, goods receipt, invoice issuance, invoice review, and accounts payable confirmation based on time identifiers. Data within the same voucher generation cycle is aggregated into a business item data group. If there are multiple batches of goods receipt and installment invoicing under the same procurement item, the system links different batches of goods receipt and invoices to different processing segments within the same business item data group according to the time identifier and amount correspondence, avoiding the erroneous merging of different batches of data into a single voucher.

[0037] After generating the business transaction data group, the system reads the business flow status, amount transfer relationships, and voucher triggering conditions. The business flow status indicates whether the purchase order has been approved, whether the goods have been inspected and received into the warehouse, whether the invoice has been received and verified, and whether the payment has been executed. The amount transfer relationship indicates the relationship between the order amount, the amount received into the warehouse, the invoice amount excluding tax, the tax amount, the total price including tax, the provisional amount, and the amount payable. The voucher triggering condition indicates whether the current data has reached the processing node for generating provisional entry, provisional reversal, invoice entry, or payment voucher.

[0038] For example, in a specific instance, the purchase order amount is 100,000 yuan, the amount received is 100,000 yuan, the invoice amount excluding tax is 100,000 yuan, the tax amount is 13,000 yuan, the invoice review status is approved, and the payment status is unpaid. Based on this, the system determines that the financial event type corresponding to this business transaction is a purchase receipt and invoice payable confirmation event, and the accounting processing stage is the invoice posting stage. If the receipt has been completed but the invoice has not been received, it is determined to be a purchase provisional posting event, and the accounting processing stage is the provisional confirmation stage. If there are previous provisional records after the invoice is received, it is further determined whether to enter the provisional reversal and invoice posting connection stage.

[0039] After determining the type of financial event and the accounting processing stage, the system structurally encapsulates the subject information, amount information, period information, and evidence citation information in the business transaction data group. Subject information includes the accounting organization, supplier entity, business department, and responsible personnel; amount information includes the transaction amount, tax amount, total price including tax, provisional amount, and difference amount; period information includes the period in which the transaction occurred, the period in which the audit was completed, and the period in which the transaction is to be recorded; and evidence citation information includes the order number, warehouse receipt number, invoice number, approval node number, and historical provisional voucher number.

[0040] Furthermore, the system configures the above information into a unified structure according to financial event types, generates financial event objects, and records the source path, time sequence, amount continuation relationship, and voucher trigger status of each data item in the financial event object. For data with amount discrepancies, the system retains a discrepancy source marker in the financial event object. For example, when the amount received is inconsistent with the invoice amount, the discrepancy is marked as a candidate for unallocated expenses, discount discrepancies, or quantity discrepancies, so that subsequent financial event graphs and accounting semantic instructions can continue to process it.

[0041] Through the above processing, this embodiment encapsulates the source data scattered in different business links of the ERP system into financial event objects with unified business transaction boundaries, clear accounting processing stages, and complete evidence citation basis. This improves the accuracy of converting multi-source business data into financial voucher generation data and enhances the controllability of subsequent accounting semantic parsing, voucher draft generation, and accounting verification processes.

[0042] It should be noted that in some embodiments, financial event objects are not voucher data objects used to directly generate financial vouchers, but rather to represent the event-level encapsulation result of a single business transaction at the current accounting processing stage. Financial event objects mainly include the business entity, transaction entity, amount composition, tax status, period attributes, process status, voucher triggering conditions, and source data reference information. Their function is to consolidate the scattered and diverse business data in the ERP system into structured event units under the same financial transaction. Since financial event objects focus on describing what has happened in the current business transaction and what processing stage it is currently in, they do not fully express the transmission paths between different business facts, the constraints between different accounting elements, or the evidence chain corresponding to each voucher element. Therefore, they cannot directly replace the financial transaction graph.

[0043] Furthermore, the financial event graph is a relational representation structure built upon financial event objects. The system generates graph nodes based on business fact information, accounting processing information, and source data reference information within the financial event objects, and configures associated edges according to business flow paths, amount transfer paths, accounting element matching paths, and evidence tracing paths. Thus, the financial event graph not only records the structured fields in financial event objects but also further expresses the directional relationships, dependencies, conflict relationships, and evidentiary relationships between fields. For example, in the scenario from purchase receipt to invoice posting, the financial event object can record event information such as receipt completion, invoice verification, payment not executed, and the existence of accounts payable confirmation requirements. However, the financial event graph can further express the path relationships between purchase orders, receipt slips, invoices, provisional vouchers, supplier master data, and candidate accounting subjects, and can mark the continuation relationship between invoice amount and receipt amount, the reversal relationship between provisional vouchers and invoice posting, and the evidence source corresponding to each amount node.

[0044] Therefore, the technical step of generating a financial event graph based on financial event objects is independently necessary. Financial event objects address the problem of merging diverse business data into a single financial event, while the financial event graph addresses the computable relationships between business facts, accounting elements, and evidence citations within the same financial event. The subsequent large language model does not merely perform natural language inference based on fields in the financial event objects, but rather identifies accounting processing scenarios and voucher generation stages under the path constraints provided by the financial event graph. Similarly, subsequent multi-dimensional verification does not only verify the completeness of fields in the financial event objects, but also traces back the source documents, amount paths, rule paths, and evidence paths corresponding to each voucher entry through the financial event graph. Thus, the financial event graph can improve the relationship expression capability, evidence tracing capability, and anomaly location capability during the voucher generation process.

[0045] In some embodiments, a financial event graph is generated based on financial event objects to represent business facts, accounting elements, and evidentiary relationships, including: Analyze the business fact information, accounting treatment information and source data reference information in the financial event object to generate graph nodes corresponding to the current financial event; Based on the business flow path, amount transfer path and accounting processing stage corresponding to the financial event object, configure business association edges, accounting mapping edges and evidence tracing edges between graph nodes; A financial transaction graph is generated based on graph nodes and associated edges, and this financial transaction graph is used as the structured input for the subsequent generation of accounting semantic instructions.

[0046] Specifically, in this embodiment, after obtaining the financial event object, the system first parses the business fact information, accounting processing information, and source data reference information within the financial event object, and generates graph nodes according to the data granularity that can be used for graph structure representation. Taking the purchase receipt and invoice payment confirmation event as an example, the business fact information may include facts such as the purchase order has been approved, the goods have been inspected and received into inventory, the invoice has been verified, and the payment has not yet been executed; the accounting processing information may include the current event being in the invoice recording stage, the existence of payment confirmation requirements, the existence of deductible tax processing requirements, and the potential existence of provisional valuation processing requirements; the source data reference information may include the purchase order number, the receiving slip number, the invoice number, the supplier code, the approval node record, and the preceding provisional valuation voucher number. Based on the above parsing results, the system generates business item nodes, subject nodes, document nodes, amount nodes, tax nodes, period nodes, accounting processing stage nodes, candidate account nodes, and evidence nodes, so that each type of node corresponds to a clear data source or processing meaning in the financial event object.

[0047] After generating graph nodes, the system configures association edges between different graph nodes based on the business flow path, amount transfer path, and accounting processing stage corresponding to the financial event object. Business association edges are used to express the process connection relationship between purchase requisition, order approval, goods receipt and warehousing, invoice verification, and accounts payable confirmation. For example, the purchase order node is connected to the goods receipt node through a business association edge, and the goods receipt node is then connected to the invoice node and the accounting processing stage node.

[0048] The amount transfer path is used to express the calculation relationship between order amount, warehouse receipt amount, invoice amount excluding tax, tax amount, total price including tax and payable amount, and payable amount. For example, the invoice amount node is connected to the tax-excluding amount node and the tax item node through the amount composition relationship, and is connected to the payable amount node through the amount inheritance relationship.

[0049] Accounting mapping edges are used to express the constraints between financial event types and candidate accounting elements. For example, the purchase-to-invoice accounts payable confirmation event node connects to inventory or cost candidate account nodes, input tax candidate account nodes, and supplier accounts receivable / payable candidate account nodes. Evidence traceability edges are used to express the source data basis corresponding to each business fact, amount information, and accounting processing node. For example, the accounts payable amount node is connected to the invoice number, warehouse receipt number, and invoice review record through the evidence traceability edge.

[0050] Furthermore, when constructing the financial transaction graph, the system also configures node attributes, edge attributes, and credibility attributes for graph nodes and related edges. Node attributes are used to record data type, business stage, amount scope, accounting period, and accounting entity; edge attributes are used to record association type, transmission direction, matching rules, and generation time; credibility attributes are used to record whether a node or related edge originates from approved data, whether it has passed amount consistency verification, and whether there is manual correction or anomaly marking.

[0051] For example, when the invoice amount and the amount received are completely consistent and the invoice status is certified, the evidence traceability edge between the amount node and the invoice node is configured as highly reliable. When there is a difference between the invoice amount and the amount received, the system configures a difference marker on the amount transmission edge and uses the reason for the difference as a prompt for subsequent large language model parsing. In this way, the financial transaction graph not only expresses the static relationships between data, but also the computable relationships between business facts, amount transfer, accounting treatment, and evidence sources.

[0052] After configuring the graph nodes and associated edges, the system performs a completeness check on the graph to determine whether the current financial transaction has subject nodes, business stage nodes, amount nodes, period nodes, candidate accounting element nodes, and evidence nodes. If key nodes are missing, the location of the missing nodes and the reason for the missing nodes are marked as graph anomaly information. If the graph is complete, the financial transaction graph is used as the structured input for the generation of subsequent accounting semantic instructions.

[0053] Through the above processing, this embodiment can transform the scattered business facts in the financial event object into graph structure data with related paths and evidence paths, improve the data interpretability of the large language model when identifying accounting scenarios and determining voucher stages, and enhance the integrity of the basis for the voucher element generation process and the ability to verify and trace it later.

[0054] In some embodiments, financial event objects and financial transaction graphs are input into a large language model to generate accounting semantic instructions corresponding to the current financial transaction, including: Extract the event semantic features of the current financial event based on the financial event object, and extract the graph path that matches the event semantic features from the financial event graph; Combine event semantic features, graph paths, and preset accounting processing prompt templates into the model input data; By performing financial semantic parsing on the model input data using a large language model, accounting semantic instructions are generated that include accounting processing scenarios, voucher generation stages, and the intent of voucher elements.

[0055] Specifically, in this embodiment, after constructing the financial event objects and financial transaction graph, the system does not directly input the original document text into the large language model. Instead, it first extracts event semantic features from the financial event objects that can characterize the current financial transaction. Event semantic features may include business transaction type, business flow status, accounting entity, transaction entity, amount scope, tax status, period attributes, voucher trigger status, and anomaly markers, etc.

[0056] For example, taking the scenario of receiving an invoice after purchase and warehousing but not yet making payment as an example, the system extracts event semantic features from the financial event object, such as purchase and invoice received, warehousing completed, invoice verification passed, payment not executed, existence of supplier transactions, and existence of input tax processing. Based on these event semantic features, the system determines that the current event belongs to the business event that requires invoice recording, rather than a fund payment event or a simple provisional event.

[0057] After extracting the semantic features of the events, the system retrieves graph paths from the financial event graph that match the semantic features of the events. Graph paths can include business process paths, amount transfer paths, accounting element candidate paths, and evidence tracing paths. For example, the system forms business process paths along purchase order nodes, warehouse receipt nodes, invoice nodes, and accounting processing stage nodes; amount transfer paths along warehouse receipt amount nodes, invoice amount excluding tax nodes, tax amount nodes, and payable amount nodes; accounting element candidate paths along purchase-to-invoice payable confirmation event nodes, inventory or cost candidate account nodes, input tax candidate account nodes, and supplier account candidate account nodes; and evidence tracing paths along invoice numbers, warehouse receipt numbers, approval records, and supplier master data. If there are amount discrepancies, inconsistent entity matching, or period anomalies in the graph paths, the system uses the abnormal nodes and abnormal related edges as constraint information for model input.

[0058] Subsequently, the system combines event semantic features, graph paths, and preset accounting processing prompt templates into the model input data. The preset accounting processing prompt templates are used to define the output boundaries of the large language model, ensuring it performs structured parsing around the type of financial transaction, accounting processing scenario, voucher generation stage, and the intent of voucher elements, rather than directly outputting the final accounting entries. The templates can also embed summaries of corporate accounting policies, voucher generation restrictions, accounting dimension prompts, and anomaly handling requirements. For example, in a purchase-to-payment scenario, the template requires the model to determine whether the current transaction belongs to the invoice posting stage, identify the relationship between debit elements and inventory, expense, or tax processing, identify the relationship between credit elements and supplier transactions, and output the evidence path corresponding to each type of element.

[0059] After receiving input data, the large language model performs financial semantic parsing on business facts, graph paths, and prompt templates. It first identifies the accounting processing scenario of the current financial transaction, then determines the voucher generation stage, and finally generates the intent of voucher elements. For the aforementioned procurement scenario, the model can generate the following: a purchase-to-payment confirmation scenario; an invoice posting stage; a debit element intent to confirm asset or cost elements and tax elements based on warehousing and invoice data; a credit element intent to confirm accounts receivable / payable elements based on supplier master data; a summary intent to generate a business summary based on the procurement transaction and invoice information; and an evidence intent to reference purchase orders, warehousing slips, invoices, and approval records. This accounting semantic instruction serves only as an intermediate instruction for subsequent rule constraints and voucher draft graph generation, and is not directly used as the final voucher for posting.

[0060] Through this embodiment, the large language model completes financial semantic parsing under structured event semantics and graph path constraints. This can reduce scenario misjudgment and voucher element drift caused by relying solely on natural language generation, improve the accuracy of accounting processing scenario identification, enhance the controllability of the voucher generation stage and voucher element intent, and provide a clear semantic input foundation for subsequent accounting rule constraints, voucher draft diagram generation, and multi-dimensional verification.

[0061] In some embodiments, financial semantic parsing is performed on the model input data using a large language model to generate accounting semantic instructions that include accounting processing scenarios, voucher generation stages, and the intent of voucher elements, including: The model input data is organized into event context to generate semantic reasoning input containing business facts, graph paths, and accounting processing hints; By using a large language model to perform scene recognition and credential stage determination on semantic reasoning input, semantic candidate results are generated. Based on the graph path, the semantic candidate results are screened for evidence consistency to generate accounting semantic instructions that include accounting processing scenarios, voucher generation stages, and the intent of voucher elements.

[0062] Specifically, in this embodiment, before the model input data is sent to the large language model, the system first organizes the model input data into an event context, transforming the input content from scattered fields into semantic reasoning input with a reasoning order. The event context organization process includes placing the event semantic features in the financial event object into the first-level context, placing the key paths in the financial event graph into the association context, placing the preset accounting processing prompt template into the constraint context, and arranging them in the order of business facts, processing stages, amount paths, evidence paths, and output boundaries.

[0063] For example, taking the business transaction of receiving an invoice after purchase and warehousing but not yet making payment as an example, the system takes the business facts such as warehousing completion, invoice verification approval, supplier consistency, payment not executed, and the existence of prior provisional records as the event basis, takes the graph path from purchase order to warehousing slip, warehousing slip to invoice, invoice amount to payable amount, and invoice node to evidence node as the reasoning basis, and takes the prompt content that currently only allows the output of accounting processing scenarios, voucher generation stage, and voucher element intent as model constraints, thereby generating semantic reasoning input.

[0064] After the semantic reasoning input is formed, the large language model jointly analyzes the business facts and graph paths within it. It first identifies the accounting processing scenario corresponding to the business transaction, then determines the voucher generation stage, and outputs one or more semantic candidate results. Taking the procurement business as an example, if the semantic reasoning input shows that the goods have been inspected and received, the invoice has been received and verified, and payment has not yet been executed, the model can generate a semantic candidate result corresponding to the procurement receipt and payment confirmation scenario. If the semantic reasoning input also shows that a provisional voucher has been formed previously, the model simultaneously generates a semantic candidate result connecting the provisional reversal to the invoice recording stage. If the semantic reasoning input shows that the invoice has not been verified or the warehousing status is not complete, the model generates an anomaly blocking candidate result, but does not output a recordable stage candidate result. Each semantic candidate result includes scenario type, stage type, debit element intent, credit element intent, summary generation intent, accounting dimension intent, and evidence citation intent, but does not directly determine the final accounting subject number and entry amount.

[0065] After obtaining the semantic candidate results, the system performs evidence consistency screening based on the financial event graph. During the screening, the system compares the scenario type in the semantic candidate results with the business process path, the voucher generation stage with the accounting processing stage node, the voucher element intent with the accounting element candidate path, the amount processing intent with the amount transfer path, and the evidence citation intent with the evidence tracing path.

[0066] If a semantic candidate result points to the payment voucher stage, but the graph path shows that the payment node does not exist or the payment status has not been executed, then the candidate result is marked as inconsistent evidence and eliminated. If a candidate result points to the invoice posting stage, and there are valid evidence paths for the invoice node, warehousing node, supplier node, amount node, and approval node, then the candidate result is retained. When multiple candidate results meet the evidence consistency requirements, the system determines the priority based on the graph path completeness, node credibility, and accounting stage matching degree, and selects the semantic candidate result with the highest priority to generate accounting semantic instructions.

[0067] The generated accounting semantic instructions include accounting processing scenarios, voucher generation stages, and voucher element intents. Taking the example business, the accounting semantic instructions can represent that the current event belongs to the purchase-to-payment confirmation scenario, the voucher generation stage is the invoice entry and connection to the previous provisional valuation processing, the debit element intent corresponds to the collection of warehousing assets or costs and the processing of deductible taxes, the credit element intent corresponds to the supplier's transaction confirmation, the summary intent corresponds to the combination of purchase items and invoice information, and the evidence citation intent corresponds to purchase orders, warehousing slips, invoices, approval records, and previous provisional valuation vouchers.

[0068] In this embodiment, the output of the large language model is constrained by both the event context and the graph evidence path, which can reduce the risks of misjudgment in accounting scenarios, voucher stage drift and insufficient evidence of voucher elements, and improve the accuracy, interpretability and stability of accounting semantic instructions and subsequent rule constraint processing.

[0069] In some embodiments, the accounting rule constraint library is invoked according to accounting semantic instructions to determine the voucher element constraints, and a voucher draft diagram is generated based on the voucher element constraints, including: Based on the accounting processing scenario and voucher generation stage in the accounting semantic instructions, match the corresponding set of rule constraints in the accounting rule constraint library; Based on the set of rule constraints, the intention of the voucher elements in accounting semantic instructions is constrained in terms of account scope, debit / credit direction, source of amount and accounting dimension, and voucher element constraint conditions are generated. Based on the constraints of the voucher elements, the voucher header information, journal entry information, amount information, account information, accounting dimension information, and evidence citation information are linked to generate a voucher draft diagram.

[0070] Specifically, in this embodiment, after obtaining accounting semantic instructions, the system first reads the accounting processing scenario and voucher generation stage, and uses this as the retrieval entry point for the accounting rule constraint library. The accounting rule constraint library pre-stores enterprise accounting policies, account adaptation relationships, debit and credit direction rules, tax processing rules, auxiliary accounting rules, period control rules, and voucher summary rules.

[0071] Taking the scenario of payment confirmation upon receipt of invoices as an example, the accounting semantic instruction indicates that the current event is invoice posting and connects with the preceding provisional valuation processing. Based on this, the system matches the rules for receipt of invoices, provisional valuation reversal, input tax rules, and supplier transactions in the accounting rule constraint library to form a set of rule constraints corresponding to the current voucher generation stage. If the accounting semantic instruction indicates that the current event is an expense reimbursement that has been approved but not yet paid, the system matches the expense aggregation rules and transaction confirmation rules, and blocks fund payment rules from participating in the voucher draft generation.

[0072] After determining the set of rule constraints, the system applies these constraints to the intent of voucher elements in accounting semantic instructions. For debit element intents, the system limits the range of selectable accounts, source of funds, and auxiliary accounting dimensions based on the business object attributes, inventory or expense attribution, invoice tax status, and accounting organization. For credit element intents, the system limits the range of supplier accounts, debit / credit direction, and source of funds based on the transaction entity, payment status, and inter-company accounting requirements.

[0073] For example, taking the confirmation of accounts payable upon receipt of invoices as an example, if the financial transaction diagram shows that the received materials belong to raw materials, the invoice amount excluding tax is 100,000 yuan, the tax amount is 13,000 yuan, and the supplier code has been matched through master data, the rule constraint set will limit the scope of debit accounts to asset accounts and input tax accounts related to raw material receipts, and limit the scope of credit accounts to supplier accounts receivable / payable accounts, and bind the amount excluding tax, tax amount, and total price including tax to the invoice amount node, tax node, and accounts payable amount node, respectively. If the diagram shows that there are prior provisional vouchers, the system will also bind the source of the provisional voucher reversal amount to the prior provisional voucher node and limit the processing order between the reversal stage and the invoice posting stage.

[0074] Furthermore, after generating the voucher element constraints, the system associates the voucher header information, journal entry information, amount information, account information, accounting dimension information, and evidence citation information according to the data structure of the voucher draft diagram. The voucher header information records the accounting organization, accounting period, voucher type, and financial event number; the journal entry information records the debit or credit direction and its order; the amount information records the source of the amount, the source of the tax amount, the exchange rate, and the calculation path; the account information records the candidate account results filtered by the rule constraint set; the accounting dimension information records auxiliary accounting objects such as suppliers, departments, projects, inventory, or contracts; and the evidence citation information records the corresponding purchase orders, receiving slips, invoices, approval records, and preceding vouchers.

[0075] The system associates each voucher entry with amount nodes, account nodes, accounting dimension nodes, and evidence nodes to form a voucher draft diagram. In cases with multiple candidate accounts, the system determines the candidate order based on rule priority, historical similarity voucher matching degree, and graph node reliability. Unconfirmed candidate accounts are marked as nodes to be verified, rather than directly generating formal vouchers.

[0076] Through this embodiment, the voucher element intent output by the large language model is converted into computable and traceable voucher element constraints by the accounting rule constraint library. Voucher headers, entries, amounts, accounts, accounting dimensions, and evidence references can form a structured relationship in the voucher draft diagram, improving the standardization and controllability of voucher element generation, reducing the risk of incorrect account selection, unclear source of amount, and broken evidence chain, and providing a stable data foundation for subsequent multi-dimensional verification and formal accounting.

[0077] It should be noted that in some embodiments, the accounting semantic instructions output by the large language model are not free-form natural language text, but rather constrained structured results generated according to a preset accounting semantic instruction pattern. This accounting semantic instruction pattern includes fields for accounting processing scenarios, voucher generation stages, debit element intent, credit element intent, amount processing intent, accounting dimension intent, summary generation intent, anomaly risk, and evidence citation. When the system calls the large language model, it organizes the financial event object, the critical path in the financial event graph, and the accounting processing prompt template together as model input data. Through output field constraints, candidate value range constraints, and evidence path citation constraints, the system restricts the large language model to output accounting semantic judgment results only within preset fields, rather than generating final accounting entries or directly generating accounting vouchers.

[0078] Furthermore, after the large language model outputs accounting semantic instructions, the system sets up an accounting semantic instruction parsing layer. This parsing layer performs structured parsing, field normalization, and evidence consistency verification on the accounting semantic instructions, generating rule retrieval keys and rule constraint requests. Specifically, the parsing layer first identifies the accounting processing scenario and voucher generation stage in the accounting semantic instructions, converting them into scenario and stage identifiers recognizable by the rule base; then it parses the voucher element intent, converting the debit element intent, credit element intent, amount processing intent, and accounting dimension intent into rule request parameters such as account scope, debit / credit direction, amount source, and auxiliary accounting dimension; finally, it performs consistency filtering on the rule request parameters based on the evidence path in the financial event graph. If the processing scenario, voucher stage, or voucher element intent in the accounting semantic instruction cannot find a corresponding evidence path in the financial event graph, the parsing layer marks the accounting semantic instruction as an invalid instruction and blocks its access to the accounting rule constraint library.

[0079] Therefore, the statement in the instruction manual regarding calling the accounting rule constraint library based on accounting semantic instructions can be further clarified as follows: The accounting semantic instructions are subjected to structured parsing and evidence consistency verification to generate rule constraint requests. Based on these requests, the accounting rule constraint library is then called to determine the constraint conditions for voucher elements. This eliminates the ambiguity between natural language output and the invocation of the structured rule library.

[0080] In some embodiments, while business semantic tags in the financial transaction graph can express explicit relationships between source data, they primarily originate from fields, states, and rule-based associations in the ERP system. This makes it difficult to handle implicit accounting intentions, exceptional business semantics, and multi-stage voucher connections in complex business scenarios. For example, the same purchase receipt and invoice arrival may correspond to different accounting scenarios such as ordinary purchase receipt, invoice receipt after provisional estimate reversal, expensed purchase receipt, assetized purchase receipt, and cross-period invoice adjustment. Similarly, the same incomplete payment status may correspond to different voucher stages such as accounts payable confirmation, prepayment offset, and partial payment pending. Relying solely on graph tags to directly index the rule base can easily lead to inaccurate rule set selection due to insufficient granularity of graph tags or complex combinations of business states.

[0081] The technical role of the large language model in this solution lies in performing contextual reasoning on multiple business facts, process states, monetary relationships, and anomaly markers under the constraints of the evidence path provided by the financial event graph. This allows for the identification of a more accurate accounting treatment scenario, voucher generation stage, and voucher element intent for the current financial event. In other words, the large language model does not replace the graph or rule base in generating vouchers; rather, it undertakes the semantic disambiguation and scenario classification functions between graph labels and accounting treatment intents. The financial event graph provides a verifiable factual basis, the accounting semantic instruction parsing layer provides structured transformation and evidence consistency screening, and the accounting rule constraint base provides the final voucher element boundaries. These three elements collectively limit the output space of the large language model.

[0082] To avoid the illusion of a large language model reducing system reliability, this application also sets up multiple constraint mechanisms: First, the input of the large language model is limited to financial event objects, critical paths in the financial transaction graph, and accounting processing prompt templates, and does not directly accept unbounded raw business text; Second, the output of the large language model is limited to structured fields in the accounting semantic instruction pattern, and does not allow direct output of final accounting subjects, final amounts, and formal vouchers; Third, the accounting semantic instruction parsing layer performs evidence consistency screening based on the financial transaction graph, and semantic candidate results lacking graph evidence support are not allowed to enter the rule base call process; Fourth, the accounting rule constraint base further imposes deterministic constraints on subject scope, debit and credit direction, source of amount, and accounting dimension; Fifth, the voucher draft diagram also needs to be verified for structural integrity, accounting balance, source document consistency, period compliance, and evidence traceability before it can be converted into the target financial voucher.

[0083] Through the above embodiments, this application clarifies that: financial event objects are event-level encapsulation results, and financial event graphs are relation-level and evidence-level expression results; the large language model generates constrained structured accounting semantic instructions, rather than free natural language vouchers; accounting semantic instructions need to be converted into rule constraint requests through a parsing layer before calling the accounting rule constraint library; the technical contribution of the large language model lies in performing accounting scenario disambiguation and voucher stage determination on graph paths and business contexts, and suppressing illusion risks through graph evidence consistency screening, rule base constraints, and voucher draft graph verification, thereby improving the accuracy, controllability, and traceability of voucher generation.

[0084] In some embodiments, a multi-dimensional verification covering the voucher structure, debit / credit relationships, source document relationships, period status, and evidence chain is performed on the voucher draft diagram to generate voucher verification results, including: Extract voucher element nodes and associated edges from the voucher draft diagram to generate a set of voucher elements to be verified. Based on preset multi-dimensional verification rules, the set of voucher elements to be verified is checked for structural integrity, accounting balance, source document consistency, period compliance and evidence traceability, and verification identifiers are generated. Based on the verification identifier, determine whether the voucher draft has been approved or blocked, and generate the voucher verification result.

[0085] Specifically, after generating the voucher draft diagram, the system first extracts the voucher header node, entry node, amount node, account node, accounting dimension node, period node, source document node, evidence node, and the association edges between each node from the voucher draft diagram, and generates a set of voucher elements to be verified according to the voucher dimension, amount dimension, business dimension, period dimension, and evidence dimension.

[0086] Taking the purchase receipt and accounts payable confirmation scenario as an example, the set of voucher elements to be verified includes accounting organization, accounting period, voucher type, debit entries for assets or costs, input tax entries, credit entries for suppliers, invoice amount excluding tax, tax amount, total price including tax, supplier auxiliary accounting, inventory auxiliary accounting, purchase order, warehouse receipt, invoice, approval records, and previous provisional vouchers, etc. The system also retains the source path and generation rules corresponding to each voucher element node, so that subsequent verification can locate specific data nodes and rule nodes.

[0087] After generating the set of voucher elements to be verified, the system calls preset multi-dimensional verification rules to perform layered verification. Structural integrity verification determines whether the voucher header, debit entries, credit entries, amounts, accounts, accounting dimensions, and evidence references are complete. For example, if a credit entry for supplier transactions lacks supplier auxiliary accounting, a structural missing marker is generated. Account balance verification calculates whether the total debit amount matches the total credit amount, and verifies this in conjunction with tax amount splitting, currency conversion, and provisional reversal amounts. For example, if there is a debit of 100,000 yuan for raw materials, a debit of 13,000 yuan for input tax, and a credit of 113,000 yuan for accounts payable, the system considers the accounts balanced. If the debit-credit difference is 0.01 yuan due to differences in tax accuracy, the system determines whether to proceed with the tail-end processing based on the amount accuracy rules.

[0088] Source document consistency verification compares the subject, amount, tax, and business status in the draft voucher to ensure consistency with the source document nodes. For example, it checks if the supplier code matches the invoice tax number, if the invoice amount matches the receiving amount, if the receiving slip has been accepted, and if the invoice has passed verification. Period compliance verification determines if the accounting period matches the business occurrence time, invoice review time, and payment period open status. For example, if the invoice review time is March 28, 2026, and the March payment period is open, generating March vouchers is allowed; if the March payment period is closed, the system marks it as an abnormal period and requires adjustment or a supplementary entry process. Evidence traceability verification determines if each entry has traceable source document and rule nodes. For example, raw material entries should be associated with receiving slips, invoices, and purchasing rules; input tax entries should be associated with invoice tax amounts and tax processing rules; and accounts payable entries should be associated with supplier master data and payment rules.

[0089] For each type of verification completed, the system generates a corresponding verification identifier, including a pass identifier, a warning identifier, and a blocking identifier. For matters that do not affect accounting but require a review prompt, such as a slight difference in amount within a preset range, the system generates a warning identifier and records the processing basis. For matters that affect the legality of vouchers or the integrity of evidence, such as discrepancies between debits and credits, unverified invoices, period closures, or missing key source documents, the system generates a blocking identifier and writes the abnormal node, abnormal association edge, and abnormal reason into the voucher verification result.

[0090] If the set of voucher elements to be verified meets the preset accounting conditions in terms of structural integrity, accounting balance, source document consistency, period compliance, and evidence traceability, the system will determine the voucher draft as having passed the accounting process. If any key verification generates a blocking flag, the voucher draft will be determined as having an abnormal blocking status, and abnormal information will be generated that can be manually reviewed or automatically corrected.

[0091] Through this embodiment, the system can perform multi-dimensional, node-by-node, and location-based verification of the draft voucher before the target financial voucher is generated. This enables the voucher structure, debit / credit relationships, source document basis, period status, and evidence chain to complete closed-loop verification before accounting, thereby improving the accuracy and controllability of the voucher generation results and enhancing the audit traceability integrity of the financial accounting process.

[0092] In some embodiments, converting a draft voucher into a target financial voucher and writing the target financial voucher back to the financial accounting module of the ERP system includes: When the voucher verification result indicates that the voucher draft diagram is in the accounting approval state, the verified voucher elements and evidence reference relationships are extracted from the voucher draft diagram. According to the financial accounting interface specification of the ERP system, the voucher elements are converted into target financial vouchers, and voucher status and evidence chain index are configured for the target financial vouchers; Write back the target financial vouchers and evidence chain index to the financial accounting module of the ERP system, and update the voucher generation status of the corresponding business transaction.

[0093] Specifically, in this embodiment, after completing the multi-dimensional verification of the voucher draft diagram, the system first reads the status identifier in the voucher verification result. If the voucher verification result indicates that the voucher draft diagram is in the accounting approved state, the system extracts the voucher header node, entry node, amount node, account node, accounting dimension node, period node, and evidence node that have passed the verification from the voucher draft diagram, and forms a set of voucher elements to be entered into the accounting according to the voucher generation order.

[0094] For example, taking the scenario of confirming accounts payable upon receipt of invoices for purchases as an example, the set of elements for the voucher to be recorded may include the accounting organization, accounting period, voucher type, purchase item number, debit raw materials account, debit input tax account, credit supplier accounts receivable / payable account, amount excluding tax of 100,000 yuan, tax of 13,000 yuan, total price including tax of 113,000 yuan, supplier auxiliary accounting, inventory auxiliary accounting, purchase order number, warehouse receipt number, invoice number, and approval record number. The system also extracts the evidence reference relationship corresponding to each voucher element, so that each entry can be traced back to the source document, graph path, and rule constraint record.

[0095] After extracting voucher elements and evidence reference relationships, the system transforms the voucher data according to the ERP system financial accounting interface specifications. The transformation process includes converting voucher header nodes into voucher master table data that the financial accounting module can recognize, converting entry nodes, account nodes, and amount nodes into voucher detail data, converting accounting dimension nodes into auxiliary accounting data, and converting evidence nodes into voucher attachment indexes or source document reference indexes.

[0096] For purchase receipt and invoice payment confirmation scenarios, the system configures the voucher date to the open accounting period corresponding to the invoice approval completion date, configures the voucher type to a transfer voucher, generates a standardized summary related to purchase receipt and invoice entry, writes debit entries to raw materials and input tax accounts respectively, writes credit entries to supplier accounts, and simultaneously writes supplier code, inventory code, purchase order number, and invoice number to auxiliary accounting fields and source document reference fields. If the ERP system has multiple organization, currency, or ledger configurations, the system also selects matching financial accounting interface parameters based on the accounting organization, currency, and ledger identifier in the voucher draft diagram to avoid incorrect entries across organizations, ledgers, or currencies.

[0097] Furthermore, the system configures voucher status and evidence chain indexes for the target financial vouchers. Voucher status can include states such as pending posting, generated, pending review, or submitted. In this embodiment, before the voucher is written back to the financial accounting module but before the general ledger posting is completed, it can be configured as pending review or pending posting. The evidence chain index is used to establish associations between the target financial voucher and the voucher draft diagram, financial transaction diagram, source data encapsulation results, and verification records. The system can generate an entry-level evidence chain index for each entry. For example, raw material entries correspond to the warehouse receipt, invoice amount excluding tax, purchase receipt rules, and debit account constraint records; input tax entries correspond to the invoice tax amount, tax processing rules, and invoice authentication status; and accounts payable entries correspond to the supplier master data, total price including tax, and transaction confirmation rules. Through the entry-level index, subsequent auditors can directly locate the business facts, source of amount, and rule basis from the financial voucher.

[0098] After the target financial voucher and evidence chain index are generated, the system calls the voucher writing interface of the ERP system's financial accounting module to write the target financial voucher to the general ledger or accounts payable module, and receives the voucher number, writing time, and interface processing status returned by the financial accounting module. If the interface returns successfully, the system writes the voucher number back to the corresponding business item data group, updates the voucher generation status of purchase orders, warehouse receipts, invoices, and accounts payable records, and archives the voucher generation log, model semantic instructions, rule constraint results, multi-dimensional validation results, and evidence chain index. If the interface returns a failure, the system retains the voucher draft and the posting approval identifier, and records the interface exception reason as a write-back exception task to prevent the same business item from being generated repeatedly.

[0099] Through this embodiment, after the voucher draft meets the accounting conditions, the system can convert the verified voucher elements into target financial vouchers according to the ERP system interface specifications, and simultaneously establish an evidence chain index and a business transaction status update mechanism, thereby improving the standardization, accuracy and traceability of the voucher writing process and reducing the risks of duplicate voucher entries, source document disconnection and lack of audit basis.

[0100] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.

[0101] Figure 2 This is a schematic diagram of the structure of the ERP multi-data financial voucher generation system based on a large language model provided in an embodiment of this application. For example... Figure 2 As shown, the system includes: The acquisition module 201 is used to acquire diverse business data from the ERP system, and configure source identifiers, object identifiers, time identifiers, and credibility identifiers for the diverse business data, and generate source data encapsulation results. Module 202 is used to construct financial event objects based on the business relationships, monetary relationships and process status relationships in the encapsulation results of the source data, and to generate a financial event graph based on the financial event objects to represent business facts, accounting elements and evidence citation relationships. The generation module 203 is used to input financial event objects and financial transaction graphs into the large language model to generate accounting semantic instructions corresponding to the current financial transaction; The determination module 204 is used to call the accounting rule constraint library according to the accounting semantic instructions, determine the voucher element constraint conditions, and generate a voucher draft diagram based on the voucher element constraint conditions; Verification module 205 is used to perform multi-dimensional verification on the draft voucher diagram, covering voucher structure, debit and credit relationships, source document relationships, period status, and evidence chain, and generate voucher verification results; The write-back module 206 is used to convert the voucher draft into the target financial voucher when the voucher verification result meets the preset accounting conditions, and write the target financial voucher back to the financial accounting module of the ERP system.

[0102] In some embodiments, Figure 2 The acquisition module 201 collects diverse business data related to the generation of financial vouchers from the business processing chain of the ERP system, and performs format normalization and field semantic alignment on the diverse business data to generate standard business data. According to the business module, business object, business occurrence node and data verification status corresponding to the standard business data, the source identifier, object identifier, time identifier and credibility identifier are configured respectively. Based on the object identifier and time identifier, the standard business data is version merged and deduplicated to generate source data encapsulation results with a unified event reference basis.

[0103] In some embodiments, Figure 2The construction module 202, based on the object identifier and time identifier in the source data encapsulation result, performs association and aggregation on the source data encapsulation results belonging to the same business matter to generate a business matter data group; based on the business flow status, amount transfer relationship and voucher triggering conditions in the business matter data group, it determines the financial event type and accounting processing stage corresponding to the business matter data group; according to the financial event type and accounting processing stage, it performs structured encapsulation on the subject information, amount information, period information and evidence citation information in the business matter data group to generate a financial event object.

[0104] In some embodiments, Figure 2 The construction module 202 parses the business fact information, accounting processing information, and source data reference information in the financial event object to generate graph nodes corresponding to the current financial event; based on the business flow path, amount transfer path, and accounting processing stage corresponding to the financial event object, it configures business association edges, accounting mapping edges, and evidence tracing edges between graph nodes; it generates a financial event graph based on the graph nodes and association edges, and uses the financial event graph as the structured input for the subsequent generation of accounting semantic instructions.

[0105] In some embodiments, Figure 2 The generation module 203 extracts the event semantic features of the current financial event based on the financial event object, and extracts the graph path that matches the event semantic features from the financial event graph; combines the event semantic features, graph path and preset accounting processing prompt template into model input data; performs financial semantic parsing on the model input data through a large language model to generate accounting semantic instructions that include accounting processing scenarios, voucher generation stages and voucher element intentions.

[0106] In some embodiments, Figure 2 The generation module 203 organizes the event context of the model input data to generate semantic reasoning input containing business facts, graph paths, and accounting processing prompts; it performs scene recognition and voucher stage determination on the semantic reasoning input through a large language model to generate semantic candidate results; and it performs evidence consistency screening on the semantic candidate results based on the graph paths to generate accounting semantic instructions containing accounting processing scenarios, voucher generation stages, and voucher element intentions.

[0107] In some embodiments, Figure 2 The determination module 204 matches the corresponding set of rules and constraints in the accounting rule constraint library according to the accounting processing scenario and voucher generation stage in the accounting semantic instruction; based on the set of rules and constraints, it constrains the voucher element intent in the accounting semantic instruction in terms of account scope, debit / credit direction, source of amount and accounting dimension, and generates voucher element constraint conditions; according to the voucher element constraint conditions, it associates the voucher header information, journal entry information, amount information, account information, accounting dimension information and evidence citation information to generate a voucher draft diagram.

[0108] In some embodiments, Figure 2 The verification module 205 extracts voucher element nodes and associated edges from the voucher draft diagram to generate a set of voucher elements to be verified; based on preset multi-dimensional verification rules, it performs structural integrity, accounting balance, source document consistency, period compliance and evidence traceability verification on the set of voucher elements to be verified, and generates verification identifiers; based on the verification identifiers, it determines the accounting pass status or abnormal blocking status of the voucher draft diagram and generates voucher verification results.

[0109] In some embodiments, Figure 2 When the voucher verification result indicates that the voucher draft is in the accounting pass state, the write-back module 206 extracts the verified voucher elements and evidence reference relationships from the voucher draft; according to the financial accounting interface specification of the ERP system, it converts the voucher elements into target financial vouchers, and configures the voucher status and evidence chain index for the target financial vouchers; it writes back the target financial vouchers and evidence chain index to the financial accounting module of the ERP system, and updates the voucher generation status of the corresponding business items.

[0110] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0111] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various system embodiments described above.

[0112] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0113] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0114] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0116] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0117] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for generating ERP multi-dimensional data financial vouchers based on a large language model, characterized in that, include: Obtain diverse business data from the ERP system, and configure source identifiers, object identifiers, time identifiers, and credibility identifiers for the diverse business data to generate source data encapsulation results; Based on the business relationships, monetary relationships, and process status relationships in the source data encapsulation results, financial event objects are constructed, and a financial event graph is generated based on the financial event objects to represent business facts, accounting elements, and evidence citation relationships. Input the financial event object and the financial transaction graph into the big language model to generate accounting semantic instructions corresponding to the current financial transaction; The accounting rule constraint library is invoked according to the accounting semantic instructions to determine the voucher element constraint conditions, and a voucher draft diagram is generated based on the voucher element constraint conditions. The draft voucher diagram is subjected to multi-dimensional verification covering voucher structure, credit / debit relationship, source document relationship, period status, and evidence link, and voucher verification results are generated. When the voucher verification result meets the preset accounting conditions, the voucher draft is converted into a target financial voucher, and the target financial voucher is written back to the financial accounting module of the ERP system.

2. The method according to claim 1, characterized in that, The process of acquiring diverse business data from the ERP system, configuring source identifiers, object identifiers, time identifiers, and credibility identifiers for the diverse business data, and generating source data encapsulation results includes: Collect diverse business data related to the generation of financial vouchers from the business processing chain of the ERP system, and perform format normalization and field semantic alignment on the diverse business data to generate standard business data; Based on the business module, business object, business occurrence node, and data verification status corresponding to the standard business data, configure the source identifier, object identifier, time identifier, and credibility identifier respectively; Based on the object identifier and the time identifier, the standard business data is version merged and deduplicated to generate source data encapsulation results with a unified event reference basis.

3. The method according to claim 1, characterized in that, The step of constructing financial event objects based on the business relationships, monetary relationships, and process status relationships in the source data encapsulation results includes: Based on the object identifier and time identifier in the source data encapsulation result, the source data encapsulation results belonging to the same business item are associated and aggregated to generate a business item data group; Based on the business flow status, amount transfer relationship and voucher triggering conditions in the business transaction data group, determine the financial event type and accounting processing stage corresponding to the business transaction data group; According to the financial event type and the accounting processing stage, the subject information, amount information, period information and evidence citation information in the business event data group are structured and encapsulated to generate financial event objects.

4. The method according to claim 3, characterized in that, The generation of a financial event graph based on the financial event object to represent business facts, accounting elements, and evidence citation relationships includes: The business fact information, accounting processing information and source data reference information in the financial event object are analyzed to generate graph nodes corresponding to the current financial event; Based on the business flow path, amount transfer path and accounting processing stage corresponding to the financial event object, configure business association edges, accounting mapping edges and evidence tracing edges between the graph nodes; A financial transaction graph is generated based on the graph nodes and associated edges, and the financial transaction graph is used as the structured input for the subsequent generation of accounting semantic instructions.

5. The method according to claim 1, characterized in that, The step of inputting the financial event object and the financial transaction graph into the large language model to generate accounting semantic instructions corresponding to the current financial transaction includes: Based on the financial event object, extract the event semantic features of the current financial event, and extract the graph path that matches the event semantic features from the financial event graph; The event semantic features, the graph path, and the preset accounting processing prompt template are combined into model input data; By performing financial semantic parsing on the input data of the model using a large language model, accounting semantic instructions containing accounting processing scenarios, voucher generation stages, and the intent of voucher elements are generated.

6. The method according to claim 5, characterized in that, The process involves parsing the input data of the model using a large language model to generate accounting semantic instructions that include accounting processing scenarios, voucher generation stages, and the intent of voucher elements, including: The model input data is organized into an event context to generate semantic reasoning input containing business facts, graph paths, and accounting processing hints; The semantic reasoning input is subjected to scene recognition and credential stage determination using a large language model to generate semantic candidate results. Based on the graph path, the semantic candidate results are screened for evidence consistency to generate accounting semantic instructions that include accounting processing scenarios, voucher generation stages, and voucher element intentions.

7. The method according to claim 1, characterized in that, The step of calling the accounting rule constraint library according to the accounting semantic instruction, determining the voucher element constraint conditions, and generating a voucher draft diagram based on the voucher element constraint conditions includes: Based on the accounting processing scenario and voucher generation stage in the accounting semantic instructions, the corresponding set of rule constraints is matched in the accounting rule constraint library; Based on the set of rules and constraints, the intentions of the voucher elements in the accounting semantic instructions are constrained in terms of account scope, debit / credit direction, source of amount and accounting dimension, and voucher element constraint conditions are generated. Based on the constraints of the voucher elements, the voucher header information, journal entry information, amount information, account information, accounting dimension information, and evidence citation information are associated to generate a voucher draft diagram.

8. The method according to claim 1, characterized in that, The process of performing multi-dimensional verification on the draft voucher diagram, covering voucher structure, debit / credit relationships, source document relationships, period status, and evidence chain, to generate voucher verification results includes: Extract voucher element nodes and associated edges from the voucher draft diagram to generate a set of voucher elements to be verified. Based on preset multi-dimensional verification rules, the set of voucher elements to be verified is checked for structural integrity, accounting balance, source document consistency, period compliance and evidence traceability, and a verification identifier is generated. Based on the verification identifier, determine whether the voucher draft diagram is in the accounting approved or abnormal blocked state, and generate the voucher verification result.

9. The method according to claim 1, characterized in that, The step of converting the draft voucher into a target financial voucher and writing the target financial voucher back to the financial accounting module of the ERP system includes: When the voucher verification result indicates that the voucher draft is in the accounting approval state, the verified voucher elements and evidence reference relationships are extracted from the voucher draft. According to the financial accounting interface specification of the ERP system, the voucher elements are converted into target financial vouchers, and voucher status and evidence chain index are configured for the target financial vouchers; The target financial voucher and the evidence chain index are written back to the financial accounting module of the ERP system, and the voucher generation status of the corresponding business transaction is updated.

10. An ERP multi-data financial voucher generation system based on a large language model, characterized in that, include: The acquisition module is used to acquire diverse business data from the ERP system, and configure the source identifier, object identifier, time identifier and credibility identifier for the diverse business data to generate source data encapsulation results; The construction module is used to construct financial event objects based on the business relationships, monetary relationships and process status relationships in the encapsulation results of the source data, and to generate a financial event graph based on the financial event objects to represent business facts, accounting elements and evidence citation relationships. The generation module is used to input the financial event object and the financial event graph into the large language model to generate accounting semantic instructions corresponding to the current financial event; The determination module is used to call the accounting rule constraint library according to the accounting semantic instructions, determine the voucher element constraint conditions, and generate a voucher draft diagram based on the voucher element constraint conditions; The verification module is used to perform multi-dimensional verification on the draft voucher diagram, covering voucher structure, loan relationship, source document relationship, period status and evidence link, and generate voucher verification results; The write-back module is used to convert the voucher draft into a target financial voucher when the voucher verification result meets the preset accounting conditions, and then write the target financial voucher back to the financial accounting module of the ERP system.

Images