An invoice intelligent archiving system and method based on a knowledge graph

Abstract

The application provides an invoice intelligent archiving system and method based on a knowledge graph. The system comprises a knowledge graph construction module for constructing and maintaining a finance and tax knowledge graph; a contract analysis module for tax classification coding reasoning on subject matter information extracted from an electronic contract file; an invoice compliance research and judgment module for obtaining invoice application information and performing compliance verification, and controlling whether to allow triggering a signature and issuing operation according to a first verification result; an input inspection module for performing multi-level compliance inspection on input invoice files and outputting inspection results; a collection module for obtaining input invoice files and associated business metadata from an external business system; a forced verification module for performing forced technical verification on input invoice files, and controlling the opening or blocking of a data writing channel according to a second verification result; an encapsulation module for generating an archiving data package; and a ledger generation module for dynamically generating a ledger according to a user-defined template.

Description

Technical Field

[0001] This invention relates to the fields of computer and artificial intelligence technology, and in particular to an intelligent invoice archiving system and method based on knowledge graphs. Background Technology

[0002] Currently, enterprises generally adopt the following technical solutions in the field of invoice management: 1. Invoicing process: Based on the paper contracts or application forms provided by the business departments, the finance staff manually enters information such as product name, tax classification code, and tax rate into the invoicing software. Some companies use invoicing auxiliary software with a drop-down list of tax classification codes, but the correspondence between the codes and the contract text still needs to be judged and selected manually.

[0003] 2. Invoice Receipt Process: After receiving the input invoices, employees submit them for reimbursement via printed copies or electronic files. Finance personnel then log into the State Taxation Administration's VAT invoice verification platform and manually input the four key elements of each invoice: invoice code, number, invoice date, and verification code, to verify its authenticity. Some companies deploy OCR recognition engines to perform text recognition on invoice images to assist in inputting invoice information; however, the OCR recognition results still require manual review and correction.

[0004] 3. Reimbursement and Internal System Process: Companies use independent OA reimbursement systems or business travel platforms to handle approval processes. Invoices are typically uploaded as attachment images or PDF files. After the approval process is completed, accounting vouchers are generated. There are no structured association fields between invoice files and business documents (such as itineraries and purchase orders); they are only attached as file attachments. There is no association between business context information (such as the reason for the business trip and cost center affiliation) and invoice files that can be automatically read by the computer.

[0005] 4. Archiving Stage: Most companies' electronic archiving solutions employ a hierarchical folder storage method using file servers or cloud storage services, storing PDF or OFD files by directory hierarchy such as year, month, and invoice type. Some companies have deployed electronic accounting archive systems, receiving invoice files pushed by the reimbursement system through a pre-set data import interface; a few companies have attempted to upload the hash value of the invoice files to the blockchain for evidence storage, or use WORM (Write Once, Read Many) optical disc media for physical storage.

[0006] 5. Data utilization stage: Finance personnel regularly export fixed-format purchase and sales invoice reports from the accounting software, or manually organize and manage ledgers using Excel spreadsheet software for tax declaration and management analysis.

[0007] In summary, the existing invoice management system has the following main shortcomings: 1. The invoicing process relies on manual experience for coding deduction: Existing invoicing assistance systems only maintain a flat list of codes for users to select from, and cannot automatically convert unstructured descriptions of goods or services in the contract text (such as providing one year of equipment maintenance services) into accurate tax classification codes (such as specific codes under Modern Services - Attestation and Consulting Services). Finance personnel need to read and understand the contract terms themselves and search for matching items one by one in the code list. Due to misunderstandings of tax policies or fuzzy memories, invoicing errors such as incorrect selection of tax classification codes, inappropriate application of tax rates, and omission of mandatory information in the remarks column occur frequently.

[0008] 2. Invoice verification is limited to authenticity checks: Current technology can only verify whether an invoice was genuinely issued by the tax system through the tax platform. It cannot automatically verify whether the transaction content on the invoice matches the actual business operations of the enterprise. For example, the system cannot determine whether the product name on the invoice is substantially consistent with the purchase object stipulated in the purchase contract, or whether the seller on the invoice is consistent with the legal entity that signed the contract. This verification method, which only examines the form of the invoice and not the substance of the business, exposes enterprises to the tax compliance risk of not being able to deduct input tax.

[0009] 3. Disconnected Data Channels Between Business Systems and Archiving Systems: Electronic invoices in the expense reimbursement approval system and business travel platform exist only as document attachments in the approval process, lacking an automated, structured data collection channel with the archiving system. Core invoice metadata (invoice date, amount excluding tax, tax amount, invoice code and number) and its associated business context information (the department of the person submitting the expense report, cost center code, purchase order number, and travel itinerary origin and destination) cannot be synchronously entered into the archiving database. This forces companies to have finance personnel manually enter this information, resulting in low efficiency, a high risk of data omissions, and difficulty in forming a complete chain of business evidence.

[0010] 4. Lack of mandatory technical verification methods in the archiving and acquisition process: The existing archiving system adopts a passive receiving mode, that is, the file system stores the file of the format that the user uploads. It is impossible to impose mandatory constraints on the compliance of the submitted file format from a technical point of view. Employees often only upload PDF files or screenshots that are easy for human readers, while the legally required XML format structured source files are largely missing. The archive library only saves the visual effect files of printed copies or converted copies of non-native formats, which cannot meet the regulatory requirements of the "Electronic Accounting Archives Management Measures" that electronic invoice source files should be archived completely.

[0011] 5. The credibility of archived data depends on the storage system's own claims: Even if existing solutions store files in blockchain systems or WORM storage media that claim to have immutability, the proof of their integrity still depends on the storage system's own claims of credibility. When archived electronic records need to be submitted to the court as judicial evidence, verification services must be provided by the original system developer or storage service provider. The records themselves cannot independently prove to third parties that they have not been modified since their creation and that their creation time is accurate, detached from the original system.

[0012] 6. Rigid and inflexible reuse of archived data: Archived data is locked in a fixed report format preset by the system. Financial personnel cannot select the required fields and customize the table structure to dynamically generate management ledgers according to the flexible management needs proposed by management (such as summarizing by specific suppliers, classifying by expense type, and filtering by project code). Archived data is unable to play its due value as a management decision support asset of the enterprise. Summary of the Invention

[0013] The purpose of this invention is to provide an intelligent invoice archiving system and method based on knowledge graphs, aiming to solve the above-mentioned problems in the prior art.

[0014] This invention provides a knowledge graph-based intelligent invoice archiving system, comprising: The knowledge graph construction module is used to build and maintain financial and tax knowledge graphs. The contract parsing module, connected to the knowledge graph construction module, is used to extract information from electronic contract documents, and to perform tax classification coding reasoning on the extracted subject information based on the financial and tax knowledge graph, and output the reasoning results to the invoicing terminal. The invoice compliance assessment module is connected to the knowledge graph construction module and the invoice issuing end. It is used to obtain invoice application information before the invoice is signed and stamped, perform compliance verification on the invoice application information based on the financial and tax knowledge graph, and control whether to allow the signing and stamping operation based on the first verification result. The input invoice inspection module is connected to the knowledge graph construction module and the internal business system. It is used to perform multi-level compliance checks on the received input invoice documents and output the inspection results. The collection module is connected to the input invoice inspection module and the external business system. It is used to obtain input invoice files and their associated business metadata from the external business system through a standardized interface, and to receive the inspection results. The mandatory verification module is deployed at the system data entry point and is connected to the collection module and the archive database. It is used to perform mandatory technical verification on the input invoice files and control the opening or blocking of the data writing channel based on the obtained second verification result. The encapsulation module is connected to the archive database and is used to extract the set of input invoices that have passed the verification from the archive database, calculate the integrity verification value of the set of input invoices, bind the integrity verification value with a timestamp, generate an archive data package, and output it to the archive database. The ledger generation module is connected to the archived database and is used to extract data from the archived database according to the user-defined template and dynamically generate ledgers, and output the generated ledgers to the user terminal. The collection module also includes a status write-back unit, which is used to send a status write-back message to the external business system when the inspection result meets the preset blocking conditions, thereby triggering the external business system to block the flow of the corresponding document.

[0015] This invention provides a knowledge graph-based intelligent invoice archiving method, comprising: Build and maintain a financial and tax knowledge graph using the knowledge graph construction module; The electronic contract document is extracted through the contract parsing module, and the extracted subject matter information is classified and coded for tax purposes based on the tax knowledge graph. The reasoning results are then output to the invoicing terminal. The invoice compliance assessment module obtains invoice application information before invoice signature generation, performs compliance verification on the invoice application information based on the financial and tax knowledge graph, and controls whether to allow the signature and issuance operation based on the first verification result. The input invoice inspection module performs multi-level compliance checks on the received input invoice documents and outputs the inspection results. The collection module uses a standardized interface to obtain input invoice files and their associated business metadata from external business systems, and receives the inspection results. The mandatory verification module deployed at the system data entry point performs mandatory technical verification on the input invoice file, and controls the opening or blocking of the data writing channel based on the obtained second verification result. The encapsulation module extracts the verified input invoice data set from the archive database, calculates the integrity verification value of the input invoice data set, binds the integrity verification value with a timestamp, generates an archive data package, and outputs it to the archive database. The ledger generation module extracts data from the archived database based on the user-defined template and dynamically generates ledgers, which are then output to the user's end. The collection module also includes a status write-back unit. When the inspection result meets the preset blocking conditions, the status write-back unit sends a status write-back message to the external business system, triggering the external business system to block the flow of the corresponding document.

[0016] This invention also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the above-described knowledge graph-based intelligent invoice archiving method.

[0017] This invention also provides a computer-readable storage medium storing an information transmission implementation program, which, when executed by a processor, implements the steps of the above-described knowledge graph-based intelligent invoice archiving method.

[0018] The embodiments of this invention can include the following beneficial effects: This invention proposes a full lifecycle compliance archiving system for invoices based on mandatory verification and intelligent judgment. By constructing a policy knowledge graph and contract semantic parsing engine, an intelligent judgment module for the compliance of sales invoices, a full-dimensional compliance inspection engine for input invoices, an internal system integration and proactive invoice collection engine, a multi-source collection and mandatory verification archiving module, an anti-tampering solidification and encapsulation and account-to-physical verification module, and a custom ledger dynamic generation module, this system solves the problems in existing technologies such as invoicing relying on manual experience inference, single-dimensional and formal review of invoice receipt, data fragmentation between business systems and archiving systems, lack of mandatory verification methods in archiving collection leading to a large number of missing source files, reliance on centralized declarations for the credibility of archived data that cannot be independently verified, and rigid and inflexible methods of using archived data. This system achieves a closed-loop intelligent compliance management of invoices throughout the entire chain, from invoice judgment, receipt inspection, internal collection, mandatory verification, anti-tampering encapsulation to dynamic utilization. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of an intelligent invoice archiving system based on knowledge graphs according to an embodiment of the present invention; Figure 2 This is a flowchart of the knowledge graph-based intelligent invoice archiving method according to an embodiment of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0022] System Implementation Examples According to embodiments of the present invention, a knowledge graph-based intelligent invoice archiving system is provided. Figure 1 This is a schematic diagram of an intelligent invoice archiving system based on knowledge graphs, as described in an embodiment of the present invention. Figure 1 As shown, the knowledge graph-based intelligent invoice archiving system according to an embodiment of the present invention specifically includes: Knowledge graph construction module 10 is used to construct and maintain a financial and tax knowledge graph; the knowledge graph construction module also includes an automatic update unit, used for: Regularly retrieve published tax rule change documents from designated data sources; Structural change information is extracted from the changed files using a named entity recognition model; Automatically generate and execute operation instructions for adding nodes, modifying node attributes, or changing edge relationships in the financial and tax knowledge graph based on the structural change information; The tax knowledge graph includes a concept layer, a rule layer, and an instance layer. The concept layer constructs coding nodes based on the tax classification coding standard. The rule layer stores tax processing rules in a condition-conclusion structure. The instance layer stores the mapping pairs between confirmed descriptions of goods or services and tax classification codes.

[0023] The contract parsing module 11, connected to the knowledge graph construction module, is used to extract information from electronic contract documents and perform tax classification coding reasoning on the extracted subject matter information based on the financial and tax knowledge graph, outputting the reasoning results to the invoicing terminal; specifically including: The text extraction unit is used to extract text content from electronic contract documents of different formats; A key information extraction unit, connected to the text extraction unit, is used to input the extracted text content into a pre-built semantic model to identify and extract structured fields that include at least the name of the subject matter of the contract. The encoding reasoning unit, connected to the key information extraction unit, is used to match the name of the target with the encoding nodes of the concept layer in the financial and tax knowledge graph, calculate the matching probability of each encoding node, and output the reasoning results to the invoicing terminal according to the matching probability.

[0024] The invoicing compliance assessment module 12, connected to the knowledge graph construction module and the invoicing terminal, is used to obtain invoicing application information before invoice signing and stamping, perform compliance verification on the invoicing application information based on the financial and tax knowledge graph, and control whether to allow the signing and stamping operation based on the first verification result; specifically used for: Obtain invoice application information; wherein, the invoice application information includes the tax classification code filled in, the selected tax rate, and the text in the remarks column; The tax classification code is used as the key to query the financial and tax knowledge graph to obtain the statutory tax rate and remarks requirements corresponding to the tax classification code. The selected tax rate is compared with the statutory tax rate. If they are inconsistent, a first type of alarm message is generated. According to the above requirements, check whether the text in the remarks column contains the required remarks fields. If it does not contain them, generate a second type of prompt information. Obtain the taxpayer identity category of the invoice issuer, determine whether the selected tax rate is within the range of tax rates allowed for the taxpayer identity category, and generate a third type of alarm information if it is not within the range of tax rates allowed for the taxpayer identity category. The first type of alarm information, the second type of prompt information, and the third type of alarm information are summarized into a structured pre-inspection report and output to the invoicing terminal for display; If the structured pre-inspection report does not contain any of the first type of alarm information, the second type of prompt information, or the third type of alarm information, then the signature and issuance operation is allowed to be triggered.

[0025] The input invoice inspection module 13, connected to the knowledge graph construction module and the internal business system, is used to perform multi-level compliance checks on the received input invoice documents and output the inspection results; specifically, it is used for: Multi-level compliance checks are performed sequentially on the received input invoice documents; The first level of inspection is used to verify the authenticity of the source of the input invoice document and the validity of the digital signature. The second level of inspection is used to perform compliance checks on the format of the input invoice documents based on the financial and tax knowledge graph. The third level of inspection is used to compare the transaction data stated in the input invoice with the business data of the internal business system; wherein, the business data includes purchase contract data and supplier master data; The results of inspections at each level are summarized to generate a structured audit report, which is then output to the aggregation module.

[0026] The collection module 14 is connected to the input invoice inspection module and the external business system, and is used to obtain input invoice files and their associated business metadata from the external business system through a standardized interface, and to receive the inspection results; The mandatory verification module 15, deployed at the system data entry point and connected to the collection module and archive database, is used to perform mandatory technical verification on the input invoice documents and control the opening or blocking of the data writing channel based on the obtained second verification result; specifically used for: Receive the input invoice file obtained by the collection module; Read the header feature byte sequence of the input invoice file to determine the actual format type of the file. When the actual format type does not match the format claimed by the file extension, generate a blocking instruction. The system detects whether the same set of input invoice files contains both an XML-formatted structured source file and a PDF or OFD-formatted visualization file. If the XML-formatted structured source file is missing, a blocking instruction is generated. The structured source file in XML format is subjected to structure compliance verification according to the preset structure definition file. The verification is made to check whether the structured source file contains all required fields and whether the data type and value of each field meet the preset requirements. If not, a blocking instruction is generated. If any of the aforementioned blocking instructions is generated, the data write channel from the aggregation module to the archive database is closed; if no blocking instruction is generated, the data write channel is opened.

[0027] Encapsulation module 16, connected to the archive database, is used to extract a set of verified input invoice data from the archive database, calculate an integrity verification value for the input invoice data set, bind the integrity verification value with a timestamp, generate an archive data package, and output it to the archive database; specifically including: The data aggregation unit is used to extract a set of verified input invoice data from the archived database; wherein, the set of input invoice data includes the input invoice source file, the business metadata, the inspection results, and accounting voucher association information; A hash calculation unit, connected to the data aggregation unit, is used to calculate an integrity verification value for the input invoice data set using a cryptographic hash algorithm; A timestamp binding unit, connected to the hash calculation unit, is used to send the integrity verification value to a trusted timestamp service provider and receive the returned timestamp token. The encapsulation output unit, connected to the data aggregation unit, hash calculation unit, and timestamp binding unit, is used to combine the input invoice data set, the integrity verification value, and the timestamp token into an archive data package according to a preset format, and output the archive data package to the archive database.

[0028] The ledger generation module 17 is connected to the archived database and is used to extract data from the archived database according to the user-defined template and dynamically generate ledgers, and output the generated ledgers to the user terminal. The collection module also includes a status write-back unit, which is used to send a status write-back message to the external business system when the inspection result meets the preset blocking conditions, thereby triggering the external business system to block the flow of the corresponding document.

[0029] The following describes in detail the above-mentioned technical solutions of the present invention with reference to the specific circumstances of the knowledge graph-based intelligent invoice archiving system of the present invention.

[0030] This invention proposes a compliance archiving system for the entire lifecycle of invoices based on mandatory verification and intelligent judgment, comprising the following seven core modules: I. Policy Knowledge Graph and Contract Semantic Parsing Engine This module consists of two parts: a policy knowledge graph construction unit and a contract semantic parsing unit.

[0031] 1. Policy Knowledge Graph Construction Unit This unit uses a graph database to construct a three-layer tax policy knowledge graph.

[0032] The first layer is the conceptual layer: based on the national standard GB / T 14885-2010, it expands to include all tax classification codes. Each code is a node in the diagram, and the node attributes include: unique identifier of the code, name of goods or services, detailed description, applicable VAT rate, and special remarks requirements.

[0033] The second layer is the rule layer: the tax treatment rules for tax rate adjustments, new or abolished codes, and specific transactions in the original text of policies and regulations issued by relevant management departments are stored as edges and additional attributes in the graph in the form of conditions-conclusions.

[0034] The third layer is the instance layer: it stores historical mapping samples that have been manually verified, namely, the verified mapping pairs of product or service description text → tax classification code.

[0035] The automatic update mechanism of the knowledge graph is as follows: The system runs a web crawler program at a preset cycle, automatically accesses relevant official websites and the tax policy release section, and crawls newly released tax policy documents; the crawled policy text is preprocessed and then input into a named entity recognition model based on bidirectional long short-term memory network and conditional random field (BiLSTM-CRF). This model is pre-trained using policy document corpora labeled with entity categories such as tax item names, tax rate figures, code numbers, and applicable industries; the model extracts structural information from the new policy text, such as adjustments to tax classification codes, changes in tax rates, and additions to tax exemption scope, and automatically generates operation instructions for adding nodes, modifying node attributes, or changing edge relationships in the graph database. After confirmation, these instructions are executed, thereby realizing the continuous evolution of the knowledge graph.

[0036] 2. Contract Semantic Parsing Unit This unit performs the following processing procedure on the uploaded electronic contract documents: The first step is text extraction: For PDF files, use a PDF text extractor to extract the original text content while preserving paragraph structure; for Word files, use a Word document parser to extract the main text and table content; for scanned or image files, call the OCR recognition engine to perform image text recognition, and mark text areas with a recognition confidence level lower than a preset threshold as requiring manual review.

[0037] The second step is key information extraction: After the extracted full text is segmented at the sentence level, it is input into a fine-tuned pre-trained semantic model (this model is based on a transformer architecture and is fine-tuned using labeled contract samples labeled with fields such as the full names of the buyer and seller, taxpayer identification number, name of the contract subject matter, specifications, quantity, unit price, amount including tax, amount excluding tax, signing date, delivery method, and service start and end dates). The model outputs the extraction results of each target field and the corresponding confidence score for each sentence. Fields with confidence scores lower than the preset threshold are submitted for manual review.

[0038] The third step is tax classification coding reasoning: The extracted contract subject matter name text is input into a coding reasoning model based on a graph attention network. The input to this model contains information from two sources: first, the vectorized representations of all candidate coding nodes extracted from the concept and instance layers of the policy knowledge graph; second, the text vector of the contract subject matter name text converted by the semantic coding model. The model uses a multi-head graph attention mechanism to calculate the matching attention score between the contract subject matter text vector and the vectors of each candidate coding node. Each candidate code obtains a matching probability value. Finally, the model outputs the top three candidate codes and their corresponding probability scores according to the matching probability from high to low.

[0039] This module upgrades the selection of tax classification codes from a model that relies on human memory and experience to an automatic reasoning model based on knowledge graphs and semantic models, thereby providing invoicing personnel with auxiliary decision-making references.

[0040] II. Intelligent Assessment Module for Sales Invoicing Compliance This module performs compliance assessment in the following three steps, after the invoice application is submitted and before the invoice XML file is generated and the tax digital certificate is invoked for signing: Step 1: Verify the consistency between the code and the applicable tax rate Read the tax classification code and selected VAT rate filled in the invoice application, use the code as the key to query the statutory applicable tax rate corresponding to the code stored in the concept layer of the policy knowledge graph, compare the selected tax rate in the invoice application with the statutory tax rate registered in the graph, and if the two are inconsistent, generate an alarm record containing conflict description and correction suggestions.

[0041] Step 2: Verification of the Remarks Column's Standards Read the text content of the remarks column filled in the invoice application. Using the tax classification code filled in the invoice application as the key, query the policy knowledge graph concept layer to see if there are mandatory remarks requirements for the corresponding industry. If there are mandatory remarks requirements (including but not limited to construction services requiring the location and project name of the construction service, real estate sales requiring the address of the real estate, and transportation services requiring the origin and destination), then search the remarks column text item by item to see if it contains the above mandatory fields. For missing fields that cannot be found, generate specific supplementary prompts.

[0042] Step 3: Taxpayer Identity Verification The system reads the taxpayer identity category (general VAT taxpayer or small-scale taxpayer) recorded in the enterprise's basic file, compares it with the legal correspondence between taxpayer identity and applicable tax rate, and determines whether the currently selected tax rate is within the set of tax rates allowed for this taxpayer identity. If it is not within the allowed range, an identity mismatch alarm message is generated.

[0043] Once the above three verification steps are completed simultaneously, all verification results are summarized into a structured invoicing compliance pre-inspection report, which is displayed to the invoicing personnel in the invoicing operation interface.

[0044] This module moves the compliance check point forward to before the invoice is signed and issued, in order to reduce the cancellation of invoices and red-ink reversal operations caused by issues such as coding, tax rate, and remarks column from the source.

[0045] III. Comprehensive Compliance Inspection Engine for Input Invoices Upon receiving the XML format file of the input invoice, this module performs compliance checks in the following three levels: First layer: Verification of source authenticity and digital signature validity The system calls the signature verification interface provided by the Tax Digital Certificate Authentication Center to read the digital signature node embedded in the invoice XML file (this signature is generated according to the national cryptographic standard GM / T 0015-2012 "Digital Certificate Format Specification Based on SM2 Cryptographic Algorithm"). It then verifies the validity of the digital signature using the root certificate public key issued by the Tax CA. The verification includes: whether the signature certificate is valid, whether the signature value matches the original content of the XML document, and whether the issuer of the signature certificate is a trusted tax authentication authority. After successful digital signature verification, the system calls the application programming interface of the relevant administrative department's VAT invoice verification platform, sending the invoice code, invoice number, invoice date, and amount excluding tax as request parameters to the verification platform. The system then compares the invoice information in the verification results returned by the platform with the invoice information obtained from parsing the XML file, field by field.

[0046] Second layer: Checking the compliance of the ticket format Using the tax classification code extracted from the invoice XML file that passed the first-level verification as the key, query the compliance attribute set of that code in the policy knowledge graph and perform the following three sub-checks: The first sub-item is code validity check: confirming whether the tax classification code exists in the current valid version of the policy knowledge graph (the system automatically records the tax classification code version number updated on January 1st of each year, and rejects codes of obsolete versions); The second sub-item is the tax rate consistency check: confirm whether the tax rate filled in each commodity line of the invoice is consistent with the statutory tax rate registered in the map for the tax classification code attached to the commodity in that line; The third sub-item is the standardization check of the remarks column: based on whether the industry corresponding to the code in the map has mandatory remarks requirements, check whether the remarks column contains the necessary remarks information.

[0047] Third layer: Business substance consistency check The system will cross-compare the structured transaction data extracted from the invoice XML file (including product name, specifications, quantity, unit price excluding tax, amount excluding tax, total amount including tax, seller's taxpayer identification number, and seller's full name) with the following three types of business data collected from the company's internal system: The first type of comparison object is procurement contract data, namely, the name, quantity, total contract amount, and taxpayer identification number of the contracting party extracted from the procurement contract documents by the contract semantic parsing unit in Module 1. The comparison logic includes semantic similarity calculation of product names, quantity deviation calculation, amount deviation calculation, and taxpayer identification number consistency verification. Among them, the product name similarity uses the edit distance algorithm, which calculates the minimum number of single-character edit operations required to convert between two strings. The similarity value is equal to the edit distance divided by the length of the longer of the two strings and then taking the complement. If the similarity is greater than a preset threshold, it is considered that the product name matches.

[0048] The second type of comparison involves data from inbound or acceptance slips, which are the material names, specifications, and actual quantities received obtained from the warehouse management system or quality acceptance system, and are compared with the product information recorded on the invoice.

[0049] The third type of comparison object is the supplier master data, namely the list of qualified suppliers and their taxpayer identification numbers obtained from the enterprise supplier file management system. It confirms that the seller identification number on the invoice meets the following two conditions: it is consistent with the taxpayer identification number of the party signing the purchase contract and it exists in the list of qualified suppliers.

[0050] After all three levels of checks are completed, the system summarizes the results of each level of checks and generates a structured input invoice audit report. The report classifies each risk into three levels according to its severity: Red Blocking Level indicates that the digital signature is invalid, the invoice is found to be counterfeit, or the invoice status is voided. The system automatically generates an interruption command to block the invoice from flowing through the subsequent reimbursement approval and archiving process; Orange Warning Level indicates that the semantic similarity of the product name is lower than the threshold, the supplier's three codes are inconsistent, or the tax rate does not match the code. The system generates a warning notification and pushes it to the financial audit personnel. It can only continue to flow after manual confirmation; Yellow Prompt Level indicates that the remarks column is missing non-mandatory optional fields or the tax classification code version number is not the latest. The system records the prompt information but does not block the flow of the process.

[0051] This module expands the review of input invoices from a single dimension of authenticity verification to a full-scale inspection of three dimensions: authenticity verification, invoice format compliance, and business substance consistency, achieving a technological upgrade from formal compliance review to substantive compliance review.

[0052] IV. Internal System Integration and Proactive Invoice Collection Engine This module consists of three parts: a standardized interface unit, an active collection unit, and a status write-back unit.

[0053] 1. Standardized interface unit The system defines a standardized application programming interface (API) specification for interfacing with various internal business systems within the enterprise. This API specification defines a common data structure for data transmission: source system identifier, source system internal document number, invoice file list (each invoice must include both a structured XML file and a PDF or OFD visualization file), and business metadata. Specific fields in the business metadata dataset vary depending on the source system type: metadata from a business travel platform includes the traveler's name, department, itinerary, travel date, order number, and expense type; metadata from a procurement and expense reimbursement system includes the claimant's name, department to which the expense belongs, cost center code, purchase order number, and accounting period to which the expense belongs.

[0054] 2. Active collection unit The system employs an event-driven architecture to automatically collect invoice data. For business systems that have already integrated with the system through standardized interfaces, the following two data acquisition modes are supported: In push mode, after the approval process is completed and approved, each business system actively sends the invoice file and business metadata to this system according to the interface specification. After receiving the data, this system returns a receipt confirmation receipt.

[0055] In pull mode, for systems that do not support active push function, the system polls the open data query interface of each business system at a configurable time interval (once every 30 minutes by default) to obtain the newly added approved invoice records and their associated business metadata since the last polling time point, and actively pulls them into the collection queue of this system.

[0056] Through the two modes described above, invoice files and their business context enter the processing queue of the archiving system as soon as the business approval is completed, realizing a structured association between business metadata and invoice files.

[0057] 3. Status write-back unit When the compliance check result of Module 3 is determined to be at the red blocking level, the system sends a status write-back message to the source business system through a standardized interface. This message contains the following information: the document number of the blocked invoice in the source system, the blocking status identifier, the blocking reason code, the textual description of the blocking reason, and the timestamp of the blocking occurrence. After receiving the write-back message, the source business system displays the blocking status and specific reason in the corresponding approval document interface and prevents the document from entering the next approval node.

[0058] This module enables automated and structured transmission of invoice data from the business system to the archiving system through standardized interfaces and proactive collection mechanisms, eliminating manual transfer and secondary data entry. Through a status write-back mechanism, a closed loop of compliance check results feedback is formed from the archiving system to the business system.

[0059] V. Multi-source Acquisition and Mandatory Verification Archiving Module This module is deployed at all data entry points in the system and employs a mandatory processing strategy that requires technical verification before allowing data to enter the database. Specifically, it includes the following three levels of verification: 1. Forced file type verification After receiving an upload request, the system determines the actual file format by reading the characteristic byte sequence in the file header. The specific verification rules are as follows: For PDF files, read the byte sequence at the file's starting offset and check if it contains the standard PDF file header identifier string; For XML files, read the file header byte sequence and check if it contains XML declaration tags or invoice root node tags; For OFD files, read the file header byte sequence, check if it matches the file header characteristics of a ZIP archive, and after decompression, check if the archive contains a specific path to the OFD core configuration file.

[0060] When the system detects that the actual format of a file does not match the format claimed by the file extension, it immediately returns an error message indicating that the file type is invalid and terminates the upload process.

[0061] In addition to the single file type verification mentioned above, this module also performs a mandatory pairing verification: the system checks whether each uploaded invoice file contains both an XML file and a PDF or OFD format visualization file. If only a PDF file is uploaded without the corresponding XML file, the system determines that the requirements for archiving source file collection are not met and refuses to accept the file set.

[0062] 2. XML file deep format validation For XML files that pass file type validation, the system further performs the following two deep validations: The first step is XML Schema structure compliance verification: The system loads the latest version of the invoice XML Schema definition file issued by the relevant management department. This file is written in XML schema definition language and fully defines all elements allowed in the invoice XML document, the order of appearance of each element, data type, value range, and required and optional attributes. The uploaded XML document is then structurally verified. The verification content includes, but is not limited to: whether the document contains all element nodes marked as required (including the seller's name, buyer's name, invoice code and number, and invoice date in the basic invoice information, and the product name, quantity, unit price, amount, tax rate, and tax amount in the product line information), whether the data type of each element meets the requirements (the value of the amount field must be a numeric type and not a text string), and whether the values ​​of each field are within the allowed range (the value of the tax rate field must be one of the values ​​in the set of statutory tax rates).

[0063] The second item is the digital signature validity verification: The system reads the digital signature node embedded in the XML document according to the verification process specified in the national cryptographic standard GM / T 0015-2012 "Digital Certificate Format Specification Based on SM2 Cryptographic Algorithm", uses the root certificate issued by the tax certification authority to verify the legality of the signature certificate, verify whether the signature value matches the original content of the document, and verify whether the signature certificate is within its validity period.

[0064] 3. Technical blocking mechanism If any of the above verification steps fails, including but not limited to the following situations: missing XML source file, XML file schema structure verification fails, XML file digital signature verification fails, the system generates a structured blocking instruction. This blocking instruction contains the following information elements: a unique blocking instruction number, the blocked business process target, the name identifier of the target system, a textual description of the blocking reason, and the standard error code corresponding to the blocking reason. This blocking instruction is sent to the source business system through the status write-back channel described in Module 4. After receiving the blocking instruction, the source business system forcibly terminates the continued flow of the corresponding approval document at the business process level, displays the blocking reason and the corrective measures to be taken in the user operation interface, and the approval document can only be unblocked and continue the subsequent process after the user resubmits and passes all verifications.

[0065] This module transforms the regulatory requirements for archiving electronic invoice source files into a system-level technical constraint by deploying a mandatory technical verification gate at the data entry point. This ensures that every invoice entering the archiving system is accompanied by a legal and valid XML structured source file, achieving a 100% complete source file collection rate.

[0066] VI. Anti-tampering solidified packaging and account-to-physical verification module This module consists of two parts: an anti-tampering solidified packaging unit and an automatic account-to-actual verification unit.

[0067] 1. Tamper-proof solidified packaging unit For invoice data that has passed all verifications and confirmations in Module 5 and is now entering the archiving system, the system performs the following encapsulation process: The first step is data aggregation: The system aggregates the following three data items into a complete data set: The first item is the invoice source file, which is the raw binary data of XML and PDF or OFD files; the second item is the metadata set, including the business metadata collected in Module 4 and the structured data of the compliance audit report generated in Module 3; the third item is the associated voucher information, which is the accounting voucher number, posting date and accounting period corresponding to the invoice.

[0068] The second step is the integrity hash value calculation: The system calculates the integrity hash value of the aggregated complete data set using the national standard SM3 cryptographic hash algorithm. The calculation process of this algorithm is as follows: The data set is divided into 512-bit groups, with the last group padded to reach 512 bits. Then, a message expansion operation is performed on each message group (expanding 16 words to 132 words), followed by 64 rounds of iterative compression, ultimately outputting a 256-bit hash value. This hash value is collision-resistant; a change in any single bit in the data set will cause an unpredictable and complete change to the final 256-bit hash value, making it a valid digital fingerprint for the integrity of the data set.

[0069] The third step is trusted timestamp binding: The system encapsulates the 256-bit hash value calculated in the second step into a timestamp request message according to the RFC3161 Internet timestamp protocol standard or the corresponding national standard GB / T 20520-2006 "Information Security Technology Public Key Infrastructure Timestamp Specification", and sends it to a trusted timestamp service provider authorized by the National Time Service Center. After receiving the request, the timestamp service provider appends the current time accurate to the millisecond level to the request message, uses the institution's private key to digitally sign the combination of hash value and accurate time, and generates a timestamp token to return to the system.

[0070] The fourth step is encapsulation and output: The system combines the original data set, integrity hash value, and timestamp token into a complete archive data package according to the preset data block splicing format. The archive data package is divided into three functional areas: the content area stores the original data of the invoice source file and metadata, the proof area stores the integrity hash value and trusted timestamp token, and the encapsulation area stores the data package format version number and the length index of each data block.

[0071] The archived data packet formed after the above encapsulation has the following characteristics: At any subsequent point in time, the verifier only needs to perform the following operations on the archived data packet to independently complete the integrity verification: The original data is extracted from the content area of ​​the data packet, and its hash value is recalculated using the SM3 algorithm. The recalculated hash value is compared bit by bit with the original hash value stored in the proof area. At the same time, the digital signature of the timestamp token is verified using the public key provided by the timestamp service provider to confirm the credibility of the time.

[0072] The entire verification process relies solely on the information carried in the archived data packets and the publicly available cryptographic algorithms, without depending on the original system's database query interface or the online verification service provided by the original vendor.

[0073] 2. Automatic Reconciliation Unit for Accounts and Actual Goods This unit automatically starts the verification process according to a preset time cycle (the default configuration is to execute once every 24 hours, and the execution time is configured to be the early morning of each day during the off-peak business period).

[0074] The verification process is as follows: The system uses a robotic workflow to automate the process of logging into the VAT invoice integrated service platform of the e-Tax Bureau. After completing identity authentication using the enterprise taxpayer identification number and login credentials, the system enters the full query page for input invoices. The query conditions are set to the time range of the previous full calendar day. The system then obtains a structured list of all input invoices recorded in the enterprise's tax digital account within that time range. This list contains the unique identification code and internal number of each invoice.

[0075] The system uses the external invoice list obtained from the tax digital account as the benchmark reference set, and uses the combination of invoice code and invoice number as the unique matching key value. It performs a set-based difference operation with all invoice records that have been archived in the system database. That is, it finds all invoices that exist in the tax digital account list but do not exist in the archived records of the system. If the difference result is not empty, the system marks each invoice in the difference set as pending entry and sends a supplementary entry notification to the system administrator in the form of a summary report, which includes the code and number of the invoice to be supplemented, the invoice date, the seller's name, the amount excluding tax, and the tax amount.

[0076] This module, on the one hand, enables archived data packets to prove their integrity and formation time independently of the original system through the joint encapsulation of hash values ​​and trusted timestamps; on the other hand, through an automated account reconciliation mechanism, it upgrades the operation that originally relied on manual periodic login to the tax system for export and comparison into a scheduled task that is automatically executed by the system.

[0077] VII. Customizable Ledger Dynamic Generation Module This module consists of two parts: a visual template editor unit and a dynamic ledger generation engine unit.

[0078] 1. Visual Template Editor Unit This unit provides a graphical interface for designing ledger templates, allowing users to complete the following design tasks through drag-and-drop and selection: In the field selection area, the system reads a list of all available data fields from the archived database and organizes them by business theme, including but not limited to: Invoice Code, Invoice Number, Invoice Date, Amount Excluding Tax, Tax Amount, and Total Amount Including Tax under the Basic Invoice Information category; Supplier Name, Supplier Identification Number, Purchase Order Number, Cost Center Code, Expense Recipient Name, and Department under the Business Context category; and Compliance Inspection Result, Risk Level, Auditor, and Audit Date under the Audit Information category. Users select the fields they want to display in the ledger by checking boxes.

[0079] In the filter definition area, users can set data filtering conditions for the ledger. The logical structure of the filter conditions is a triple of field name - comparison operator - threshold. Multiple filter conditions support combinations of logical AND and logical OR.

[0080] In the table layout area, users can adjust the order of fields in the final ledger table by dragging and dropping field names, and set the basis field for grouping and summarizing, such as grouping by supplier name and summing the amount field within each group.

[0081] After the user completes the above design and saves it, the system will store the template configuration in the template library in the form of a structured description file.

[0082] 2. Dynamic Ledger Generation Engine Unit When a user selects a saved template and clicks the generate button, this unit initiates the ledger generation process: The first step is template parsing: The engine reads the user-selected template structured description file and parses out the defined field list, filter condition combination logic, sorting order and grouping summary rules; The second step is data extraction: Based on the parsed field list and filtering conditions, the engine extracts data records that meet the conditions from the metadata table in the archive database. During the extraction process, only the fields explicitly selected in the template are read. The third step is data rendering: The engine renders the extracted structured data into a tabular electronic ledger according to the field arrangement order, grouping method and summary rules defined in the template. During the rendering process, the following calculations are automatically performed: grouping and summing or calculating the average of numeric fields according to the grouping key defined in the template, and deduplicating and counting text fields according to the grouping key. The fourth step is output format: The engine will export the rendered ledger in the format specified by the user, supporting export to Excel spreadsheet format and PDF format.

[0083] This module, through the combination of a visual template designer and a dynamic generation engine, allows finance personnel to create new ledger templates and generate reports on demand at any time according to management needs without relying on developers, thereby enhancing the management decision support value of archived data.

[0084] Method Implementation Examples According to embodiments of the present invention, a knowledge graph-based intelligent invoice archiving method is provided. Figure 2 This is a flowchart of the knowledge graph-based intelligent invoice archiving method according to an embodiment of the present invention, such as... Figure 2 As shown, the knowledge graph-based intelligent invoice archiving method according to an embodiment of the present invention specifically includes: Step S201: Construct and maintain a financial and tax knowledge graph using the knowledge graph construction module; Step S202: Extract information from the electronic contract document through the contract parsing module, and perform tax classification coding reasoning on the extracted subject information based on the financial and tax knowledge graph, and output the reasoning result to the invoicing terminal; Step S203: Before the invoice is signed and stamped, the invoice application information is obtained through the invoice compliance assessment module. The compliance of the invoice application information is verified based on the financial and tax knowledge graph. The first verification result is used to control whether to allow the signing and stamping operation. Step S204: Perform multi-level compliance checks on the received input invoice documents through the input invoice inspection module and output the inspection results; Step S205: Obtain the input invoice files and their associated business metadata from the external business system through the collection module using a standardized interface, and receive the inspection results; Step S206: The input invoice file is subjected to mandatory technical verification by the mandatory verification module deployed at the system data entry point, and the opening or blocking of the data writing channel is controlled according to the obtained second verification result. Step S207: Extract the set of input invoices that have passed verification from the archive database through the encapsulation module, calculate the integrity verification value of the input invoice data set, bind the integrity verification value with the timestamp, generate an archive data package, and output it to the archive database; Step S208: The ledger generation module extracts data from the archived database according to the user-defined template and dynamically generates a ledger, and outputs the generated ledger to the user terminal. The collection module also includes a status write-back unit. When the inspection result meets the preset blocking conditions, the status write-back unit sends a status write-back message to the external business system, triggering the external business system to block the flow of the corresponding document.

[0085] The embodiments of the present invention are method embodiments corresponding to the system embodiments described above. The specific operations of each step can be understood by referring to the description of the system embodiments, and will not be repeated here.

[0086] In summary, compared with the prior art, the beneficial effects of the embodiments of the present invention include: 1. Invoice coding reasoning is upgraded from manual experience to automatic model reasoning: By constructing a policy knowledge graph and a coding reasoning model based on graph attention network, the selection of tax classification codes is transformed from a mode that relies on manual memory to an automatic reasoning mode based on structured policy knowledge and semantic matching model. 2. Compliance checks have been upgraded from passive error correction after invoicing to proactive prevention before invoicing: By setting up multi-dimensional compliance assessment steps before invoices are signed and issued, the control point of compliance risks is moved forward to the source of the transaction; 3. The receipt verification process has been upgraded from a single authenticity check to a three-dimensional full-scale inspection: In addition to authenticity verification, the compliance check of the receipt format and the consistency check of the business substance have been added, realizing the leap from formal compliance to substantive compliance; 4. Data collection has been upgraded from manual secondary entry to automatic structured collection by the system: Through standardized interfaces and event-driven mechanisms, invoice metadata and business context are automatically collected and entered into the archive database when the approval is completed; 5. Source file collection has been upgraded from institutional constraints to technical enforcement: By combining mandatory file type verification, XML Schema verification, digital signature verification, and process blocking, 100% complete collection of XML source files has been achieved; 6. Archive credibility is upgraded from relying on system declarations to independent self-verification: Through the joint encapsulation of SM3 hash algorithm and trusted timestamp, archived data packets gain the ability to independently verify the integrity of content and the time of formation, independent of the original system; 7. The reconciliation of accounts and physical assets has been upgraded from manual comparison to automated set difference calculation: By automatically acquiring the list of tax digital accounts on a regular schedule and performing set difference calculation with the internal archived records, the discovery cycle of discrepancies between accounts and physical assets has been significantly shortened; 8. Data utilization is upgraded from fixed reports to flexible custom ledgers: Through a visual template editor and dynamic generation engine, users can customize fields, filter conditions and table structures to dynamically generate management ledgers as needed.

[0087] Device Example 1 This invention provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it performs the steps described in the method embodiment.

[0088] Device Example 2 This invention provides a computer-readable storage medium storing an information transmission implementation program, which, when executed by a processor, performs the steps described in the method embodiment.

[0089] The computer-readable storage media described in this embodiment include, but are not limited to, ROM, RAM, disk, or optical disk.

[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A knowledge graph-based intelligent invoice archiving system, characterized in that, include: The knowledge graph construction module is used to build and maintain financial and tax knowledge graphs. The contract parsing module, connected to the knowledge graph construction module, is used to extract information from electronic contract documents, and to perform tax classification coding reasoning on the extracted subject information based on the financial and tax knowledge graph, and output the reasoning results to the invoicing terminal. The invoice compliance assessment module is connected to the knowledge graph construction module and the invoice issuing end. It is used to obtain invoice application information before the invoice is signed and stamped, perform compliance verification on the invoice application information based on the financial and tax knowledge graph, and control whether to allow the signing and stamping operation based on the first verification result. The input invoice inspection module is connected to the knowledge graph construction module and the internal business system. It is used to perform multi-level compliance checks on the received input invoice documents and output the inspection results. The collection module is connected to the input invoice inspection module and the external business system. It is used to obtain input invoice files and their associated business metadata from the external business system through a standardized interface, and to receive the inspection results. The mandatory verification module is deployed at the system data entry point and is connected to the collection module and the archive database. It is used to perform mandatory technical verification on the input invoice files and control the opening or blocking of the data writing channel based on the obtained second verification result. The encapsulation module is connected to the archive database and is used to extract the set of input invoices that have passed the verification from the archive database, calculate the integrity verification value of the set of input invoices, bind the integrity verification value with a timestamp, generate an archive data package, and output it to the archive database. The ledger generation module is connected to the archived database and is used to extract data from the archived database according to the user-defined template and dynamically generate ledgers, and output the generated ledgers to the user terminal. The collection module also includes a status write-back unit, which is used to send a status write-back message to the external business system when the inspection result meets the preset blocking conditions, thereby triggering the external business system to block the flow of the corresponding document.

2. The system according to claim 1, characterized in that, The knowledge graph construction module also includes an automatic update unit, used for: Regularly retrieve published tax rule change documents from designated data sources; Structural change information is extracted from the changed files using a named entity recognition model; Automatically generate and execute operation instructions for adding nodes, modifying node attributes, or changing edge relationships in the financial and tax knowledge graph based on the structural change information; The tax knowledge graph includes a concept layer, a rule layer, and an instance layer. The concept layer constructs coding nodes based on the tax classification coding standard. The rule layer stores tax processing rules in a condition-conclusion structure. The instance layer stores the mapping pairs between confirmed descriptions of goods or services and tax classification codes.

3. The system according to claim 2, characterized in that, The contract parsing module specifically includes: The text extraction unit is used to extract text content from electronic contract documents of different formats; A key information extraction unit, connected to the text extraction unit, is used to input the extracted text content into a pre-built semantic model to identify and extract structured fields that include at least the name of the subject matter of the contract. The encoding reasoning unit, connected to the key information extraction unit, is used to match the name of the target with the encoding nodes of the concept layer in the financial and tax knowledge graph, calculate the matching probability of each encoding node, and output the reasoning results to the invoicing terminal according to the matching probability.

4. The system according to claim 1, characterized in that, The invoicing compliance assessment module is specifically used for: Obtain invoice application information; wherein, the invoice application information includes the tax classification code filled in, the selected tax rate, and the text in the remarks column; The tax classification code is used as the key to query the financial and tax knowledge graph to obtain the statutory tax rate and remarks requirements corresponding to the tax classification code. The selected tax rate is compared with the statutory tax rate. If they are inconsistent, a first type of alarm message is generated. According to the above requirements, check whether the text in the remarks column contains the required remarks fields. If it does not contain them, generate a second type of prompt information. Obtain the taxpayer identity category of the invoice issuer, determine whether the selected tax rate is within the range of tax rates allowed for the taxpayer identity category, and generate a third type of alarm information if it is not within the range of tax rates allowed for the taxpayer identity category. The first type of alarm information, the second type of prompt information, and the third type of alarm information are summarized into a structured pre-inspection report and output to the invoicing terminal for display; If the structured pre-inspection report does not contain any of the first type of alarm information, the second type of prompt information, or the third type of alarm information, then the signature and issuance operation is allowed to be triggered.

5. The system according to claim 1, characterized in that, The input item inspection module is specifically used for: Multi-level compliance checks are performed sequentially on the received input invoice documents; The first level of inspection is used to verify the authenticity of the source of the input invoice document and the validity of the digital signature. The second level of inspection is used to perform a compliance check on the format of the input invoice document based on the financial and tax knowledge graph. The third level of inspection is used to compare the transaction data stated in the input invoice with the business data of the internal business system; wherein, the business data includes purchase contract data and supplier master data; The results of inspections at each level are summarized to generate a structured audit report, which is then output to the aggregation module.

6. The system according to claim 1, characterized in that, The mandatory verification module is specifically used for: Receive the input invoice file obtained by the collection module; Read the header feature byte sequence of the input invoice file to determine the actual format type of the file. When the actual format type does not match the format claimed by the file extension, generate a blocking instruction. The system detects whether the same set of input invoice files contains both an XML-formatted structured source file and a PDF or OFD-formatted visualization file. If the XML-formatted structured source file is missing, a blocking instruction is generated. The structured source file in XML format is subjected to structure compliance verification according to the preset structure definition file. The verification is made to check whether the structured source file contains all required fields and whether the data type and value of each field meet the preset requirements. If not, a blocking instruction is generated. If any of the aforementioned blocking instructions is generated, the data write channel from the aggregation module to the archive database is closed; If no blocking instruction is generated, the data writing channel is opened.

7. The system according to claim 1, characterized in that, The encapsulation module specifically includes: The data aggregation unit is used to extract a set of verified input invoice data from the archived database; wherein, the set of input invoice data includes the input invoice source file, the business metadata, the inspection results, and accounting voucher association information; A hash calculation unit, connected to the data aggregation unit, is used to calculate an integrity verification value for the input invoice data set using a cryptographic hash algorithm; The timestamp binding unit, connected to the hash calculation unit, is used to send the integrity verification value to a trusted timestamp service provider and receive the returned timestamp token. The encapsulation output unit, connected to the data aggregation unit, hash calculation unit, and timestamp binding unit, is used to combine the input invoice data set, the integrity verification value, and the timestamp token into an archive data package according to a preset format, and output the archive data package to the archive database.

8. A knowledge graph-based intelligent invoice archiving method, characterized in that, include: Build and maintain a financial and tax knowledge graph using the knowledge graph construction module; The electronic contract document is extracted through the contract parsing module, and the extracted subject matter information is classified and coded for tax purposes based on the tax knowledge graph. The reasoning results are then output to the invoicing terminal. The invoice compliance assessment module obtains invoice application information before invoice signature generation, performs compliance verification on the invoice application information based on the financial and tax knowledge graph, and controls whether to allow the signature and issuance operation based on the first verification result. The input invoice inspection module performs multi-level compliance checks on the received input invoice documents and outputs the inspection results. The collection module uses a standardized interface to obtain input invoice files and their associated business metadata from external business systems, and receives the inspection results. The mandatory verification module deployed at the system data entry point performs mandatory technical verification on the input invoice file, and controls the opening or blocking of the data writing channel based on the obtained second verification result. The encapsulation module extracts the verified input invoice data set from the archive database, calculates the integrity verification value of the input invoice data set, binds the integrity verification value with a timestamp, generates an archive data package, and outputs it to the archive database. The ledger generation module extracts data from the archived database based on the user-defined template and dynamically generates ledgers, which are then output to the user's end. The collection module also includes a status write-back unit. When the inspection result meets the preset blocking conditions, the status write-back unit sends a status write-back message to the external business system, triggering the external business system to block the flow of the corresponding document.

9. An electronic device, characterized in that, include: The memory, the processor, and the computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the knowledge graph-based intelligent invoice archiving method as described in claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an information transmission implementation program, which, when executed by a processor, implements the steps of the knowledge graph-based intelligent invoice archiving method as described in claim 8.

Images