An AI-based electronic invoice lifecycle management system and method

Abstract

This invention discloses an artificial intelligence-based electronic invoice lifecycle management system and method, relating to the field of electronic invoice management technology. The method acquires the characteristics of electronic invoices, preprocesses them into a unified JSON format, stores them in a database, and generates hash values ​​for storage on a blockchain to ensure data security. It establishes association keys based on the issuer and user, integrates invoices into a dataset, and extracts business characteristics, including invoicing frequency and device usage ratio. It constructs a link graph containing invoice nodes, main nodes, and device nodes, identifying abnormal links based on frequency and ratio thresholds. It extracts the corresponding hash values ​​and timestamps from the blockchain for verification: if the hash values ​​match and the timestamps are within the allowed range, it is determined to be an abnormal data link; otherwise, it is a data modification link, and a classification warning is implemented. This method utilizes blockchain technology to ensure the authenticity and integrity of invoice data, effectively improving the standardization and risk control capabilities of electronic invoice management.

Description

Technical Field

[0001] This invention relates to the field of electronic invoice management technology, specifically an artificial intelligence-based electronic invoice lifecycle management system and method. Background Technology

[0002] Current invoice analysis technology is gradually transforming from traditional manual verification to intelligent processing, and its applications are becoming increasingly diversified.

[0003] However, the existing data verification system for electronic invoice management technology is imperfect and has limited verification dimensions, making it difficult to fully resist risks such as information forgery and tampering, and failing to fully guarantee the authenticity and security of invoice information. At the same time, invoice data lacks effective integration with business scenarios, usage contexts, and other related information, resulting in fragmented management. This leads to insufficient sensitivity in identifying abnormal situations such as non-compliant use, making it easy to miss judgments and affecting the standardization and reliability of invoice management. Summary of the Invention

[0004] The purpose of this invention is to provide an artificial intelligence-based electronic invoice lifecycle management system and method to solve the problems raised in the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] An AI-based method for managing the lifecycle of electronic invoices, comprising the following steps:

[0007] Step S1: Obtain the bill features of the electronic bill. The bill features are structured data, including information data and scenario data. Preprocess the bill features to obtain standard bill features, store the standard bill features in the database, generate the hash value of the standard bill features, and store the hash value in the blockchain network.

[0008] Furthermore, step S1 includes:

[0009] The information data consists of structured fields carried by the electronic invoice, including invoice code, invoice number, invoice issuer name, invoice date, and invoice user name; the scenario data is the operating device number when the electronic invoice is submitted.

[0010] The preprocessing involves constructing a unified JSON format template, converting the invoice features according to the unified JSON format template to obtain standard invoice features; storing the standard invoice features in the database; if any one of the following is missing from the electronic invoice: invoice code, invoice number, invoice issuer name, invoice date, invoice user name, or operating device number, the corresponding electronic invoice is marked as invalid and a review request is issued.

[0011] The hash value includes an identity hash value and a feature hash value. The identity code is obtained by sequentially concatenating the bill code and bill number in the standard bill features. The identity code is then converted into an identity hash value using a hash algorithm such as SHA-256. Finally, the feature hash value of the standard bill features of the electronic bill is generated using a hash algorithm. The combination of the bill code and the bill number is the unique identifier of the electronic bill, ensuring the uniqueness of the identity hash value.

[0012] After the hash value is generated, a data upload request is sent to the blockchain network, where blocks are arranged in a chain structure.

[0013] After receiving the data upload request, the blockchain network generates a new block, stores the corresponding identity hash value and the corresponding feature hash value into the new block, and records the on-chain timestamp.

[0014] The new block contains the characteristic hash value of the electronic ticket, the on-chain timestamp, the identity hash value of the previous block, and the identity hash value of the new block.

[0015] Step S2: Obtain standard invoice features from the database, establish association keys based on the standard invoice features, and integrate standard invoice features with the same association key into a related dataset; obtain the business features of the related dataset;

[0016] Furthermore, step S2 includes:

[0017] The database is traversed for standard bill features, and a correlation key is established between the bill issuer's name and the bill user's name. This key is used to integrate standard bill features with the same correlation key into a single associated dataset. The correlation key is a fixed-order concatenation string of "bill issuer's name - bill user's name" to ensure that bills from the same two parties in the same transaction can be accurately integrated.

[0018] The average frequency of occurrence of standard invoice features within a preset unit time period for the invoice date in the statistically linked dataset is used as the frequency feature of the linked dataset; the unit time can be adjusted to daily, weekly, monthly, or quarterly according to business needs;

[0019] It also obtains all the operating device numbers in the associated dataset, calculates the proportion of the number of times the same operating device number appears to the total number of times all operating device numbers appear, and uses this as the device association feature of the associated dataset; an associated dataset contains one frequency feature and several device association features;

[0020] The frequency feature and the device association feature are used as the business features of the corresponding associated dataset.

[0021] Step S3: Construct a link diagram based on the business characteristics, and obtain the normal links and abnormal links in the link diagram;

[0022] Furthermore, step S3 includes:

[0023] Step S3-1: Use the bill code, bill number, and billing date from the standard bill features as bill nodes, the associated dataset as main nodes, and the operating device number as device nodes; construct a link graph using a graph model based on the bill nodes, main nodes, and device nodes.

[0024] In the link diagram, the main node, the ticket node, and the device node are interconnected through links;

[0025] The link attribute between the main node and the ticket node is the frequency feature of the corresponding associated dataset;

[0026] The link attributes between the master node and the device node are the device association features of the corresponding associated dataset;

[0027] For ticket nodes and device nodes linked to the same principal node, obtain the operation device number that corresponds to both the ticket code and ticket number of the ticket node. If the operation device number is the same as the corresponding device node, then link the ticket node to the device node.

[0028] Step S3-2: Obtain a frequency threshold based on a preset percentage of the frequency characteristics of the main node; retrieve the invoice nodes that are connected to the main node within the latest preset unit time period and use them as verification nodes; when the number of verification nodes exceeds the frequency threshold, mark the link between the verification node and the corresponding main node as an abnormal link; and mark the device nodes connected to the verification node as abnormal nodes.

[0029] Step S3-3: Preset a ratio threshold. When the device association characteristic between a device node and a main node is less than the ratio threshold, mark the link corresponding to the device node as an abnormal link; and mark the ticket node connected to the device node as an abnormal node.

[0030] Links other than abnormal links are treated as normal links.

[0031] Step S4: Extract on-chain information from the blockchain network, verify the abnormal links based on the on-chain information, and obtain the verification results; classify the abnormal links into data abnormal links and data change links based on the verification results, and mark the abnormal links and their corresponding types in the link diagram.

[0032] Furthermore, step S4 includes:

[0033] Traverse the abnormal links in the link graph and retrieve the standard ticket features corresponding to all abnormal nodes as abnormal features.

[0034] An identity hash value for anomaly features is generated using a hash algorithm and used as a retrieval hash value. Then, a feature hash value for anomaly features is generated using a hash algorithm and used as a comparison hash value.

[0035] Locate the block corresponding to the identity hash value that is the same as the search hash value, and extract the feature hash value and the on-chain timestamp of the block as on-chain information;

[0036] The verification process includes:

[0037] If the feature hash value of the on-chain information is the same as the comparison hash value, and the time interval between the on-chain timestamp of the on-chain information and the invoice date of the abnormal feature is less than the preset time difference range, then the corresponding abnormal link will be regarded as a data abnormal link.

[0038] Otherwise, the corresponding abnormal link will be treated as a data change link; an alert will be issued according to the type of abnormal link.

[0039] If the feature hash value is the same as the comparison hash value and the time interval is within the preset range, it means that the data has not been tampered with from the time it is uploaded to the chain until the anomaly is detected. This indicates that the data itself is abnormal and is judged as an abnormal data link. Otherwise, it means that there is a possibility of data tampering after it is uploaded to the chain, i.e., the hash values ​​are not equal, or the chain upload process is abnormal, i.e. the time interval exceeds the preset time difference range. This means that the data is highly likely to be tampered with and is judged as a data change link.

[0040] An AI-based electronic invoice lifecycle management system, comprising an invoice feature processing module, a related data integration module, a link diagram construction module, and an abnormal link verification module;

[0041] The bill feature processing module is used to acquire the bill features of electronic bills and preprocess them to obtain standard bill features, store the standard bill features in the database, and generate the hash value of the standard bill features and store it in the blockchain network.

[0042] The associated data integration module is used to establish association keys based on standard invoice characteristics, integrate associated datasets, and obtain the business characteristics of the datasets.

[0043] The link graph construction module is used to construct a link graph based on the ticket node, the main node, and the device node, and to obtain the normal links and abnormal links in the link graph.

[0044] The abnormal link verification module is used to extract on-chain information from the blockchain network, verify abnormal links, classify the types of abnormal links, and mark them in the link diagram;

[0045] The output of the invoice feature processing module is connected to the input of the associated data integration module; the output of the associated data integration module is connected to the input of the link graph construction module; and the output of the link graph construction module is connected to the input of the abnormal link verification module.

[0046] The invoice feature processing module also includes a feature preprocessing unit and a hash chaining unit;

[0047] The feature preprocessing unit is used to acquire information data and scenario data of electronic invoices, convert them into standard invoice features according to a unified JSON format template, store them in the database, and mark invalid invoices.

[0048] The hash-on-chain unit is used to convert the identity code of the standard ticket feature into an identity hash value, generate a feature hash value, upload it to the blockchain network and store it in a new block.

[0049] The associated data integration module also includes an association key establishment unit and a business feature extraction unit;

[0050] The association key establishment unit is used to traverse the standard bill features in the database, establish an association key between the bill issuer name and the bill user name, and integrate the standard bill features with the same association key into an association dataset.

[0051] The business feature extraction unit is used to statistically analyze the frequency features of the associated dataset, calculate the device association features, and use the frequency features and device association features as the business features of the associated dataset.

[0052] The link graph construction module also includes a link graph generation unit and an abnormal link identification unit;

[0053] The link graph generation unit is used to construct a link graph and establish connections between nodes by using the invoice code, invoice number, and invoice date as invoice nodes, the associated dataset as main nodes, and the operating device number as device nodes.

[0054] The abnormal link identification unit is used to mark abnormal links between verification nodes and main nodes and corresponding device nodes according to frequency thresholds and proportion thresholds, while the rest are normal links.

[0055] The abnormal link verification module also includes an on-chain information extraction unit and a link type determination unit;

[0056] The on-chain information extraction unit is used to retrieve the standard ticket features corresponding to the abnormal node to generate retrieval hash value and comparison hash value, locate the corresponding block and extract the corresponding feature hash value and the corresponding on-chain timestamp;

[0057] The link type determination unit is used to classify abnormal links into data abnormal links and data change links and issue warnings based on whether the feature hash value and the comparison hash value are the same and whether the time interval is within a preset range.

[0058] Compared with the prior art, the beneficial effects of the present invention are:

[0059] 1. This invention stores the characteristic hash value of electronic invoices on a blockchain network. Leveraging the distributed ledger and immutability of blockchain, it ensures the authenticity and integrity of invoice data from the moment it is uploaded to the chain, effectively preventing the risk of information forgery or tampering. Simultaneously, the system automatically marks missing data as invalid invoices and issues a review request, improving data quality reliability and thus fundamentally ensuring the secure management of electronic invoices.

[0060] 2. This invention establishes a connection key based on the invoice issuer and the invoice user, integrates invoice data into a related dataset, and extracts business features such as frequency features and device association features to construct a link graph model for intelligent analysis of node relationships throughout the invoice lifecycle. This method can dynamically identify abnormal links, such as frequent invoicing or abnormal device usage, improve the sensitivity of detecting non-compliant usage behaviors, reduce missed detections, and enhance the intelligence level of invoice management.

[0061] 3. This invention verifies abnormal links by extracting on-chain information from the blockchain. Based on feature hash value comparison and timestamp verification, it accurately classifies abnormal links into data anomaly links and data change links, and implements classified early warning. This verification mechanism not only improves the accuracy of anomaly handling but also helps managers quickly locate the root cause of problems, optimizing the efficiency and standardization of invoice lifecycle management. Attached Figure Description

[0062] Figure 1 This is a flowchart illustrating an artificial intelligence-based electronic invoice lifecycle management method according to the present invention.

[0063] Figure 2 This is a schematic diagram of the structure of an AI-based electronic invoice lifecycle management system according to the present invention. Detailed Implementation

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

[0065] Example 1: As Figure 1As shown, this invention provides a technical solution: an artificial intelligence-based electronic invoice lifecycle management method, which includes the following steps:

[0066] Step S1: Obtain the bill features of the electronic bill. The bill features are structured data, including information data and scenario data. Preprocess the bill features to obtain standard bill features, store the standard bill features in the database, generate the hash value of the standard bill features, and store the hash value in the blockchain network.

[0067] Step S1 includes:

[0068] The information data consists of structured fields carried by the electronic invoice, including invoice code, invoice number, invoice issuer name, invoice date, and invoice user name; the scenario data is the operating device number when the electronic invoice is submitted.

[0069] The preprocessing involves constructing a unified JSON format template, converting the invoice features according to the unified JSON format template to obtain standard invoice features; storing the standard invoice features in the database; if any one of the following is missing from the electronic invoice: invoice code, invoice number, invoice issuer name, invoice date, invoice user name, or operating device number, the corresponding electronic invoice is marked as invalid and a review request is issued.

[0070] The hash value includes an identity hash value and a feature hash value. The identity code is obtained by sequentially concatenating the bill code and bill number in the standard bill features. The identity code is then converted into an identity hash value using a hash algorithm such as SHA-256. Finally, the feature hash value of the standard bill features of the electronic bill is generated using a hash algorithm. The combination of the bill code and the bill number is the unique identifier of the electronic bill, ensuring the uniqueness of the identity hash value.

[0071] After the hash value is generated, a data upload request is sent to the blockchain network, where blocks are arranged in a chain structure.

[0072] After receiving the data upload request, the blockchain network generates a new block, stores the corresponding identity hash value and the corresponding feature hash value into the new block, and records the on-chain timestamp.

[0073] The new block contains the characteristic hash value of the electronic ticket, the on-chain timestamp, the identity hash value of the previous block, and the identity hash value of the new block.

[0074] Step S2: Obtain standard invoice features from the database, establish association keys based on the standard invoice features, and integrate standard invoice features with the same association key into a related dataset; obtain the business features of the related dataset;

[0075] Step S2 includes:

[0076] The database is traversed for standard bill features, and a correlation key is established between the bill issuer's name and the bill user's name. This key is used to integrate standard bill features with the same correlation key into a single associated dataset. The correlation key is a fixed-order concatenation string of "bill issuer's name - bill user's name" to ensure that bills from the same two parties in the same transaction can be accurately integrated.

[0077] The average frequency of occurrence of standard invoice features within a preset unit time period for the invoice date in the statistically linked dataset is used as the frequency feature of the linked dataset; the unit time can be adjusted to daily, weekly, monthly, or quarterly according to business needs;

[0078] It also obtains all the operating device numbers in the associated dataset, calculates the proportion of the number of times the same operating device number appears to the total number of times all operating device numbers appear, and uses this as the device association feature of the associated dataset; an associated dataset contains one frequency feature and several device association features;

[0079] The frequency feature and the device association feature are used as the business features of the corresponding associated dataset.

[0080] Step S3: Construct a link diagram based on the business characteristics, and obtain the normal links and abnormal links in the link diagram;

[0081] Step S3 includes:

[0082] Step S3-1: Use the bill code, bill number, and billing date from the standard bill features as bill nodes, the associated dataset as main nodes, and the operating device number as device nodes; construct a link graph using a graph model based on the bill nodes, main nodes, and device nodes.

[0083] In the link diagram, the main node, the ticket node, and the device node are interconnected through links;

[0084] The link attribute between the main node and the ticket node is the frequency feature of the corresponding associated dataset;

[0085] The link attributes between the master node and the device node are the device association features of the corresponding associated dataset;

[0086] For ticket nodes and device nodes linked to the same principal node, obtain the operation device number that corresponds to both the ticket code and ticket number of the ticket node. If the operation device number is the same as the corresponding device node, then link the ticket node to the device node.

[0087] Step S3-2: Obtain a frequency threshold based on a preset percentage of the frequency characteristics of the main node; retrieve the invoice nodes that are connected to the main node within the latest preset unit time period and use them as verification nodes; when the number of verification nodes exceeds the frequency threshold, mark the link between the verification node and the corresponding main node as an abnormal link; and mark the device nodes connected to the verification node as abnormal nodes.

[0088] Step S3-3: Preset a ratio threshold. When the device association characteristic between a device node and a main node is less than the ratio threshold, mark the link corresponding to the device node as an abnormal link; and mark the ticket node connected to the device node as an abnormal node.

[0089] Links other than abnormal links are treated as normal links.

[0090] Step S4: Extract on-chain information from the blockchain network, verify the abnormal links based on the on-chain information, and obtain the verification results; classify the abnormal links into data abnormal links and data change links based on the verification results, and mark the abnormal links and their corresponding types in the link diagram.

[0091] Step S4 includes:

[0092] Traverse the abnormal links in the link graph and retrieve the standard ticket features corresponding to all abnormal nodes as abnormal features.

[0093] An identity hash value for anomaly features is generated using a hash algorithm and used as a retrieval hash value. Then, a feature hash value for anomaly features is generated using a hash algorithm and used as a comparison hash value.

[0094] Locate the block corresponding to the identity hash value that is the same as the search hash value, and extract the feature hash value and the on-chain timestamp of the block as on-chain information;

[0095] The verification process includes:

[0096] If the feature hash value of the on-chain information is the same as the comparison hash value, and the time interval between the on-chain timestamp of the on-chain information and the invoice date of the abnormal feature is less than the preset time difference range, then the corresponding abnormal link will be regarded as a data abnormal link.

[0097] Otherwise, the corresponding abnormal link will be treated as a data change link; an alert will be issued according to the type of abnormal link.

[0098] If the feature hash value is the same as the comparison hash value and the time interval is within the preset range, it means that the data has not been tampered with from the time it is uploaded to the chain until the anomaly is detected. This indicates that the data itself is abnormal and is judged as an abnormal data link. Otherwise, it means that there is a possibility of data tampering after it is uploaded to the chain, i.e., the hash values ​​are not equal, or the chain upload process is abnormal, i.e. the time interval exceeds the preset time difference range. This means that the data is highly likely to be tampered with and is judged as a data change link.

[0099] For example:

[0100] Bill 1: Information data includes bill code 1100XX123456, bill number 00XX5678, issuer name A Co., Ltd., issue date 2024-XX-XX, and user name B Trading Company; Scenario data includes operating device number 001.

[0101] Bill 2: Information data includes bill code 1100XX123456, bill number 00XX5679, issuer name A Co., Ltd., issue date 2024-XX-XX, and user name B Trading Company; Scenario data includes operating device number 001.

[0102] Bill 3: Information data includes bill code 1100XX123456, bill number 00XX5680, issuer name A Co., Ltd., issue date 2024-XX-XX, and user name C Technology Co., Ltd.; Scenario data includes operating device number 002.

[0103] Bill 4: Information data includes bill code 1100XX123456, bill number 00XX5681, issuer name: Company A, issue date: 2024-XX-XX, user name: Trading Company B; scenario data is missing.

[0104] Bill 5: Information data includes bill code 1100XX123456, bill number 00XX5682, issuer name: Company A, issue date: 2024-XX-XX, user name: Ding Building Materials Company; Scenario data includes operating equipment number 003.

[0105] Bill 6: Information data includes bill code 1100XX123456, bill number 00XX5683, issuer name: Company A, issue date: 2024-XX-XX, user name: Trading Company B; Scenario data includes operating device number 001.

[0106] Preprocessing: Construct a unified JSON format template and convert the features of tickets 1, 2, 3, 5, and 6 into standard ticket features according to the template; Ticket 4 is marked as invalid due to missing scenario data, and the system issues a review request;

[0107] Generate hash values: Concatenate the ticket code and ticket number of each standard ticket in sequence to form an identity code, and generate an identity hash value using the SHA-256 algorithm; then generate a feature hash value for each standard ticket characteristic using the SHA-256 algorithm (the feature hash value of ticket 6 was tampered with in subsequent storage).

[0108] On-chain storage: Upload the identity hash value and feature hash value to the blockchain network. The blockchain generates a new block, stores the above hash values, and records the on-chain timestamp (on-chain timestamp for Ticket 1: 2024-XX-XX, 14:XX:XX; for Ticket 2: 2024-XX-XX, 10:XX:XX; for Ticket 3: 2024-XX-XX, 09:XX:XX; for Ticket 5: 2024-XX-XX, 16:XX:XX; for Ticket 6: 2024-XX-XX, 11:XX:XX). The new block contains the feature hash value, the on-chain timestamp, the identity hash value of the previous block, and the identity hash value of this block.

[0109] Establish association keys: Traverse the characteristics of 5 standard invoices in the database. The association key is a string concatenated in a fixed order of "invoice issuer name - invoice user name". The association keys for invoices 1, 2, and 6 are "Company A - Trading Company B", the association key for invoice 3 is "Company A - Technology Company C", and the association key for invoice 5 is "Company A - Building Materials Company D".

[0110] Integrate the associated datasets: form three associated datasets: dataset A (association key "Company A - Company B", containing standard features of invoices 1, 2, and 6), dataset B (association key "Company A - Company C", containing standard features of invoice 3), and dataset C (association key "Company A - Company D", containing standard features of invoice 5).

[0111] Extracting business characteristics:

[0112] Dataset A: The preset unit time is 1 month (Month X of 2024). The number of invoices issued within this period is 3, and the frequency feature = 3 ÷ 1 = 3 times / month; there is a total of 1 operating device number (001), and the frequency of occurrence is 100%, with the device association feature being 100%.

[0113] Dataset B: The preset unit time is 1 month (Month X of 2024). The number of invoices issued within this period is 1, and the frequency feature = 1 ÷ 1 = 1 time / month; there is a total of 1 operating device number (002), the occurrence rate is 100%, and the device association feature is 100%.

[0114] Dataset C: The preset unit time is 1 month (Month X of 2024), the number of invoices issued within this period is 1, the frequency feature = 1 ÷ 1 = 1 time / month; there is a total of 1 operating device number (003), the occurrence rate is 100%, and the device association feature is 100%.

[0115] Constructing a link graph:

[0116] Bill Nodes: Bill 1 Node (1100XX123456, 00XX5678, 2024-XX-XX), Bill 2 Node (1100XX123456, 00XX5679, 2024-XX-XX), Bill 3 Node (1100XX123456, 00XX5680, 2024-XX-XX), Bill 5 Node (1100XX123456, 00XX5682, 2024-XX-XX), Bill 6 Node (1100XX123456, 00XX5683, 2024-XX-XX);

[0117] Main nodes: Dataset A node, Dataset B node, Dataset C node;

[0118] Device nodes: 001, 002, 003;

[0119] Link connections: The link attribute between node A and nodes 1, 2, and 6 of the dataset is a frequency feature of 3 times / month, and the link attribute with node 001 is a device association feature of 100%; the link attribute between node B and node 3 of the dataset is a frequency feature of 1 time / month, and the link attribute with node 002 is a device association feature of 100%; the link attribute between node C and node 5 of the dataset is a frequency feature of 1 time / month, and the link attribute with node 003 is a device association feature of 100%; the operating device number corresponding to nodes 1, 2, and 6 of the dataset is 001, and a link is established with each of these nodes; the operating device number corresponding to node 3 of the dataset is 002, and a link is established with this node; the operating device number corresponding to node 5 of the dataset is 003, and a link is established with this node.

[0120] Identify abnormal links:

[0121] Frequency threshold: The preset percentage is 90%. The frequency threshold for dataset A is 3 × 90% = 2.7, the frequency threshold for dataset B is 1 × 90% = 0.9, and the frequency threshold for dataset C is 1 × 90% = 0.9. The most recent month's connected bill nodes are retrieved as verification nodes. Dataset A has 3 verification nodes, exceeding the threshold of 2.7. Therefore, the links between bills 1, 2, and 6 and dataset A are marked as abnormal links, and the nodes of bills 1, 2, and 6, as well as their associated node 001, are marked as abnormal nodes. The number of verification nodes in dataset B is... 1. If the threshold of 0.9 is exceeded, the link between bill 3 and dataset B is marked as an abnormal link, and the node of bill 3 and its associated node 002 are marked as abnormal nodes; The number of verification nodes in dataset C is 1, which exceeds the threshold of 0.9. Therefore, the link between bill 5 and dataset C is marked as an abnormal link, and the node of bill 5 and its associated node 003 are marked as abnormal nodes; The preset percentage of the frequency threshold is determined based on the statistics of historical transaction data. The normal transaction frequency of most entities will be concentrated in the range corresponding to this percentage. The threshold can filter out a very small number of high-frequency transactions that exceed the reasonable range.

[0122] Proportion Threshold: The preset proportion threshold is 30%. The device association characteristics of datasets A, B, and C are all 100%, which is not less than the threshold, and there are no additional abnormal links. Based on the device usage logic of normal business: Most enterprises or trading entities will submit electronic invoices through 1-2 fixed devices. The usage ratio of commonly used devices is usually high (e.g., more than 30%). Setting the threshold below this proportion can accurately mark the abnormal scenario of "multiple low-percentage devices submitting invoices for the same entity". Existing technology lacks verification of the relationship between invoices and devices. The proportion threshold supplements the verification dimension from the perspective of device usage concentration, complementing the frequency threshold and comprehensively covering different types of abnormal risks.

[0123] Ultimately, the abnormal links were: Ticket 1 - Dataset A, Ticket 2 - Dataset A, Ticket 3 - Dataset B, Ticket 5 - Dataset C, and Ticket 6 - Dataset A; the remaining links were normal.

[0124] The following analysis will be conducted on the abnormal links related to dataset A:

[0125] Extracting abnormal features: Traverse the abnormal link and extract only the standard ticket features corresponding to the abnormal ticket nodes (tickets 1, 2, and 6) as abnormal features;

[0126] Generate retrieval and comparison hash values: Generate identity hash values ​​(retrieval hash values) and feature hash values ​​(comparison hash values) for the abnormal features of tickets 1, 2, and 6 respectively using the SHA-256 algorithm;

[0127] Extracting on-chain information: Locate the corresponding block in the blockchain by retrieving the hash value, and extract the on-chain feature hash value and the on-chain timestamp (ticket 1: on-chain feature hash value, 2024-XX-XX, 14:XX:XX; ticket 2: on-chain feature hash value, 2024-XX-XX, 10:XX:XX; ticket 6: on-chain feature hash value, 2024-XX-XX, 11:XX:XX).

[0128] Verification and Judgment:

[0129] The preset time difference range is 72 hours;

[0130] Ticket 1: The on-chain feature hash value is the same as the comparison hash value. The time interval between the on-chain timestamp and the ticket issuance date (2024-XX-XX) is 0.625 hours, which is less than 72 hours. It is determined to be an abnormal data link.

[0131] Ticket 2: The on-chain feature hash value is the same as the comparison hash value. The time interval between the on-chain timestamp and the ticket issuance date (2024-XX-XX) is 0.4375 hours, which is less than 72 hours. It is determined to be an abnormal data link.

[0132] Note 5: Subsequent testing revealed that Note 5 experienced a delay in being uploaded to the blockchain due to an operational error. The time interval between the blockchain timestamp and the invoice issuance date was 80 hours, exceeding 72 hours. Furthermore, the on-chain feature hash value was identical to the comparison hash value, indicating a data change link.

[0133] Ticket 6: The on-chain feature hash value is different from the comparison hash value, and the time interval between the on-chain timestamp and the ticket issuance date is 0.5 hours, which is less than 72 hours, indicating a data change link;

[0134] Warning: The system marks two data anomaly links and two data change links in the link diagram and issues classified warnings to financial auditors and risk control specialists.

[0135] Example 2: Figure 2 As shown, the present invention provides an electronic invoice lifecycle management system based on artificial intelligence. The system includes an invoice feature processing module, a related data integration module, a link diagram construction module, and an abnormal link verification module.

[0136] The bill feature processing module is used to acquire the bill features of electronic bills and preprocess them to obtain standard bill features, store the standard bill features in the database, and generate the hash value of the standard bill features and store it in the blockchain network.

[0137] The associated data integration module is used to establish association keys based on standard invoice characteristics, integrate associated datasets, and obtain the business characteristics of the datasets.

[0138] The link graph construction module is used to construct a link graph based on the ticket node, the main node, and the device node, and to obtain the normal links and abnormal links in the link graph.

[0139] The abnormal link verification module is used to extract on-chain information from the blockchain network, verify abnormal links, classify the types of abnormal links, and mark them in the link diagram;

[0140] The output of the invoice feature processing module is connected to the input of the associated data integration module; the output of the associated data integration module is connected to the input of the link graph construction module; and the output of the link graph construction module is connected to the input of the abnormal link verification module.

[0141] The invoice feature processing module also includes a feature preprocessing unit and a hash chaining unit;

[0142] The feature preprocessing unit is used to acquire information data and scenario data of electronic invoices, convert them into standard invoice features according to a unified JSON format template, store them in the database, and mark invalid invoices.

[0143] The hash-on-chain unit is used to convert the identity code of the standard ticket feature into an identity hash value, generate a feature hash value, upload it to the blockchain network and store it in a new block.

[0144] The associated data integration module also includes an association key establishment unit and a business feature extraction unit;

[0145] The association key establishment unit is used to traverse the standard bill features in the database, establish an association key between the bill issuer name and the bill user name, and integrate the standard bill features with the same association key into an association dataset.

[0146] The business feature extraction unit is used to statistically analyze the frequency features of the associated dataset, calculate the device association features, and use the frequency features and device association features as the business features of the associated dataset.

[0147] The link graph construction module also includes a link graph generation unit and an abnormal link identification unit;

[0148] The link graph generation unit is used to construct a link graph and establish connections between nodes by using the invoice code, invoice number, and invoice date as invoice nodes, the associated dataset as main nodes, and the operating device number as device nodes.

[0149] The abnormal link identification unit is used to mark abnormal links between verification nodes and main nodes and corresponding device nodes according to frequency thresholds and proportion thresholds, while the rest are normal links.

[0150] The abnormal link verification module also includes an on-chain information extraction unit and a link type determination unit;

[0151] The on-chain information extraction unit is used to retrieve the standard ticket features corresponding to the abnormal node to generate retrieval hash value and comparison hash value, locate the corresponding block and extract the corresponding feature hash value and the corresponding on-chain timestamp;

[0152] The link type determination unit is used to classify abnormal links into data abnormal links and data change links and issue warnings based on whether the feature hash value and the comparison hash value are the same and whether the time interval is within a preset range.

[0153] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. An artificial intelligence based electronic bill life cycle management method characterized by: The method comprises the following steps: Step S1, obtaining the ticket characteristics of the electronic ticket, the ticket characteristics being structured data, the ticket characteristics comprising information data and scene data; preprocessing the ticket characteristics to obtain standard ticket characteristics, storing the standard ticket characteristics in a database, and generating a hash value of the standard ticket characteristics and storing the hash value in a blockchain network; The information data is a structured field carried by the electronic ticket, including a ticket code, a ticket number, an invoicer name, an invoicing date, and a ticket user name; and the scene data is an operation device number at the time of submission of the electronic ticket; Step S2, obtaining the standard ticket characteristics in the database, establishing an association key according to the standard ticket characteristics, integrating the standard ticket characteristics with the same association key into an association data set, and obtaining the business characteristics of the association data set; Step S3, constructing a link graph according to the business characteristics, and obtaining normal links and abnormal links in the link graph; The step S3 comprises: Step S3-1, taking the ticket code, the ticket number, and the invoicing date in the standard ticket characteristics as ticket nodes, taking the association data set as a principal node, and taking the operation device number as a device node; constructing a link graph according to the ticket nodes, the principal node, and the device node through a graph model; In the link graph, the principal node, the ticket node, and the device node are connected to each other through links; The link attribute between the principal node and the ticket node is the frequency feature of the corresponding association data set; The link attribute between the principal node and the device node is the device association feature of the corresponding association data set; For the ticket node and the device node linked to the same principal node, the operation device number corresponding to the ticket code and the ticket number of the ticket node is obtained, and if the operation device number is the same as the corresponding device node, the ticket node and the device node are linked; Step S3-2, obtaining a frequency threshold value according to a preset percentage of the frequency feature of the principal node, calling the ticket nodes connected to the principal node through links within a latest preset unit time as verification nodes; when the number of verification nodes exceeds the frequency threshold value, marking the link between the verification node and the corresponding principal node as an abnormal link; and marking the device node connected to the verification node as an abnormal node; Step S3-3, presetting a proportion threshold value, when the device association feature between the device node and the principal node is less than the proportion threshold value, marking the link corresponding to the device node as an abnormal link; and marking the ticket node connected to the device node as an abnormal node; Links other than abnormal links are regarded as normal links; Step S4, extracting on-chain information in the blockchain network, verifying the abnormal links according to the on-chain information to obtain a verification result, classifying the types of the abnormal links into data abnormal links and data change links according to the verification result, and marking the abnormal links and the corresponding types in the link graph; The step S4 comprises: Traversing the abnormal links in the link graph, calling the standard ticket characteristics corresponding to all abnormal nodes as abnormal characteristics; An identity hash value of the abnormal feature is generated by a hash algorithm as a search hash value, and a feature hash value of the abnormal feature is generated by a hash algorithm as a comparison hash value; A block corresponding to the same identity hash value as the search hash value is located, and a feature hash value and a chain-up timestamp of the block are extracted as on-chain information; The verification process includes: If the feature hash value of the on-chain information is the same as the comparison hash value, and the time interval between the chain-up timestamp of the on-chain information and the billing date of the abnormal feature is less than a preset time difference range, the corresponding abnormal link is regarded as a data abnormal link; Otherwise, the corresponding abnormal link is regarded as a data change link; and a warning is given according to the type of the abnormal link.

2. The electronic bill lifecycle management method based on artificial intelligence according to claim 1, characterized in that: The step S1 includes: The preprocessing includes constructing a unified JSON format template, converting the bill features into the unified JSON format template to obtain standard bill features, and storing the standard bill features into a database; if the bill features of the electronic bill are missing, the corresponding electronic bill is marked as an invalid bill, and a review request is sent out; The hash value includes an identity hash value and a feature hash value; the bill code and the bill number in the standard bill features are sequentially spliced to obtain an identity code, the identity code is converted into the identity hash value by a hash algorithm, and the feature hash value of the standard bill features of the electronic bill is generated by a hash algorithm; After the hash value is generated, a data upload request is sent to a blockchain network, and the blockchain network includes blocks arranged in a chain structure; After the blockchain network receives the data upload request, a new block is generated, the corresponding identity hash value and the corresponding feature hash value are stored in the new block, and a chain-up timestamp is recorded; The new block includes the feature hash value of the electronic bill, the chain-up timestamp, the identity hash value of the previous block, and the identity hash value of the new block.

3. The electronic bill lifecycle management method based on artificial intelligence according to claim 2, characterized in that: The step S2 includes: The standard bill features in the database are traversed, and an association key is established between the billing party name and the bill user name, which is used to integrate the standard bill features with the same association key into an association data set; The average frequency of the standard bill features in the association data set within a preset unit time is calculated as the frequency feature of the association data set; all operation equipment numbers in the association data set are obtained, and the proportion of the number of the same operation equipment number to the number of all operation equipment numbers is calculated as the equipment association feature of the association data set; one association data set includes one frequency feature and a plurality of equipment association features; The frequency feature and the equipment association feature are used as the business feature of the corresponding association data set.

4. An electronic bill life cycle management system based on artificial intelligence, applied to the electronic bill life cycle management method based on artificial intelligence in any one of claims 1-3, characterized in that: The system includes a bill feature processing module, an association data integration module, a link graph construction module, and an abnormal link verification module; The bill feature processing module is used to obtain the bill features of the electronic bill, preprocess the bill features to obtain standard bill features, store the standard bill features in a database, and generate hash values of the standard bill features and store the hash values in a blockchain network; The association data integration module is used to establish an association key according to the standard bill features, integrate an association data set, and obtain the business feature of the data set; The link graph construction module is configured to take the invoice code, the invoice number, and the invoice date in the standard invoice feature as the invoice node, take the association data set as the principal node, and take the operation device number as the device node; construct a link graph according to the invoice node, the principal node, and the device node, and obtain normal links and abnormal links in the link graph; The link attribute between the principal node and the invoice node is the frequency feature of the corresponding association data set; The link attribute between the principal node and the device node is the device association feature of the corresponding association data set; A frequency threshold is obtained according to a preset percentage of the frequency feature of the principal node, and the invoice nodes connected to the principal node within the latest preset unit time are taken as verification nodes; When the number of verification nodes exceeds the frequency threshold, the link between the verification node and the corresponding principal node is marked as an abnormal link, and the device node connected to the verification node is marked as an abnormal node; A preset proportion threshold, when the device association feature between the device node and the principal node is less than the proportion threshold, the link corresponding to the device node is marked as an abnormal link, and the invoice node connected to the device node is marked as an abnormal node; The abnormal link verification module is configured to extract on-chain information in the blockchain network, verify the abnormal link, divide the type of the abnormal link, and mark in the link graph; The output end of the invoice feature processing module is connected to the input end of the association data integration module; the output end of the association data integration module is connected to the input end of the link graph construction module; and the output end of the link graph construction module is connected to the input end of the abnormal link verification module.

5. The electronic bill lifecycle management system based on artificial intelligence according to claim 4, characterized in that: The invoice feature processing module further includes a feature preprocessing unit and a hash on-chain unit; The feature preprocessing unit is configured to obtain information data and scene data of the electronic invoice, convert the information data and the scene data into standard invoice features according to a unified JSON format template, store the standard invoice features in a database, and mark invalid invoices; the information data is structured fields carried by the electronic invoice, including the invoice code, the invoice number, the invoicer name, the invoice date, and the ticket user name; and the scene data is the operation device number when the electronic invoice is submitted; The hash on-chain unit is configured to convert the identity code of the standard invoice feature into an identity hash value, generate a feature hash value, upload the feature hash value to a blockchain network, and store the feature hash value in a new block.

6. The electronic bill lifecycle management system based on artificial intelligence according to claim 4, characterized in that: The association data integration module further includes an association key establishment unit and a business feature extraction unit; The association key establishment unit is configured to traverse the standard invoice features in the database, establish an association key between the invoicer name and the ticket user name, and integrate the standard invoice features with the same association key into an association data set; The business feature extraction unit is configured to count the frequency feature of the association data set, calculate the device association feature, and take the frequency feature and the device association feature as the business features of the association data set.

Images